#bzr 2008-06-02
<lifeless> morning y'all
<Verterok> moin
<beuno> hey lifeless!  feeling better?
<lifeless> beuno: yes thanks
<spiv> poolie: that fix of mine just landed
 * igc out for a while - bbl
<poolie> spiv, great
<lifeless> abadger1999: ping
<lifeless> abadger1999: sorry
<lifeless> abentley: ping; I have a bundle confusion thing; I'm debugging but perhaps you've seen it in the past and can advise
<jml> spiv: which bug was that a fix for?
<jml> spiv: because my attention is being drawn to bug 236380 in Launchpad, and I wonder if they are perhaps related.
<jml> how can I get a list of changes to trunk filtered by whether they changed files in a particular directory?
<jml> bzr log --short foo/bar does *something*
<spiv> jml: I don't think my fix is related to that bug
<jml> spiv: ok. thanks.
<spiv> jml: I can reproduce 236380 with bzr.dev, btw
<poolie> hello jml
<jml> poolie: hi
 * markh waves
<markh> I'm looking through the API docs, but I can't see a way to do iter_changes or changes_from non-recursively - ie, if I pass a directory name, I do *not* want children checked.  Any clues?
<lifeless> I'm not sure we have that
<markh> eg, I'd like to know the dir has been "added", but I don't yet care about children
<markh> for tortoise, I'd obviously like to avoid doing a full tree status if a user happens to browse to the root of a large working tree.
<markh> I can see how to work around it for files - but it seems that to get the status of a single directory anywhere in a tree requiring me to do a full tree status update is going to kill in some cases.
<markh> at least '--no-recurse' is listed as a todo ;)
<brandon_rhodes> After numerous experiments (and learning to delete ~/.bazaar/subversion.conf after each one!), I have managed to make "bzr svn-import" import a project from my subversion repository (yay!)
<brandon_rhodes> But it's treating my tags as branches
<brandon_rhodes> Rather than giving the mainline trunk a list of actual tags that can be listed with "bzr tags"
<brandon_rhodes> Is there anything that can be done about that?
<brandon_rhodes> Or should I march boldly into the future without my old tags around as tags? :-)
<bob2> tag support is planned but not implemented yet, aiui
<brandon_rhodes> Roger.  I'm about to move a project to Launchpad and wanted to make sure I wasn't missing something first
<brandon_rhodes> Thanks.
* lifeless changed the topic of #bzr to: launchpad bazaar hosting is shutdown for urgent maintenance | Bazaar version control system | http://bazaar-vcs.org | bzr-1.5 is out! | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<pickscrape> What would I need to call in bzrlib to get a Tree of a branch at some given revision?
<jamesh> pickscrape: branch.repository.revision_tree(rev_id)
<pickscrape> Thanks. Could you point me at somewhere I could have looked that up myself?
<pickscrape> I've looked around for a 'bzrlib for plugin developers' doc but couldn't find one.
<lifeless> doc/developers/ has some stuff
<pickscrape> Thanks
<lifeless> sorry, doc/en/developers I think.
<poolie> hm there is a document aimed at just that
<poolie> pickscrape: http://bazaar-vcs.org/Integrating_with_Bazaar
<poolie> i'm sure there are things plugin developers might want to know that aren't answered there though
<poolie> so if you hit something please ask here or on the list
<pickscrape> poolie: thanks for that!
<pickscrape> It's a very rich API, which is great but a tad bewildering when you first look into it. :)
<poolie> yeah
<poolie> and it does change over time too
<poolie> but we are pretty friendly, do ask
<pickscrape> Yes, this is actually what's I'm doing (accounting for a removed method)
<poolie> it's the best way to guide documentation improvements too
<lifeless> yay 5 errors to go in bundle tests
<markh> It seems the bzr tests fail to remove the test directory when the test fails (Permission denied: unable to remove testing dir tmpfq3hof) - is that known?
<lifeless> markh: it is a bug indeed
<markh> any idea if its already reported?
<markh> save me searching :)
<lifeless> I know it has been discussed/partially fixed etc in the past
<markh> great, thanks
<markh> lifeless or poolie: any idea if adding a 'recursive' param to iter_changes and changes_from would be controversial?  ISTM it would have to be implemented in inventory.iter_entries_by_dir() and might not be that hard or deep.  Should I give it a shot, or discuss the requirement itself on the mailing list first?
<lifeless> markh: inventory.iter_changes* are largely deprecated
<lifeless> markh: look at workingtree_4.py's iter_changes
<lifeless> markh: and definitely discuss on the list; I mean - it seems to me you actually are looking at a single path rather than a dir?
<markh> lifeless: I'm not sure what the last part of that means.  The way TSVN works is that when a filename or directory name is requested, the status of all items in the parent are queried and cached.
<markh> but actually that doesn't seem relevant - even if we just fetch one item at a time, I don't want to recurse when the status of a directory is requested.
<lifeless> markh: to a large extent this depends on the definition of 'status' for a directory
<lifeless> markh: say you are putting an emblem on altered directories
<lifeless> should a directory with an altered child get an emblem ?
<markh> well, its more like "get the full status of a dir in the backgroumd, but the "immediate" status in the foreground"
<markh> we will manage the background part, but do need a way to say "give me the 'immediate' status of the folder itself, not of its children"
<markh> if we want to show *any* emblem before the full recursive status is calculated
<markh> which we do
<markh> (and the fact the status command has a comment indicating 'no recurse' is a todo item gave me hope the requirement itself is kinda 'obvious')
<lifeless> I am behind on a deadline due to being sick for a week
<markh> no worries - I hope you are better - thanks for the comments and I'll take it to the list
<lifeless> so can't really offer good interactive discussion on this; it certainly doesn't need to block on me - the pointer already given, to the fast-path iter_changes function should give you an idea of the code that you'd need to modify
<lifeless> nice:
<lifeless> time bzr log megarepo/pool/main/p/pyvorbis/
<lifeless> real    0m1.274s
<lifeless> user    0m0.150s
<lifeless> sys     0m0.050s
<lifeless> cold cache
<lifeless> real    0m0.178s
<lifeless> user    0m0.150s
<lifeless> sys     0m0.020s
<lifeless> hot cache
<pickscrape> lifeless: what's the context of those timings?
<lifeless> pickscrape: http://www.advogato.org/person/robertc/diary/83.html
<lifeless> robertc@manganese:~$ du -sh megarepo/.bzr/
<lifeless> 22G     megarepo/.bzr/
<lifeless> its a single repository with ~all of ubuntu
<poolie> pickscrape: for curiousity what are you working on?
<pickscrape> Ah yes, I did read that blog post. Very nice :)
<pickscrape> poolie: getting diffstat working again
<poolie> oh yay
<pickscrape> Probably a 5 minute job for someone well versed in bzrlib, but good learning material for me :)
<jml> I was just reminded how neat 'merge --uncommitted' is, so I blogged about it: http://mumak.net/2008/06/02/neat-bazaar-feature/
<poolie> jml, we should add you to planet bazaar hey?
<jml> poolie: oh yeah maybe
<poolie> pickscrape: that would be great to have
<poolie> actually it might be nice to have it builtin, at least if it just adds new options to diff, status, send, etc
<pickscrape> poolie: that's what I was hoping to do to it next
<pickscrape> I actually don't think it needs to add any new command at all
<poolie> great
<pickscrape> Do you know if Michael Ellerman (its origina author) is still around?
<poolie> i haven't seen him for a while
<pickscrape> It's not been touched since 2006, so I have the impression that it's basically unmaintained at this point.
<poolie> i think you're right
<pickscrape> That being the case I was thinking of hosting it on launchpad (once I've got it working), but I'm unsure of the etiquette with regard to picking up things like this.
<poolie> i think just go ahead and publish it
<poolie> after all he can always merge back if you want
<pickscrape> Yes
<pickscrape> ok, I'll do that.
<poolie> markh: i think that 'permission denied' might be windows-specific?
<poolie> does it happen with all failing tests?
<markh> yes, I've no doubt its windows specific, and best I can tell, all tests
<poolie> could you maybe put a breakpoint at the place it is raised so we can work out what specifically is going wrong?
<markh> actually, not all tests now it has finished :)  No transport tests
<markh> ok, I'll see how I go
<markh> likely to be a handle to that dir is open, so the trick might be finding it.  I'll see what I can find.
<poolie> i think that would be it
<beuno> mwhudson, around?  I have good news  :)
<poolie> beuno: he has a public holiday toda, but you can tell me :)
<beuno> poolie, well, let me get you the URL.  I got Loggerhear to *not* request all diffs for each revision, and you can request each diff via ajax, cutting by 4 the time/memory needed for each diff  :)
<poolie> nice
<beuno> so, with the new templating system, and diffs being cheaper, it should be feasable to run it without it explodind a dozen times a day   :)
<beuno> s/explodind/exploding
<beuno> I still think we should throw away the current code  :)
 * mwhudson is here but worrying about loggerhead definitely seems like work
<beuno> mwhudson, :)
<poolie> beuno: ok with me, as long as you agree with mwhudson and other folks that it's the best thing to do
<beuno> let me try and get this port open so you can peak
<poolie> and what specifically to do instead
<poolie> and hopefully it'll be something that's both easy for users to deploy and works in well as part of lp
<poolie> hello keir
<keir> hey martin
<mwhudson> tbh, the main concern i have with beuno's ideas is the requiring javascript stuff
<keir> so i guess launchpad bzr is down :(
<keir> i was here to ask about that
<mwhudson> keir: will be back very soon
<poolie> keir, yes, jml is working on it, should be back soon
<keir> cool
<keir> i was thinking i was doing something wrong :)
<mwhudson> i think a gmail-for-bzr could be really really cool though :)
<keir> woot! did i hear gmail+bzr?
<poolie> well, i think we need to have some kind of reasonable fallback if they don't have js (enabled)
<poolie> i think he meant gmail-style interface
<mwhudson> yes
<beuno> mwhudson, http://intranet.pentacorp.net:8080/bazaar/bzr_dev/revision/pqm%40pqm.ubuntu.com-20080530010236-e3x7ckdc25s57pgc?start_revid=pqm%40pqm.ubuntu.com-20080530010236-e3x7ckdc25s57pgc
<beuno> mwhudson, well, the way I'm doing things now, we can fall back to an html-only version pretty easily
<mwhudson> beuno: seems to work
<mwhudson> some kind of progress report would be a good idea
<beuno> I haven't done extensive benchmarking, but a 8k diff uses very little memory, and, even more important, now, it's optional  :)
<mwhudson> (maybe just a spinning gif)
<beuno> mwhudson, right, there are *tons* of improvements to do on top of that
<beuno> because of the way loggerhead works, it's getting the diff for those files anyway, I'm just not parsing them
<poolie> beuno: sweet
<beuno> :)
<poolie> is that tested at all?
<poolie> we should think about that too
<poolie> and when i say 'we' i mean 'you' :-) :-)
<beuno> poolie, test what, sorry?
<poolie> well
<poolie> actually i don't know if it has any automatic tests at present
<poolie> but it would be nice to get some
<poolie> including that the js works as expected
<mwhudson> loggerhead has some _very_ basic tests currently
<beuno> mwhudson, I haven't figured out how to run them  :)
<mwhudson> beuno: nosetests
<mwhudson> or py.test
<beuno> mwhudson, I'll take a look at that (we should document that :p)
<jml> poolie: the corporate 'we' :)
* lifeless changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.5 is out! | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<beuno> cool, tests kinda of work!
<beuno> mwhudson, so, getting diffs individually seem to be *way* cheaper
<mwhudson> beuno: interesting
<mwhudson> i think it's all in the rendering probably
<beuno> I'm using the zpt branch
<mwhudson> oh cool
<mwhudson> you got that working in the end?
<beuno> so, it we combine zpt + not rendering everything + individual diffs, it should be a big improvement peformance-wise
<beuno> yeap
<beuno> I pulled your branch, and tweaked a little
<beuno> I'm going to add a progress while it's fetching the diff
<beuno> and then update the branch to use the new methods (it still has the deprecated ones)
<beuno> clean up, and push
<beuno> and the font seems to be smaller for some add reason. Css is ignoring me today
<beuno> s/add/odd
<beuno> poolie, I'm not sure how we can test javascript. Especially since each browser renders it differently
<beuno> I am using a very popular js library, so it's almost guaranteed to work on all popular browsers
<mwhudson> 'selenium' is one answer
<markh> poolie: I noticed my debugger changes the behaviour, which made me think "gc" - and sure enough, a gc.collect() before the osutils.rmtree(dirname) in tests._rmtree_temp_dir() seems to solve the problem.  Apart from the problem that a number of tests are still failing ;)
<beuno> mwhudson, looks good, I'll look into it
<beuno> and stop bothering you on a holiday  :)
<jml> some of the JS could be unittested with spidermonkey & integrated into the main suite using subunit.
<jml> but I don't think very much could.
<abentley> lifeless: pong
<lifeless> abentley: I mailed the list
<lifeless> abentley: I think there is a conceptual bug in the mpdiff interface/output
<abentley> lifeless: I believe the bundle specifies what the parents are, but I can double-check that.
<lifeless> abentley: even if it does I think that the lower level api will break because each individual text can have hit different orderings or different ghost texts
<abentley> The orderings used are the orderings specified in the bundle.
<beuno> mwhudson, loader added: http://intranet.pentacorp.net:8080/bazaar/bzr_dev/revision/pqm%40pqm.ubuntu.com-20080530010236-e3x7ckdc25s57pgc?start_revid=pqm%40pqm.ubuntu.com-20080530010236-e3x7ckdc25s57pgc
<mwhudson> beuno: sweet
<mwhudson> a 'view all' might be appropriate i guess
<beuno> mwhudson, yeah, I'm not putting too much work into the interface considering I'm going to be implementing the new theme next week
<lifeless> abentley: looking at mpdiffs, I just don't see were the text parent ids are grabbed - the diffs list contains MultiParent.from_lines output only
<beuno> mwhudson, I have to do major code cleanup now, and change the way loggerhead builds that page, so it doesn't still internally get the diffs and discard them
<abentley> mpdiffs don't list the parents.  The bundles list the parents.
<mwhudson> beuno: fair enough
<beuno> and, well, tests and such would be nice
<abentley> lifeless: The metadata entries for a record include a "parents" entry, and this is what should be used when applying the mpdiff.
<lifeless> yay only reconcile to go
<lifeless> abentley: I'm concerned about a mismatch between the actual used parents in the knit and that record
<lifeless> concretely, looking at add_mp_records, ghosts will be present in the record
<lifeless> but ghosts are filtered out of the diff generation
<abentley> Where are they filtered out?
<lifeless> bzrlib/versionedfile.py line 266
<lifeless> parents = [lines[p] for p in parent_map[version_id] if p in knit_versions]
<abentley> lifeless: I think I agree.  Whatever parents were used to generate the mpdiff should match the parents in the metadata.
<jml> beuno: btw, your branch should be working now.
<beuno> jml, ah, let's see....
<beuno> jml, the problem was with all knit branches?
<jml> beuno: not all. just many.
<jml> beuno: anything that needed to write an escaped path to disk.
<beuno> jml, works perfect, thanks
<jml> beuno: my pleasure.
<mwhudson> does upgrade work over bzr+ssh yet?
<lifeless> no
<beuno> mwhudson, bzr branch lp:~beuno/loggerhead/zpt.ajax
<beuno> and I'm off to bed
<beuno> it still needs cleaning up, and a lot of work to do on top of it, so I'll keep working on that branch from now on
<beuno> I replaced the deprecated methods, and updated the templates with the latest from your branch
<poolie> ok i'm preparing a beta...
<Frank_Heinen> Hi, can someone help me with a problem I got with a branch. I accidentally removed a file manually. Now I'd like to get the latest version of the branch again without checking out again, is this possible (getting back to the original branch again)? bzr update doesn't work, it mentions it is allready up to date.
<Peng> Frank_Heinen: What? Do you want bzr revert?
<tca> Is http://pastebin.org/39994 a safe workaround for https://bugs.launchpad.net/bzr/+bug/235055 ?
<ubottu> Launchpad bug 235055 in bzr "bzr log fails with KeyError in graph.get_parent_map" [Undecided,Confirmed]
<poolie> hi tca
<tca> hello
<TFKyle> tca: might want to do the graph.get_parent_map call outside of the try block so you couldn't get any exceptions from it, but probably isn't needed
<poolie> tca, i _think_ so
<poolie> tca, could you send it to bazaar@lists.canonical.com quoting that bug number?
<poolie> it does look like this is the case that comment was looking for
<poolie> it may be something unusal in the history coming from arch
 * tca subscribing to the list
<tca> Yes, I think lots of weird stuff happened in arch ;-)
<awilkins> Frank_Heinen: bzr revert <my_file>
<Frank_Heinen> Peng: Awilkins: tanks, lets try.
<Frank_Heinen> Peng: Alwilkuns: It works! :-) Stupid that I didn't see this....
<jrydberg> lifeless: ping?
<poolie> jrydberg: he's feeling tired, probably won't be back for 12h
<poolie> ie tomorrow morning
<jrydberg> i see.
<jrydberg> thanks!
<jdub> hey duderinos
<jdub> what are the chances of having bzr-svn in the bzr ppa?
<jdub> i can't follow bzr easily without it :|
<mwhudson> bzr get lp:bzr-svn ~/.bazaar/plugins/svn
<mwhudson> releases are for weenies :)
<awilkins> Anyone here working on the xmlrpc server?
<semslie> hi. I'm in a situation where I've updated, which has converted some commits to a pending merge. I'd prefer to go back and rebase now. Is it possible for me to convert those commits involved with the pending merge back into commits and basically rollback to before the update?
<james_w> semslie: I'm not sure of a way to get back to what you had before, I can talk you through getting back to an equivalent.
<james_w> semslie: I'm not sure if "bzr revert" will do what you want though, I think it may do the opposite of what you want, so I'm wary of telling you to try it.
<semslie> james_w: fortunately I've got a backup
<luks> I'd unbind the checkout, commit the pending merges, then lookup the revid of the merged revision and branch of that
<semslie> luks: thanks, I'll give that a try
<james_w> luks: exactly
<luks> after that you should have the branch you had before and you can use rebase on those revisions
<james_w> though "pull --overwrite" instead of "branch" will save you a temporary branch.
<james_w> and I was wrong before, that will get you back to what you had.
<luks> I just don't like destructive operations
<luks> having two branches feels safer to me
<semslie> james_w: when you say you were wrong before, do you mean that "bzr revert" wont delete the pending merge, but rather get me back to where I was before the commit?
<luks> no, revert will get rid of your local commits
<luks> they are still in the repository, but not so easy to look up
<semslie> luks: right, I'll avoid that then
<james_w> semslie: no, I meant that I was wrong when I said that I wasn't sure whether I could get you back to what you had before. I was going to suggest luks' method, but that will get you back to what you had before.
<semslie> okay, I'll try that
<semslie> ftr I'm merging a fairly complicated branch back into a subversion rep that I've diverged from. It now makes sense that update did what it did, but I think what I was looking for was rebase
<semslie> rebasing seems to have worked nicely. nearly there now. Thanks for the advise!
<abentley> lifeless: I don't think the mpdiff ghotst bug is a conceptual bug.  It's just a bug bug.
<visik7> can I commit a filechange on a revision ?
<bob2> you only want to commit the changes made to a paricular file?
<visik7> the problem is that I've a working copy at a revision xy and the deploied app to a revision older
<visik7> now I want to submit some modification to the deploied app
<visik7> maybe I need to branch and revert
<vila> visik7: may you need two branches
<vila> be even
<visik7> another question
<visik7> I've a shared repo
<visik7> at the beginning I've commited on it a lot of files
<visik7> now I deleted those files from the working tree
<visik7> and I don't want them anymore
<visik7> but the shared repo still has it
<visik7> has them
<visik7> I can't find any command on how to manage a shared repo
<bob2> that is unrelated to using a shared repository or not - bzr doesn't currently have an (easy) way to purge things from history
<visik7> but it's 1gb of useless data
<visik7> :(
<visik7> and a way to purge a repo from a revision to the beginning ? I mean I've the problem at revision 7
<visik7> a way to remove from 1 to 7
<andrea-bs> I don't know if this is the best way, but you can make an another branch, "bzr revert -r1" the original branch, copy all needed files to the new branch and commit, "bzr revert -r 2", copy and commit, ...
<awilkins> visik7: Export r 8 ; initialize it, then merge revisions 9.. with it
<visik7> my current revision is at 37
<visik7> it's ok to do it ?
<mtaylor> visik7: try bzr pack
<visik7> they are png
<Pieter> Hmm, creating a bidirectional git-bzr thing should be really easy
<Pieter> I might even try it someday
<jelmer> Pieter, there already is something like that
<jelmer> Pieter, http://launchpad.net/bzr-git
<Pieter> but that won't write to git, right?
<jelmer> Pieter, not yet, no
<jelmer> Pieter, or is what you're intending to do different from a bzr plugin?
<Pieter> I was thinking about using fast-import/export
<Pieter> You'd just need to extend git-fast-export and bzr fast-import to import/export marks files
<Pieter> and then you can go both ways incrementally
<dato> I'm planning to add incremental support to bzr-fast-export
<dato> it already exports a marks file
<Pieter> bzr-fast-export already has a --import-marks thing
<jelmer> Pieter, that won't work because you'd break referential integrity
<dato> Pieter: I know, I wrote it :)
<Pieter> jelmer: you'll have to maintain the marks files, then it should be ok
<dato> (though I'm not planning in bidirectional, no)
<dato> (just incremental bzr -> git)
<Pieter> that already works
<semslie> I'm constantly getting an AssertonError when pushing from a rebased bzr branch to a subversion repository: assert self._new_revision_id is None or self._new_revision_id == revid
<semslie> has anyone else had experience with this?
<Jc2k> semslie: do you mean you pushed once, rebased and pushed again>
<semslie> Jc2k: no, but after I branched the subversion branch diverged from the bzr one. Rather than merge and loose my changelog in a single subversion commit, I rebased off the new subversion head and tried to svn-push
<semslie> interestingly, the commit that should have been last (at the bzr head) was the only one that got committed to svn before it crashed
<semslie> I wonder if it has somehow gotten turned around?
<jelmer> semslie, hi
<jelmer> semslie, there is an open bug report about this
<semslie> jelmer: thanks. I'll take a look in launchpad
<semslie> jelmer: is that a bug against bzr or bzr-svn?
<jelmer> semslie, bzr-svn
<semslie> thanks
<PeakerWork> hey, I used "bzr commit --local" when I had some connectivity problems, then I used "bzr commit" and it failed cause it is out of date. So I used "bzr update" (when I have some local changes) and it gave me a bazillion merge conflicts! Nothing needs merging, only I have changes, the remote tree was untouched the whole time
<PeakerWork> why is that?
<PeakerWork> I removed all the .THIS/.OTHER files (I took the .OTHER.moved files) and now I have lots of "Conflict adding file raytrace/Plane.hs.BASE.  Moved existing file to raytrace/Plane.hs.BASE.moved." conflict messages and I can't get rid of them
<PeakerWork> is this a bug or did I do something wrong?
<PeakerWork> Its pretty terrible :(   only revert worked to get rid of the conflicts so I manually re-applied the ~1~ backup files, and all directory tree changes had to be manually re-done..
<james_w> PeakerWork: hi, it sounds like the file ids ended up different between the remote and local branches.
<PeakerWork> I think it happened to me before -- whenever I commit --local, later updates are trouble
<james_w> if nothing happened on the remote side what did you do locally? was it just edit and commit, or did you add and remove any files?
<PeakerWork> does bzr have tests for "commit --local" followed by updates?
<PeakerWork> I renamed/moved some files, I don't think I added/removed anything
<Keybuk> I'm clearly missing something, because one of my most common "other branch" operations is damned hard to do with bzr
<james_w> it does have tests, yes
<james_w> PeakerWork: it may be the renames then, did you use "bzr mv"?
<Keybuk> the operation is "what changed in this branch when compared to the mainline?"
<PeakerWork> james_w, I think I consistently get merge conflicts for all modifications made with --local when I try to update later
<PeakerWork> james_w, Yeah I did
<james_w> Keybuk: hi. what changed as in diff, or revisions?
<Keybuk> james_w: diff
<james_w> Keybuk: "bzr diff -r ancestor:submit:" might be what you are looking for
<james_w> or it may give you something completely different.
<Keybuk> bzr: ERROR: Not a branch: "/home/scott/tmp/sadmac/submit:/".
<james_w> oh wow
<james_w> does "bzr diff -r submit: work?
<LarstiQ> or bzr diff --new path/to/branch
<Keybuk> james_w: nope, it uses a totally random path
<Keybuk> (also this appears to be require me to checkout the branch I want to look at ... which sucks)
<Keybuk> if I'm in my upstart branch
<Keybuk> and somebody gives me the URL to their branch of changes
<Keybuk> which is branched off my upstart branch, though probably an earlier revision
<Keybuk> what's the recipe for that?
<LarstiQ> bzr diff --new http://bazaar-vcs.org/bzr/bzr.dev
<LarstiQ> works for me?
<james_w> hi LarstiQ
<LarstiQ> I can imagine cases where that is not the most readable diff.
<Keybuk> LarstiQ: shows the reversal of changes in local branch ?
<LarstiQ> Keybuk: diffs the other branch with the current one, you can also do --old
<LarstiQ> that's just for left and right
<james_w> Keybuk: there's another possibility, "bzr merge --preview URI"
<Keybuk> LarstiQ: which isn't what I want ... I want to see what _they_ changed
<Keybuk> not what I changed since
<Keybuk> james_w: has random side-effects like setting the submit branch
<LarstiQ> Keybuk: aha
<Keybuk> aha!
<Keybuk> james_w: you were onto the right idea originally
<Keybuk> bzr diff -r ancestor:. OTHER_BRANCH
<Keybuk> :p
<LarstiQ> if you are in their branch that is?
<james_w> Keybuk: yeah, it should definitely be something that is possible. I think that "merge --preview" would be the suggested way to ask what they changed, but I'm not sure what to do about the submit branch thing.
<Keybuk> also merge --preview doesn't work with difftools, so I can't use meld to see it ;)
<james_w> if you haven't got a submit branch set then that may be why "-r submit:" didn't work.
<Keybuk> it's not me who needs to set that, no? :p
<LarstiQ> james_w: hey :)
<Keybuk> it's if _they_ haven't got a submit branch? :P
<james_w> you did ask for your differences to the mainline first though, which I think is a "diff -r ancestor:" operation.
<james_w> Keybuk: maybe you would like to post to the list so that we can get some discussion on this, it should definitely be something that is easy to do.
<PeakerWork> james_w, does it sound like a bug though?
<Keybuk> what's the address?
<james_w> Keybuk: bazaar@lists.canonical.com
<james_w> PeakerWork: it does sound like one, though there may have been something that I missed.
<james_w> PeakerWork: is it a public project?
<james_w> PeakerWork: or better yet, can you isolate a test case on a couple of dummy branches?
<PeakerWork> james_w, I'll try that at home yeah
<james_w> PeakerWork: thanks. You can file a bug either way, but a simple test case will probably get it looked at far quicker.
<schierbeck> abentley: hey dude
<abentley> schierbeck: Hey there.
<schierbeck> abentley: it's nice to see the branch review functionality coming to lp -- do you have any idea when it will match the functionality of bundle buggy?
<schierbeck> i'm thinking of starting to use it in bzr-gtk
<abentley> schierbeck: They're never going to have the same feature set.
<Keybuk> Your mail to 'bazaar' with the subject
<Keybuk>     Two things that bzr makes hard :-(
<Keybuk> Is being held until the list moderator can review it for approval.
<Keybuk> :-(
<Keybuk> FAIL
<pickscrape> It's because you're not subscribed I think.
<schierbeck> abentley: in what way do you mean? i'm thinking: when will it allow users of bundle buggy to switch to lp without changing workflow
<schierbeck> i.e. reviewing over email must be supported
<abentley> schierbeck: I don't know.  What's important to you?
<schierbeck> abentley: i know jelmer must have email support if he's to switch over -- personally, i only really need better integration with the code browser
<schierbeck> so i can see a full diff
<abentley> Email integration is what I'm working on right now.
<abentley> I'm not sure when we'll add the ability to view a diff.
<jelmer> schierbeck, abentley: Voting support is another thing I think launchpads merge request integration doesn't have atm
<schierbeck> jelmer, abentley: as far as i know it's just been introduced
<jelmer> schierbeck: Also, is there any reason to switch to launchpad from bundlebuggy once these things have been resolved in launchpad?
<abentley> jelmer: No, it has voting.
<jelmer> schierbeck, I prefer using free over non-free software when possible
<schierbeck> jelmer: that's true, but if we disregard that very valid point, having the bugs, branches and review proposals in one place offers a very real benefit, at least for me
<schierbeck> i feel it would be a good idea to start linking bug reports to hosted branches, and using lp to request code reviews would mean that i would have one single location from which i could view the status of my work
<jelmer> The linking between bug reports and hosted branches should already be happening if you use --fixes
<abentley> schierbeck: So, that requires actually having branches.  BB doesn't require that, which gives you a lower barrier to entry.
<schierbeck> abentley: that's true, but support for patches/bundles in lp merge proposals would be possible
<abentley> That's true.  What's actually been proposed is that you could use a bundle to create a branch.
<semslie> jelmer: I've dug around a bit and it seems like the first revision to be pushed is off by one. So todo in branch.py line 360 is missing the first revision that needs to be pushed. Not sure if this helps, but I am rebasing before I push
<schierbeck> abentley: that would be cool too, but i think the best solution would be to allow uploading bundles when making a merge proposal
<abentley> schierbeck: Well, supporting bundles as first-class objects rather than just a way of getting branches isn't on the radar, so please file a bug to help put it there.
<schierbeck> abentley: sure
<schierbeck> abentley: but would it technically be the same, if the internal representation is in fact a branch
<schierbeck> it would just be anonymous to the lp user
<abentley> I don't know what you mean by "anonymous to the lp user".
<schierbeck> abentley: i mean that all they see is a file chooser dialog, they don't need to first create the branch from a bundle, then point to it from the merge proposal
<schierbeck> many changes are small, and figuring out a unique name for it is perhaps overkill
<abentley> schierbeck: So you're saying accepting a bundle should create a branch without a name?
<schierbeck> abentley: yeah, if done from the merge proposal form
<abentley> I highly doubt that will fly.
<schierbeck> the internal name could correspond to the merge proposal id
<schierbeck> abentley: why wouldn't it?
<abentley> If a branch doesn't have a name, it's hard to access it.
<schierbeck> abentley: since they'd be read-only, they could be exposed through the review interface
<schierbeck> i'm not familiar with the url scheme, but something like /merge-proposals/<id>/branch
<abentley> Concretely, you're not going to be able to get a diff of a branch that doesn't have a name through the code browser.
<abentley> Because you won't be able to construct a URL for that.
<jelmer> abentley, I'm trying to track down an error in bundlebuggy
<jelmer> "freeze" for emails is used to store them somewhere else for reprocessing?
<jelmer> one of the emails is raising UnicodeDecodeError and that is causing bundlebuggy to reprocess it over and over again
<jelmer> since UnicodeDecodeError isn't handled in MailQueue.handle()
<abentley> freeze is used for emails that have permanent failures.
<abentley> While UnicodeDecodeError is permanent, it shouldn't be happening at all.
<jelmer> I've  made it print a traceback next time this happens
<nevans> has anyone ever had a problem committing to a bound branch, even though unbinding, committing, and pushing works just fine?
<jelmer> nevans, what sort of problems?
<nevans> FWIW, I have this problems with a couple of subversion branches (using bzr-svn 0.4.9)
<nevans> commit tells me to update and try again, and update tells me that I'm up to date
<semslie> jelmer: hi again. I've got an idea why I might be seeing #230863 (AssertionError on push -r x)
<jelmer> semslie, ok
<jelmer> semslie, what do you think is causing it?
<semslie> jelmer: it looks like it is following the branch when choosing the next revision id, but there are revisions in the repository that are newer than in the branch, so we are choosing something that collides with something elsewhere in the repository.
<jelmer> semslie: any chance you can write up a script that reproduces this?
<jelmer> that would be a huge help
<jelmer> and would be useful to make sure this doesn't regress
<jelmer> oncewe fix it
<semslie> jelmer: sure
<jelmer> nevans, what does "bzr missing" say?
<nevans> I'll try to reproduce it... I've got everything committed now.  ;-)
<jelmer> nevans, thanks
<abentley> jelmer: You should already have a traceback in the message it sends you.
<jelmer> ah, I didn't actually bother to look at those
<jelmer> abentley, http://pastebin.ubuntu.com/16447/
<abentley> Well, that's cute.
<abentley> The message claims to be utf-8, but ain't?
<abentley> Well, for this purpose, 'replace' should be fine.
<antoranz> Hi, Guys!
<semslie> jelmer: a friend and I have started a test script, and confirmed that when the head revision is on the target branch then a the push is successful
<jelmer> semslie: can you attach that script to the bug report?
<semslie> jelmer: sure, as soon as its finished I'll do that
<semslie> jelmer: adding  something to the target branch fixed the problem in practice, but we are finding that creating a new repository, then making some revisions such that the last revision is not to the target branch is not producing the error on our script. I'll post it if I can get it to reproduce the problem
<jelmer> semslie, ah, ok - thanks
<jelmer> beuno, bundlebuggy is up again
<beuno> jelmer, you rock  :)
<jam> jelmer: so why have you decided to switch from pyrex back into plain 'C' wrappers, and why not just use the latest svn-1.5 bindings?
<jam> Just curious on your rationale
 * fullermd has given up believing that svn 1.5 exists.
<dato> can I expect the listing in TreeDelta.renamed to be comprehensive on directory renames?
<dato> hm
<jam> dato: define "comprehensive"
<jam> I believe it just lists the directories
<jam> not their children
<jam> unless they have *also* been renamed underneath
<dato> well, I'm confused, because in one bzr-export-case, I get both 'dir1 -> dir2', and then a full list of their children
<dato> I get
<dato>  dir1 -> dir2
<dato>  dir1/fileA -> dir2/fileA
<dato> etc
<jam> dato: I don't really know what your 'bzr-export-case' is, but generally you don't get that
<jam> I'm not sure how you could
<dato> let me see if I can reproduce from a python prompt
<jam> I need to clean out my spam folder more often.... 15.3k spam messages
<dato> ah, you are right jam
<dato> i was just blind; fileA gets renamed too
<jam> what do you mean 'gets renamed too', shows up in the TreeDelta.renamed? Or just that it was physically moved?
<dato> yes, that it was dir1/fileA -> dir2/fileB
<dato> and dir1 -> dir2
<jam> right, *that* will show up
<jam> because we check if the 'parent' or the 'name' has changed
<dato> now I'm not sure how to make git-fast-import happy about this
<jam> dato: yeah, because IIRC it *doesn't* handle directory renames
<jam> so, I think you have to iterate the children and give them new homes
<jam> if kind == 'directory': iterate_children
<jam> something like that
<pygi> poolie, around? :)
<dato> jam: no, I think it handles them just fine, except this degenerate case in which fileA is the only file in dir1
<jam> pygi: poolie is sleeping for a little while longer
<pygi> jam, oki ^_^
<jam> I think he'll be around in maybe 2hrs or so
<jam> can I help?
<dato> jam: so if I rename the directory first, the file rename fails; and if I rename the file first, the dir rename fails because the dir is empty so it does not exist for git
<pygi> jam, lemme pm you :)
<jam> dato: so do you need to track that the directory was renamed, and then rename the new location?
<dato> I guess
<jam> that's... crummy
<jam> "I caught you naked bazaar-commits-owner"
<jam> uh-oh, what has poolie been doing
<jam> At least it is obviously spam when it comes through the bazaar mailing list owner like that
<fdv> jelmer: you mentioned something a few days ago about some memory leaks in the python-subversion bindings being fixed. If I recall correctly, this was not ported fully to hardy, but fixed someplace else. I'm not sure which packages are actually fixed (or having problems), is this something that's available anywhere?
<Jc2k> fdv: subversion 1.5 has the fixes
<fdv> Jc2k:
<fdv> whoops
<fdv> Jc2k: they're nowhere else?
<Jc2k> afaik that means you have some compiling to do :)
<fdv> well, compiling is no problem
<Jc2k> 1.5 hit rc8
<Jc2k> afaik that is their gold release
<Jc2k> if all goes well
<fdv> one can always hope
<fdv> then maybe I won't care so much for the python bindings anymore
<fdv> svnmerge is very cumbersome, and being able to use a bazaar mirror would likely be progress
<fdv> but when I try to import the repo, memory is soon exhausted
<fdv> so basically, I need a bzr mirror while waiting for decent functionality in svn 1.5, but now I also need svn 1.5 to get a bzr mirror working :p
<Jc2k> fdv: pretty much ;D
<Jc2k> fdv: your branch much be special in some way...
<fdv> maybe
<Jc2k> i converted 20gb worth of SVN without breaking the hardy python-subversion, 200 modules. A few weighed around 2gb
<fdv> it's rather big, with lots of history (also from aeons of CVS) and I think they've omitted some conventions
<fdv> hm
<Jc2k> how many revisions?
<Jc2k> evolution had about 23,000
<fdv> ~150k
<Jc2k> yeah, that would explain it
<fdv> but I think that's only the svn revs
<Jc2k> :P
<Jc2k> evo only had 23,000 svn revs but still took 2gb of space on disk - maybe binary data?
<Jc2k> fdv: are there lots of branches?
<fdv> probably
<fdv> yep
<fdv> plenty :p
<Jc2k> bugger :)
<fdv> yep :)
<Jc2k> do you need them all :D
<fdv> the svn-import doesn't rise above 0/n
<fdv> well, not at all
<fdv> I only need trunk
<Jc2k> when i did the initial GNOME mirror i only mirrored trunk of each module
<fdv> but afaics, svn-import won't work with branches
<Jc2k> and then used svn-import to top them up
<fdv> how'd that work?
<Jc2k> http://live.gnome.org/JohnCarr/Bazaar
<Jc2k> that script creates a repository called $MODULE and then branches trunk of the SVN repo into $MODULE/trunk
<Jc2k> it used bzr pull to fetch 1000 revs at a time, dodging the leaking
<fdv> ah :)
<fdv> neat trick
<Jc2k> then when i'd done, i discovered svn-import
<Jc2k> :p
<Jc2k> so ran that on my mirror of trunk and it figured out what i was missing and started topping stuff up
<Jc2k> it was pretty good about recovering from errors, too
<fdv> but that requires the whole repo, right?
<fdv> I'm not sure I have understood this completely
<sabdfl> poolie: 1.6rc1 today?
<Jc2k> fdv: so svn-import works out what the branches are and then makes a bzr repository dir with multiple branch dirs
<Jc2k> fdv: my bash script does that too, but only for trunk rather than all the branches
<fdv> right
<Jc2k> fdv: you could pull the import branches by hand...
<fdv> I'll certainly give it a shot
<fdv> well, they're not interesting, really
<Jc2k> *important branches, even
<fdv> I just want a non-central repo I can commit to frequently
<fdv> :)
<Jc2k> fdv: the page i linked to also has my python script for updating the mirror on svn commit
<Jc2k> though its a tad specific to the GNOME svn-commits mailing list
<fdv> I saw it, looks neat :)
<fdv> well, that could probably be tweaked, I guess
<beuno> jelmer, btw, BB still won't let me vote via email, just through the web interface. I don't mind at all, but if you happen to trip over the DB and see something funny...  :)
<jam> sabdfl: 1.6beta1 was today, 1.6rc1 is this Fri
<jam> Jc2k: well, starting with your script might be a good start, depending on if 'svn-import' is smart enough to work in 1k revision batches like yours is
<Jc2k> jam: it doesn't, i know from locking up my server ;D
<pickscrape> Is there any chance someone well versed in bzrlib could give me some feedback on the diffstat patch I posted to the mailing list?
<pickscrape> Since it's my first work using bzrlib I'm uncertain as to whether I've made any monumental screwups or not. :)
<jam> pickscrape: this is the 'make it work with 1.5' ?
<pickscrape> jam: yes
<jam> pickscrape: giving you feedback on the list
<pickscrape> jam: thanks
<jam> pickscrape: basic summary, lock your objects, and reuse them as much as possible
<jam> I sent a modified form to the list
<jam> I think its right, but you should certainly test it to make sure
<pickscrape> jam: thanks for that, much appreciated :)
<poolie> sabdfl: no 1.6rc1 is for friday, beta1 was monday
<jam> hi poolie, we on for a call in 10min or so?
<fdv> Jc2k: the last pull in the script, from FINAL_REP, what's the exact purpose of that?
<jelmer> beuno: I'll have a look at it next time I deal with bundlebuggy
<fdv> is it so that the bzr repo there is set to "point" to the central svn repo?
<Jc2k> fdv: in my case i was converting a local rsync'd copy of svn.gnome.org
<pickscrape> jam: some very useful pointers there: thanks. I didn't actually know about locking at all.
<Jc2k> so the FINAL_REP just points it at the http://svn.gnome.org/ instead of my local rsync'd copy
<jam> pickscrape: a lot of api's do it 'automagically' for you, but if you hold the lock, you get more caching
<pickscrape> The method of parsing diff output is how the inherited code did it (__diff was also inherited), but these are things I could look at next.
<fdv> right, then I got i correctly (I think) :)
<jam> especially helpful for multiple 'as_revision_id()' lookups
<jam> etc
<fdv> Jc2k: thanks!
<pickscrape> The first priority was to just get it working with the current version of bzr :)
<beuno> jelmer, I keep getting emails telling me I'm not allowed to vote. It must be processing my votes through the web interface. Anyway, don't worry about it, just thought I'd mention it
<lifeless> abentley: agreed; I hadn't fully got the layerings straight in my head
<timelyx> hrm
<timelyx> is "versionedfiles" a technical term?
<lifeless> timelyx: bzrlib.versionedfile is a module in the bzr code base
<lifeless> timelyx: versionedfiles is an upgraded api I am working on
<timelyx> ok, and it's spelled in lowercase?
<timelyx> would it be wrong for me to stick it in ``ticks`` ?
<lifeless> timelyx: context?
<timelyx>     * New annotate merge (--merge-type=weave) implementation is fast on
<timelyx> -     versionedfiles withough cached annotations, e.g. pack-0.92.
<timelyx> +     versionedfiles without cached annotations, e.g. pack-0.92.
<timelyx>       (Aaron Bentley)
<lifeless> ah, that is versionedfile pluralised
<timelyx> grr
<timelyx> that's just wrong then
<timelyx> can i do ``versionedfile``s?
<timelyx> or /something/
<timelyx> because your thing really makes what was written there amazingly ambiguous
<timelyx> or just plain wrong, your choice :)
<lifeless> I'm looking for a better name
<timelyx> yeah, i saw
<lifeless> I wouldn't go change all the existing things just yet :P
<timelyx> anyway... suggestions? versionedfile's ?
<timelyx> i'm fixing spelling, as you can see, that line's going to change either way
<lifeless> versionedfiles is appropriate plural of versionedfile. versionedfile's would indicate ownership
<timelyx> yeah, but people write url's and stuff
<lifeless> they are wrong
<timelyx> it's not right, but it is common :/
<timelyx> rather, it isn't right :(
 * timelyx cries
<timelyx> anyway, would ''versionedfile''s be bad?
<timelyx> or however that magic markup workls
<lifeless> I think it is fine as it is, given the context and detail present
<timelyx> ok
<timelyx>      * Add scenarios as a public attribute on the TestAdapter classes to allow
<timelyx>        modification of the generated scenarios before adaption and easier
<timelyx>        testing. (Robert Collins)
<timelyx> +XXX this doesn't make sense
<timelyx> "adaption" is generally not considered much of a word
<lifeless> if you wish to refer to the class name more precisely it is ``bzrlib.versionedfile.VersionedFile``, and I would probably phrase it as 'on $above implementations' rather than using the plural ABC. But its not a problem as it is :)
<timelyx> the tail of that "sentence" doesn't work (before X and easier Y)
<lifeless> to allow (modification of the generated scenarions before adaption) and (easier testing)
<lifeless> AFAIK its ok english
<lifeless> also
<lifeless> http://dictionary.reference.com/search?q=adaption
<timelyx> yeah, i know... it's just that things like: http://www.merriam-webster.com/dictionary/adaption
<timelyx> basically say "not common, use X"
<lifeless> it would be a boring world if we only used the most common ways to say something
<Marco> Hello
<Marco> I'm doing bzr up on a branch I checked out from a launchpad project
<Marco> and it insists that it's up to date at revision 332 even though the most recent revision is 335
<lifeless> Marco: bzr info
<lifeless> Marco: if it does not say 'checkout of' then you made a new branch (e.g. bzr branch) rather than a checkout (e.g. bzr checkout)
<Marco> is there a way to "convert" a new branch into a checkout?
<Marco> I haven't made any changes
<thumper> if someone was looking to switch from CVS to Bazaar, what is the currently accepted "best converstion tool"?
<lifeless> Marco: you can convert it to a checkout with 'bzr reconfigure  --checkout'
<timelyx> lifeless: if i reordered it as to allow easier testing and modification...
<timelyx> would you object?
<lifeless> timelyx: generally I think we shouldn't alter NEWS that has been issued
<timelyx> ok
#bzr 2008-06-03
 * timelyx leaves it alone
<jam> this is weird
<jam> my machine won't allow any new connections
<jam> but preserves the connections it has
<lifeless> timelyx: so my default is yes; but if its really a problem - create a patch and send it in for review
 * timelyx nods
<lifeless> jam: in or out or both
<jam> so I can't open a *new* ssh connection, or a mail connection, but I can still work on the connection I have
<jam> lifeless: out
<jam> not sure about in
<lifeless> jam: ssh running, I can connect to you if you like ?
<lifeless> jam: tcpdump offer any hints?
<lifeless> jam: do you have iptables active?
<jam> lifeless: ssh isn't running, I might try that
<jam> I don't have iptables active
<jam> worse case, I can just restart ...
<lifeless> it may be upstream of you
<lifeless> -> deep hacking mode, interrupt threshold just tripped
<jam> restarting fixed it
<lifeless> igc: ping
<igc> hi lifeless
<lifeless> poolie said you were having trouble reading my stacked loom
<igc> lifeless: I think I was going about the merging the wrong way
<igc> in particularly, I think I should have been looking at diff -rancestor: instead of a plain diff
<lifeless> erm thats wrong
<lifeless> you were going to merge bzr.dev into it right ?
<igc> when merging bzr.dev, the latter was just too big to show anything as suspect
<lifeless> do you know how to merge in a loom?
<igc> lifeless: so my conclusion was that I needed to know more about your code before trying to 'just merge'
<igc> I read the doc if that's what you mean
<lifeless> but you haven't been working with a loom yourself?
<igc> not until I branched yours, no
<lifeless> ok
<lifeless> this is roughly 'updating to upstream'
<lifeless> in a clean branch made from mine
<lifeless> bzr switch bzr.dev
<lifeless> (or down-thread until it errors)
<lifeless> then bzr pull $bzr.dev
<lifeless> bzr up-thread
<igc> did that
<lifeless> bzr diff -r thread:
<lifeless> (that will show the current patch)
<igc> right
<lifeless> run the test suite if there seems a chance of bzr.dev breaking what the patch does
<igc> I was not adding the -r thread: bit
<lifeless> st etc
<lifeless> commit -m 'merge bzr.dev'
<lifeless> bzr up-thread
<lifeless> rinse, repeat
<lifeless> when you reach the top, after committing do 'bzr record' push it somewhere and I'll pull it
<igc> lifeless: cool. I'll do that now.
<lifeless> k, back to deep hack for me
<igc> I've been feeling pretty lousy lately but my brain ought t be good for a few hours
<lifeless> I know the feeling
<igc> lifeless: I suspect you feel worse actually
<igc> mine is more a long term thing - perhaps something nasty I picked up on my last holiday
<igc> off to the specialist tomorrow anyhow so at least I'd know what's going on then
<igc> s/I'd/I'll/
<lifeless> gl
<jml> hmm. bzr just segfaulted on me.
<bob2> 100 points
<jml> well, my bzr plugin just segfaulted on me :)
<jml> I guess I should be clear about that.
<Gilgad13> hey has anyone one found a good way to reconcile eclipse's workspace directory structure with good repository layout?
<Gilgad13> right now i'm just making links in my projects
<Gilgad13> but thats not great because the project itself isn't source controlled
<beuno> Verterok, ^
<beuno> (and hi)
<Gilgad13> and putting it in the same folder could work, but i was wondering if there is something better
<beuno> Gilgad13, Verterok is the bzr-eclipse developer, so if you give him a minute or two to settle in, I'm sure he'll be able to give you a good answer
<Gilgad13> nice
<Verterok> Gilgad13: Hi... I don't know if I understand the idea :P
<Verterok> you can have one workspace per repository :)
<Gilgad13> yea
<Gilgad13> thought of that
<Gilgad13> i guess its the best way to go
<Verterok> but it's a mess to keep configurations between workspaces :(
<Gilgad13> i'm just used to having more control over where my projects go
<Gilgad13> are the links in the eclipse project relative
<Verterok> you can have the projects outside the workspace
<Gilgad13> nvm, that would still mean many little workspaces running around
<Gilgad13> really?, then what is the workspace used for?
<Verterok> only to keep the .metadata directory
<Verterok> so, you can have one workspace, and all your projects in other directory...like /home/<user>/Projects :D
<Gilgad13> how would i create those
<Gilgad13> just do the normal creation then move them out of my workspace?
<Verterok> Gilgad13: take a look to: File --> Import --> Existing project into workspace
<Gilgad13> ahh
<Verterok> and if bzr-eclipse don't detect the .bzr..please file a bug :D
<Gilgad13> certainly, i actually havn't dl'ed the plugin, how usable is it?
<Verterok> Gilgad13: it's quite usable, but a bit slow (it uses bzr executable)...but I'm working on this problem right now :)
<Gilgad13> alrighty, i'll take a look at it
<Gilgad13> good luck
<Verterok> thx!
<Verterok> beuno: Hi, (and thanks for the pointer :) )
<beuno> Verterok, whatever makes you work more  ;)
<Verterok> hehe
<lifeless> T-27
<poolie> hello all
<poolie> lifeless: ?
<lifeless> poolie: 27 failing fixtures
<poolie> oh great
<Verterok> hi poolie
<poolie> lifeless: jam was also wanting to help with the repository refactoring and stacking branches, could you mail him some pointers on where to get started?
<lifeless> sure
<lifeless> uhm
<lifeless> network network network I would say
* poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6beta1 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<poolie> meaning network get_data_stream, or optimizations of what's currently done?
<lifeless> the former
<beuno> poolie, if you want any help with uploading 1.6 beta to PPA, let me know  :)
<poolie> beuno: thanks, should be ok, going to do that soon
<beuno> alright, I'm heading home then
 * igc lunch
<lifeless> T-16 time for lunch
<Gilgad13> Verterok: does your bzr-eclipse plugin manage changing the name of the project when you branch?
<Gilgad13> because when i try to do it manually, eclipse doesn't let me load more than one project with the same name into the same workspace (which is logical, i guess)
<Gilgad13> or do you handle it a different way?
<Verterok> Gilgad13: if you branch using the plugin, yes. it aallow to specify the project name
<Verterok> Gilgad13: and yes, eclipse don't allow repeat project names or change them during import
<Gilgad13> nice
<Gilgad13> that seems to be the killer feature, because that is too much effort to do manually
<Verterok> Gilgad13: I recently fixed a Bug #180207 related to the branch wizard, I'll try to upload a new build as soon time permits
<ubottu> Launchpad bug 180207 in bzr-eclipse "Creating project from bazaar branch" [High,Fix committed] https://launchpad.net/bugs/180207
<Gilgad13> yea, looking at that right now, actually
<Verterok> :)
<lifeless> ok, in theory thats 0 failures
<lifeless> running the full suite
<Gilgad13> Verterok: thanks for the help
<Verterok> Gilgad13: np, y're welcome
<Verterok> if you have any other question, don't doubt to ping me
 * igc pick up kids
<lifeless> ok, zero failures
<lifeless> (I'm not going to claim zero defects)
<jml> lifeless: woot.
<jml> lifeless: Does this make it a 1.6 candidate?
<lifeless> no, now for weave_store nukage
<igc> lifeless: http://people.ubuntu.com/~ianc/bzr/shallow-branch/ is my progress so far
<igc> it's done bar 3 tests that I need to fix up
<igc> tracking them down now ...
<pygi> hey folks
<lifeless> igc: what thread do they start failing in ?
<igc> lifeless: they vary ...
<igc> one was fixed by removing deprecations from bzr-loom
<igc> i.e. merging abentley's branch
<igc> one is related to tests/http_server unicode path handling
<igc> I think I've just fixed it
<igc> the last is test_interprepository - about to do it next
<Slant> Is there a way to have bzr call a script after a commit?
<bob2> Slant: bzr help hooks
<Slant> bob2: Thanks.
<Slant> bob2: Can a hook be embedded in a repo?
<bob2> probably, but hooks are run by clients
<igc> lifeless: shall I upgrade the format # from 1.3 to 1.6 where applicable while I'm in there?
<bob2> how's the new rich-as-a-default-format thing looking for 2.6?
<bob2> oops, the beta's out
<Slant> bob2: Thanks!
<poolie> night
<igc> current state of merging bzr.dev into the stacked branches loom is now pushed to http://people.ubuntu.com/~ianc/bzr/shallow-branch/
 * igc dinner
<jelmer> LarstiQ: I just found what is causing the slowness in the bzr-svn testsuite
<jelmer> LarstiQ: libsvn_client (the glue between working copy and remote repository access) waits for the next second every time you do a disk operation!
<Jc2k> jelmer: that sounds quite yucky!
<AfC> Yikes!
<AfC> I think that Jelmer should win an award for being the guy who puts up with coding against Subversion so the rest of us can deal with foreign VCSes
<Jc2k> he needs our beer, for sure
<jelmer> AfC, :-)
<jelmer> Jc2k: yeah, it's pretty nasty - but shouldn't be too hard to work around
 * mwhudson thinks the jelmer beer fund should be considerable by now
<lifeless> jelmer: ah yes, the old '1 sec wait to 'fix' race conditions' bug
<liw> . o O (First Internet Bank of Beer)
<munckfish> Hi is it possible to specify an alternative SSH key for use with bzr+ssh protocol? I have two keys for separate uses. I'm not seeing an obvious way either in 'push' or in the available config options.
<Pieter> stupid first three letter match
<Pieter> heh
<Pieter> nevermind that
<james_w> munckfish: hi, you want a different key to be used for sftp:// and bzr+ssh:// to the same host, or something else?
<munckfish> james_w: Hi. I have 2 keys one for work in id_rsa and one for ubuntu which is stored in id_rsa.1
<james_w> munckfish: so the differentiation would be by host?
<munckfish> I need to select use of the second key
<munckfish> Um yes I guess so
<james_w> I do this with ~/.ssh/config
<munckfish> aha I see
<james_w> with stanzas like:
<james_w> Host bazaar.launchpad.net
<james_w> Hostname bazaar.launchpad.net
<james_w> User james-w
<james_w> IdentityFile2 ~/.ssh/id_rsa.1
<munckfish> james_w: thx I'll try that.
<jelmer> lifeless, yep, that's the one
<jelmer> lifeless, I'm working around it by simply not using libsvn_client but using the bzr infrastructure to let the diff reporter and commit builder talk to each other
<lifeless> jelmer: :P
<lifeless> jelmer: that *is* why we wrote bzr's code the way we did
<jelmer> lifeless: yeah, that's a big help
<jelmer> strangely enough there's no way to turn that behaviour in the subversion client libraries off
<jelmer> no wonder their test suite takes so long to run :-P
<awilkins> jelmer: I think the "wait next second" thing had a purpose, possibly to do with timestamps, but I can't recall exactly what it is
<jelmer> awilkins: yes, it does indeed have a purpose - see lifeless' comment
<awilkins> I have half a mind to test bzr using this ext2 driver for windows to see if things get faster
<awilkins> Problem is I don't have any internal ext2 partitions so it's not a fair test I suppose
 * awilkins waits 'til he gets home
<lifeless> awilkins: this is the 1 sec thing: diff is expensive, so vcs's often avoid diffing by using a timestamp comparison on the file - if it hasn't been edited since the vcs last had a empty diff, don't bother diffing
<lifeless> awilkins: now filesystems have a granularity (e.g. 2 seconds for FAT)
<awilkins> Makes sense
<lifeless> awilkins: and the record of when a diff was done has some granularity (e.g. 1 second)
<lifeless> so what cvs did at one point (its broken these days) and svn does to, is to wait until the system time is greater than the time it wrote into any of its records as the last diff done
<awilkins> Is hashing faster than diff?
<lifeless> hashing is faster yes, but still not free
<awilkins> Indeed
<lifeless> now in principle that delay can be 0 if the last file was modified before the current time when the op finishes
 * awilkins potters off to install some software (Including bzr! Hahaha!)
<lifeless> but there is a better way
<lifeless> which is to not write the time *at all* to disk for a file created during the file systems granularity, and then you can return immediately safely
<lifeless> gnight
<awilkins> By that, you mean writing the time to the cache?
<lifeless> yah
<lifeless> just say 'we don't know if the file is modified or not'
<lifeless> on small trees this means 'checkout' ends up with no files in the cache after checkout
<lifeless> on big trees the first files written will be in the cache
<lifeless> so its self limiting
<lifeless> and allows extremely fast repeated operations whenever diff can be done in less time than waiting one secod
<lifeless> (and as the limit is the time to write files, this is almost guaranteed to be the case)
<lifeless> really gone - ciao
<mpt> Is "bzr check" supposed to be usable on a remote branch that doesn't belong to you?
<jelmer> mpt: I think so
<jelmer> at the very least it should give a sensible error if it can't - what are you seeing?
<mpt> reported as bug 237067
<ubottu> Launchpad bug 237067 in bzr ""bzr check" on bzr+ssh:// branch returns ObjectNotLocked error" [Undecided,New] https://launchpad.net/bugs/237067
<james_w> it might be a side effect of "Server does not understand Bazaar network protocol 3, reconnecting. (Upgrade the server to avoid this.)"
<james_w> or it may just be a missing lock call of course.
<spiv> I very much doubt the protocol 3 warning is related.
<spiv> After all, that message happens because it *isn't* using the new, shiny protocol :)
<james_w> hi spiv
<spiv> Good evening.
<dash> hi, got a bzr-svn question
<Jc2k> whats up
<dash> how do I create a new branch in the svn repo? branch, then svn-push?
<asabil> jamesh: ping ?
<jelmer> dash: Yeah, svn-push is the command to use
<dash> i'm trying to use bzr-svn to cheat on our svn workflow a little
<dash> normally all branches are created from trunk, due to lack of merge tracking
<dash> I want to use bzr-svn to create a branch from an existing non-trunk svn branch
<dash> later on i'll probably merge it forward
<dash> (meaning, create a new svn branch from trunk, apply the diff of the old branch to its WC, commit)
<dash> still trying to figure out how to do that without confusing myself or our other svn users :)
<radix> does svn-push create an empty revision for the creation of the branch?
<radix> I think it didn't in the past, but I remember hearing about discussion on that
<radix> many SVN-based merging methods or tools won't work unless it's there
<radix> dash: (such as Combinator)
<dash> yeah
<dash> radix: right now i'm thinking i'll just not bother with svn-push at all
<dash> and make a branch with combinator after the pending branch is merged, and copy the diff manually into it
<dash> crude, but effective!
<tethridge> is there a known bug where you can't resize the width of olive aka "bzr vis" to make it smaller?
<tethridge> I can't find a bug on launchpad or google
<tethridge> I'm not sure if olive is considered part of bzr
<dash> i'm pretty sure bzr vis and olive are different
<tethridge> it looks like the same user interface to me
<tethridge> I didn't install olive, I installed bzr-tools
<pickscrap1> I thought they were both part of bzr-gtk?
<tethridge> that's one way to limit your bug count
<tethridge> make it impossible to find the project in launchpad.  :-)
<tethridge> I'll add a bug
<beuno> tethridge, viz is a part og bzr-gtk
<tethridge> beuno, thanks.  I'm adding a bug there now.
<beuno> so please file the bug against bzr-gtk, and thanks for reporting it  :)
<semslie> jelmer: I didn't manage to reproduce that problem I was having yesterday, but I did find that if I cleared the svn-cache before and after rebasing, then the svn-push worked without a hitch. Perhaps this is worth adding as a comment in that bug?
<Stavros> hi
<beuno> hey  :)
<beuno> well
<Stavros> so how do i do that? :P
<beuno> bzr branch lp:bzr
<Stavros> in my site-packages dir?
<beuno> well, this is windows or linux?
<Stavros> windows
<beuno> hrm, well, in Linux you just symlink the bzr executable to /usr/bin
<beuno> so I imagine you can do something similar, but I can't really give you specifics, as I haven't run windows in years
<Stavros> hmm
<Stavros> i can't even find which script runs when i run bzr in windows...
<Stavros> oh wait, "which bzr" works
<beuno> markh, maybe you can provide some insight on how to run bzr.dev on windows?
<Stavros> beuno: actually i probably only need to pull bzrlib
<beuno> (he's probably not around yet)
<beuno> Stavros, well, in general, yes
<beuno> and, you can't really *just* pull bzrlib
<Stavros> hmm, why not?
<beuno> well, it's not a separate branch
<Stavros> ah
<Stavros> well the bzr script that runs imports bzrlib
<Stavros> and that's the only thing i have in my site-packages
<beuno> well, let me know how that goes  :)
<Stavros> will do :)
<awilkins> Yeah, just pull bzr.dev and change the script to point to THAT bzrlib instead
<Stavros> let me try that
<awilkins> I don't dogfood it though, just test it
<awilkins> Which is cd <bzr.dev> ; python bzr selftest [options]
<muszek> hi... would "bzr: ERROR: [Errno 13] Permission denied" mean that I don't have sufficient permissions somewhere withing .bzr or within working directory?
<beuno> muszek, it depends if you're pushing through ssh/sftp/ftp or locally
<beuno> locally, yes, because it updates automatically
<beuno> remotely, within .bzr
<muszek> bueno: I've made a commit from a remote machine (binded to this repo) without a problem... now I want to update this tree and that's the error I get
<beuno> muszek, then it's probably within the working tree
<beuno> did you peak in .bzr.log?
<beuno> it should say what file is complaining
<muszek> bueno: I added myself to a group "hotels", chowned everything to belong to this group and then chmodded everything g+w
<muszek> bueno: looking now
<muszek> bueno: it's just this error + a bunch of python error messages, which I don't really follow... would you please take a look at: http://alpha.muszek.com/bzr.txt ?
<beuno> muszek, it seems to be either this file: webroot/css/hotels.css, or the one after it
<beuno> could you run a "ls -l" on that dir and check for what permision/users are set??
<muszek> bueno: I followed these instructions to make it "multiuser-friendly" - http://buszek.mine.nu/temp/bzr.setup
<muszek> everything belonged to tomekg before that.
<beuno> oh, so we should blame james_w, that's great news!  :)
<muszek> to me permissions seem to be fine... everything belongs to tomekg/hotels
<james_w> what did I do this time?
<muszek> heh :).  I talked to him maybe 2 months ago when was setting another repo (same server)... it works fine.
<beuno> muszek, and you are updating with a user via ssh/sftp, which is the "hotels" group?
<beuno> hi james_w   :)
<james_w> oh, yeah, I thought something about this was familiar
<james_w> hi beuno
<james_w> hi muszek
<muszek> bueno: in the bzr.setup there's a "newgroup"... I substituted it with "hotels"
<muszek> hi james_w ... as you can see, your help isn't forgotten :)
<james_w> not forgotten because it didn't work :-)
<muszek> :)
<muszek> this commit creates/modifies/deletes files and creates a new dir... is it possible that I don't have a permission for something?
<muszek> s/commit/revision
<muszek> bueno: bzr log -v tells me that hotels.css is a last file... prior to that I manually erased one file that's been outputted after hotels.css (as you can see, previous error starts right after [23902] 2008-06-03 15:26:31.776 INFO: -D  webroot/css/reset-fonts-grids.css)
<beuno> muszek, then it's probably a problem with deleting files
<beuno> which I can't really understand why, so maybe james_w does  :)
<muszek> bueno: but I've been able to delete it from command line (using the same user)
<james_w> well the failure is actually in a rename.
<james_w> but it looks like that rename is actually part of a delete operation
<muszek> hmmm... on my local machine I renamed manually (not via bzr) reset-fonts-grids.css to hotels.old-yui.css ... but I haven't added hotels.old-yui.css to bzr
<danielm> hi all :).. sorry the noob question, but any idea why a bzr push to a LP new brach returns me: "but does not have a valid .bzr directory" Â¿? maybe a bzr version problem?
<james_w> muszek: can you check to see whether you have a .bzr/checkout/pending-deletion directory on the side where you are getting the error
<james_w> muszek: and if you do what the permissions on it are.
<james_w> danielm: does it work if you supply "--use-existing-dir" as suggested?
<danielm> yes
<muszek> james_w: no, I don't
<muszek> james_w: I mean I don't have such dir
<james_w> muszek: ok, can you run "BZR_PDB=1 bzr update" and when it gives you the prompt have another look?
<muszek> james_w: http://pastebin.us/?show=m35797f60 (after hotels.css)
<james_w> muszek: yup, can you see if you have ".bzr/checkout/pending-deletion" now please?
<muszek> james_w: still nothing
<muszek> and I am able to create a dir manually in .bzr/checkout
<james_w> muszek: ok, so if you haven't got one then that may be why it is failing
<james_w> actually, to be sure, can you run "find . -name pending-deletion" please?
<james_w> muszek: you didn't exit the debugger before looking for the directory did you?
<muszek> james_w: nothing found
<muszek> james_w: I didn't exit
<muszek> james_w: I did right before using "find", though
<james_w> though it would be really odd if the directory were created by you and then you couldn't write to it.
<james_w> ok, so can you please run "BZR_PDB=1 bzr update" again?
<james_w> then when you get the prompt please type "p from_"
<james_w> and then "p to"
<muszek> james_w: http://pastebin.us/?show=m7212f682
<james_w> ok, and again before quitting, can you see if you have "/var/www/hdev/app/.bzr/checkout/pending-deletion/"
<james_w> I'm assuming that "/var/www/hdev/app/app_controller.php" exists.
<muszek> app_controller.php exists, pending-deletion still doesn't
<muszek> debugger is running
<james_w> weird
<beuno> muszek, you could you possibly be testing through ssh, and pushing through ftp/sftp?
<james_w> and so why is it EPERM and not ENOENT?
<james_w> muszek: can you please run (normal shell) "cp /var/www/hdev/app/app_controller.php /var/www/hdev/app/.bzr/checkout/pending-deletion/"?
<james_w> it will fail, but I'm interested if it is EPERM.
<muszek> jamesh: app_controller.php is a second modified file on the list (first one is .bzrignore)
<muszek> bueno: I don't know exactly  what you mean.  I have a local repo that I binded with remote via "bzr bind bzr+ssh://remote.server/var/www/hdev/app" command.  I commited from local machine and now I'm updating on a remote server (via ssh)
<muszek> james_w: muszek@alpha:/var/www/hdev/app$ cp /var/www/hdev/app/app_controller.php /var/www/hdev/app/.bzr/checkout/pending-deletion/
<muszek> cprov: cannot create regular file `/var/www/hdev/app/.bzr/checkout/pending-deletion/': Is a directory
<muszek> do you want me to create pending-deletion first?
<cprov> muszek: excuse me ?
<james_w> muszek: no need, how about "mv /var/www/hdev/app/app_controller.php /var/www/hdev/app/.bzr/checkout/pending-deletion/new-3"?
<muszek> cprov: sorry... my xchat somehow auto-completed cp: to cprov: (don't know how that happened, I pasted the whole two lines)
<muszek> james_w: mv: cannot move `/var/www/hdev/app/app_controller.php' to `/var/www/hdev/app/.bzr/checkout/pending-deletion/new-3': No such file or directory
<james_w> muszek: ok, thanks, so there is something a bit weird there, but I don't think it's the cause of your problem, let me look at some code for a minute
<muszek> james_w: ok...
<muszek> james_w: maybe I should try that with a user who owns those files (tomekg)?
<muszek> brb (2 minutes)
<james_w> muszek: aha, can you in fact make the /var/www/hdev/app/.bzr/checkout/pending-deletion/ dir?
<james_w> my guess is not.
<muszek> one sec
<muszek> created... now update or copying of app_controller.php? (btw... app_controller.php is not the file that was about to be deleted)
<muszek> app_controller.php was merely modified in this revision
<muszek> I tried bzr update and got an error telling me to delete pending-deletion (something about leftover files)
<muszek> I removed it, updated again and this time I got an error... same thing, only with .bzr/checkout/limbo
<james_w> telling you to delete limbo?
<muszek> yes
<james_w> and if you do that what happens
<james_w> ?
<muszek> "almost" the same, as original error
<muszek> I recreated manually deleted webroot/css/reset-fonts-grids.css in the meantime
<muszek> james_w: http://pastebin.us/?show=m4225a7de
<james_w> ok, can you run again, adding the -Derror argument to bzr plrease?
<muszek> james_w: http://pastebin.us/?show=m47e2de21
<muszek> james_w: just to be safe, I chowned reset-fonts-grids.css from muszek:muszek to tomekg:hotels
<james_w> ok, so it's the same error it seems
<muszek> james_w: I could always revert to the last revision locally, remove and commit on the remote machine and commit back... but I'm affraid I'll run into the same thing next time I remove something locally
<jam> abentley: BB is down again
<james_w> muszek: care to add a line to bzr to test a hypothesis for me?
<muszek> james_w: sure
<abentley> jam: Thanks.  Back.
<james_w> muszek: we need to edit bzrlib/transform.py , what distro are you running? Are you using the packaged version?
<beuno> abentley, btw, I did keep on working on migrating BBs DB, I just came to the conclusion that I need to write a script to do it, so it will take a bit more time  :)
<andrea-bs> is the launchpad plugin included in bzr 0.15?
<abentley> beuno: Oh, okay.
<muszek> james_w: hardy, packages from official repos (both machines)
<james_w> cool, the easy case
<muszek> james_w: the remote machine is installed from some really small image (~100MB, it's a VPS)
<james_w> so, please edit /usr/lib/python2.5/site-packages/bzrlib/transform.py
<muszek> it was stripped of pretty  much everything (I don't even get a tab completion when I do sudo chmod wwwTAB)
<james_w> line 1164, it should currently be
<james_w> raise errors.ExistingPendingDeletion(deletiondir)
<james_w> please add a line after that is
<james_w> raise
<james_w> it should be indented to the same level as the "if e.errno == errno.EEXIST:" line just above
<muszek> care to remind me how to "go to" or check what line it is in vim? (sorry, I'm not a wiz :/ )
<james_w> :1164
<james_w> or 1164gg
<james_w> and make sure you are indenting with spaces, no tabs.
<muszek> single word "raise" inserted there
<james_w> yup
<muszek> update again?
<james_w> I think there may be an error here that is being swallowed.
<james_w> yes please.
<muszek> did a regular bzr update... same error
<james_w> same traceback with -Derror?
<muszek> james_w: http://pastebin.us/?show=mfe42e12
<james_w> ok, it's not that then
<james_w> I'm stumped
<muszek> I'm checking a dictionary for "stumped" :)
<james_w> care to pastebin the output of "ls -lR .bzr"?
<muszek> james_w: http://pastebin.us/?show=m7165e1dc
<muszek> (reverting trasform.py back to what it was originally)
<james_w> looks fine to me
<james_w> would you like to file a bug report?
<muszek> sure... only what would I put in it?
<muszek> I can attach a log from this conversation.  Pastebins should be there for 1 month.
<james_w> the traceback is the most important thing
<james_w> can you paste that in directly, rather than relying on the pastebins please
<muszek> also (unrelated to a bug report).  would you like me to try deleting locally and updating on a remote server with that repo that you helped me with ~2 months ago?
<muszek> it seems to  work, only I'm not sure that I've done this exact operation there
<muszek> james_w: I've done it on the other repo - it worked ok
<muszek> same machines, same steps followed when setting them up
<james_w> odd
<muszek> james_w: just updated it with the user that owns all files (tomekg) and it worked fine
<muszek> james_w: the last question: is this the output I should attach? http://pastebin.us/?show=mfe42e12
<muszek> james_w: thanks a lot for you time.  bug report's here: https://bugs.launchpad.net/bzr/+bug/237140
<ubottu> Launchpad bug 237140 in bzr "bzr dies when trying to delete a file that doesn't belong to the user, but is deletable (user and file belong to a group, file has group write permission)" [Undecided,New]
<muszek> I removed anothere file locally, commited and did bzr update on a remote machine - it went fine.  So I can't even reproduce it anymore :/
<abentley> muszek: write permission on a file does not confer permission to delete it.  Only write permission on its containing directory does.
<muszek> abentley: group had a write permission on a parent directory
<muszek> and I was able to delete the file manually
<abentley> Then perhaps it was inability to rename into the temporary directory.  Seems unlikely, though.
<fullermd> Sure you logged out in between?  Groups are set when your session begins, so it doesn't pick up changes until you relog.
<muszek> fullermd: I know, I opened new sessions right after I added myself to that group.
<abentley> muszek: Whatever the cause, the permission error was encountered by the underlying OS.  Bazaar just propagated it.
<muszek> abentley: I was able to create that file manually.  james____w (mistyped nick, I don't want to ping him) asked me to issue some commands and possibly their goal was to see if .bzr/checkout/pending-deletion  (or similar) was created and it wasn't... but I was able to create it manually.
<abentley> muszek: Create which file?
<muszek> create dir .bzr/checkout/pending-deletion
<abentley> That's very odd.  If that directory cannot be created, you should get an exception immediately.
<muszek> imo it's not worth looking into now that I can't even reproduce it.
<abentley> Okay, looks like there's a flaw in that creation logic.
<abentley> It special-cases ExistingPendingDeletion, and forgets to handle the rest.
<james_w> abentley: yup, I asked him to add a raise there, but it didn't seem to show any errors
<abentley> james_w: yeah, that doesn't make much sense.
<siretart> how to set the 'submit' branch in my branch?
<muszek> siretart: you might be looking for bzr bind command (I'm not even remotely good at this stuff)
<siretart> muszek: no, that does something completely different
<muszek> ok.  sorry, I can't help you then
<james_w> siretart: $EDITOR ? :-)
<beuno> siretart, you can do:  bzr send BRANCH --remember
<james_w> siretart: I think "merge --remember" does it as well
<siretart> james_w: ah, but when I don't actually want to do a merge, but just use 'bzr diff -rsubmit:', and fix the broken submit path?
<siretart> beuno: that sounds interesting. will try that
<james_w> siretart: I think it's in locations.conf, but I know that's not ideal.
<james_w> siretart: btw, did you see that I would like an upload of builddeb? It's not urgent, but if you get some time soon then I would appreciate an upload.
<siretart> james_w: no, I must have missed that
<siretart> james_w: was that on pkg-bazaar?
<james_w> siretart: ah, no problem, I snuck it in.
<james_w> siretart: yes, and IRC a while before that, but you were away at the time.
<siretart> ah, found the mail
<james_w> it's sitting in the trunk branch on bzr.debian.org if you get time.
<siretart> I'm not sure if I get to it today, but I see that I do that soon
<siretart> need to fixup ffmpeg :/
<james_w> siretart: good luck
<perre> hi... i
<perre> i'm using bzr to get a branch... i even tried the bzr devel branch (bzr branch http://bazaar-vcs.org/bzr/bzr.dev). but it gets too slow... i couldn't pass the Copying inventory texts 2/5 step
<perre> am i missing sth?
<perre> btw, version is 1.5
<beuno> perre, is this a public branch?
<perre> yes
<beuno> perre, what's the URL?
<perre> this happens even when i try to get the bzr development branch... but i first tried with mysql
<perre> bzr branch lp:mysql
<perre> or bzr branch http://bazaar-vcs.org/bzr/bzr.dev
<beuno> ah, with big-ish branches
<james_w> perre: have you run "bzr lp-login" before?
<beuno> could you take a look at ~/.bzr.log?
<beuno> james_w, AFAIK, branching through http is faster than ssh, currently, so that shouldn't be the problem
<perre> yes, i tried but no success
<james_w> beuno: ah, ok.
<perre> beuno: yes, taking a look at .bzr.log
<perre> what should i look for?
<beuno> perre, could you do:  bzr branch lp:bzr -Dhpss
<beuno> and then, tail .bzr.log
<beuno> we should get more information from there
<beuno> (speeds, eventual errors, etc)
<perre> just lines like this
<perre> 552.563  http readv of 56cec13f12c690045140c0067e99a2b4.pack  offsets => 516 collapsed 3
<beuno> perre, could you paste the last ~100 lines from that in pastebin?
<perre> hmm.. wait.. it just finished to get the bzr.dev
<beuno> ah
<beuno> :)
<perre> but mysql is taking longer
<perre> is because of the size of the branch?
<beuno> perre, well, the size of the branch obviously matters a lot, yes
 * beuno checks for the size of the mysql branch
<perre> i see... the problem is that i didn't get any visual notification of progress...
<perre> there is the progress bar, but since it is too big, it was slow
<perre> and even using verbose didn't show anything else
<beuno> right, we should do better in that area, yes
<beuno> we have sucky progress bars  :/
<perre> LOL :P
<perre> ok... i will let the pc working
<beuno> perre, feel free to file a bug for it  :)
<perre> thanks folks!!!
<beuno> that makes me wonder if http still really is slower than bzr+ssh...   spiv should know, but it may be a but too early
<Peng> I benchmarked branch once, and with packs, nosmart+http was quite a bit faster than bzr+http.
<Peng> That might've been with artificially low latency though.
<beuno> well, lifeless explained why it was slower, but the fix wasn't too complicated, so it may have gotten fixed
<beuno> at the last sprint, that is
<beuno> Repository:
<beuno>      54233 revisions
<beuno>     706538 KiB
<beuno> that explaines why it's slow to branch mysql  :)
<j^> hi, a question, what is the difference between bzr+ssh and sftp?
<j^> which one should be faster
<beuno> j^, if the server has bzr installed too, than bzr+ssh, which uses the bzr smart server
<Peng> j^: sftp simply uses sftp. bzr+ssh sshes in and runs 'bzr serve', which means bzr has to be installed on the server, but it's faster.
<j^> ok great, have installed bzr on both sides will use bzr-ssh from now on
<j^> pushing still is a bit slow
<j^> but that would be ssh key negotiation or something like that
<beuno> j^, it's especially fast with push/pull/merge operations, as it can easly find out what it needs to transfer
<newz2000> what do you do when you accidentally commit an enormously large file and now your .bzr folder is too large?
<mtaylor> buy more disk
<Peng> newz2000: "bzr uncommit" ASAP?
<Peng> Or that.
<mtaylor> ;)
<newz2000> hmm. Well, about the asap thing, I realize I did this months ago
<Peng> Heh.
<Peng> Oops.
<j^> if its not the last commit bzr branch -rBEFORE and continue in the other branch
<newz2000> what are the consequences of deleting the offending .knit file?
<beuno> terrible  :)
<beuno> it will probably break the repo
<Peng> Ew, you're still using knits?
<newz2000> yep, you're write, terrible.
<newz2000> something is now foobar'd
 * newz2000 tries something else
<Peng> You deleted the knit?
<newz2000> from a copy of the branch
<Peng> When is deleting random files ever *good*?
<newz2000> it was worth a try. Maybe I should have just cat /dev/null > the.knit
<newz2000> but I'll try your suggestion and make the branch
<beuno> newz2000, nothing good will come from anything other than re-branching without that file
<beuno> there may be some magic possible with rebase
<beuno> but I may be wrong
<newz2000> is there detailed instructions on how to do this? I'm still not that experienced with bzr's advanced features
<beuno> I'm pretty sure there isn't
<newz2000> ok, so I have to find out what version the file was added at, then branch from right before that
<beuno> yes, that seems like the safest option
<newz2000> then what, copy thew newest versions of my files over to the branch and commit?
<beuno> yeap
<newz2000> ok, simple enough
<beuno> you'll loose the history after that file was committed
<beuno> but I guess it's a tradeoff
<beuno> btw, newz2000, you do a lot of work with webpages, right?
<newz2000> yeah that's no problem. I use bzr for a safety net and collobration
<newz2000> beuno: yes
<beuno> well, we've been working on a plugin that might interest you
<beuno> bzr-upload
<newz2000> what does it do?
<beuno> it basically uploads files
<beuno> no bzr-related information
<beuno> remembers the last revision uploaded
<Peng> newz2000: You might be able to rebase so that you won't have to recommit everything.
<beuno> so bzr-upload will just upload what was changed since the last upload
<beuno> main target is obviously for webpage developers
<beuno> it's still under development, but I use it almost daily, and it's stable enough
<newz2000> so right now I often use sftp to copy an entire site up, and your plugin would only copy the files that changed since the last time I uploaded?
<beuno> correct
<beuno> sftp/ftp
<newz2000> and it leaves out the .bzr folder?
<beuno> yeap
<newz2000> that is nice
<beuno> :)
<newz2000> is it on the bzr website?
<beuno> not really, but,  http://launchpad.net/bzr-upload
<beuno> and/or:  bzr branch bzr-upload ~/.bazaar/plugins/upload
<newz2000> I actually think about this quite often
<beuno> and you're ready to help us test it  :)
<newz2000> well, once a week or so
<beuno> yeah, I did too. So, a bzr sprint and vila's magic later, we're pretty close
<newz2000> ok, so I apparently bzr rm'd the file a while ago and I'm not sure how to find out what revision to branch from
<newz2000> is there a way?
<beuno> newz2000, bzr log filename
<beuno> should still tell you I think
<newz2000> bzr: ERROR: Path does not have any revision history: live.backup.sql.gz
<newz2000> how would you interpret that?
<beuno> is that the full path?  that file was in the root of the branch?
<newz2000> I guess I don't know
<newz2000> I think so though, it's not a deeply nested project
<beuno> hrm
<ToyKeeper> bzr log -v | grep -20 my.file.name ?
<beuno> right, it doesn't work once the file is gone
<beuno> there should probably be a bug about this...
 * beuno looks
<newz2000> no luck using log -v. :-) I guess most people who use vcs don't want to delete segments of their history
<beuno> right, bug #181520
<ubottu> Launchpad bug 181520 in bzr "bzr log FILE don't show revisions where file was removed" [High,Confirmed] https://launchpad.net/bugs/181520
<newz2000> so can I look for missing revisions?
<ToyKeeper> Hmm, works for me.  "bzr log -v" with no other parameters shows all files added/removed, even if they on longer exist.
<beuno> newz2000, I'd say fo something like:   bzr log -v > log.temp, and then grep log.temp for that file name
<ToyKeeper> s/on longer/no longer/ :)
<beuno> find the last revision it was added, go form there
<newz2000> wow, maybe I'm just really confused, it's not even in log.temp
<newz2000> oh
<newz2000> my copy is small
<newz2000> my copy apparently didn't have the file in its history
<beuno> ah, well, that solves a lot  :)
<newz2000> ok, well, I have no idea what happened but it's fixed now.
<newz2000> Thanks a bunch for your help
<beuno> np  :)
<mwhudson> so if you have a lightweight checkout and the branch it's a checkout of has moved
<mwhudson> is there an easier way of updating things than 'emacs -nw .bzr/branch/location' ?
<awilkins> bzr bind <new_location> ?
<mwhudson> hm, i thought that complained if it couldn't find the old location
<mwhudson> i'll have to remember to try it next time :)
<spiv> mwhudson: bzr switch
<mwhudson> spiv: no, that definitely complains
<beuno> mwhudson, howdy
<mwhudson> beuno: hi!
<beuno> mwhudson, how's everything?
<mwhudson> beuno: ok, still worrying mostly about the ~vcs-imports stuff
<beuno> mwhudson, ah, you always get to work on the fun stuff...  :)
<beuno> is that what made code scanner crazy the other day?
<mwhudson> no
<mwhudson> that was something else :)
<beuno> heh, I'll keep on guessing then
<beuno> did you have a chance to take a peak at the latest branch I uploaded?
<mwhudson> no :(
<beuno> ah, np
<beuno> I've done a few tests, and I can get a 30k diff without many problems
<beuno> the current code is still a little hackish, but it does seem promising
<beuno> there is a few good reasons, aside from zpt that it does render faster/with less memory, one of them being we don't render/process it twice, for unified/side by side view
<beuno> unless you can think of something else that would be better, I'm going to cleanup that branch, and get it into a usable state, with the API upgrades and whatnots
<mwhudson> oh yes, that unified/side-by-side stuff is pretty dumb :(
<mwhudson> it complicates all kinds of linking stuff with cookies and so on
<mwhudson> i think trac's diff view is quite nice, fwiw
<beuno> ah, it's more like the unified diff
<beuno> but nicer
<beuno> I think I actually like the side-by-side more, but we can provide both with this ajaxish interface, and let the user decide
<beuno> side-by-side is a bit more expensive to generate, but not terrible
<mwhudson> it does tend to be very very wide though
<beuno> yes, and I'm only testing on bzr.dev, which is very careful not to go over 80 characters
<beuno> Still like it though, it's more vimdiff-ish
<jam> beuno: btw, one of the issues with color encoding is when you see the unified diff, the side-by-side doesn't matter as much
<beuno> jam, aaah, that makes sense  :)
<jam> most people seem to feel side-by-side is prettier
<jam> I do prefer vimdiff to unified diff, though I'm comfortable with unidiff at this point
<beuno> jam, would adding + and - still address that, or do you think we should opt for different colors anyway?
<poolie> hello
<beuno> mornin' poolie
<lifeless> moin
<jam> poolie: I'm around for the call after all
<jam> beuno: lifeless is the one you should be asking
<jam> he can tell you whether it is all just grey or not
<beuno> morning lifeless  :)
#bzr 2008-06-04
<beuno> got a minute?
<jam> beuno: adding + and - would be a prereq, I don't know if it sufficient
<poolie> oh hello jam
<lifeless> beuno: sure, what should I look at ?
<beuno> lifeless, have the mockups for loggerhead landed in your email?
<lifeless> beuno: newer ones?
<beuno> lifeless, yes, a week ago, max
<beuno> the diff view, specifically
<lifeless> the ones via joey ?
<beuno> yeao
<beuno> *yeap
<lifeless> yes, I have it
<beuno> good, well, how does it look to you?
<jml> lifeless: can I merge my loom status branch?
<lifeless> I am able to tell the red and green apart
<beuno> ah, yay!  :)
<beuno> thanks lifeless
<lifeless> however, I'm only red-green colour insensitive
<lifeless> there are emulators for all colourblindness types
<lifeless> if you haven't, you should simply view the page view them
<lifeless> *via*
<beuno> yes, I'll make sure we test it with some tool (GIMP seems to have something that does that)
<lifeless> but I think the reason is solely that red is left and green is right
<lifeless> any change on one side is one colour in that layout
<lifeless> so you could use one colour 'change from this side'
<lifeless> :P
<lifeless> jml: did it get the tick ?
<beuno> hrm, I wonder if it would be too invasive to cross out the actual text being deleted
<jml> lifeless: it hasn't got any reply yet that I've seen
<lifeless> I have a queue for loom reviews
<lifeless> two for aaron
<lifeless> and that one needs its final pass I think
<lifeless> and 2 pqm branches to me
<lifeless> *merge*
<jelmer> 'evening beuno, jml, lifeless
<jelmer> lifeless: any news on bzr-gtk pqm and/or a shallow-branches+bzr.dev merge?
<jml> jelmer: hello.
<beuno> hey jelmer
<jml> lifeless: that was the tick right?
<lifeless> jml: I think thats what I mean
<jml> :)
<jelmer> lifeless: ping
<lifeless> hi
<jelmer> lifeless: what's the current status of shallow branches? Planned for 1.7 ?
<lifeless> jelmer: 1.6 hopefull
<lifeless> jelmer: igc has posted a merged copy
<jelmer> lifeless: ah, I must've missed that
<lifeless> 17:28 < igc> current state of merging bzr.dev into the stacked branches loom is now pushed to http://people.ubuntu.com/~ianc/bzr/shallow-branch/
<jelmer> lifeless: thanks, I'll see if I can get bzr-svn to implement it then or at least cope with the new API :-)
<lifeless> jelmer: cool
<lifeless> jelmer: ping me with questions
<lifeless> jelmer: I'm sure there will be various
<jelmer> lifeless: will do
<jelmer> lifeless: also, the bzr-gtk pqm: should I keep asking you about it or would it just be easier to set up something outside of the core bzr infrastructure ?
<lifeless> I will mail you today a set of questions
<lifeless> then you reply and I forward to RT
<jelmer> lifeless: ah, cool - thanks again :-)
<lifeless> I've been meaning to make up good answers myself
<lifeless> but clearly that isn't working
<jelmer> ah, ok
<Pieter> "bzr missing" to a launchpad url isn't really fast
<jml> Pieter: the Launchpad code server is running much slower than normal at the moment. We're trying to fix it now.
<Pieter> ah ok :)
<lifeless> jml: have you announced this anywhere?
<jml> lifeless: no. just about to.
<lifeless> jml: /topic here and /launchpad is my normal first port of call
<lifeless> jml: as soon as I know there is a problem
* jml changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6beta1 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | bazaar.launchpad.net running slower than usual, we're fixing it now
<lifeless> (also, put it at the left, GUI clients hide the right hand edge)
* jml changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6beta1 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<thumper> igc: ping
<igc> hi all
<igc> thumper: pong
<thumper> igc: quick call?
<igc> thumper: sure
<igc> skype is ok if you wish
<lifeless> jam: still here?
<lifeless> jam: why would cvsps-import hang on 'creating a dump'
<lifeless> stracing the cvps process its stuck in read(), cvs is stuck in select ..
<jam> lifeless: I couldn't tell you for sure, if it was up to me, I would run cvsps manually and pass cvsps-import the dumpfile
<lifeless> I've found it
<lifeless> write(4, "Argument gnash\n", 15)        = 15
<lifeless> write(4, "rlog\n", 5)                   = 5
<lifeless> read(5, "E cvs rlog: Logging gnash\n", 4096) = 26
<lifeless> read(5, "E cvs [rlog aborted]: cannot stat /var/lock/cvs/sources/gnash: No such file or directory\n", 4096) = 89
<lifeless> read(5, "error  \n", 4096)              = 8
<lifeless> cvsps doesn't handle rlog failures
<lifeless> at least the version on tungsten
<lifeless> I'm going to fix the modules file and note this somewhere
<lifeless> for cscvs when we get a cvs tarball it manually creates a clean cvs configuration
<lifeless> I think cvsps-import needs to do the same
<lifeless> jam: I have another question now though :P
<lifeless> have you seen
<lifeless> request for non-existent rev 1.6573 in file ChangeLog
<lifeless> before ?
<lifeless> there is such a version
<lifeless> at least in the commit info metadata
<lifeless> and in the main content too
<jam> lifeless: is the content considered deleted, etc though?
<jam> or is there a Attic file hiding somewhere?
<lifeless> do you mean is it flagged -k ?
<lifeless> this file is not in the Attic
<lifeless> nor is it shadowed in the attic
<lifeless> corrupt  ~/.cvsps/#home#bzr_conversion#conversions#gnash#gnash-cvs#gnash file
<lifeless> and here I thought cvsps was stateless; its not! hahaha cscvs sounds more and more attractive to me ;P
<bob2> haha
<jam> lifeless: Well, if it had been public, and someone else had been willing to work on it, I probably wouldn't have used cvsps either
<jam> this stuff was started 2-ish years ago
<lifeless> I know :)
<lifeless> I wasn't intending criciscm
<lifeless> spiv: is there a urlutils.unescape that doesn't go to unicode?
<lifeless> spiv: I really want to just unescape :P
<lifeless> nvm, I'll use urllib directly
 * igc pick up kids
<poolie> lifeless: hi, still around?
<lifeless> yes the diet hasn't worked yet
<poolie> heh
<poolie> i'm i'm working on test_get_texts_eol_variation again
<poolie> it's failing in a way i don't remember seeing last week
<poolie> http://pastebin.ubuntu.com/16771/
<poolie> you don't need to work on it i think i just need a teddybear
 * abentley has disconcerting visions of poolie using lifeless as a teddy bear
<poolie> hm ok maybe it's losing a line-ending therefore the serialized form is wrong
<lifeless> that indicates that a full text or delta was written as
<lifeless> prefix\n
<lifeless> content
<lifeless> suffix\n
<lifeless> one likely cause is the initial bug: a basis text with an unchanged line doesn't have the \n for the internal canonical form and thus is copied across corrupting the full text at a snapshot point
<poolie> right
<poolie> so taking out the cleanup_eol call, as my original patch was going to do
<poolie> does fix that, but causes some failures in TestKnitMerge, a bit surprisingly
<poolie> maybe also due to aliasing bugs...
<lifeless> what are the failures? incorrect assignment of annotations?
<igc> lifeless: I need your help if you have a moment. See http://rafb.net/p/Th8E4140.html
<igc> That's the source of the broken test
<poolie> ah ok
<poolie> it's doing an annotation-based knit and the final newline is incorrect
<igc> basically get_ancestry (revision_id) was throwing NoSuchRevision and I need to do the same in your replacement code
<igc> lifeless: if found_ids is the empty set, can I then raise NoSuchRevision?
<lifeless> igc: thats what was coming to my mind
<lifeless> igc: please be sure to commit this to the appropriate thread, not just the top of the stack :)
<poolie> yay
<igc> lifeless: of course
<lifeless> poolie: found a matching bug elsewhere?
<poolie> yep, similar bug in handling annotated content
<lifeless> igc: ;) as you haven't been working with looms I'm being cautious is all
<igc> lifeless: no problems. I'll try that anyhow.
<igc> lifeless: no luck with that ...
<lifeless> igc: what thread is this?
<igc> both found_ids and result_set = frozenset(['pizza'])
<lifeless> is pizza what is meant to be missing?
<igc> StackableBranch
<igc> yep
<igc> it's the revision-id :-)
<lifeless> ok
<lifeless> you need to unpack that _breadth_first_searcher use
<lifeless> there are two next() methods on BFS
<lifeless> one returns the ids
<lifeless> one checks for ghosts and returns (present, absent)
<lifeless> you need to use the latter for the first step
<lifeless> and then you can switch back to the former for the rest of history
<igc> what's the chain(*...) about?
<lifeless> pydoc itertools.chain
<igc> I read that
<lifeless> :)
<lifeless> ok, uhm, at this point I think its easier for me to do it
<poolie> update for #234748 sent if someone wants to look at it
<lifeless> or at least, I can't do what I need to do know if what I've described isn't enough for you to be unblocked
<lifeless> (my head is full of cotton wool - ask jml what I sounded like on the phone)
<igc> lifeless: no - I'll do it
<igc> you're busy enough
<jml> hmm. pizza *is* missing.
<lifeless> basically for the first step use the more complex api on the searcher
<igc> ok
<lifeless> if you get a ghost back raise
<lifeless> then you can use the pithy logic for the rest
<igc> ok
<poolie> lifeless: would you please send your 'add_lines' patch to pqm, it looks good to me too
<lifeless> poolie: I was expecting you to merge it into your branch
<lifeless> poolie: because my fix wasn't necessarily good standalone foo; and they are really about the same stuff
<poolie> oh ok
<poolie> i can do that
<lifeless> e.g. I have a hacky workaround
<lifeless> the test in mine is good to have, the extra assertion is good, but the
<lifeless> if thing not ending in newline give it one
<lifeless> that code shouldn't have to exist
<lifeless> jml: is tonight or thurs better for you ?
<jml> lifeless: tonight has become impossible since I wrote the email.
<lifeless> sadness
<poolie> snort
<poolie> (not at you)
<lifeless> also, ECHANNEL, fixed
<poolie> lifeless: ok i merged your change into mine
<lifeless> cool, thanks
<poolie> every thing passes
<poolie> um
<lifeless> and you removed that hacky thing of mine ?
<poolie> i think the situation i was just talking about before will obviate the need for the "add a newline back in"
<poolie> not yet
<poolie> would like to, i agree it's gross
<poolie> can you read my patch and see if you agree it will do instead?
<lifeless> url?
<poolie> http://bundlebuggy.aaronbentley.com/request/%3Ce01316480806032317p11b6b885n396cb037dc55c001%40mail.gmail.com%3E
<lifeless> jml: latin login support for hardy: https://edge.launchpad.net/~lifeless/+archive/+builds
<lifeless> poolie: your XXX: in check will spuriously conflict with my mega branch
<poolie> kk
<jml> lifeless: sweet.
<poolie> well it should be easy to resolve :)
 * jml corrects himself
<jml> lifeless: bonus!
<lifeless> ridere ex
<lifeless> (ewww, I know thats wrong)
<lifeless> poolie: did you ring me?
<poolie> nup
<lifeless> poolie: the reasons are not historical, they are current
<lifeless> poolie: the reason is that this layout is the internal form used on disk by knits, so its more efficient to keep it in this form during all transformations until we need to hand it to a user
<lifeless> poolie: your repr is buggy; if you really want a naked except be sure to not catch KeyboardInterrupt and SystemExit, but I question wanting that at all
<lifeless> poolie: finally, yes I think you should be able to remove my hack with your patch present
<lifeless> though I wonder perhaps if we're unwinding a performance tweak (presumably johns, he was focused on annotate) and whether this needs verification in that sense)
<poolie> lifeless: i think naked except doesn't catch them, does it?
<lifeless> it catches everything
<lifeless> the general rule for it is 'it is never correct to use it'
<lifeless> seeing it -> red flag
<jml> except when it is :)
<jml> but the flag is still there.
<lifeless> jml: thats why its a general rule ;P
<poolie> ok, catching Exception lets it pass through but bare except does not
<poolie> i thought they were the same
<lifeless> I'm still unclear why you want to catch Exception
<lifeless> what errors are you expecting
<poolie> i want to avoid an error in repr masking the real underlying exception
<spiv> poolie: There's a BaseException now
<lifeless> poolie: I can't see anything that can error there
<poolie> the particular case that has bitten several times is when the object is not fully initialized
<poolie> for example if the transport doesn't exist or isn't working yet
<lifeless> on *KnitAccess* ?!
<spiv> poolie: it's new in 2.5.  SystemExit and KeyboardInterrupt in particular are now based from BaseException rather than Exception
<poolie> i sent a patch proposing that we should as a general pattern we should make reprs defensive
<poolie> it is not about this specific case
<lifeless> oh
<lifeless> It smells to me. I'll need to think about it I guess
<poolie> i agree that catching interrupts is bad
<spiv> poolie: the other thing "except Exception:" won't catch is string exceptions.  Bare except always catches everything.
<poolie> it should at most be 'except Exception'
<lifeless> it smells to me of bug masking
<lifeless> (trying to hunt down my dislike of this concept)
<jml> poolie: regarding reprs, another approach is to define a safe_repr method.
<spiv> Well, bugs in __repr__ are generally unimportant bugs.  We use __repr__ for debugging rather than user output (except maybe in bzrlib.errors I guess).
<poolie> jml, yes, we could call that from code that might be handling broken objects...
<poolie> spiv, yes, that was my reasoning; i would rather get teh real error and only a faint indication there's a problem in repr than vice versa
<lifeless> spiv: not bugs in __repr__. bugs in other code, both design and simple omissions etc which don't get diagnosed and fixed as such because they are only percieved as 'makes repr print 'unprintable''
<spiv> It certainly seems like a poor tradeoff if a bug in writing to a rarely-read log file (the ~/.bzr.log) causes a more serious problem.
<poolie> perhaps just catching AttributeError would be enough.
<lifeless> spiv: For me, I'd rather know that something deep is wrong and have to go fix it than have a repr that hides that from me
<poolie> lifeless: well, if the bugs are in the category of "an incompletely initialized object can be seen by other code" it's pretty hard to fix/avoid in python
<lifeless> poolie: __init__ is relatively easy to make very robust
<spiv> lifeless: well, in debugging situations you can still sometimes see half-initialised objects.
<spiv> lifeless: e.g. when attaching a gdb, or looking at gc.get_objects() when looking for a memory leak.
<poolie> well, those are perhaps edge cases
<spiv> That said, it hasn't often happened to me.
<lifeless>  I haven't seen it happen ever to me
<poolie> i guess we could require __init__ always create all attributes with None first before doing anything that could possibly fai
<poolie> or do them on the class...
<lifeless> poolie: does this happen often to you ?
<poolie> a few times
<gour> arch
<lifeless> is it usually on code you are crafting, or when diagnosing an existing bug ?
<poolie> i have to say the absence of reprs altogether annoys me more than this
<gour> oops
<poolie> the second
<poolie> hello :)
<lifeless> poolie: I think we have quite different debugging styles; this may cause you to want a smoother repr facility
<poolie> possibly
<lifeless> poolie: also, I'd rather than we make __init__ on objects which are fragile in this way for you be cleaner, than use naked exceptions
<poolie> i'm not talking about just interactive debugging but also tracebacks and test failures
<lifeless> poolie: yes thats the broad category of 'debugging styles' I was referring to
<poolie> sure, if this ever trips it is in a senes a bug
<awilkins> I have some code that enhances the default traceback which I keep meaning to tidy up and submit
<poolie> however, i'm concerned with catching information on first failure as much as possible
<poolie> therefore catching the most important error
<poolie> which is not really that __init__ has an impossible-to-totally-avoid bug
<lifeless> well
<poolie> s/really/usually
<lifeless> I think there are other approaches to do that
<lifeless> an object graph walk for instance will gather much more data
<lifeless> and can be made much more robust in general
<lifeless> as well as not requiring scatterings of partial-object-dump code in every class
<poolie> walking the whole dir() of the classes?
<jml> objgrep ftw!
<lifeless> (your _KnitAccess repr is IMO hiding import data about its internals such as _need_to_create), and I often find that repr() functions bitrot, which is one reason I rarely add them - I can't depend on them so I don't
<lifeless> poolie: e.g. pickle to a text backend
<spiv> Except that pickle isn't exactly robust.
<lifeless> which can be human read
<lifeless> spiv: 'e.g.'
<spiv> lifeless: sure, but solutions that are theoretical are less helpful than concrete ones :)
<lifeless> spiv: well, concretely - walk the __dict__
<spiv> (pickle in particular is even more sensitive to the exact unexpected-object-state problem than repr)
<jamesh> spiv: you could always post process the pickle into XML
<jamesh> oh wait, this isn't #zope
<poolie> ok this is definitely a difference in debugging style
<poolie> i am looknig for a hint as to what it is,not the whole details
<poolie> mwh i think just complained that one of them was very big
<lifeless> Inventory specifically I believe
<lifeless> it prints its content
<lifeless> (which I find useful if I am going to poke at an inventory)
<spiv> lifeless: it sounds like you're suggesting an alternative to gathering simple tracebacks.  I don't think that's what poolie is talking about; he's happy with simple tracebacks, he just wants to make sure that generating them doesn't occasionally fall over and lose the original error.
<poolie> not so good if someone gets a traceback contaninig one on a real tree
<lifeless> poolie: I would argue its quite useful actually, it has enough to reconstruct most if not all of the inventory here and check it for consistency
<lifeless> not that we've written a parser
<spiv> Having richer debug tools than tracebacks could be useful, but I think is solving a different problem.
<lifeless> spiv: sure, but it comes back to debugging style I think
<poolie> "what poolie is talking about" <-- correct
<lifeless> so I get that that is what poolie is talking about :)
<poolie> anyhow...
<poolie> i agree the bare except is too strong
<lifeless> and I've already put my vote in which is that I would rather we fix those bugs than add 4 lines of hand holding to every single repr; and if we're going to have repr's as a policy thing, not an occasionally useful thing, thats a whole lotta code
<gour> nix
<poolie> any other comments on the meet of that patch?
<poolie> meat*
 * gour has problem switching buffers today
<lifeless> poolie: other than what I've raised I think its good
<poolie> ok so
<poolie> 1- correct comment about 'historical reasons'
<lifeless> 2- check with John about performance with this applied
<lifeless> 3-repr mumble mumble mumble
<poolie> i'll take out the except; i'll leave the repr if that's ok with you
<lifeless> thats fine
<lifeless> thank you
<lifeless> ugh
<lifeless> so one way in which check is slow
<lifeless> is that it appears to check every text weave twice
<poolie> i think so
<lifeless> not your XXX:
<lifeless> your XXX: refers to w.check() and for thing in w:
<lifeless> there are two code sites calling w.check()
<poolie> oh well at least twice then
<lifeless> so there is w.check(), w.check() and for thing in w:
<lifeless> I think your XXX: is flawed because w.check() and for thing in w: can be different statements of correctness.
<lifeless> indeed, confirmed
<poolie> i didn't mean strictly redundant
<poolie> perhaps that is unclear
<lifeless> it is
<lifeless> also the code doesn't exist anymore here :) not in such a form anyhow
<poolie> there is a lot of overlap but not complete overlap
<poolie> otherwise i would have killed it already
<lifeless> check_one_rev also checks the revision tree
<lifeless> and the file text scan does that too
<lifeless> which is overlap
<lifeless> I'll be happy to give that comment a new home
<lifeless> if you want to make it a bit clearer that would help
<lifeless> hmm, interesting
<poolie> tbh the only thing i am confident in is that check could be faster
<lifeless> I get 10 inconsistent parents for a test that wants 9 :P
<lifeless> :)
<lifeless> FWIW that comment is in the class of comments I don't make; because folk wanting random things to do go to the bugtracker, and folk optimising generally start with a profile :)
<lifeless> (But I don't object to them existing, just explaining why I tend not to make them)
<poolie> ok
<igc> lifeless, poolie, jml: rev 3250 of http://people.ubuntu.com/~ianc/bzr/shallow-branch/ now passes all tests
<lifeless> igc: thanks!. the next thing for that loom is to start peeling off threads from the bottom and updating them with review comments and merging
<igc> I guess the next step is to break it up into different bits for review?
<lifeless> igc: it comes pre-broken :)
<igc> true
<igc> I think the bottom one - errors - is already merged
<lifeless> igc: all the threads up to and includin external_reference_tests should be reviewed-with-comments already
<igc> ah
<igc> that's good
<igc> I'll chase down those reviews
<lifeless> note that 'revno' doesn't really apply to a loom, you need the loom's revno, which isn't currently exposed :)
<lifeless> ok, that was weird:
<lifeless>  bzr pull http://people.ubuntu.com/~ianc/bzr/shallow-branch/
<lifeless> http://people.ubuntu.com/%7Eianc/bzr/shallow-branch is permanently redirected to http://people.ubuntu.com/~ianc/bzr/shallow-branch/
<lifeless> note the / -> no / -> /
<igc> lifeless: have you already applied the reviewed comments for those early threads?
<lifeless> igc: I don't believe so
<lifeless> igc: I was already context switched
<igc> lifeless: so I'm happy to do that but ...
<igc> I'll then assume someone else - beyond you and I - will review the result
<igc> (I'm concerned about reviewing my own tweaks to your code if that makes sense)
<lifeless> if you did the original review I think its fine for me to ack the actual changes made
<lifeless> it does - bounce them to me for +1
<igc> lifeless: so to confirm, I'll do a review of each thread and make the tweaks requested so far and my own
<igc> lifeless: you'll then approve the final result
<igc> i.e. review
<igc> and merge to bzr.dev
<lifeless> I'll approve, I'm happy for you to do the merges
<igc> :-)
<lifeless> the less I do until I finish the weave_store removal the better; I'm a single point of effort at the moment
<igc> np - I agree
<lifeless> check seems happy now (though I'm sure I have some tests to update :P)
 * igc dinner
<lifeless> spiv: one reason knit reconcile is slow
<lifeless> spiv: it does list_dir() of the knits tree on every loop
<spiv> lifeless: ouch
<lifeless> len(weave_store) -> much IO
<lifeless> Its the general side effect of len being unclear about implications
<lifeless> don't worry, I'm deleting the code :P
<spiv> Deleting code is a wonderful thing.
 * spiv heads off for a swim
<kumi_> Hello. I upgraded to 1.5 and bzr+ssh is broken. I keep getting "The server's host key is not cached in the registry": http://pastebin.com/d52c7ea5b
<kumi_> Where _is_ the registry? :)
<lifeless> on linux, ~/.ssh/host_keys I think
<kumi_> here's the Python traceback in case it's relevant: http://pastebin.com/d17386e
<lifeless> 'registry' is a bit of a vague term, unless its referring to windows, where it may well be in the registry somewhere ( the registry is a windows configuration database)
<kumi_> I don't see anything in the actual Windows registry
<kumi_> the install log didn't say it was doing anything in there anyways
<kumi_> In the previous version I was using, the host keys were in C:\Documents and Settings\user\Application Data\bazaar\2.0\ssh_host_keys
<lifeless> I'm afraid I don't know enough about windows ssh stuff these days to help you much :(
<lifeless> is it possible the server's host key changed after the recent ssl issue on debian machines?
<kumi_> nope
<lifeless> igc: errors is indeed merged - you can tell because diff -r thread: -> empty
<kumi_> in the previous version, bzr gave a nice informative error if the key was missing from ssh_host_keys. It told you to "try editing c:\document settings\etc"
<kumi_> this is rather cryptic
<lifeless> please do file a bug
<lifeless> I completely agree
<kumi_> OK :)
<igc> lifeless: does that mean I can switch to that thread (errors) and simply 'bzr combine-thread'?
<lifeless> yes
<igc> lifeless: Can I then just 'bzr record' or should merge up and record at the top?
<igc> (still trying to work out exactly when record is required)
<lifeless> igc: you record before you push
<lifeless> igc: probably in this case you would do a whole bunch of work and changes ;)
<igc> lifeless: thanks. record-before-push is easy to remember :-)
 * igc really heads to dinner now
<kumi_> bug filed https://bugs.launchpad.net/bzr/+bug/237297
<ubottu> Launchpad bug 237297 in bzr "Win32: The server's host key is not cached in the registry" [Undecided,New]
<lifeless> thanks
<lifeless> well I'm signing off
<kumi_> have a good one
<lifeless> currently working on fetch using the new apis
<siretart> james_w: woah, `bzr bd --merge svn+ssh://svn.debian.org/svn/pkg-multimedia/unstable/ffmpeg/debian` is working now. that's what I call cool! :-)
<james_w> siretart: yeah!
<james_w> siretart: do you need --merge?
<siretart> yes, I do need --merge. but most probably because svn:mergeWithUpstream is not set on svn+ssh://svn.debian.org/svn/pkg-multimedia/unstable/ffmpeg/debian
<james_w> ah, ok.
<siretart> james_w: btw, I just uploaded 0.95 to unstable
<james_w> thanks :-)#
<siretart> sorry that I missed your mail that time on the mailing list. I really should have uploaded it faster
<james_w> no problem.
<siretart> that's just too cool! :) - will save me tons of time in the debian games team
<awilkins> Gah, this doesn't make sense : I "bzr send"ed a bundle from my work desktop to home
<gour> ohh no, svn-1.5rc9...what the hell are they doing with 1.5 release
 * gour is eager to see svn-1.5 to avoid patching old one for bzr-svn
<TFKyle> gour: you could use one of the rc's or the svn svn :)
<gour> TFKyle: lazy
<gour> rc8 was supposed to be last one
<pickscrape> rc1 was supposed to be the last one :)
<gour> btw, bzr-gtk-0.95 was not released?
<awilkins> Ok ; I committed a revision to a branch which is now one revision ahead of it's sibling ; I bundled that revision but it refuses to merge with the one-less-revision sibling
<awilkins> It says "bzr: ERROR: Revision {('adrian.wilkins@gmail.com-20080604133624-ybwe2ll9qc0x3vyt',)} not present in "<bzrlib.knit.KnitGraphIndex" ... but the revid it's quoting is the tip revision from the bundle....
<awilkins> The bundle correctly marks the parent revision as the same revid as the tip of the target... what's wrong ??
<gour> pickscrape: something wrong with their workflow? maybe they should change VCS
<gour> awilkins: have you checked bugs at LP?
<james_w> awilkins: there is a bug that gives that error message
<james_w> it's to do with mixing knit and pack repos IIRC
<awilkins> james_w: They are both rich-root-pack
<james_w> probably not that then
<awilkins> These are branches which are usually bound to my USB thumb
<james_w> can you reproduce with two dummy branches?
 * awilkins has a go
<awilkins> They are identical apart from this last revision
<awilkins> (well, should be)
<james_w> https://bugs.edge.launchpad.net/bzr/+bug/177874
<ubottu> Launchpad bug 177874 in bzr "upgrading to rich-root-pack fails" [Critical,Fix committed]
<james_w> that's the one that I was referring to.
<awilkins> They started rich-root-pack because they are bzr-svn branches
<awilkins> Yup, reproducible, but I'm fairly sure the use case should work
<awilkins> I'm being *slightly* unorthodox with the way I'm constructing my bundle
<awilkins> Possible
<james_w> what's the command line you used for send?
<awilkins> bzr send . -r -2.. --mail-to me@me.com
<james_w> yeah, I think that's going to cause you trouble
<james_w> using "." for submit branch is probably the cause
<james_w> and I'm scared by "-r" to send as I know that it can often lead you to believe you are doing something that you aren't
<james_w> bzr branch . ../xxx -r -2
<james_w> bzr send ../xxx --mail-to me@me.com
<james_w> will probably get you the bundle that you want.
<awilkins> I'm going to do it and run the bundles through diff to see what changes
<awilkins> I still think mine should work.... saying "I don't have that revision" is true... BECAUSE IT's the frickin revision I want you to pulll.....
<awilkins> :-)
<jelmer> gour, the next version of bzr-svn will hopefully come with its own bindings for subversion
<jelmer> awilkins: I started working on a branch of bzr-svn that uses C bindings rather than pyrex ones
<awilkins> jelmer: Yipe
<awilkins> jelmer: Are they any easier?
<jelmer> yep, the bindings themselve are done now
<jelmer> Now working on fixing the remaining bugs
<awilkins> Oooh... bugs in the bindings, or the Python?
<awilkins> And do they work for 1.46?
<awilkins> james_w: That bundle differs by timstamp, target_branch and a large chunk of base64
<jelmer> bugs in the bindings
<jelmer> yes, they work with 1.4.6 out of the box
<awilkins> Groovy ; let me know when you have a public branch and I'll test them on Win32 for you
<jelmer> wil do, thanks
<gour> jelmer: great news! depending on svn is...well..
<james_w> awilkins: the base64 is the revision data, is the change addition of lots of it in the new version?
<jelmer> gour, there will still be a dependency on svn itself, just not on a particular version of its python bindings
<gour> right, that's what i meant
<awilkins> james_w: Yes, the block is substantially longer
<james_w> awilkins: it probably means that there is actually some revision data in it now, does it work if you pull/merge it now?
<awilkins> james_w: Yes, it pulls perfectly as I would have expected
<gour> jelmer: any eta?
<awilkins> james_w: I have another case to test...
<jelmer> gour: I suspect a couple of weeks
<james_w> awilkins: do you understand the difference in changing the target branch?
<gour> jelmer: around 1.6 ;)
<awilkins> james_w: It doesn't feel intuitive to me that it would behave differently just because I specified the local branch as the submit branch
<awilkins> james_w: I can understand the mechanics of what is happening but not the difference in behaviour.
<james_w> awilkins: the submit branch is the branch you intend it to be merged in to, by giving it a branch that already has the revision it decides that there are no revisions to send.
<vila> abentley: Tryibg to trick again ? :) What is your current bzrtools HEAD: http://code.aaronbentley.com/bzr/bzrrepo/bzrtools/ or http://bazaar.launchpad.net/~abentley/bzrtools/bzrtools.dev/ ?
<awilkins> james_w: I suppose what I want is a a way to state "the target is this branch, but at -r -2"
<vila> abentley: ghaa, forget the first question, look only at the second :)
<abentley> http://bazaar.launchpad.net/~abentley/bzrtools/bzrtools.dev/
<vila> abentley: good, thanks
<james_w> awilkins: I think that is reasonable. I don't know if it's currently possible, and if not whether we would want to make it possible.
<awilkins> james_w: I'm used to that sort of thing from SVN merges (which obviously don't have local repositories) where you can always quote a particilar revision in any given location URI
<awilkins> james_w: Which is why I'm being audacious enough to try it here, I suppose :_)
<awilkins> I suppose, actually, that would enable it (and probably some other uses) ; being able to specify revision as part of location
<awilkins> But it also makes certain things scarier because of the "local namespace for revision identifiers" paradigm that Bazaar has in contrast to centralised systems
<visik7> why bzr-svn RevNo ar different from revision number of svn
<visik7> ?
<jelmer> visik7: bzr revno's are branch-specific, svn revno's are repository-specific
<pickscrape> Could someone explain what is meant by the server-side hooks that 1.4 provided initial code for?
<visik7> I dunno what it means but ok
<pickscrape> i.e. are they things like pre/post-commit etc?
<jam> pickscrape: there is only really 1, which is a post-changed-branch-tip
<jam> which should fire for push/pull/update/commit
<jam> but it is a Post fire
<jam> not a pre
<pickscrape> So there's no way to (say) run a checker before the commit is allowed to take place?
<pickscrape> One thing we do now (with svn/svk) is run php -l on all files affected by the commit to ensure that they all parse before the commit is allowed to take place.
<jelmer> visik7: In subversion you have multiple branches in one repository
<statik> awilkins: thanks for the patch on bzr-gtk bug 221414. are you planning on submitting a merge request for it?
<ubottu> Launchpad bug 221414 in bzr-gtk "gcommit: unknown error "float division"" [Undecided,New] https://launchpad.net/bugs/221414
<jelmer> visik7: and the same namespace for revno is shared between the branches in that repository
<jam> pickscrape: afaik, there is no way to do that server side, it isn't hard to do client side
<jam> or via a bot which commits to the mainline
<pickscrape> Like PQM?
<jam> pickscrape: right, though you could have much simpler requirements depending on what you need
<jam> certainly if people aren't using checkouts, server-side hooks don't help them either
<jam> (if they are only committing locally)
<pickscrape> No, that's true too. Most people will be using checkouts, but it can't be depended on.
<Pieter> whooo
<jam> hi Pieter
<Pieter> bidirectional git<->bzr syncing
<Pieter> it works!
<Pieter> ;)
<visik7> jelmer: in subversion ?
<pickscrape> I was thinking of writing a custom plugin for our internal use whicch would do things like that.
<jam> pickscrape: that would certainly be my recommendation
<jam> if you wanted, the plugin could even 'auto-update' itself
<pickscrape> ï»¿We're also wanting commits to mainline to fire off a continuous integration system too. I should read on up what PQM can do really.
<visik7> another thing that I've not undestood is why a pull doesn't work after bzr branch of an svn repo
<jam> pickscrape: well, the post-branch-tip-changed hook can  be set up to fire a CI without much difficulty (I assume)
<jam> PQM is meant as a "before this gets integrated" not a "check after the fact"
<jam> perhaps subtle, but means that bzr.dev *always* has all tests passing
<pickscrape> jam: I was hoping to be able to use the plugin manager plugin that has been talked about recently to handle keeping the plugin up to date
<jam> (at least on the PQM platform)
<pickscrape> jam: Ah, I see...
<jam> pickscrape: you probably could, but I think that means users need to run "bzr update-my-plugins" rather than having it "forced" on them by your plugin
<jam> or maybe... encouraged :)
<jelmer> visik7: yes
<pickscrape> Maybe our plugin could auto-update all of their plugins for them :)
<jam> pickscrape: certainly
<jam> If you had it check every 1hr/1day or so, it wouldn't even really get in the way
<pickscrape> Yeah
<j^> is there a way to setup a shared repository that does not require shell accounts? sftp and bzr+ssh depend on that as far as i can see
<james_w> j^: hi, you can serve your branches over plain http
<james_w> if you want to give write access then ssh access is the easiest, but you can do it over http as well.
<j^> james_w, if i want someone to push changes?
<j^> ssh is easy, i just dont feel comfortable to give full shell access just for bzr
<james_w> is it an open source project?
<j^> not right no
<j^> w
<j^> otherwise i would just make read only public
<j^> just thought there might be something as easy as setting up svn via https and htpasswd
<james_w> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#serving-bazaar-with-fastcgi
<j^> thats read only?
<james_w> no, that should allow read-write
<j^> just that the guide says "you want to provide read-only ..." will give it a go
<j^> or look at ssh > 4.8 with chroot sftp support
<james_w> 8.4.5.1   Pushing over bzr+http://
<jam> j^: or you could set up the 'authorized_keys' file so that only 'bzr' can be run
<jam> there is a 'contrib/bzr_access' script that can expose only a chrooted bzr via ssh
<jam> you basically just add a 'command=XXX' to the beginning of the authorized_keys line
<Pieter> james_w, igc: I'm trying to make bzr-fast-import incremental. Sort of like the id-map, but then that it doesn't skip revisions
<Pieter> Also, I want it to take the same input as bzr fast-export outputs
<james_w> Pieter: great! That would be fantastic.
<james_w> I thought it did already, am I missing something?
<Pieter> bzr-fast-export adds a header
<Pieter> that's why import can't read it
<Pieter> and bzr-fast-import, if it uses the revmap thing, still expects the commits on the stream, but just skips them
<Pieter> my exporter won't export them, so it can't skip them
<Pieter> so I want to perhaps add a --import-marks and --export-marks to bzr-fast-import, but without changing too much code
<j^> jam, do you know of a version of bzr_access that works, the one in bzr.dev will always give permission denied
<j^> since it requires a request != / while ssh will always send only /
<vila> Has anyone ever tried to import a plugin from another plugin ? What are the rules ? How is the import order defined ?
<Jc2k> vila: bzr-svn uses bzr-rebase in its svn-upgrade command
<vila> Jc2k: thks, will have a look (I don't use bzr-svn nor bzr-rebase though :-/ )
<jelmer> vila, you can simply import "bzrlib.plugins.otherplugin"
<vila> jelmer: simply... yes... why not ? :-)
<vila> jelmer: thks
<Pieter> james_w: I'd like to extract the import/export mark code
<Pieter> eh
<Pieter> nvm
<jelmer> is there some way to upgrade a read lock to a write lock?
<jelmer> I need to modify the source branch from a push hook
<yacc> Hmm, how can I add a file to .bzrignore "dynamically" inside a plugin.
<pickscrape> I'd look at the ignore command code for that
<beuno> yacc, well, you could *just* append to the file
<pickscrape> One problem I noticed with the ignore command, was that if you ignore something you've already ignored, it appends anyway.
<beuno> pickscrape, that sounds like a bug
<pickscrape> Something else that worries me is that bzr doesn't seem to mind if you push over a shared repository
<james_w> hi beuno
<beuno> howdy james_w
<james_w> yacc: when I had to do this appended a line to the file. It would be great if bzrlib had a better API for this.
<yacc> beuno, yeah, but that would get commited, right?
<beuno> yacc, it would get committed anyway
<yacc> james_w, I don't want the fact that these files get ignored to get recorded.
<beuno> well, ignore .bzrignore  :)
<james_w> yacc: ah, you just want it while the plugin is doing its thang?
<yacc> james_w, exactly.
<beuno> pickscrape, could you report the bug about a file getting added even though it's already being ignored?
<james_w> yacc: I think there is something in bzrlib for that.
<pickscrape> Certainly
<beuno> yacc, interesting use case  :)
<james_w> yacc: add_default_ignore() or something similar.
<yacc> james_w, any hints for google keywords?
<james_w> yacc: I think grep would be more successful, but I may be wrong.
<yacc> james_w, probably right.
<james_w> yacc: add_runtime_ignores
<james_w> bzrlib/ignores.py
<yacc> beuno, you don't want to know what the use case is ;)
<ja1> j^: hm... I had used it before merging, it seems something funny is happening here
<ja1> j^: I would probably simplify it a lot, since (as you say) path is always '/'
<newz2000> I'm having a problem committing because of a problem with gpg but I can only reproduce it while using bzr http://pastebin.com/d3479c44e
<newz2000> anyone have a suggestiong that will allow me to commit?
<j^> jam, removing the check for path != "/" and join (base, path) it works now but yes it could be further reduced and the sample should make clear that one can not provide permissions for paths but just for /
<jam> newz2000: you could disable requiring a gpg signature :)
<newz2000> :-)
<newz2000> Anything else
<jam> newz2000: for starters, you are using the wrong value
<jam> you want to have "create_signatures = always" in ~/.bazaar/bazaar.conf
<jam> second, can you paste the traceback in ~/.bzr.log?
<jam> j^: patches welcome, it is, after all, a 'contrib' item :)
<jam> Seriously, I'm happy to merge fixes for it, I just don't have time right now to work on it
<newz2000> jam: bzr: ERROR: Invalid signatures policy 'always'
<yacc> james_w, the Wiki page is not uptodate, any docs on how currently hooks work?
<j^> jam, ok will look into it later this week, will ping you if i come up with a patch
<james_w> yacc: I'm not familiar with hooks, sorry.
<jam> newz2000: really?
<jam> check_signatures = require
<jam> create_signatures = always
<yacc> james_w, no problem, I noticed that bzrlib is installed unpacked, so I'll go and read the quality docs :)
<jam> is what I have
<newz2000> oh, right, subtle diff
<jam> and you want to get rid of your check_signatures entry maybe
<jam> newz2000: yeah, older versions of bzr had the logic backwards, 'check_signatures' enabled signing for some odd reason
<jam> what *seems* to be happening is that 'gnome-gpg' is returning non zero even if the signature worked
<jam> possibly because of the agent issue
<newz2000> http://pastebin.com/d51909c30
<newz2000> I tried with just gpg instead of gnome-gpg too, same results
<jam> newz2000: what happens if you do 'gpg --cl' manually?
<pickscrape> beuno: bug 237438
<ubottu> Launchpad bug 237438 in bzr "ignore adds to .bzrignore even if pattern is already ignored" [Undecided,New] https://launchpad.net/bugs/237438
<newz2000> jam it works just fine
<jam> newz2000: does it give you the same warning?
<newz2000> no
<jam> and what is 'gpg --cl && echo $?'
<newz2000> oh, it does give the warning
<newz2000> but it still works
<jam> newz2000: so what is the 'echo $?' value?
<jam> I'm guessing it is non-0
<jam> There are 2 "fixes"
<jam> get your agent to work
<jam> or edit gpg.conf to not expect an agent
<beuno> pickscrape, you rock, thanks!
<newz2000> I don't see the result of echo $?
<jam> or some versions of gpg don't actually return non-zero
<jam> newz2000: so do your normal "gpg --cl" type stuff, hit ^D
<jam> it should spit out the signature
<jam> then just type
<jam> echo $?
<jam> which should result in a number
<newz2000> oh
<newz2000> 2
<jam> newz2000: 2 != 0 so gpg is complaining
<jam> saying it didn't succeed
<newz2000> http://pastebin.com/d6cf3be6e
<newz2000> oh nice, I just pastebin'd my email address
<jam> newz2000: well, it is already at https://edge.launchpad.net/~newz
<jam> so it isn't like it is something new
<newz2000> true
<jam> newz2000: so... take your pick. Do you want to get gpg-agent working, or change 'gpg' to not expect it
<newz2000> I think I want gpg-agent working
<jam> newz2000: there is a line in ~/.gnupg/gpg.conf which says
<jam> use-agent
<jam> comment out that line
<jam> and try again
<jam> just as a first pass
<jam> getting agents working is a bit more work
<jam> oh, and can you give 'gpg --version' ?
<newz2000> gpg (GnuPG) 1.4.6
<newz2000> this all started because I got mad at gnome and tried to isntall kde4. It was worse so I uninstalled all the packages it installed. Now this.
<jam> newz2000: weird, because with 1.4.5 I get:
<jam> http://pastebin.com/mb09cd0a
<jam> which says that it failed to connect to the agent, but still returned 0
<newz2000> that is interesting
<newz2000> I wonder why we have diff versions of gpg
<newz2000> are you using hardy?
<jam> that is on a different machine
<jam> actually, I think that one is FC3
<jam> cygwin has 1.4.9
<newz2000> ok, with that commented out I can commit
<jam> weird, gnome-gpg seems to think it would be using Gnome keyring
<jam> according to jamesh
<jam> http://blogs.gnome.org/jamesh/2006/01/12/gnome-gpg-improvement/
<jam> newz2000: if you use gnome-gpg does the commit still work, and it still allows you to save the passphrase in your keyring?
<newz2000> yes, it did use gnome-gpg in my recent commit and it did not ask me for a password meaning it cached it
<newz2000> (I have it set to remoember until I logout)
<jam> newz2000: then I think your setup is complete for you
<jam> you probably never ran a gpg-agent
<jam> and the kde stuff tried to set it up for you
<newz2000> aaah, maybe
<jam> i'm guessing, but I like the answer
<newz2000> I think it did do something like that
<newz2000> I am set, thanks a bunch jam
<mpt> <http://doc.bazaar-vcs.org/latest/developers/packrepo.html> says "to check the integrity of your repositories before migrating them to knitpack format [...] run: bzr check"
<Pieter> Whoo
<Pieter> it works like a charm
<newz2000> ok, one more question... can I change the default push location for a branch?
<mpt> But when I do "bzr check", I get "bzr: ERROR: Not a branch: "/home/mpt/hacking/lprepo/.bzr/branch/"."
<beuno> newz2000, bzr push new_location --remember
<newz2000> thanks
<mpt> What am I doing wrong? :-)
<LarstiQ> mpt: run it from a branch, not a repo? :)
<mpt> LarstiQ, I don't want to check a branch, I want to check my repository
<jam> mpt: you need to do 'bzr check' in a branch, however, for *this specific* case, I would upgrade and then run check/reconcile
<jam> after copying '.bzr/repository'
<jam> mpt: check will check everything 'down' so you start in a branch => repo
<jam> or WT => branch => repo
<mpt> ahhh
<mpt> jam, why do you suggest upgrading before checking in this specific case?
<jam> mpt: but the pack code is much faster, and it happens that it can copy slightly bogus knit data
<yacc> My first Wiki update ;)
<Pieter> james_w: look at this http://pastie.textmate.org/private/jvcinnuwy76kekwp532g
<Pieter> james_w: I can now commit to either bzr or git, then fetch from bzr, do what I want, and push back
<Pieter> it's fully bidirectional git <-> bzr
<LarstiQ> _fully_ functional?
<james_w> Pieter: wow, nice work.
<Pieter> LarstiQ: well, it's bit fragile, but it should do everything correctly :)
<LarstiQ> Pieter: sweet
<gour> Pieter: this would be useful to post to DVC list. there was recent thread about bzr vs. git
<Pieter> what's dvc?
<Pieter> or, what's the list? :)
<yacc> A plugins __init__ should register commands on import time I guess?
<gour> Pieter: starting with http://article.gmane.org/gmane.emacs.dvc.devel/2119
<mpt> thanks for your advice jam
<gour> Pieter: see http://xsteve.at/prg/emacs_dvc/dvc.html
<yacc> The joys of DVC, two branches without a hint which an uninterested user should pull.
<LarstiQ> yacc: hmm?
<yacc> http://xsteve.at/prg/emacs_dvc/dvc.html <= just after reading the page you realize that these two branches are from the two maintainers.
<yacc> And I guess depending which DVC you use you might decide to use one over the other.
<LarstiQ> yacc: I'd go with the one labeled as 'main branch'
<yacc> LarstiQ, right ;)
 * mpt is thoroughly confused
<mpt> My repository is now apparently at the new format, but if so, it happened just through a reconcile, not an upgrade, and it took less than a minute for a three-year-old repository
<beuno> AFAIK, if you're using shared repos, you have to upgrade the shared repo too
 * vila thinks we should optimizing bzr, that confuses even old users
<mpt> That is the shared repository
<vila> grr s/should/should stop/ freudian slips in jokes now :)
<beuno> vila, lol
<beuno> mpt, I think you have to upgrade shared_repo/ and shared_repo/branch/
<mpt> bzr check in shared_repo/branch/ gives me a KeyError
<mpt> I assume that's not supposed to happen
<beuno> that doesn't happen to me
<beuno> what version of bzr are you using?
<mpt> 1.6b1
<mpt> http://pastebin.com/m13295f47
<beuno> hrm, I wonder if it's a problem with knits...
<beuno> mpt, can you backup that dir, and upgrade shared_repo/branch?
<mpt> ok
<mpt> beuno, bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
<beuno> hrm
<beuno> bzr info -v
<beuno> shows it's at packs?
<mpt> beuno, no, it returns a NoSuchRevision error
<mpt> http://pastebin.com/m33af5d5
<mpt> though the traceback *does* use the phrase "KnitPack" occasionally :-]
<beuno> heh
<beuno> doesn't look good
<beuno> jam, any ideas?  :)
<jam> mpt: I believe that is a known bug with check and ghosts, just reported IIRC
<jam> when the mailine of your branch has a ghost in it
<jam> mpt: that looks like a bzr revision id, though
<jam> any ideas how it could be a ghost?
<jam> ahh, wait
<mpt> When I ran "bzr upgrade" on the repository, it complained about a missing revision:
<mpt> starting repository conversion
<mpt> bzr: ERROR: Revision {robertc@robertcollins.net-20050919044328-0205c679f3051340} not present in "KnitVersionedFile(file:///home/mpt/hacking/lprepo/.bzr/repository/text%3Atools-20050707102144-fee2fd7fd6ddfc1c)".
<jam> mpt: you were using packs locally, and a knit repo on the remote, right?
<jam> and you probably did a push and ^C part way through?
<mpt> jam, I have a local repo and a remote repo
<mpt> I have been known to ^C occasionally
<jam> mpt: is one knit and one pack?
<mpt> but I --overwrite afterwards
<mpt> hmm, good question
 * mpt checks
<jam> mpt: well, technically you should never need to, ^C should be safe. There is just a known issue if you ^C a pack => knit copy while it is coping revision texts
<jam> it doesn't copy them in the correct order.
<jam> mpt: you should be able to:
<mpt> "Shared repository (format: dirstate or dirstate-tags or knit)"
<mpt> that's the remote one
<jam> bzr push -r revid:MISSING_REV_ID remote:/temp/branch
<jam> it will create a branch you can then delete
<jam> you are just doing it to copy the revision text across
<mpt> So I guess the remote repository needs upgrading, then
<jam> mpt: right, we would like you to upgrade that one, too, but you still need to copy that revision across
<mpt> ok
<jam> there might be a bug in the knit => knit code, but the Generic fetcher is the only part I know
<mpt> another KeyError :-(
<jam> mpt: from which side?
<mpt> http://pastebin.com/m1cbcf532
<jam> mpt: actually, I wanted you to 'bzr push -r revid:mpt@canonical.com-20080604185556-txuu6iw2ejfs0gea'
<jam> not the robertc one
<mpt> oh
<jam> though there is still something funny happening
<jam> you might actually need to 'bzr branch -r revid:... remote: .'
<jam> Looking at the last traceback it looks like it is missing locally
<mpt> Exactly the same error for the mpt@canonical.com revision
<pickscrape> Can someone point me at a plugin that provides a good example of how add an option to an existing command
<beuno> pickscrape, xml-output
<mpt> jam, should I do that bzr branch command from the top level of my local repo?
<jam> mpt: as long as you are in it, it doesn't really matter
<pickscrape> beuno: thanks
<jam> it might be 'cleaner' to do it from the top
<mpt> From the top I get "bzr: ERROR: Target directory "." already exists." :-)
 * mpt does it into a temporary branch instead
<jam> mpt: sorry, I didn't mean '.' I just meant to the local area
<mpt> It's thinking hard about it
<pickscrape> beuno: xml-output seems to do it by subclassing the builtin command handlers. What if more than one plugin wants to extend the same command?
<pickscrape> Or is it Really Really clever :)
<beuno> pickscrape, well, I don't really know  :)
<beuno> moquist, bzr launchpad-login your_lp_id
<beuno> and it should use bzr+ssh instead of http, which will be able to write
<beuno> and, I'd recommend upgrading to the newest version of bzr, using PPA  :)
<moquist> beuno: thx, I'm one step further now.
<moquist> beuno: hrm. OK, I'll google around a bit to see if I can figure that out.
<jam> bbiab
<beuno> moquist, what bit?
 * beuno wonders what it would take to get a newer version of bzr into 8.04.1/2
<moquist> beuno: I don't know how to use bzr with my PPA.
<beuno> moquist, https://launchpad.net/~bzr/+archive
<moquist> beuno: should I go ahead and "--use-existing-dir" to start off this branch of vpnywhere? LP seemed to want to create that dir, so I suppose this is probably expected...
<beuno> moquist, yeah, add it
<moquist> looks like the push worked; thanks!
<beuno> moquist, :)
<moquist> heh - now everyone in the whole world can read my totally lame commit comments. :p
<beuno> moquist, welcome to the club  :)
<pickscrape> jam: if you can confirm that pushing a branch over a shared repository doesn't cause damage to the shared repository, I'll go ahead and close bug 237439
<ubottu> Launchpad bug 237439 in bzr "bzr should not allow push over shared repository" [Undecided,New] https://launchpad.net/bugs/237439
<beuno> mornin' mwhudson    :)
<beuno> I just tried a 36k line diff on my branch
<beuno> 100mb res memory
<mwhudson> nice
<beuno> timing it now
<beuno> but it was very CPU friendly too
<mwhudson> can you try two concurrent requests?
<beuno> yeap
<mpt> (jam, the "bzr branch -r revid:..." is still working hard 30 minutes later)
<beuno> hrm, I can't get loggerhead to work with wget/curl...  :/
<beuno> mwhudson, two concurrent requests, ~160mb RES
<beuno> Firefox hates me though
<beuno> but that's a different issue  :)
<mwhudson> beuno: for wget/curl you perhaps need to remember to put the url in quotes ''
<mwhudson> beuno: we'd better make it faster too then, so there are less concurrent requests :)
<beuno> mwhudson, still get a 500 error, seems to not pass on URL values correctly, as it tracebacks in the kwargs arguments
<mwhudson> beuno: oddness
<beuno> mwhudson, well, if we're going to take on concurrent requests, then I can't see anything better than caching static HTML from what we generate  :)
<beuno> well, the good news is that it works with other URLs, just not the one I did for diffs
<beuno> I'm not sure how to make it faster without tweaking bzrlib
<mwhudson> yeah, fair enough
<jam> mpt: that seems odd
<beuno> mwhudson, it's about 3 secs getting the diff and processing it, and 20sec applying the template to a 36k diff
<mpt> jam, strace shows it's still busy, not hung or anything
<beuno> mwhudson, although we use a *lot* less memory
<jam> mpt: remote is on another machine, right?
<jam> otherwise I would have you break in with ^|, but that hangs up connections, too
<mwhudson> beuno: i wonder if we could render the diff in a less complicated way, perhaps?
<mpt> jam, yes, another machine a few km away
<mwhudson> beuno: but i think we work on getting some of this stuff into trunk
<beuno> mwhudson, well, if we don't use a templating engine to generate it, it should improve quite a lot, as it's just manipulating strings
<mwhudson> it may not be as good as it can be, but it's still a heap better
<beuno> mwhudson, ok, cool. I'll focus on cleaning up the code in order for it to be mergeable.  Maybe we can set it up on a different port, and test it on edge.LP for a few days?
<jam> mpt: ok, my guess is that you are running into some of the performance regressions with knits, and it just has a lot of revisions to copy
<fsafdsf> is there a way to add support for webdav in bzr 1.5?
<jam> you *might* want to switch to an officila release (1.3, 1.4, 1.5) for the copy and just do the same thing
<jam> or just let it finish
<mwhudson> beuno: there is no edge for codebrowse
<mwhudson> (though that would be nice)
<beuno> fsafdsf, that sounds like a question for vila, if he's still around
<mwhudson> but there is staging
<mpt> jam, heh, how long should I wait for the latter before I try the former? :-)
<beuno> mwhudson, well, if we can point edge to a different LH port, and make *that* edge...  :)
<vila> beuno: stop reading above my shoulder will you
<jam> mpt: well, if you do tail ".bzr/repository/revisions.kndx" and it is still processing at a ... decent rate
<jam> I would stick with it
<beuno> vila, :p
<mwhudson> beuno: yeah, i should talk to IS about that
<jam> mpt: we're trying to get rid of an "unnecessary" caching layer, but not all the code paths can get by without it
<jam> so for the official releases, we restore it.
<beuno> mwhudson, great, that will help us test  :)    back to cleaning up code then
<vila> fsafdsf: I'm working on the webdav plugin at this precise minute
<vila> fsafdsf: since 1.6 is around the corner it will certainly be a requirement, is that a problem ?
<fsafdsf> do you have a time frame or an alternative for pushing commits to central repo hosted on a shared hosting?
<mpt> jam, where is that .bzr/repository/revisions.kndx supposed to be? In the target branch directory? In the repo top level?
<mpt> (it's not in either)
<fsafdsf> seeing it's almost impossible to get the smart server working under a shared hosting
<jam> mpt: in the repo top level
<jam> mpt: ah, your local is now a pack repo?
<mpt> jam, allegedly
<jam> mpt: then you should have a .bzr/repository/upload/*.pack that is growing
<vila> fsafdsf: please file bug reports against smart server, it *should* be widely usable and will provide far better performances
<fsafdsf> then I'm obviously doing something wrong
<beuno> mwhudson, do you have any strong feelings against generating the diffs without a template?
<mwhudson> beuno: well, i wouldn't want to generate anything as fancy as what loggerhead currently does without a template
<beuno> mwhudson, well, we could add an arbitrary limit, like we have now, and generate simple diffs when it's over X lines
<vila> fsafdsf: file bugs, doc bugs if needed, mention your environment as precisely as possible, os/version/web server/python/ etc
<fsafdsf> that's the thing, I doubt it's a problem on bzr's end
<vila> if you can't make it work it's at least a doc bug
<mpt> jam, the .pack file hasn't changed size in the past three minutes, and was apparently last modified 44 minutes ago (about 10 minutes after the branching started)
<fsafdsf> most likely a serer problem, seeing DH tends to cripple fcgi scripts
<mpt> jam, so downgrade and try again?
<mwhudson> beuno: yeah.  seems like a hack though
<jam> mpt: first us ^| to interrupt and see what it is doing
<mpt> jam, ok, in a debugger, now what?
<jam> mpt: can you paste the traceback ?
<jam> "bt"
<jam> backtrace in debugger terms
<beuno> mwhudson, I could run some more tests with other non-xml based templating engines
<mwhudson> beuno: let's get something into trunk first :)
<vila> progress ! webdav failing 49/142 tests with apache2-dav instead of 4/71 without :-)
<beuno> mwhudson, yes, focus, sorry  :)     back to cleaning up
<mpt> jam, http://pastebin.com/m668806a2
<jam> mpt: interesting... I'm guessing the ghost is confusing the search stream, otherwise it looks like it was genuinely copying data
<jam> anyway, try a "c" to continue, it will likely fail
<jam> then downgrade and try again
<beuno> vila, btw, you owe me an email reply!   bzr-upload is starting to get anxious and wants to see the light
<fsafdsf> is there a recored instance of someone being able to use the smart server on a shared hosting, as far as you know?
<beuno> fsafdsf, I use it through bzr+ssh on a shared hosting
<vila> beuno: don't worry, bzr-upload is processed in the background :-) webdav get some love now as an experiment in plugin a real http server into the bzr test suite, from there, I'll be able to do the same with ftp/sftp servers and get a better testing env for bzr-upload
<fsafdsf> mind sharing how you did it? to make sure I haven't skipped any step?
<beuno> vila, :) :) :)    I've got some time seperated for it too, mainly in UI stuff
<beuno> fsafdsf, what steps are you following?  do you have bzr working on the shared server already?
<fsafdsf> indeed
<fsafdsf> mostly I've been following the fcgi smart server guide on the official docs
<vila> beuno: wow, you send me an email may the 24th and it appears in the bzr-upload mailbox as if received today >-/ Something really wrong is going on there, anyway, I'll reply now
<beuno> vila, ah, I thought it was odd it took you so long to get back, with your kitchen all done and all   :p
<vila> hehe, 50 years birthday party for a friend last week-end and kitchen tiling still to be done, family life, etc ;-)
<fsafdsf> I think I'm messing it up when I'm trying to adapt the steps they listed to a shared hosting environment
<beuno> fsafdsf, what URL are you looking at?
<fsafdsf> url of?
<beuno> "steps they listed to a shared hosting environment"
<fsafdsf> ah
<fsafdsf> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id73
<fsafdsf> "Serving Bazaar with FastCGI"
<fsafdsf> fcgi is already enabled and working
<mpt> jam, ok, trying with 1.5
<beuno> fsafdsf, ah, that's not what I've got working, I use bzr+ssh, not bzr://
<fsafdsf> I can't use bzr, seeing it invokes a daemon
<fsafdsf> which isn't allowed
<beuno> fsafdsf, I think spiv is the expert in that area, but he may not be awake/working yet
<beuno> you may want to send an email to the list
<beuno> with as much information of the problem as you can  :)
<fsafdsf> won't vila's webdav solution be the best solution for me?
<beuno> fsafdsf, well, he should know  :)
<fsafdsf> seeing I'm kinda pressed for time here, and I have nothing but bad experience with mailing lists and help channels
<fsafdsf> vila, do you have any idea when we can see a first working version of your plugin?
<beuno> fsafdsf, well, if you have a few hours, spiv might be able to help you
<Peng> fsafdsf: DreamHost supports SFTP...
<fsafdsf> yes, but I can't give them all the same user/password
<Peng> fsafdsf: Oh.
 * Peng just came in on this conversation.
<mpt> whee, progress bars
<fsafdsf> and I prefer each user to have their own u/p, similar to how I do it in SVN now
<mpt> Spastic progress bars, but progress bars nonetheless
<Peng> fsafdsf: Also, bzr+ssh and bzr+http usually worked for me.
<Peng> fsafdsf: Procwatch only ever killed them when I was doing big things.
<fsafdsf> Peng, I don't doubt it.. My bet is that I'm doing something wrong
<beuno> mwhudson, I'm not really updating NEWS, should I?
<Peng> I've since moved to a VPS though. No more procwatch. :)
<fsafdsf> and I wanted someone to walk me through it, to see if I did something wrong
<vila> fsafdsf: as soon as it works :-) Should be in some days, weeks at most
<vila> fsafdsf: if you can administer your server you can use ssh keys. That's better than using u/p
<vila> fsafdsf: by the way, isn't launchpad an alternative ?
<fsafdsf> I can use local keys, problem is.. I'm working with Windows user and I prefer not to expose them to the private key creation process
<fsafdsf> vila, it would, but then I'd need a way to push all the changes upon commit to a working, live directory
<fsafdsf> and I doubt launchpad will help me with that
<vila> fsafdsf: you want a remote working directory up-to-date with your bzr branch ?
<fsafdsf> yes
<fsafdsf> similar to how I did it with SVN's post-commit-hook
<mwhudson> beuno: hm, adding a note at least would be nice
<vila> fsafdsf: do you need the remote branch too or is it just a way to get the remote working dir >
<vila> s/>/?/
 * vila thinks sed can be as noisy as perl
<fsafdsf> let's assume the latter
<mpt> jam, alas, another error - http://pastebin.com/ma1ec204
<fsafdsf> seeing I can work on the repo locally too
<jam>  mpt: ;(
<jam> :'(
<vila> if the remote branch is not a requirement, the bzr-upload plugin may help and that would be a far simpler solution
<fsafdsf> and that can be used with launchpad?
<jam> mpt: that is weird, as it shows that knit => pack is rather broken... can you try using sftp:// instead of bzr+ssh?
<mpt> ok
<vila> the plugin will upload the working tree only, the branch can be anywhere and the repo to synchronize devs in yet another place
<fsafdsf> so I'll have to tell every used to use it every time they commit?
<fsafdsf> user*
<vila> fsafdsf: you have to tell me a bit more about your workflow to allow me to answer that ;-)
<fsafdsf> basically, I want the bzr experience to be a similar as possible to SVN for the end users
<fsafdsf> at least while they adapt to bzr's
<fsafdsf> so, every user works on the same working version with possible mergers and conflict resolves if needed
<fsafdsf> and again, I'll still need a way to store the central repo
<vila> fsafdsf: what is your project ?
<fsafdsf> simple web project, similar to a CMS
<vila> ok, so bzr-upload may be relevant. Do you have a test server and a production server or just the later ?
<fsafdsf> one server, a shared hosting
 * beuno is off for a few hours
<vila> ok, so the simplest solution is to keep the central repo and the working tree at the same place, but it's not a *requirement*
<fsafdsf> not a problem
<fsafdsf> that's what I wanted anyway
<vila> if you want to separate them, you can use launchpad as code hosting provider and use bzr-upload to your production server
<fsafdsf> assuming I want to have them both on the same server, what can I do?
<vila> now, if your workflow was: hack/test/commit/hack/test/commit it would become: hack/commit/upload/test/hack/commit/upload/test
<fsafdsf> which will expose the end users to another step, one that I can skip using bzr's hooks assuming I get the smart server working
<fsafdsf> or wait for your plugin
<vila> if you want to have them both on the same server: bzr+shh, bzr+http, bzr+webdav in better to worse order
<vila> the plugin will not help for hooks
<vila> the *webdav* plugin will not help I meant
<fsafdsf> the hooks depend on the smart server?
<fsafdsf> even if I use that auto mirror plugin for bzr?
<vila> executing hooks *on the server side* yes
<vila> auto mirror ? Is that the same as push+update ?
<fsafdsf> then that brings me to my original problem, how do I get the smart server to work under my server environment?
<fsafdsf> "Automatically update a remote working copy upon commit. "
<vila> so far, spiv is the expert :)
<vila> what are the supported protocols ?
<fsafdsf> one moment, launchpad seems dead
<vila> the crux of the problem when updating remote working trees are the permissions bits, and that can be addressed only by a process on the remote end whatever that process is
<fsafdsf> when I tried it
<fsafdsf> I got this error: bzr: ERROR: Generic bzr smart protocol error: Invalid http response for http://url/project/.bzr/smart: Unknown response code 500
<vila> AFAIK push and update requires sftp, the smart server is another option, but I don't remember if updating the remote working tree
<vila> 500 is internal server error, look at your logs
<fsafdsf> says it tried to send an empty file, ie, without any headers and then timed out
<vila> vaguely rings a bell, but it's sleep time for me, I'm afraid I won't be good at debugging that
<fsafdsf> FastCGI: incomplete headers (0 bytes) received from server "/dir/.bzr-smart.fcgi"
<fsafdsf> ah
<vila> file a bug report on launchpad or send a mail to the list or wait for spiv to appear here are my best bets :)
<fsafdsf> indeed
<fsafdsf> thanks anyway
<vila> you're welcome, keep us informed of your progress anyway (but may be a more recognizable nick may help ;-)
<fsafdsf> my usual nick is taken here
#bzr 2008-06-05
<mpt> jam, success!
<jam> mpt: so does bzr check on your original branch work?
<poolie> lifeless: can you join us if you're still around?
<mpt> jam, I'll get back to you on that, it's checking revision 117/38124 :-)
<jam> mpt: if it didn't fail right away, that is, indeed a good sign
<mpt> jam, however, "bzr log" gives me a KeyError in a different branch
<jam> mpt: well, then you need to do the 'bzr branch' with *that* revision, too :)
<mpt> woohoo
<mpt> ok
<mpt> this could be a long night
<mpt> thanks for your continued help jam
<jam> mpt: I'll be off in a bit, but you can poke at spiv or igc I think
<mpt> ok
<pickscrape> Well, I've got bzr diff --stat working
<tufloc> is there a way to enable user authentication for the dedicated bzr server?
<mneptok> tufloc: serve the branch over ssh/sftp
<tufloc> I'm starting to miss svn
<tufloc> the dedicated server doesn't allow write operations?
<mwhudson> it can do
<bob2> pickscrape: yay
<jml> igc: <3
<nhandler> Could someone explain to me how to modify the email address that is used by bzr? It shows up as username@host (where username is my current username and host is the host of my computer).
<cody-somerville> bzr help whoami
<nhandler> Thanks cody-somerville, that did it
<tufloc> any idea what's wrong here? when I try to init-repo the central repository I get this error "bzr: ERROR: No such file: '/dir': [Errno 2] No such file" (using sftp)
<mwhudson> tufloc: what was the command line ?
<tufloc> bzr init-repo --no-trees sftp://dir
<lifeless> spiv: ping; any idea what would trigger InvalidURL: Invalid url supplied to transport: "2e/%2554%2552%2545%2545_%2552%254f%254f%2554.kndx"
<lifeless> only happening on remote tests. ..
<lifeless> oh; punicode
<lifeless> jam: ping
<tufloc> mwhudson, nevermind
<lifeless> tufloc: you want sftp://host/absolute_path
<tufloc> yeah
<lifeless> tufloc: or sftp://host/~/homedirpath
<lifeless> ok, fetch.py converted
<lifeless> well, nearly
<igc> lifeless: wrt the Development1 format, currently it says "(needs bzr.dev from before 1.3)" and ...
<igc> "This format should be retained until the second release after bzr 1.2."
<igc> What do you want those strings to say now?
<lifeless> the idea is they roll
<lifeless> so if this lands in 1.6 it will say from 1.6
<lifeless> (from before 1.6)
<igc> and retain until 1.6 + 2?
<lifeless> 1.5 + 2
<lifeless> so we delete it after 1.7 is released
<igc> ok
<lifeless> this gives users of a dev format 2 development cycles to toy with it
<igc> lifeless: so what's the relationship between development1 and BzrBranch7 if any?
<lifeless> development1 incorporates BzrBranch7
<lifeless> as well as the new pack format
<bob2> does dev1 support rich roots atm?
<igc> is development1 needed for stacked branches to land (sorry if that's a dumb Q)?
<lifeless> dev1 *is* stacked branches
<igc> ok
<igc> I wasn't sure if one was a copy of the other or dependent on the other
<lifeless> so:
<igc> (yet to look at the code in dpeth)
<lifeless> development is an alias to the tip of the dev series
<lifeless> dev1 is the first dev format to support stacking
<lifeless> dev refers to branch7 and packs-that-stack
<lifeless> sorry, last line should read dev1 refers ....
<lifeless> bob2: no it doesn't - we do need to stack on existing non rich root repos
<lifeless> development-rich-root however should (I think I skipped that for development-subtree, this should likely be fixed)
<bob2> ah, right - just hanging out for the unification ;)
<lifeless> there won't be a unification, but there will be a pivot on the default
<pickscrape> I'm looking at getting --stat working as an option to bzr log, but can't find an obvious way to hook it in
<pickscrape> That is, without copying and pasting the code from cmd_log, which doesn't strike me as being at all clever :)
<lifeless> pickscrape: you may well need to change log to be more hookable
<pickscrape> What I really need is a hook that is called after each log entry, which passes the revision and/or tree that can be worked with
<pickscrape> lifeless: so I'd need to hack on bzr itself and send to the mailing list etc?
<pickscrape> It jsut occurred to me that such a hook would allow glog -p (patch) to be implemented as a plugin also.
<pickscrape> s/glog/log/
<spiv> lifeless: hmm
<lifeless> http://mail.python.org/pipermail/python-dev/2004-July/046416.html
<lifeless> is enough for me
<spiv> lifeless: I don't recall off the top of my head
<lifeless> I don't know if 'sorted()' has the same guarantee, but I happen to have a list
<spiv> lifeless: it would, yeah
<lifeless> would or does :P
<spiv> I would be shocked if sorted() was not stable but list.sort() was.
<lifeless> given the impact is more than your shock :)
<lifeless> I will use list.sort
 * spiv nods
<lifeless> also pydoc sorted blows
<spiv> pydoc blows.
<spiv> file:///usr/share/doc/python2.5/html/lib/built-in-funcs.html#l2h-68 is where it's at.
<spiv> (although even that doesn't mention stability)
<lifeless> yah, thus my not depending on it
<lifeless> pydoc has the potential to be extremely useful, it is saddening that it is not
<spiv> Sure.
<pickscrape> lifeless: how would you recommend making cmd_log more hookable? Using a mechanism like post_push etc or something more raw like an overridable method of cmd_log?
<lifeless> pickscrape: well, I think the general concept here is that log -v, log --diff, log --stat all need the same minimum data: a tree delta
<lifeless> pickscrape: so I'd think of it as selecting which filter to pass tree deltass through during log
<lifeless> pickscrape: -> a registry of filters, and the core code calls into that
<pickscrape> lifeless: Bearing in mind that the user might be asking for more than one filter at the same time.
<pickscrape> Could quite legitimately want to do bzr log -p --stat
<lifeless> pickscrape: sure. may need some infrastructure work to allow selecting multiple items from a registry
<pickscrape> The existing formats could also be rewritten as filters in this registry too.
<lifeless> pickscrape: the ones that do tree deltas yes - thats exactly what I'm suggesting
<lifeless> --line vs the default is already registry based
<lifeless> they select what revisions are shown and ordering; somewhat different part of the code path for log
<pickscrape> I'll have a think about that then. It certainly seems that log --stat is impossible without it.
<kumi_> Just curious, what benefits does rich-root have over pack-0.92?
<kumi_> Or rich-root-pack (what's the difference with rich-root?)
<poolie> kumi_: this format puts a unique id on the root directory, so it can be used with versioned subtrees (like svn externals) and split/join-
 * kumi_ looks up svn externals
<poolie> basically so that you can link an external library into a subdirectory of your project
<kumi_> Nice. I can think of several places where that would be useful to me
 * igc lunch
<lifeless> abentley: around?
<abentley> lifeless: Hi.
<lifeless> I have a question about rich root root id generation during fetch
<jfro> hey all, quick question, is there a way to edit a file in a past revision, like say if you accidentally committed a hard-coded password in your code =P
<abentley> lifeless: Okay.
<lifeless> the parents list for the new root text is the revisions parent list - revisions with different root ids, and including ghosts
<lifeless> did you consider looking up the root id in the revision tree of revisions with different roots, to find root-renames done in those trees?
<abentley> That doesn't sound like a good idea.
<lifeless> which line are you replying to :)
<abentley> The first.
<abentley> I wasn't considering root ids changing.
<lifeless> the first was a paraphrase of the comment in the existing code
<abentley> Oh, well maybe I was.  I don't remember that...
<lifeless> fetch.py line 390 in bzr.dev
<kumi_> Is it possible to try rich-root in version 1.5?
<lifeless> anyhow, It seems to me that running reconcile after generating these texts could find mismatched parents with the current code, because it does look at the full inventory of each tree
<abentley> lifeless: That says we *drop* parents with different file_ids.
<lifeless> abentley: yes, I meant drop with my use of '-', sorry for confusion
<lifeless> revisions_parent_list.subtract(changed_ids)
<abentley> lifeless: It looked like a dash to me.
<lifeless> kumi_: it is, there are some caveats: its a one way conversion
<lifeless> kumi_: we plan to make it the default soon
<kumi_> I think I'll wait, thanks lifeless
<lifeless> abentley: ok, with the confusion sorted, the next line was my actual question: did you consider looking for that id elsewhere in the other tree
<kumi_> btw I fixed that windows problem you helped with yesterday. thanks again
<lifeless> kumi_: excellent
<lifeless> kumi_: I saw the comment in the bug; I wonder if we can make the error nicer/more clear
<abentley> lifeless: I don't think I did.
<kumi_> lifeless: yes, if it mentioned where the error came from "plink.exe", that would be enough
<lifeless> abentley: ok. I'm not going to change this code, I just wondered while looking. Could you think about it at some point?
<lifeless> abentley: (well, I have to rephrase the code to new apis,but I'm not changing the intent of the code)
<abentley> Sure.
<abentley> What I was aiming for was a conversion that was reasonably hi-fi, but definitely with good performance.
<abentley> And definitely reproduceable.
<lifeless> right, which we have. It seems a shame if (and I think it does) reconcile and check were to find things to do post-conversion ;).
<abentley> lifeless: Not a tragedy, though, since only experimental versions of Bazaar could get into that situation.
<lifeless> abentley: couldn't converters ? e.g. arch could have an id be root one commit elsewhere another in theory
<abentley> I don't think converters touched root ids.
<abentley> Not until bzr-svn went dirstate-with-subtree on us.
<lifeless> mmm, I'd need to check
<lifeless> anyhow, I'm not fussed, you know the implications at least as well as I do
<lifeless> 19 references to weave_store in bzrlib/*.py to go
<lifeless> argh!
<lifeless> weave_modifed_revisions = set(file_weave.versions())
<lifeless> all-of-history calls die die die
<poolie> lifeless: we need something stronger than -Devil i think
<poolie> cutely name though it is
<lifeless> poolie: what d you mean by stronger?
<pickscrape> -Dsatanic
<jamesh> -Dponies
<lifeless> but we have one
<poolie> lifeless: i mean one that's harder to ignore
<lifeless> poolie: e.g. output to console not just log?
<poolie> i guess the only thing is to actually fix them then make them fail the tests
<lifeless> I think thats the only workable approach
<lifeless> some O(history) operations are necessary
<lifeless> I really should tackle log at some point
<lifeless> but I want to cry when I see the code
<mwhudson> log.py needs a lot of love
<mwhudson> (also, revision numbering)
<beuno> +1 to revision numbering  :)
<lifeless> users seem to really like it
<igc> lifeless: is there a reason why add_falback_repository in repository.py checks for format compatibility but ...
<igc> the one is remote.py does not?
<lifeless> igc: yes
<igc> and it is ...?
<lifeless> its only a proxy object
<thumper> poolie: I just want to make sure you are aware of the bzr client side stacking policy stuff that abentley has and its need to be in 1.6 with the other stacking stuff.
<lifeless> or perhaps its oversight. But I think that was my thinking in february
<igc> thumper: your alias patch is merged to bzr.dev now
<thumper> igc: w00t
<igc> pqm seems much faster today. Thanks to whomever enabled the 'go-fast' option.
 * igc pick up kids
<lifeless> abentley: I plan to add a file_id parameter to PlanMerge, does that seem ok? (vf is now a VersionedFiles so we need a prefix
<kumi_> Hmm, I have an error when I try bzr st: KeyError: 'pop(): dictionary is empty'
<lifeless> kumi_: there was a bug in merge, it is fixed in mainline I believe
<lifeless> kumi_: you have just done a merge haven't you ?
<kumi_> oh dear
<kumi_> yeah I just did
<lifeless> just revert
<kumi_> Alrighty
<kumi_> Is there any way to get around this?
<lifeless> well, you probably did merge and then merge --force?
<kumi_> Nope, just bzr merge -c 161
<abentley> lifeless: That makes sense.
<lifeless> kumi_: its probably already merged; I think grabbing the latest bzr.dev may be the most straight forward solution
<abentley> lifeless: At some point, if we're brave, we might allow multiple file ids :-)
<lifeless> abentley: I'm trying to balance scope creep, and updating apis towards that as I go
<lifeless> but yeah :)
<kumi_> lifeless: unfortunately I can't do that (on Windows and I don't know how to compile)
<lifeless> kumi_: oh, there is no need to compile
<lifeless> kumi_: if you have python already installed you can just branch bzr and run it; if you don't then its more tricky. Do you have python installed ?
<kumi_> Yeah, I have Python 2.5
<lifeless> then bzr branch http://bazaar-vcs.org/bzr/bzr.dev <some-path-here>
<lifeless> I think there is a bzr.bat included in there by default
<kumi_> Cheers, I'll try that
<kumi_> is bzr.dev usually in a stable state?
<lifeless> if there isn't say so and I'll help you
<lifeless> we run all our regression tests before every merge - we try to keep it immediately releasable
<kumi_> nice :)
<lifeless> (except for occasional massive feature drops, they tend to cause issues no matter how hard we try - but even then its still passing tests)
<kumi_> Out of curiosity, is there a way to branch the point releases?
<lifeless> I think there are tags, there are also separate branches for each release
<kumi_> gotcha
<kumi_> I branched bzr.dev and I put it in a directory away from my 1.5.0 files. If I run C:\bin\Python25\python.exe G:\temp\bzrdev\bzr version, it's not using it's own path for bzrlib
<kumi_> I will try the start_bzr.bat that is in bzr.dev (have to modify it because it uses bzr.exe)
<poolie> abentley: hitchhiker is very cool
<abentley> poolie: thanks.
 * jml was thinking the same thing.
<abentley> poolie: I deliberately left out write commands for now.
<abentley> I
<abentley> I'm not sure any good would come of that.
<kumi_> Where is the BZR_HOME environmental variable supposed to point to?
<bob2> kumi_: normally it's unset and HOME is used
<spiv> kumi_: generally you don't want to set it
<kumi_> the location of bzr, tools, doc, contrib, etc? Or the location where bazaar.conf etc are located?
<kumi_> OK
<poolie> kumi_: if it's not set it defaults to ~/.bazaar on unix
<poolie> not sure where on Windows but bzr --version should show it
<kumi_> That's why I asked, it doesn't explicity mention "home"
<kumi_> only "Bazaar configuration" and "Bazaar log file" directories. All looks fine, though
<poolie> i think it's the first
<abentley> poolie: It looks like it defaults to ~/ on unix
<kumi_> me too
<kumi_> On Windows, if you set BZR_HOME to c:\foo, it will put configuration files in c:\foo\bazaar\2.0, and the log file in c:\foo\.bzr.log
<lifeless> hitchhiker?
<poolie> lifeless: a text-mode client for bzr transports
<lifeless> lftpesque?
<poolie> yes
<kumi_> lifeless: it worked! Thanks a million
<lifeless> kumi_: cool
<kumi_> hm, automirror doesn't seem to work when a revision is pushed
<lifeless> igc: you have removed the use of chain, but kept the import :P
<igc> lifeless: o damn - I'll fix that
<igc> lifeless: any further thoughts on that RemoteRepository check of fallback issue?
<lifeless> no
<igc> I'm just wrapping up my review of the Development1 thread and the rest is ok  I think
<lifeless> I don't think we want to merge the formats just yet, because they are so limited
<lifeless> but perhaps I'm wrong
<igc> as in the development1 formats?
<lifeless> yes.
<lifeless> lets start at the bottom and work up
<lifeless> get them fully ready to merge at minimum
<igc> lifeless: so some quick Qs if you have time
<igc> the new init method in BzrBranch6?
<igc> it's saving development1... as the metadir
 * igc pulls up the diff
<igc>     def __init__(self):
<igc>         super(BzrBranchFormat6, self).__init__()
<igc>         self._matchingbzrdir.repository_format = \
<igc>             RepositoryFormatPackDevelopment1Subtree()
<lifeless> yes
<lifeless> thats for testing
<igc> lifeless: any side-effects from that?
<lifeless> yes, tests run with old branches, new repositories. Its good :)
<poolie> i'm trying to page back in the countedlock refactoring
<poolie> which is meant to eventually help Remote objects stay in sync with their vfs objects
<poolie> want to finish it off anyhow
<igc> lifeless: and is all_revision_ids() still meant to return a list? Or just a sequence now?
 * igc wondering why check.py needed the list() added around all_revision_ids()
<lifeless> igc: well, if you remove it and it fails, it needs it ;P
<igc> some tests were updated to put set() around things which is fine of course
<igc> lifeless: the code change is harmless enough but I'll update the al_revision_ids docstring if it's no longer correct
<lifeless> what does it claim ?
<igc> I guess it would need to be added to API CHANGES/BREAKS as well if it no longer aways returns a list
<igc> "Returns a list ..."
<lifeless> yeah thats false now, lists are very slow at duplicate detection
<igc> ok - I'll tweak that docstring
<igc> and update NEWS
<igc> poolie, spiv: is one of you able to review the external_references tests patch please?
<lifeless> igc: I can review your changes if they are busy
<igc> lifeless: in this case, they had already reviewed that code
<lifeless> igc: ah, k
<poolie> i can
<igc> poolie: thanks. you had voted tweak earlier though it may need some more given spiv's comments
<poolie> it's a good time, i just worked out what patch i want to do but haven't started
<poolie> is this
<poolie> igc hm the only patch about that i see was in february
<poolie> ok i see it
<poolie> http://bundlebuggy.aaronbentley.com/request/<48474354.1040103@canonical.com> right?
<igc> poolie: https://lists.ubuntu.com/archives/bazaar/2008q1/037703.html is the earlier thread
<igc> poolie: that's the one
<poolie> +from bzrlib.tests import (
<poolie> +                          adapt_modules,
<poolie> not a big deal but can you make them just indented by 4 spaces in future, as the others are
<poolie> (might not even be your code)
<lifeless> I think the rest of the others were deep
<lifeless> or something
<poolie> i wish the boilerplate in load_tests wasn't proliferating the way it is
<poolie> igc, sent
<igc> poolie: thanks
<igc> lifeless: please let me know if you have any comments on poolie's requested tweaks
<lifeless> so, they seem fine
<lifeless> the scenario tuple is name, dict_of_things
<igc> lifeless: and vila has voted resubmit
<poolie> i'll reply to vincent
<lifeless> the multiply_ method is different, I did look at reusing but its at the wrong level
<lifeless> - it does too much
<igc> poolie: thanks. Did you mind submitting this to pqm as well, once tweaks are agreed?
<lifeless> vila: ping; please look at bzrlib/tests/*_implementations/__init__.py
<vila> lifeless: regarding adapt_modules ? or regarding defining adapter classes ?
<lifeless> regarding the need
<lifeless> to adapt many modules identically
<lifeless> (we do it *all the time*)
<vila> I'm fine with using adpat_modules, I'm not with gettind rid of adapter classes
<lifeless> vila: I want to nuke them all
<vila> the adpater classes ?
<lifeless> yes, there should only be one
<lifeless> application and generation of scenarios are different responsibilities
<lifeless> this became clear some time after first creating the ability to adapt at all
<lifeless> tests.TestScenarioApplier is meant to be used as an instance, not subclassed; its subclassable for historic reasons onl
<lifeless> y
<vila> hence my tendency to call the classes adapters not appliers :)
<lifeless> its fine to have a class for generating scenarios that you reuse and extend, but it shouldn't subclass the applier
<lifeless> instead have it provide the scenarios and use them with a stock applier
<vila> lifeless: I never thought about it but I fully agree, just apply that sentence to my comments
<vila> ..with the stock applier of course ;)
<lifeless> (which it uses :P)
<vila> so adap_tests and adapt_modules will become methods ? Sounds coherent.
<lifeless> errr
<lifeless> I'm scrambled now
<lifeless> this is 4 month old code and I'm deep updating merge
<lifeless> can I come back to this?
<poolie> hello vila
<vila> hi poolie ;)
<poolie> i sent mail wihch i think robert will agree with
<poolie> bit i can never tell
<poolie> oh the scrollback does make it look like he would agree
<lifeless> thats why there is you, and me, vive la difference!
<poolie> but*
<poolie> vila, i may be missing the point somehow
<vila> poolie: well, I'm waiting for your mail, but seeing Robert comments, I think I need to re-read the code with the idea of separating scenario generation and application, I'm deep into other subjects right now. I remember being uneasy with the adap_test and adpat_modules functions but not *why* I thought subclassing applier was the best solution
<vila> I remember it vastly simplified the http tests where many combinations were required between transport implementation/proxy/auth schemes with tests needing various combinations
<vila> but may be that's specific to http
<lifeless> vila: I think you would find the repository_check_reconcile permutations enlightening
<lifeless> they do a cross product test permutation
<lifeless> nearly done
<lifeless> 17 references to go outside of tests
 * jml always wants to say "cartesian product" not "cross product".
<lifeless> fine
<jml> but I guess the latter makes sense.
 * vila always translate 'cross product' into 'produit cartesien' ;-)
<jml> heh heh
<RAOF> Not to be confused with the _actual_ operation 'cross product' :)
 * vila also has no trouble translating applier into 'adapteur' hence he missed lifeless point ;)
<vila> lifeless: url ? grep repository_check_reconcile bzr.dev gives no matches :)
<poolie> :)
<lifeless> test_check_reconcile.py
<lifeless> and __init__.py
<lifeless> in repository_implementations package
<lifeless> back soon -> atm
<lifeless> poolie: ringing you for brief chat
<poolie> jml, hm, Cartesian product seems more correct
<jml> poolie: especially since the ordering doesn't matter, since they are unit tests.
<poolie> lifeless: ready whenever
<jml> iirc, cross product makes sense if you define multiplication as 'cons'
<spiv> Ah, I just accidentally found the bug in the test suite that allowed bug 237067 to happen.
<ubottu> Launchpad bug 237067 in bzr ""bzr check" on bzr+ssh:// branch returns ObjectNotLocked error" [Undecided,New] https://launchpad.net/bugs/237067
<poolie> spiv, good for you
<lifeless> mobiles work better with battery power
 * igc dinner
<vila> lifeless: class RepositoryTestProviderAdapter(TestScenarioApplier): explains my confusion I would say :) Or are you referring to a newer, yet unknown to me, implementation ?
<vila> lifeless: hmm, no, I think you meant:     broken_scenario_applier = TestScenarioApplier()
<vila>     broken_scenario_applier.scenarios = broken_scenarios_for_all_formats
<vila> which better illustrates your point
<vila> poolie, igc, lifeless: I just realized I did  class ServerAdapter(tests.TestScenarioApplier): in my local_test_server plugin just to define a dict :-)
<lifeless> vila: yes :)
<lifeless> vila: this is the point really
<lifeless> also
<lifeless> crying tiger++
<vila> lifeless: consider me enlightened then :) But not for the tiger though...
<lifeless> its thai food
<awilkins> It's the new filem "Crying Tiger, Sulking Dragon"
<proppy> Hi, I get the following when installing bzr on ubuntu-hardy
<proppy> http://pastebin.com/m76595733
<proppy> is this a known problem ?
<Peng> I don't think scrollkeeper is related to bzr.
<poolie> oops
<poolie> proppy: please report a bug against scrollkeeper
<proppy> poolie: thanks for the direction :)
<proppy> poolie: https://edge.launchpad.net/scrollkeeper/+filebug ?
<proppy> or scrollkeeper package in ubuntu ?
<proppy> https://bugs.edge.launchpad.net/ubuntu/+source/scrollkeeper/+filebug
<poolie> the second is better but either will do
<proppy> poolie: reported https://bugs.edge.launchpad.net/ubuntu/+source/scrollkeeper/+bug/237579
<ubottu> Launchpad bug 237579 in scrollkeeper "/usr/bin/scrollkeeper-update: corrupted double-linked list on apt-get install bzr" [Undecided,New]
<strk> is this the #bzr branch ? :)
<strk> ok, serious question: does bzr support aliases for locations ?
<jamesh> strk: there is a bzr bookmark plugin you might want to try
<Peng> Ooh, you were just barely too fast for me.
<jamesh> https://edge.launchpad.net/bzr-bookmarks
<jamesh> https://launchpad.net/bzr-bookmarks
<nasloc__> anyone know how to update partial (like only doc directory) in a checkout?
<nasloc__> I wanna update part of working tree, not full of them.
<Peng> nasloc__: I don't think you can do that.
<Peng> nasloc__: You can revert only parts of a tree, but that doesn't help if you want to update to a new revision..
<nasloc__> Peng, oh :(  because svn can do that and my partner says he would use bzr over svn if bzr supports that.
<nasloc__> Peng, thanks anyway.
<Peng> nasloc__: With Bazaar, you'd finish your work and commit, then merge new changes. Not sure how that translates to checkouts though..
<jamesh> nasloc__: you can always use multiple branches
<jamesh> if you generally edit a subset of a tree as a unit, then perhaps it should be its own branch
<nasloc__> jamesh: ok I'll check if that works. thanks
<james_w> yay! Bazaar shirt.
<gour> james_w: where, what, how...
<james_w> gour: it just arrived in the post.
<james_w> they were a gift for all contributors to celebrate the 1.0 release. Mine just took a bit of time to arrive.
<gour> heh...next time let's think to better contribute...well, we're still news with bzr
<gour> s/news/new
<j^> jam, regarding the bzr_access cleanup, i put a patch at http://oil21.org/~j/patches/bzr_access.permission_fix.bundle
<strk> we're doing some tests with bzr. I get:
<strk>   Path conflict: a_silent_test_file / RENAMED_TEST
<strk> how to resolve such conflicts ?
<james_w> strk: put the file that you want at the path and then "bzr resolve <path>"
<james_w> I've never had to deal with one, so I can't be more specific, sorry.
<strk> mm, I did bzr resolve a_silent_test_file
<strk> resolved, but kept the other :)
<igc> abentley: if you're around, can you help me with some subtree Qs?
<abentley> igc: Okay.
<igc> looking at sprout() in bzrdir.py, what's the recurse_branch bit about?
<igc> the variable isn't used ...
<igc> which might well be a bug
<igc> Also, do you think shallow=shallow ought to be passed?
<igc> (in lifeless' branch that is)
<lifeless> igc: I would say shallow should propogate to child trees, yes.
<igc> thanks. I could see why they wouldn't
<igc> s/could/couldn't/
<abentley> igc: Nesting generally requires a tree and a branch.
<abentley> Because the location of the nested tree's branch is determined by the current tree's branch.
<igc> ok
<abentley> So it looks like the loop at 1009 may be buggy.
<abentley> If buggy, it's buggy for a scenario where a lightweight checkout is being sprouted.
<abentley> Actually, I'm not sure source_branch can ever be None when branching.
<abentley> In the lightweight checkout scenario, I think it would be set to the lightweight checkout's branch.
<igc> abentley: I'd expect so.
<igc> So do you think recurse_branch can be safely deleted?
<abentley> I think so.
<igc> me too. It looks like it was going to be used by then wasn't needed ... or something like that.
<igc> s/by/but/
<igc> abentley: thanks.
<abentley> igc: What's the purpose of your branch for shallow branch support?
<igc> I'm just reviewing Robert's work and making any minor tweaks as I go
<abentley> Are you working with Robert's prototype or the final one based on VersionedFiles?
<igc> the one lifeless asked me to merge bzr.dev into
<igc> I've run export-loom and I'm working my way up the stack
<igc> reviewing each thread
<igc> lifeless has agreed to review my tweaks and then I'll merge the pieces, giving him time to continue on the VersionedFile stuff
<abentley> igc: Would it be appropriate to land my stacking policy stuff on that?
<igc> abentley: sure
<igc> I'm just putting up the next patch now fwiw
<abentley> igc: Are you in Sydney?
<igc> Brisbane
<abentley> Well, that's dedication.
<igc> and deadlines :-)
<igc> that's it from me today - night all
<barry> hi bzr hackers.  i'm having some trouble integrating setuptools_bzr with looms.  i'm wondering if anybody is available to lend some help
 * khaeru bleats
<khaeru> Anyone home?
<abentley> barry: I can help later, but I'm putting out fires right now.
<barry> abentley: thanks!  no rush, i have a hackaround in place right now.  ping me when you're free?
<abentley> will do.
<barry> abentley: thx!
<proppy> regarding testing deferToThread addition
<proppy> here is the failing test
<proppy> http://proppy.aminche.com/hg/service-test/rev/583aae136706
<proppy> and the patch that make test pass http://proppy.aminche.com/hg/service-test/rev/1c8716677930
<proppy> someone care to parse it ?
<proppy> oops wrong channel
<proppy> :)
<abentley> barry-away: What can I do for you?
<plexq> how do I list what changes where in a revision?
<Kinnison> how do you mean?
<barry> abentley: https://bugs.edge.launchpad.net/setuptoolsbzr/+bug/237652
<ubottu> Launchpad bug 237652 in setuptoolsbzr "setuptools_bzr does not work with looms" [High,Confirmed]
<abentley> barry: from bzrlib.plugin import load_plugins; load_plugins()
<barry> abentley: that'll load the loom plugin and install any necessary hooks?
<abentley> barry: Right.  Especially, in this case, it will register the loom branch formats.
<barry> abentley: awesome, thanks
 * barry is trying it...
<barry> abentley: works like a charm.  thanks!
<abentley> You're welcome.
<radix> Stacked branches sound awesome. It sounds like it'll make using launchpad code hosting much more practical.
<gour> radix: they won't be in 1.6?
<radix> gour: what?
<gour> stacked branches
<radix> gour: Was that meant to be a statement?
<radix> I don't understand the question.
<gour> stacked branches will not be ready for bzr-1.6, right?
<radix> gour: I don't know, I'm not a bazaar developer.
<radix> gour: I just read jam's blog about them.
<radix> http://jam-bazaar.blogspot.com/2008/05/this-week-in-bazaar_29.html
<gour> i'm speaking based on what i heard here, iirc
<pygi> shhh gour again :)
<gour> pygi: ;)
<jam> gour: well, we are reviewing the changes to hopefully get it landed today
<jam> at least as a dev format
<gour> jam: great. you working tirelessly to improve bzr
<gour> i'm waiting to finish some written assignments (still under darcs) and then we'll conduct a big darcs --> bzr migration
<jam> we try, I do get tired sometimes :)
<kumi_> wow, more sexy new features :)
<pickscrape> The rate and quality of work done on this project astounds me.
<gour> jam: hopefully you don't code too much when getting tired ;)
 * gour agrees with pickscrape 
<pickscrape> I think that's testament to the tool too, which presumably helps a great deal :)
<jam> naw, that's when I review code :)
<jam> pickscrape: well, we have some decent processes in place. Though honestly as a developer it is a slightly different view
<jam> *big* changes are easy because of our process
<jam> *small* changes end up with a lot of process overhead versus their actual impact
 * gour hopes to become somewhat familiar with python to be able to help a bit in the future. for now we're busy working on a haskell (project)
<jam> 11,000 unit tests can be a great thing, and can be a bit of a pain at the same time :)
<pickscrape> :)
<pickscrape> Our developers have a simple solution to that problem: don't write them and don't bother to run them.
<schierbeck> you guys know if there's a bzr-svn ppa?
<Peng> bzr-svn is in the main bzr PPA.
<beuno> AFAIK, that version doesn't work the bzr 1.5, which is the version in PPA
<beuno> but jelmer would know best
<schierbeck> ok
<schierbeck> i was hoping there was a more recent version
<Peng> Yeah, ppa compatibility sucks.
<Peng> Well, in this case, it's not the ppa's fault really, but still. :P
<jelmer> bzr-svn isn't in PPA anymore
<Peng> Oh?
<Peng> Where is it?
<jelmer> the only packages available are my packages for Debian Sid (http://samba.org/~jelmer/debian)
<schierbeck> cool
<schierbeck> what about bzr-avahi?
<schierbeck> can't find a ppa for that either
<jam> new this week post
<jam> for those who want there news right away
<jam> http://jam-bazaar.blogspot.com/
<pickscrape> jam: an interesting read, and something for us to think about when we come to migrate to bzr
<bimberi> jam: Thankyou.  I look forward to seeing how Elliot is described each week. ;)  You've invented "pair-blogging"!
<jam> yeah, statik is pretty creative in that regard
<jam> In our case, the pairing is mostly out of necessity, I tend to write too much or too little
<jam> statik is good about helping to make sure it isn't all just a stream-of-consciousness out of me
<jam> and he is certainly better about humor
<statik> aw shucks
<bimberi> :)
<pickscrape> I tend to ramble bit time when I write.
<pickscrape> big time
<lifeless> moin
 * beuno hugs bzr shelve/unshelve
 * pickscrape wonders why the shelf isn't core
<beuno> mwhudson_, howdy    :)
<mwhudson_> beuno: i hate my isp
<beuno> mwhudson_, I think most people here do   :p
<beuno> ever thought about irssi on a server somewhere stable?
<mwhudson_> as of this morning, we're moving house though, hopefully the connection will be more stable there
<mwhudson_> beuno: yes i have, but not done anything about it
<beuno> mwhudson_, if you don't like irssi, there is ircproxy, which is client-agnostic
<beuno> but, if you're moving, that may help
<bob2> irssi_proxy is quite spiffy
<beuno> mwhudson_, anyway, I've been poking at loggerhead from a "clean it up" point of view, and I've found that it uses args/kwargs quite inconsistently. I'd like to mode everything to kwargs, unless you have something against me doing thath
<mwhudson_> beuno: you mean in urls?
<beuno> mwhudson_, yes
<beuno> in some cases, it uses /revision/, and, in some /revision?values=random
<mwhudson_> yeah, it's not great
<mwhudson_> beuno: on a call now, i'll get back to you in a few minutes
<beuno> (as a side effect, using args let's you use wget/curl, but there has to be a better way around it)
<beuno> mwhudson_, sure, no hurry
<lifeless> beuno: ? is less likely to be cached in general
<lifeless> beuno: and you can use wget/curl with ? just fine
<beuno> lifeless, in respect to ?, do you mean that as a good thing, or as something bad?
<beuno> and, I can't seem to get loggerhead to recieve any ? parameters from wget/curl
<beuno> actually, looking deeper into it
<beuno> I only get the first parameter
<beuno> not the subsequent ones with &
<lifeless> beuno: put '' around the url
<lifeless> & is a shell metachar
<lifeless> :)
<mwhudson_> beuno: i bet this is a shell issue or something
<beuno> lifeless, argh, thank, works. mwhudson_ told me yesterday, but it didn't seem to work, so I may of had a problem in the code
<beuno> ok, good, back to more reliable benchmarks now  :)
<mwhudson_> beuno: so, i actually quite like having the revision, at least, in the path part of the url
<mwhudson_> if i was starting again, i'd probably have:
<mwhudson_>  /branch/path -> changelog view
<mwhudson_>  /branch/path/$revno -> revision view
<mwhudson_>  /branch/path/$revno/path/to/file -> annotate view
<mwhudson_>  /branch/path/$revno/path/to/dir -> inventory view
<mwhudson_> i think having the "restrict to revisions that touch some file" as a query arg makes some kind of sense
<beuno> ok, 3 sec to generate a 36k line diff in bzrlib, 20sec to apply the template and return. It outputs a 7mb file, which is considerable. We should be able to cut that down with proper CSS/HTML.
<lifeless> ><
<beuno> mwhudson_, that sounds like a good structure, and add kwargs for any filters we may want/need
<mwhudson_> beuno: what are the comparable numbers for trunk?
<mwhudson_> (if you have the RAM to repeat the benchmark...)
<beuno> mwhudson_, well, I can't compare, since trunk generates a diff for each file, twice
<lifeless> so
<lifeless> nested trees
<beuno> mwhudson_, my PC chokes at ~20k diffs with trunk, if that serves for comparison
<mwhudson_> beuno: heh heh
<beuno> the diff uses 100-150 RES memory, and it's mainly the templating engine
<beuno> we could probably improve it a *lot* if, instead of a per-line loop, we had a per-column loop  (3 columns)
<beuno> but I'd expect some work would need to be done in order to get CSS to show that properly in many scenarios
<beuno> anyway, lots of room for improvement, but, the current branch is a major improvement over trunk, in resource usage
<mwhudson> right
<mwhudson> i'm sure our admins would like a three orders of magnitude improvement more than a three fold improvment
<mwhudson> but they'll be happy with what we've got already, i'm sure
<beuno> mwhudson, I have many ideas, so it's hard not to drift away. I'll focus on getting this approach cleaned up for review, and plan the next step after that
<mwhudson> thanks
<beuno> I even have the html/css for the new theme partly ready, which I will play around with until we can adapt it's current design to what will actually be used
<mwhudson> so why does bzr push-ing a new branch very very occasionally create a branch reference instead?
<igc> morning
<lifeless> mwhudson: bleep, it shouldn't because you can't actually open a branch reference
<lifeless> (they resolve at open)
<lifeless> there was, once, a bug
<mwhudson> lifeless: yeah, it certainly shouldn't
<mwhudson> lifeless: https://pastebin.canonical.com/5889/ (apologies for the private url)
<lifeless> you should apologise for openid instead
<lifeless> your bash history may help reproduce
<mwhudson> i deleted the branch and pushed again, it worked fine this time
<poolie> good morning lifeless, all
<mwhudson> i know this happened to thumper a week or so ago
#bzr 2008-06-06
<lifeless> hi poolie
<awilkins> Hey, how come there's a VCS flamewar going on on Slashdot and no-one mentioned Bazaar so far ?   http://bsd.slashdot.org/article.pl?sid=08/06/04/1749233
<lifeless> because we actually do stuff?
<awilkins> :-P
<RAOF> Heh.  Begins switch to subversion.
<awilkins> It is a step up from CVS, I suppose (although someone points out all the core devs use Perforce
<lifeless> its worse than cvs in many ways
<lifeless> its user model particularly
<lifeless> however, it scales better than cvs
<RAOF> But it's easier to work with svn than cvs in a dvcs, I believe.  So it's a step up in that respect :)
<lifeless> RAOF: not at all
<lifeless> cvs these days has atomic changesets believe it or not
<RAOF> lifeless: So my lack of exposure to bzr-cvs is due to my lack of exposure to cvs?
<lifeless> no, its due to old cvs data still being a pillock ;)
<RAOF> Right :)
<lifeless> bzr cvsps-import does exist and do a decent enough job though
<lifeless> (my point being that you could just cleanup the tree and go from there)
<lifeless> oh, also don't forget cvsup - distributed cvs ;)
<lifeless> poolie: call over ?
<jam> lifeless: not quite yet
<lifeless> bbiab
<lifeless> -> doctors, back, well, later
<Zelut> I would like to create a bzr trunk on a private server to backup my home folder. Can anyone point me to some docs on how I might do that?
<kumi_> Zelut: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#branching-a-project
<bob2> I don't think bzr is a very good solution for backing up your whole home dir
<Zelut> bob2: well mainly what I'm looking for is archiving and tracking my .folders, and upon a fresh install just being able to branch my ~ and be done.
<bob2> storing all your config files and documents etc works well, though
<Zelut> bob2: seems simpler to branch that and get my .ssh, .gnupg, etc than manual backup/restore each time.
<bob2> I'd be weary of putting ssh and ngupg private keys in, but I do version all my dotfiles
<Zelut> bob2: kind of like /etc/skel I guess, but just requires branching.
<bob2> er, wary
<Zelut> I've been using bzr with LP but I'm unsure how to create a trunk on my own machine is the main problem.
<mwhudson> Zelut: bzr init path/to/branch
<Zelut> mwhudson: lets say I've got a folder locally that I want to push to a remote server and then be able to branch from remote in the future, what else do I need?
<mwhudson> bzr init in the folder
<mwhudson> bzr add to add the contents of the folder
<mwhudson> bzr commit to record these files
<mwhudson> bzr push to the server
<mwhudson> that's it
<Zelut> I swear I had done that before but all I have on remote is .bzr with no contents.
<bob2> that is indeed what push does
<bob2> unless it is pushing to a local directory
<bob2> you can a) leave it, since you can still branch from that remote one fine, b) manually 'bzr co' in the remote dir after each push or c) install the 'up-afte-rpush' plugin that does b automatically
<Zelut> so I could branch from remote and get those files, even though they are not listed there?
<bob2> (https://launchpad.net/bzr-push-and-update)
<bob2> yup
<Zelut> interesting.  I figured I had done something wrong because I didn't see anything on remote.
<Zelut> well how 'bout that. bzr co and its all there.  bzr is some magical voodoo :)
<Zelut> is there a preferred method of defining bzr whoami? .bashrc or..?
<bob2> using bzr whoami
<Zelut> I mean, does 'bzr whoami joe hacker <email@server.org>' define it long-term or per-session?
<bob2> it writes it to ~/.bazaar/bazaar.conf (so per-machine)
<Zelut> perfect.
<poolie> spiv: if mhammond comes up here in the 16th do you think you'll be free?
<spiv> poolie: yes
<jml> poolie: has there been a change in plans?
<poolie> jml, he can't get a meeting room at the hotel that week
<poolie> so we can either meet at my house or postpone it
<jml> ahh ok.
<poolie> jml, were you wanting to come for most of that time
<jml> poolie: yeah, I was.
<poolie> spiv, jml, how would the week of the 23rd be?
<jml> poolie: pretty god.
<jml> good.
 * jml smiles
<spiv> poolie: that's fine too
<lifeless> back
<emgent> hi lifeless :)
<lifeless> hi
<poolie> oh you're back already? time flies
<lifeless> got lucky, only 10 minute wait
<jml> that is lucky
<jml> in fact, if you had witnesses, I'd suggest sending an email to the Guinness Book of Records :)
<lifeless> for that doctor its amazing
<lifeless> usually 2-3 hours
<mneptok> lifeless: yes, please do (continued from -ops)
<mneptok> O:)
<lifeless> terrible man
<mneptok> lifeless: although my personal motto is "non universim sed singulatem fretus," which has a far more lapidary tone.
<lifeless> Sempre utor ubi-bracae perhaps
<lifeless> also mneptok whats with the no-idling attitude?
<mneptok> lifeless: channel rules
<mneptok> lifeless: i have no idea what caused their creation, though.
<abentley> lifeless: Any thoughts on whether it is kosher to mutilate the in-memory inventory of a DirStateRevisionTree?
<abentley> I.e. to feed it to apply_inventory_delta?
<lifeless> mmm
<lifeless> so what we do is try to either modify the dirstate, or the inventory, but never both
<lifeless> the inventory is re-flattened on unlock() if it has been modified (as checked by a flag in WorkingTree4)
<lifeless> thats for the wt; uhm for a rev tree
<lifeless> the in memory inventory is cached
<lifeless> if you modify it, other callers asking for it will get the same modified inventory. This could be bad.
<abentley> Half of igc's branch speed gain comes from using the existing InventoryEntry objects, rather than re-calculating the data from the TreeTransform and working tree.
<abentley> Is there a way to do this safely?
<lifeless> this is new clone ?
<lifeless> or build tree?
<abentley> This is build_tree.
<lifeless> where is the dirstate rev tree coming into the picture? (I would have thought we grabbed a repository inventory ...)
<abentley> The dirstate rev tree is the basis tree of the branch we are branching from.
<abentley> When that revision isn't available as a basis tree, we do use a repository-backed RevisionTree.
<abentley> If the source branch has a working tree that we can use, we use it to retrieve files from disk instead of the repo, which I've benchmarked as faster.
<lifeless> ok
<lifeless> so what do we need from the inventory - do we have an iterator we can use without upcasting from dirstate to a full inventory in the first place ?
<lifeless> (making an inventory is slow in the first place)
<lifeless> I realise I'm not directly answering the question. To directly answer it - add a private method to detach the inventory from the dirstate rev tree, then you own it can do $whatever you want to.
<abentley> We are using iter_entries_by_dir which I don't believe creates a new inventory.
<abentley> But if the cost of generating an inventory is in constructing the objects, then it's just as expensive.
<abentley> Which is an unavoidable cost.
<abentley> Given the input requirements of apply_inventory_delta.
<igc> abentley, lifeless: the meta-question I had while profiling local branch creation was ...
<lifeless> the major cost when I looked deeply at inventories was simply creating xK objects and stitching them together
<igc> given a pristine local mirror, can you reuse the source dirstate to get the target one fast
<igc> both apply_inventory_delta and set_parent_trees suck when run on an OOo tree
<abentley> igc: pristine shouldn't matter.
<lifeless> in principle you can copy the dirstate basis column to an output dirstate with a iterator and filter (to remove renamed/deleted/added rows) duplicating entries to create current-disk values
<lifeless> igc: apply_inventory_delta should be good because it generally has to deal in 10's of objects not 10's of K of objects
<igc> lifeless: on branch, the delta is the whole 100K entries
<abentley> lifeless: apply_inventory_delta is used by build_tree when creating inventories from scratch.
<lifeless> yes, I can see that. to me this comes back to 'python is slow, whats the best way to work around it'
<abentley> subprocess.cmd('cp -a')
<lifeless> some benchmarks might be good to check I actually drew the right conclusions (e.g. create a 100K inventory 50 times)
<lifeless> abentley: I mean of the python primitives we have available'
 * igc lunch
<abentley> I can tell you that when building emacs, WorkingTree4._get_inventory is 2% of total runtime, and apply_inventory_delta is 3%.
<abentley> That's according to kcachegrind, of course.
<lifeless> righto, step 1 - gather stats :P
<lifeless> how big is emacs btw ?
<abentley> 400M
<abentley> Sorry, 105M
<abentley> With my current patch, actually reading and writing the tree files dominates.
<igc> that's good
<igc> I was seeing 20-25% on the iter_changes over the accelerator tree
<abentley> That's bad.  I haven't changed anything that should have affected that.
<igc> abentley: there's a mozilla repo in http://people.ubuntu.com/~ianc/benchmarks/repos/bzr/ that I was profiling against fwiw
<igc> it's a good size without being crazy
<abentley> igc: Thanks.  I'm pulling that down.
<abentley> I also worry that we might be optimizing for the wrong case.  We tend to benchmark against hot cache.
<abentley> But when branching, the branch source is likely to be cold cache.
<lifeless> I would expect branch source and repository to both be cold
<lifeless> abentley: you know you can drop caches right?
<abentley> Yep.
<igc> abentley: I agree that cold cache is the more important time
<abentley> igc: Which have you been testing?
<igc> hot cache is important though: it's what most people benchmark the tools on, and it highlights what we have most control over
<igc> io patterns aside
<igc> I've been using hot cache
<abentley> What would cause our extensions to get compiled with -Wall?
<Pieter> CFLAGS=-Wall
<abentley> Pieter: It's not set.
<jamesh> abentley: see /usr/include/pythonX.Y/config/Makefile
<jamesh> distutils gets some flags from there
<abentley> jamesh: Thanks.
<jamesh> including -fno-strict-aliasing and other necessary ones
<abentley> Turned out that wasn't the problem after all.
<abentley> It was the lack of libc6-dev...
<jamesh> actually, that should have been /usr/lib/pythonX.Y/config/Makefile
<igc> Pieter: apologies for not getting to your fastimport/export questions/improvements - knee deep in the stacked branches reviews right now. Will do soon though.
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> oh, ringing you :P
<spiv> lifeless: oops, my cheek mashed the "hang up" button
<igc> lifeless, poolie: all the stacked branches reviews/tweaks sent to the ML now
<igc> ml: see test_branch_shallow_branch_also_shallow_same_reference() in the patch
<igc> jml^^
<jml> igc: has this changed from lifeless's branch of two weeks ago, or is this a difference between API and UI?
<beuno> mwhudson__, I know your day is about to finish, so these are the benchmarks against loggerhead trunk, your zpt branch, and my zpt branch, for the same 36k diff:  trunk, real 1m38.033s, 400mb+ RES mem.  Your zpt, real 0m35.243s, 220mb RES mem. My zpt, real 0m23.116s, 120mb RES mem.
<beuno> so it's more like a 8x improvement to the current trunk
<beuno> I can still shave a few seconds/mb off of it once I finish refactoring some un-needed operations, and it's missing tests. But it's looking good  :)
<igc> jml: it doesn't look like the UI controls this so I'm guessing it done under the API - will dig
 * gour just read latest from bzr ml
<jml> igc: the patch I sent you for clone() addressed just this behaviour.
<gour> having gnome on bzr, won't be bad...
<jml> igc: it's possible that I'm confusing things, given my relatively shallow (no pun intended) knowledge
<igc> jml: I can't apply your patch yet sorry - I think it needs abentley's policy stuff first?
<jml> igc: yeah, that makes sense. I was working against abentley's branch.
<jml> igc: I've sent it to him to apply.
<Pieter> gour: I wonder how they decide
<jml> igc: if he bounces me, then I'll redo it for bzr.dev once your patches have landed.
 * beuno is off to bed
<gour> Pieter: me too, but it's better that bzr become ready if something can be done with 1.6 release taking into consideration their needs
<gour> see http://guadec.expectnation.com/guadec08/public/schedule/detail/81
<abentley> jml: That patch seems like it could do serious harm.
<Pieter> seems a bit odd to rush a feature so that some party may perhaps choose bazaar
<jml> abentley: can you please elaborate?
<abentley> jml: If I branch, I expect to have everything I need.
<lifeless> Pieter: I'm not rushing the feature - I've been hacking towards all the bits coming together for months
<abentley> If I push, the resources I have locally may not be available to all users.
<lifeless> Pieter: I'm trying to ensure its not stuck in trunk with 3 weeks to go at a point where it may be extremely relevant for discussion
<gour> lifeless: sure. if stacked branches go into 1.6 and everything can be polished a bit, i do not object waiting for 1.6 some week more
<lifeless> Pieter: also, to invert things slightly, it would be strange not to work on the things that our users seem to want most :P
<jml> abentley: are we talking about my patch or the UI2 patch?
<gour> otoh, having  big(ger) party using bzr is very good for bzr 'cause new  workflows and/or user-cases are explored leading to bzr improvement in general
<abentley> jml: Your patch.
<gour> s/bzr impr./bzr's impr.
<abentley> It causes stacking without user intervention, no?
<jml> abentley: it preserves stacking without the users intervention
<abentley> Tomato, potato.
<lifeless> jml: preserving stacking is surprising, it doesn't fit our current behavioural model
<jml> abentley: ok. I don't pretend to have a deep understanding here but it seems like a good idea for 'BzrDir.clone' to clone
<jml> lifeless: given that I wrote the patch based on your guidelines I'm more than happy to withdraw support for it if you no longer think it's a good idea, conditional on me understanding why.
<lifeless> oh - clone() should clone() for sure
<lifeless> abentley: bzr branch uses sprout
<abentley> lifeless: push uses clone.
<lifeless> abentley: yes; hmm
<lifeless> so the case that identified this was 'how does launchpads hosting service clone a shallow branch most appropriately'
<lifeless> (without rewriting clone())
<abentley> lifeless: paramaterize clone to preserve stacking?
<abentley> lifeless: Alternatively, does push *need* to use clone?
<lifeless> well clone fits push much better than sprout IMO
<lifeless> actually, this is high up the merge stck
<abentley> Neither of them is exact
<lifeless> I'm going to head-down and finish the current patch
<lifeless> then I will have many more cycles to think
<abentley> lifeless: fairy nuff.
<abentley> jml: I can adjust the patch so the behaviour is optional.  Does that appeal?
<jml> abentley: it fits my use case, certainly
<jml> abentley: the deeper bzr model issues I can leave to the experts :)
<abentley> done.
<jml> thanks.
<abentley> jml: Your patch's stacked_on selection will be overridden if there is a configuration directive.  Is that what you expected?
<jml> abentley: no, it isn't.
<abentley> i.e. if the user has a .bzrdir/config with a default_stacked_on set, your patch has no effect.
<abentley> Okay then, I think we can simplify the patch.
<lifeless> abentley: what jml wants is to be able to do - in the puller:
<lifeless> if (we dont have the branch)
<lifeless>   local_branch = remote_branch.bzrdir.clone(options)
<lifeless> and thats about it
<abentley> lifeless: Yeah, I have a fairly good idea of the use case.  I just wasn't sure whether that was a deliberate choice.
<lifeless> abentley: :)
<abentley> jml: Some examples of how BzrDir.clone doesn't clone:
<abentley> 1. if the target has a shared repository, it always uses it
<abentley> 2. if the source is in a shared repository and the target isn't, it creates a target as a standalone branch
<abentley> 3. it doesn't create remote working trees
<abentley> Perhaps clone is simply misnamed.
<jml> abentley: hmm.
<jml> abentley: the evidence is certainly mounting
<abentley> jml: As another example, when you branch a subversion branch, bzr-svn doesn't create a Subversion repository.
<abentley> It's really more like a mimeograph than a clone.
<lifeless> branch uses sprout though
<lifeless> so that other example isn't one ;)
<abentley> lifeless: Sorry, "push from"
<lifeless> abentley: can you actually push from a svn branch though? I didn't think they existed on disk, only conceptual branch references
<abentley> lifeless: I haven't investigated.  But I would assume push -d will specify a subversion branch.
<lifeless> oh interesting
<poolie> ok i'm starting to merge the external reference patch
<chandlerc> what would cause a NotBranchError when using bzr-svn on a previously working repository?
 * igc pick up kids
<lifeless> i'm callin it a week
<lifeless> 5:30 time to crack a beer I think
<poolie> cheerio lifeless
<lifeless> might see you online :P
<lifeless> otherwise tuesday
<poolie> once i finish cleaning this up
<poolie> btw mark is confirmed for the week of the 16th
<poolie> uh
<poolie> if you want to reply on tuesday to my mail re scenarios that would be cool
<poolie> if only to say +1
<lifeless> sure
<poolie> igc: i think you forgot the attachment?
<igc> lifeless: if you're still around, abentley has suggested using a path in branch.conf vs a new branch format
<igc> is that the plan for making stacked branches production?
<igc> poolie: thanks. fixed.
<igc> lifeless: abentley had a bunch of other good feedback as well that I found today (post my review overnight). I think we should include most/all of his suggestions.
<lifeless> igc: if I understand the proposal correctly, its a bad idea, it will break, badly
<lifeless> its definitely not the plan - a new branch and repository format is required
<uws> Hi all.
<uws> Does anyone happen to know whether the Fedora Core 8 subversion packages contain the necessary patches for bzrsvn to work?
<lifeless> igc: however abently proposed using a branch.conf key rather than a new *file* for storing where things are stacked
<lifeless> igc: and that was a good idea
<lifeless> uws: the bzr-svn test suite can detect them
<igc> lifeless: ah - ok. Here was the thread: https://lists.ubuntu.com/archives/bazaar/2008q2/040079.html
<lifeless> uws: install it, run bzr selftest svn
<lifeless> igc: I'm really just passing through
<lifeless> igc: this can wait till tuesday
<igc> lifeless: enjoy your beer. I'm off to cook dinner. Have a good weekend all
<uws> lifeless: Installed Subversion version does not have updated Python bindings. See the bzr-svn README for details.
<uws> lifeless: Too bad :(
<uws> lifeless: I'll have to update/compile svn myself. Would you suggest the latest stable 1.4 release + the patch, or svn trunk instead?
<gour> bzr is quite ok at http://live.gnome.org/DistributedSCM
<gour> uws: svn-1.5rc9?
<uws> gour: http://bzr-mirror.gnome.org/
<gour> uws: ohh, nice. it means it's a serious candidate
<lifeless> uws: there is a faq about this, bazaar-vcs.org/svn I think
<uws> lifeless: you mean http://bazaar-vcs.org/BzrForeignBranches/Subversion?highlight=%28bzr-svn%29#python-subversion-1-5 ?
<uws> lifeless: It only lists the patch, but doesn't suggest which one to use
<Jc2k> uws, gour: bzr-mirror.gnome.org is my baby if you have any questions about GNOME and bzr...
<uws> Jc2k: Ah. haven't used it personally yet
<uws> though I use bzr mostly, my gnome development happens using svn for now
<gour> Jc2k: i do not use gnome myself (only xmonad + xmobar), except some gnome apps, but would like to see gnome adopts bzr
<uws> dunno what the jhbuild support for this is
<uws> gour: /me too :)
<Jc2k> uws: thats my other project ;)
 * gour hopes that this overly-complex-easy-to-shoot-oneself-in-the-foot VCS won't prevail
<uws> Jc2k: rock on :)
<Jc2k> git-mirror.gnome.org is also coming by the way..
<uws> i've never used git. it
<uws> 's interface is horrible
<uws> its*
<Jc2k> agreed
<Jc2k> i mirrored about half of GNOME in 2 days, then realised it was wrong
<uws> i don't care about the kernel hackers' opinion that much
<Jc2k> i have to start from scratch
<Jc2k> so i have a few questions actually
<Jc2k> there are a few thing the GNOME GIT people do, and are likely to whine about if they can't with Bzr
<Jc2k> (regardless of whether they are good ideas or not)
<Jc2k> is there an equivalent to git rebase --interactive
<james_w> Jc2k: nope, it needs someone to spend some time on the rebase plugin
<Jc2k> james_w: i guess its not something that a bazaar code newb such as myself can really approach, either?
<james_w> Jc2k: actually, I think it should be possible.
<Jc2k> oh?
<james_w> I would hope that the rebase itself would be demonstrated by the existing code in the plugin, and it would just be a case of coding the interactive stuff, which hasn't got a lot to do with bzrlib
<james_w> I may be being optimistic, but we would certainly help you if you wanted to give it a go.
<Jc2k> i was wondering if it was maybe better as bzr-refactor as i don't think hacking apart your branch is really the same as rebasing, but yes.. am interested in giving it a go
<bob2> bzr-resequence?
<james_w> Jc2k: I think "rebase --interactive" would be the way to go, as diverging from git here would probably just cause confusion.
<Jc2k> ok
<Jc2k> james_w: would a bzr-gitmode pluging be possible that emulated the git wc/repo/branches model?
<bob2> you could do it as a repo format
<Jc2k> there was a suggestion that someone could make a bzr-loom without the stacked looms bit
<james_w> Jc2k: yes, it would be possible.
<james_w> Jc2k: bzr-git allows you to work with git using the bzr ui, but it would also be possible to write a plugin that gave multiple branches in one directory.
<Jc2k> james_w: its the 2nd one that i'm after
<Jc2k> oh, is there any way to pull a whole repo?
<bob2> multi-pull plugin
<Jc2k> bob2: can that pull branches that i haven't already branched?
<lifeless> jamesh: jhuild groks bzr yeah ?
<jamesh> lifeless: I did some bzr support code way back, but I don't know if it is still in a working state or not
<jamesh> if it isn't working, it should be trivial to fix
 * AfC tried to get that to work, oh, 8-9 months ago, but I couldn't make it go. I'm not a regular jhbuild user, so it may have been something else.
<AfC> [the mapping or repository's type & href attributes to a Bazaar URL and the branch element being inside an autotools (which we don't use) one made it all a bit vague]
<jamesh> AfC: the nesting of the elements actually matches the modularity of the code
<jamesh> AfC: the autotools build rules can have various VCS backends plugged in to grab the code (including "download and extract the tarball" VCS)
<jamesh> there are other sets of build rules (e.g. Python distutils) which use the same VCS backend code
<AfC> Oh, I don't doubt its design makes sense, but I couldn't grok it is all.
<Jc2k> AfC: i'm going to look at some "bzr-mirror and jhbuild" notes
<AfC> Jc2k: yo dude
<Jc2k> :)
<AfC> Here, let me pastebin what I wrote
<AfC> http://rafb.net/p/f3e70j67.html
<AfC> Jc2k: (note this is slightly different from "I want to use bzr to work with GNOME modules currently living in Subversion"; I wanted to add java-gnome to the GNOME jhbuild modulesets but couldn't quite figure it out)
<Jc2k> AfC: sorry, i think i phrased what i said badly - i'm going to add some notes to the bzr part of live.gnome.org about jhbuild and bzr
<RainCT_school> Hi
<lifeless> so, rebase -i - I think that a low entry point one that is a clone of gits should live in the rebase plugin
<lifeless> james_w: bzr-git is not that complete fwiw
<james_w> lifeless: hi. ah yeah, I know that, but I was just wondering what functionality they wanted.
<lifeless> Jc2k: yes, multi pull can replicate a full set of branches
<lifeless> Jc2k: I think its important to remember though 'the way git does it' is what contributes to the feeling you had that it wasn't the right thing when you played with it :P
<lifeless> Jc2k: so we want to be somewhat careful about dropping git workflow in wholesale - providing plugins for git users that don't want to change is definitely possible though
<Jc2k> lifeless: yeah, its more about eroding pro Git arguments by supplying plugins for their workflows
<RainCT_school> what's the easiest way to configure bzr on a server so that it can be used over bzr-ssh://?
<AfC> Jc2k: It was a shame to see that the imendio guys are using Git. So that means its probably too late for GTK, though if anyone respects letting others work together its them.
<gour> RainCT_school: install it so that's in the path
<AfC> RainCT_school: assuming you have Bazaar installed on the machine in question, there's not really anything further you need to do. It'll Just Workâ¢
<spiv> RainCT_school: the URL prefix is bzr+ssh:// rather than bzr-ssh://, btw.
<spiv> s/prefix/scheme/ to be precise I guess.
<AfC> spiv: good catch
<RainCT_school> Oh, OK. Commit privilegies just depend on the SSH configuration / system users then?
<RainCT_school> spiv: yeh.. bad memory ^^
<spiv> RainCT_school: Right, ordinary filesystem permissions.
<RainCT_school> great :)
<RainCT_school> thanks
<RainCT_school> well, gonna go. bye!
<gour> AfC: gtk will move to git?
<Jc2k> gour: a lot of GTK hackers are already using it, which means its harder to get them to bzr
<gour> :-(
<gour> one reason more to try get gnome
<Jc2k> gour: but they are using it in an unoficial capacity, much like the other GNOME hackers like me and AfC are using bzr-svn
<AfC> Jc2k: not exactly. They are using Git exclusively for their 3.0 work. Whether or not that ever makes it back to Subversion remains to be seen.
<Jc2k> gour: GNOME will be providing some "experimental" hosting for bzr branches, though :)
<AfC> Between them and the Cairo / Pango people, I'd say it's probably a lost cause. But we can keep trying.
 * gour has hard time to understand why people love git...powerful? yes. but utterly complex model which stands on the way
<AfC> gour: because its fast, because it handles things like families of branches as single units, and because other projects they are familiar with use it. These things are viral.
<AfC> s/its/it's/
<Jc2k> its not entirely a lost cause, git has no backing from a sysadmin. the git people need to provide a volunteer to ensure smooth operation of git.gnome.org.
<AfC> gour: and, don't forget, these people are all power users.
<AfC> Jc2k: at this point, with Imendio and Codethink and Collabora all hosting their own git repos, someone hosting a git.gnome.org is somewhat less relevant. Yes, Olav is on our side, but he's a sysadmin, not a hacker.
<gour> i understand that...but, e.g. families of branches are just one reason why i prefer bzr (coming from darcs)
<Jc2k> AfC: With a bzr-rebase --interactive, codethink can be turned.
<AfC> Jc2k: :) I forced Rob to use bzr to make some fixes to java-gnome. That got him started, at least.
<Jc2k> AfC: :p, Rob said he'd be willing to give bzr more of a look with rebasing.
<AfC> Fact is that's just the way a lot of people look at distributed version control. It's getting on towards pointless to tell them that they're wrong. I understand and accept the arguments made by the bzr hackers about history loss, but most people don't seem to care that much because it hasn't burned them so far as they can see.
<gour> right, no change until getting burnt
<gour> same here...i had few serious issues with darcs
<lifeless> AfC: I understand why git users rebase now better than I used to.
<lifeless> AfC: its because their  log is broken.
<lifeless> (it sorts by date not by branch, so if you imagine 10 branches, each that last a week, all merging to mainline one after another,
<lifeless> if they have 10 commits each
<lifeless> and spread equally over that week
<lifeless> then git log does:
<lifeless> branch1-commit10
<lifeless> branch2-commit10
<lifeless> ..
<lifeless> branch10-commit10
<lifeless> branch1-commit9
<lifeless> ...
<lifeless> branch10-commit9
<lifeless> ...
<AfC> Ouch
<lifeless> now imagine trying to understand what has happened when you see that output
<AfC> [of course, I am on record as being terribly unfond of `bzr log` but mostly `bzr viz` makes up for it]
<jamesh> lifeless: apparently bisection techniques are easier with linear history too
<AfC> lifeless: so, from a marketing standpoint, can you just say "bzr doesn't need rebase because our logging works right"?
<lifeless> jamesh: its easier if you don't think about it :)
<lifeless> AfC: well, I can say 'bzr doesn't provide the same anti-social pressure that makes rebase so important to git users'
<AfC> lifeless: (that would be something really concrete for the compare and contrast crowd)
<lifeless> or even remove the word anti-
<jamesh> I think the only time I've really used the bzr-rebase plugin was to move some commits that had been made to the wrong branch
<jamesh> basically a cherry picking operation
<lifeless> to enlarge on the social pressure
<lifeless> you want every commit to be as stand-alone as possible
<lifeless> small tweaks that are part of a bigger picture become unhelpful unless they are really well documented
<lifeless> you may also want the dates of each commit to be close together as this be more likely to group the commits in log
<lifeless> and this fits quite well I think, wit what I see git using projects asking for
<pbor> personally I'd very much like rebase in combination to some way of "rewriting history"
<pbor> that is, I branch, work without minding much about about things on a branch (commits, trial and error, revert, etc)
<pbor> then before merging to the master branch, rebase to the current head and rework the "branch" as a logical series of changes
<lifeless> thats largely the quilt workflow
<AfC> pbor: You might find that the loom thing that Robert and others supports that development style.
<lifeless> and there is some user demand for loom to support this more directly
<AfC> s/others/others are working on/
<pbor> which make history very good to read (not only the log, also the diffs)
<AfC> I must admit I'm a bit vague on why one needs looms in an environment where people are already being encouraged to make lots of little inconsequential commits anyway
<lifeless> loom is specificall designed for collaborative quilts, if I can coin a phrase
<jamesh> it also helps create the illusion of infallibility :)
<AfC> jamesh :)
<AfC> That said, I must admit I am often hesitant to make micro commits in the face of needing to set the example to  encouraging others to send me good quality patches with well written commit messages.
<pbor> AfC: it is useful because I can work on a branch as I like, but then submittit as a logical and clean series of consecutive and evolutionary patches
<jamesh> the testing angle is the biggest problem I have with rebase
<AfC> jamesh: yeah, I buy that one now too
<lifeless> AfC: so perhaps you don't need such good quality (individual commits) and well written (individual commit messages)
<AfC> lifeless: I'm not sure about that
<lifeless> AfC: and perhaps could instead want good quality (merges) and well written (merge commit messages)
<lifeless> this is all the the bzr project *itself* looks for
<AfC> tools like viz and gannotate make sense when the meta data they display has some relevance to the code in question.
<lifeless> thats true
<AfC> lifeless: [well, since I'm the poor shumck who does the merges, yes, I try to do that as best I can.
<lifeless> the barrier for that is relatively low though, in large part because of the topological grouping of data
<AfC> The point being made here, though, is sorta standing out in my current experience as a sore point]
<AfC> Its almost like I wish for something to "roll up" a series of revisions into a single "commit". YES I realize that merges can fill that function, but there are lots of other merges that happen too.
<lifeless> you know about log --line ?
<AfC> (and I don't feel like being the only person who has to write good commit messages, which is why I am so completely frustrated with the fact that `bzr log --line` only prints left hand most revisions
<AfC> Its almost enough to make me go use something else I hate it so much)
<lifeless> AfC: so what I am saying is require that the *submission* contains the pre-written commit message, and make it a good one
<AfC> lifeless: right, so that's what you guys do with bug bunny, but that's out of band to the VCS tool
<AfC> which seems a serious oversight.
<AfC> (ie, it's nice that you gents have it all nice and sorted, but it doesn't help anyone else who has the temerity not to use your PQM code management model)
<AfC> (ie, everyone else trying to use bzr)
<AfC> {shrug} these are my pain points.
<AfC> I point these out only because a) they've been my pain points more or less since the beginning [that and no cherry picking], and b) they're my *only* pain points to what is otherwise an excellent experience.
<pickscrape> I had an idea the other day for a log format that showed only the 'leaves'. I wonder how useful that would be.
<AfC> lifeless: I have more or less come around to abandoning revision commit messages and asking people to edit a ChangeLog file instead. I was so happy not having to have people do that over the last 2 years, but...
<AfC> pickscrape: (that would seem to assume that all of the mainline commits are merges, which may not be accurate either)
<lifeless> AfC: so, I have been mulling having a editable merge-message in branches
<lifeless> AfC: for precisely this reason
<AfC> lifeless: that's an interesting notion
<pickscrape> Any mainline commit that is not a merge would be considered a leaf.
<AfC> pickscrape: (ah)
<pickscrape> In fact, the point is only show non-merge commits
<AfC> pickscrape: well I'd love that personally, because then my projects would look like they were written by the people who wrote them, and not all "Andrew Cowie"
<pickscrape> It's like --short, but where you have a merge, substitute it with the commits that made up the merge
<pickscrape> Grossly simplified of course, but that's the idea
<lifeless> AfC: log should be taught to honour --author
<lifeless> AfC: vs committer, we do differentiate; hmm is there a bug on that
<uws> lifeless: It seems log shows the author
<AfC> pickscrape: [though along the way I got into the habit of also making real changes during merges until I finally learned that this wasn't helping and Robert showed me a few other ways to do it]
<pickscrape> Hmm, changes made during the merge would be a problem with such a format
<AfC> lifeless: it's not the author vs committer thing, it's the fact that the only revisions shown by `bzr log --line` of, say, bzr.dev were all written by some ninja named Canonical Patch Queue Manager. Dunno who that guy is, but man are they ever slick.
<AfC> pickscrape: hence my just wanting *all* revisions in single line format, not just left hand most
<uws> AfC: Btw, it's "bzr vis", not "bzr viz", you heretic.
<AfC> uws: WORKSFORME
<lifeless> AfC: that is precisely commiter vs authro
<lifeless> AfC: pqm does not yet do --author for us, when it does, the output you are talking about will change
<lifeless> (for new commits since that point)
<pickscrape> I was meaning to ask about that
<AfC> lifeless: what happens when there are 13 authors who contributed 450 revisions that collectively roll up to a single left-hand-most merge? Why aren't they being shown? A single --author has nothing to do with this
<uws> AfC: American spelling degeneration ;P
<pickscrape> If you use --author, does that credit *all* lines to that author, even if the branch being merged contained work from more than one person?
<AfC> uws: ah. I didn't realize they had added "vis" as a short form.
<lifeless> pickscrape: it credits the commit, in a social sense. bzr always knows where lines come grom
<AfC> uws: that's good of them
<lifeless> *from*
<pickscrape> lifeless: sweet
<pickscrape> This is one of the things about svk that we struggle with the most. The merger gets credit for everything.
<pickscrape> svn's limitation really
<lifeless> yup
<AfC> pickscrape: which is, outside of `bzr gannotate`, the impression created by Bazaar.
<AfC> (unless they're doing a shared central model and checkouts, of course, then lots of people are committing to left-hand edge. I suppose I should allow for that)
<pickscrape> AfC: I think lifeless has said that they're going to get PQM setting --author, which fixes that problem
<AfC> Bah
<pickscrape> Actually it was on a recent blog post too
<AfC> That's what I'm talking about.
<AfC> I have no intention of using Canonical's Patch Queue Manager bot.
<AfC> and most other people I have interacted with don't plan to adopt it either.
<lifeless> its not canonicals
<lifeless> though we are paying the maintainers these days
<AfC> One of Bazaar's hallmark's is the support of multiple workflows.
<pickscrape> But it's PQM that causes the perceived single-commitor problem with the bzr source
<AfC> This is lovely.
<AfC> But when I keep hearing that "really, to make it work you need to use PQM" I go from being quite bullish about Bazaar to being slightly off put.
<lifeless> and yes, there is no need to adopt it, it only fits some quite specific needs (primarily - run 10's of minutes long tests during merge commits(
<AfC> pickscrape: no, it's any project where the mainline is maintained by a gatekeeper.
<lifeless> AfC: tell me who says that and I'll biatch-slap them the next time I meet them
<AfC> You know, say, the linux kernel, or any other such star model.
<pickscrape> AfC: can they not use --author?
<AfC> lifeless:  :)
<AfC> pickscrape: If I am merging a branch with revisions from 2-10 unique individuals, who is the --author?
<AfC> (even assuming `bzr log --line` were to start reporting such data)
<AfC> YES, I realize that what I need to do is write a custom logger, but the reason I am fighting this so steadily is that I believe the left hand bias in Bazaar is wrong and does a disservice to the authors of all the subordinate revisions.
<pickscrape> Well, the merger is the author of changes made during the merge that didn't come from the merged revisions. How else to do it though, short of having multiple 'author' values for each commit?
<AfC> pickscrape: what you said earlier: don't only output left hand edge revisions. Output all revisions and a single summary line. After all, `bzr vis` can handle it, why can't `bzr log`?
<pickscrape> It does doesn't it?
<lifeless> night guys
<AfC> Answer, because of the bias embedded in the command that only left hand revisions are significant. I understand the original argument in favour of this. I just think it is wrong
<pickscrape> So you want something like --short which outputs the same revisions as --long?
<AfC> pickscrape: --short only does left hand edge as well. I want something like `bzr log` that presents single lines.
<pickscrape> Yeah, what I said :)
<AfC> pickscrape: in order to a) see all the history  and b) have credit clearly attributed to the people that did the work
<pickscrape> Doesn't sound too difficult
 * gour shares AfC's sentiments
<pickscrape> What would you call it though?
<pickscrape> 'brief'?
<AfC> Alas, I am not a bzr hacker, and in any case would never get such a patch past the bias I have described. Because until the core hackers agree that the current behaviour is doing a disservice to people, they won't change it / accept a change to it.
<AfC> ï»¿ {shrug} it's their code
<AfC> pickscrape: --line !!!!!!
<lifeless> meh
<pickscrape> --line already exists
<lifeless> we have a long history of changing our opinion on new information
<pickscrape> Would you want the right hand revisions to be indented, or the whole thing flat?
<AfC> lifeless: Indeed. That's why I am attempting to present a case that this should change
<lifeless> the most *effective* way to do this is to write a plugin that does the thing you want, and when folk use it on mass because its so much better, well -> it gets into mainline
<AfC> lifeless: but fully accepting that it won't change unless you want it to
<lifeless> AfC: I don't think its better, I think it is likely to have nearly all the negative connotations of git's log; but I may not be understanding what you want - so why not actually just do it?
<lifeless> oops :P
<lifeless> mind you, 11pm at night
<pickscrape> :)
<sabdfl> morning folks
<emgent> morning sabdfl
<sabdfl> morning emgent
<sabdfl> i have an issue with bzr check on a large tree
<sabdfl> it makes it through the first part fine
<sabdfl> then gets stuck
<sabdfl> checking versionedfile    0/8616
<sabdfl> any suggestions?
<jam> lifeless, AfC: 'bzr log' *does* honor --author
<jam> sabdfl: if you do ^| (ctrl+shift+\) it should break you into a debugger, and you could try to look at what it is currently doing
<jam> use 'bt' to get a backtrace
<jam> 'c' to continue
<jam> you could paste the backtrace
<jam> sabdfl: is the "throbber" ticking, or nothing at all?
<jam> you could also try "strace -P PID" etc to see if there is actually stuff happening.
<dato> (-p PID)
<Pieter> is there a way to apply git/mercurial like patches (with commit log and author information)?
<Ng> could bzr be slightly modified so when you do a status, it tells you that it's not playing with a subdir because it's a branch of its own? atm they just show up in "unknown"
<abentley> Ng: If you use status --short, it's show up specially.
<Ng> abentley: kinda seems the same as properly unknown stuff - a ?
<abentley> It doesn't append + to the filename?
<abentley> Strange.  I thought it used to.
<Ng> not afaics
<jam> abentley: I believe you have to be in subtree format, otherwise we don't *detect* that directories are subtrees
<pickscrape> If I have a change I want to contribute to bzr-gtk via the new review feature, do I need to register a branch against bzr-gtk and push to it, or is there some other way?
<beuno> pickscrape, same as with bzr, there is a bzr-gtk mailing list where you send merge-directives
<pickscrape> oic
<beuno> (bundles, patches, not sure what the term is currently)
<pickscrape> Will it matter if I'm not subscribed to that mailing list?
<beuno> well, you could subscribe and set it so you don't get emails
<pickscrape> didn't know you could do that :)
<beuno> yeap yeap, mailman setting
<pickscrape> Hmm, apparently "lists.canonical.com uses an invalid security certificate"
<jam> pickscrape: I believe it is signed with lists.ubuntu.com or something like that
<pickscrape> eek! the bzr-gtk code is riddled with trailing whitespace... :)
 * gour wonders what editor did it
<pickscrape> Shelve to the rescue
<ekimus> hmmm why do I get this: "bzr: ERROR: Transport operation not possible: http does not support mkdir()" it happens when I want to push to an empty branch on launchpad....
<beuno> ekimus, you should set:  bzr launchpad-login username
<beuno> then, you will have to use --use-existing-dir with push
<ekimus> *lol* happens when you start working on a new host :)
<beuno> and you're on you way
<beuno> *your
<pickscrape> beuno: thanks for your help on sending to bzr-gtk
<beuno> (the --use-existing-dir switch is just for this time, since the http failure creates the branch dir)
<beuno> pickscrape, my pleasure  :)
<jam> ekimus: you need to 'bzr launchpad-login"
<jam> beuno: why do you have to "--use-existing-dir" ?
<pickscrape> I've had to do that too.
<beuno> jam, for some reason, LP creates the dir when you try http
<beuno> I think I go through this half a dozen times a day (the lp-login bit), so I really hope 1.5/1.6 can get upgraded into hardy 8.04.1/2
<beuno> (1.4 or 1.5 LP plugin does a better job at explaining how to solve it)
<jam> beuno: except it doesn't tell you to use '--use-existing-dir' :)
<beuno> jam, heh, right
<beuno> but I think the bzr error doe
<beuno> *does
<beuno> so most users may figure out that last bit by their own
<beuno> or that may wishful thinking  :)
<pickscrape> Yes, I figured it out. I thought it was a bit weird though, and hoped that I wasn't breaking anything... :)
<jam> beuno: so i just upgraded my public repo to packs, and now Launchpad has decided it wants all of my bandwidth
<jam> I'm glad I don't have a strict upload cap
<jam> though who knows, maybe I do and just never hit it :)
<jam> I have 169 branches owned by me registered in launchpad. I have a feeling at least 150 of those are mirrored
<jam> and all of it will take ~50-70 MB to transfer
<beuno> oh, that's quite a lot
<beuno> you're canonical, can't you just ssh and upgrade?  :p
<jam> beuno: mirrored branches aren't hosted on the ssh side
<jam> and I don't think they give direct access to that stuff anyway
<beuno> and you're upgrading the mirrored branches?
<statik> hi! i tried upgrading a large shared repository to rich-root-packs, and I got a KnitCorrupt error. i thought i'd check in here before doing anything with it
<jam> I'm upgrading my public repo, which chains down to everything LP is mirroring for me
<jam> statik: something about missing a revision?
<jam> or something else
<beuno> jam, ah, good thing it's friday. "leave it, check back monday"  :)
<statik> jam: sha-1 of reconstructed text does not match expected, for a version that looks like it was Arch
<statik> (this is a my launchpad shared repo)
<jam> statik: you might be hitting what mpt ran into a while ago, does this happen to be something you got from devpad/rocketfuel?
<statik> jam: yes indeed
<jam> statik: abentley was helping mpt with that yesterday
<jam> best to find out their solution
<jam> I believe there is something weird in one of the inventory texts
<jam> (oh, and spiv helped before that)
<statik> jam: cool, thanks for the tip
<jam> statik: why 'rich-root-pack' rather than '--pack-0.92' ?
<jam> out of curiousity
<abentley> statik: We went back to a known-good revision and recommitted the changes as one big commit.
<statik> abentley: oic
<radix> btw, is there a blueprint or something where I can follow the status of Stacked Branches?
<abentley> statik: However, you may not have the same issue he had.
<statik> i'm just doing an upgrade, this looks like a very old revision
<statik> I'll pastebin the traceback
<jam> hmm... it seems like it is going to take 15GB of transfer before Launchpad is going to be happy with my mirrored branches.
<jam> Or 5 days of solid transfer at my 30kB/s upload cap
<jam> I think I need to find a different solution
<abentley> static: Yes, so you've probably got an instance of 234748
<abentley> statik: ^^^
<abentley> statik: Bug 234748 causes false reports of corruption.
<ubottu> Launchpad bug 234748 in bzr "Knit inventory corrupt in bzr.dev with bzr.dev r3452 (KnitCorrupt)" [High,Fix released] https://launchpad.net/bugs/234748
<abentley> bzr.dev has a fix.  bzr 1.2 was unaffected.
<statik> abentley: I was hoping this was the same issue that had already been solved, great! is it appropriate to update my bzr.dev checkout and run upgrade again?
<statik> I'm running bzr.dev now, but about 14 revisions old
<beuno> jam, how do you know that in advance?
<jam> beuno: 150 branches, approximately 90 MB each
<jam> I imagine the older ones will be smaller
<abentley> statik: I would update your bzr.dev and run check first.
<jam> but the total size of packs + indices is 97MB for that repo.
<statik> abentley: excellent, i'll do that. thanks for the help!
<abentley> statik: np
<jam> Anyone here know how to use "tc" well?
<jam> I'd rather have 10 days of 50% capacity than 5 days of 100%
<beuno> jam, if you have another server to ssh to, it may make sense to do it from there
<jam> beuno: do what from there? Remember this is Launchpad *pulling* my branches, not me pushing
<jam> And you can't pre-push to the same location
<jam> because mirrored branches don't share disk space with hosted branches
<jam> I would complain in bzrlp, but they are all gone for the weekend. :)
<beuno> jam, ah, right. You'd have to move what you have to the server, which defeats the point
<statik> abentley: I was running upgraded for a shared repo, but it looks like check needs to run in a branch. does it matter which branch I run check in?
<abentley> statik: Just make sure it's a branch of whatever triggered the error.
<statik> abentley: ok. wow, check gives me   File "/home/emurphy/src/bzr.dev/bzrlib/repository.py", line 1570, in iter_reverse_revision_history
<statik>     parents = graph.get_parent_map([next_id])[next_id]
<statik> KeyError: 'launchpad@pqm.canonical.com-20080606133605-f13slt1fhp14unnw'
<abentley> statik: That's not necessarily a bad thing, but I need to finish up what I'm doing.  Can I get back to you?
<statik> abentley: sure thing. thanks for your assistance on this.
<jam> statik: that looks like you have a ghost in your mainline
<statik> jam: it's over my head, this is the same launchpad repo I've been using on this box for over a year
<jam> statik: give me a sec, but I'm betting you haven't done "bzr log --long --no-aliases" on it
<statik> jam: should I be moving my .bzr.backup directory back?
<jam> statik: Isn't it called "backup.bzr" ?
<statik> heck no I don't run log on big repositories, it takes too long :)
<jam> Or is this older than that
<jam> statik:  if this is the converted repo, it is likely to be broken, with stuff missing, yes
<statik> jam: my mistake, I have two of them, looks like I forgot to delete the backup when I upgraded to packs a while back
<jam> if the 'upgrade' did not complete
<statik> jam: no, this is the source tree for launchpad itself
<statik> not the conversion
<jam> statik: it is the one you tried to 'upgrade --rich-root-pack' and it failed mid-way, right?
<statik> jam: right
<jam> so that is probably broken, I would copy bzr.backup back into place, and then run bzr check to make sure everything is working
<statik> ok, trying that now
<jam> keep copies of stuff when possible
<statik> definitely
<pickscrape> What are ghosts anyway? I keep hearing about them, but don't know what they are.
<jam> statik: I do have a script here: http://launchpadlibrarian.net/15061264/copy_all_revisions.py
<jam> In case we need to fill in any gaps
<jam> pickscrape: revisions which are referenced, but not present
<jam> so a node can say "I have parents XXX and YYY" but the repository may not contain "YYY"
<statik> cool, check is getting a lot farther than before
<pickscrape> oic
<pickscrape> So basically a repo can't by definition 'contain' a ghost
<Pilky> statik: hey, how are you finding BazaarX
<statik> Pilky: it looked nice when i ran it yesterday, but I didn't manage to get it to do anything yet (only played for 5 minutes)
<Pilky> cool, well let me know if you have any suggestions or anything :)
<statik> Pilky: I'm pulling the latest now and trying to run it again while I wait for my 38K revisions to finish checking :)
<jam> pickscrape: if you want to look at it that way, it "has" a "ghost" because it doesn't "have" the revision.
<Pilky> heh
<statik> pilky, i'm a bit confused about what to do at first. I see the + button, but not sure what the dialog means
<statik> is this asking me to tell it about a branch that I already have?
<Pilky> well, if a branch already exists it just adds it, otherwise it will create a new one in the selected directory
<Pilky> same if you choose repository
<Pilky> when creating a branch you select which repository you want it to appear in, or if you just want it to be a standalone branch
<statik> Pilky: cool, that makes sense. When I type a name, select branch, and point it to my standalone branch of bazaarx, the add button doesn't do anything
<statik> do I put a human readable name in the Name field, or a path?
<pickscrape> jam: in the same way that something can have a hole in it :)
<Pilky> human readable name in the name field
<jam> pickscrape: pretty much
<statik> Pilky: not sure then, clicking the add button doesn't do anything for me :( I'm running this via the "Build and Go" button in XCode, is there a way I can dig out some more info so you can tell what is happening?
<Pilky> aha, just had an idea... where is bzr stored on your machine, /usr/bin or /usr/local/bin ?
<Pilky> atm BazaarX is hard coded to look in /usr/local/bin
<statik> oh, that might be the thing. I normally run bzr.dev linked into ~/bin
<statik> I can add a symlink, no problem
<Pilky> there'll be an option in the preferences of 0.1 to change that
<statik> cool
<radix> jam, statik: I've read your blog post which points to https://edge.launchpad.net/bzr/+milestone/1.6 , but I don't see anything about stacked branches there. I'm wondering what the status is and if it's going to be in 1.6
<jam> radix: we are reviewing the code changes right now, and will probably slip the final 1.6 release to make sure stacked branches are merged
<statik> stacked branches are the future! the future is now!
<radix> that's good to hear :)
<radix> I'm *really* excited about it
<radix> It means I'll be able to use Launchpad for my larger projects, finally
<statik> radix: i have been doing my best to destroy launchpad with large branches and failing. I've uploaded over 30GB of branches in the last weeks
<statik> please join me
<radix> statik: awesome!
<Pilky> statik: btw, you may occasionally notice the odd beachball when running things, at the moment we're designing it on the assumption that bzr will get faster so it's all done in the main thread atm
<statik> awww, cmon. the world is parallel, multicore, etc.
<statik> Pilky: seriously though, I do work on branches that are hundreds of megs, with many thousands of revisions, it's very likely that some operations will take longer than you want to block the main thread
<Pilky> true
<statik> Pilky: so now that I've told BazaarX about a standalone branch, what can I do with it?
<statik> I still only see the big merge icon in the middle
<Pilky> well, if you click on it, it will do a status on it
<Pilky> blue is modified, green is added, grey is unknown, red is removed
<Pilky> you can then commit/add by clicking on the toolbar items (no icons yet but they should be top left)
<statik> huh, I'm not seeing anything happen when I click on it
<Pilky> hmm..
<Pilky> is anything coming up in your run log in Xcode?
<statik> I've restarted the whole app now that I added the symlink, added a second reference to my bazaarx branch, but still don't see anything
<statik> ah, the run log. I was trying to find something like this earlier
<statik> yes, Range or index out of bounds on NSCFSTring substringToIndex
<Pilky> hmm
<statik> I'm not that familiar with XCode, so no idea how to get a stack trace for that, but I'm willing to try if you can explain how to do it
<Pilky> hmm, well you could put a breakpoint on substringToIndex but that would stop for every substringToIndex, not just the ones in my code
<Pilky> I've got an idea what it could be though
<Pilky> have you got any blank lines in your global ignore file?
<Pilky> I'm forgetting a bit of error checking
<statik> Pilky: no, it looks like it's totally standard, 8 lines of patterns
<Pilky> hmm
<tethridge> is it possible to just remove a specific revision after other commits have been made?
<statik> tethridge: you have to uncommit all the way back
<tethridge> damn
<beuno> or branch from that revision
<tethridge> I was hoping for some kind of undocumented bzr uncommit -r 3
<beuno> and commit everything else
<beuno> (probably faster if it's a lotof commits)
<statik> tethridge: I think that would leave a hole in the history or something like that
<tethridge> I'm contributing to a project and I had submitted a patch, then started working on something else.
<tethridge> then they wanted me to revise the patch
<statik> tethridge: you should check out looms! they are perfect for that use case
<tethridge> but to do so I'd have to branch at the revision I made the patch and then reapply the changes I made for the patch after I had done the other work.
<tethridge> looms?
<tethridge> link?
<statik> https://launchpad.net/bzr-loom
<statik> you can keep each patch that you submit in a separate "thread"
<beuno> thekorn, or, feature branches. Branch everytime you're going to work on something different  (I still haven't jumped on the looms wagon)
<statik> when the code reviewers ask for a revision to the patch, you can drop back down to that thread and revise only your patch
<tethridge> statik, looms sounds like the answer
<tethridge> branching for each feature seems like a lot of waste if the project is large
<tethridge> I assume that it makes a complete copy
<beuno> tethridge, not if you're using a shared repo (which you should for this workflow)
<beuno> but, looms is *the* way to go
<statik> tethridge: no, branches are super lightweight if you use a shared repo, and you can even switch a single working tree between branches easily, it's just that looms make this specific use case a bit easier to manage than doing it with branches
<Pilky> statik: just committed some changes to LP with better error checking, try getting the latest revision and seeing if that fixes your problem
<statik> Pilky: glad to
<Pilky> I really need to get into the habit of checking the length of a string before trying to get a substring of it, it seems to be my most common runtime error
<statik> Pilky: I see files! this is great
<Pilky> heh, cool
<abentley> statik: jam got you sorted?
<statik> abentley: yessir, looks like i was running check on the busted repo when i needed to have moved back the backup and started over
<statik> thanks
<abentley> np
<jam> statik: can you help me out with some testing?
<jam> I'm trying to set up rate limiting
<jam> and want to make sure it is working
<tethridge> any of you guys work for canonical?
<tethridge> I have a quick off topic question if you do
<jam> tethridge: I do, as does statik and abentley, but I don't know if they're talkative
<statik> jam: on the phone, but happy to help testing something
<tethridge> I've tried my question on launchpad answers, but it went unanswered
<tethridge> I was just wondering if there had been any talk of providing landslide for a limited number of machines?
<tethridge> I was thinking that it could be used by developers
<statik> what is landslide?
<beuno> landscape?
<jam> tethridge: I think he means landscape
<jam> radix would be the person to ask
<tethridge> it would provide more users to help find issues without affecting the amount of paying users
<radix> hello
<tethridge> yes landscape
<tethridge> I was just curious
 * radix --> privmsg
<statik> btw jam, thanks for posting about fast-forward on your blog, that was useful to me
<tethridge> I've seen that there is a plugin that allows a user to have a bzr branch of a subversion repository.  The user uses bzr and the bzr plugin sends commands to subversion so that the user doesn't need to interact with subversion.  Is there a plugin similar to this for clear case?
<tethridge> so I'm guessing that there isn't a bzr-clearcase plugin that I haven't heard of
<lifeless> hi
<lifeless> I have heard rumours of folk doing a plugin inside companies using clearcase; I have not seen any code or heard of them making the plugin available :(
<tethridge> we use a bastardized version of clearcase that really sucks
<tethridge> it makes it such that viewing the history of a file is next to impossible because of the way they are constantly merging
<tethridge> so basically I'm working without a history
<tethridge> technically it exists, but it takes forever to find the actual changes to a specific file
<bpeterson> What does this mean? TooManyConcurrentRequests: The medium '<bzrlib.smart.medium.SmartSSHClientMedium object at 0x205c550>' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
<beuno> bpeterson, many things. I believe that masks other potential problems. Can you try pushing/pulling again?
<lifeless> bpeterson: it basically indicates an exception on the server which the client hasn't properly accomodated
<lifeless> bpeterson: I believe the new client and server protocol in 1.6 will help this immensely
<lifeless> bpeterson: if you check ~/.bzr.log on the server there is probably an exception logged
<wolever> Here's my problem: I've been working out of my own bzr repository for a few days, and I want to push it up to an SVN server so other people can use it.  Is there some way I can push the history from my repository into the SVN repository?
<lifeless> if you made your branch with 'bzr branch svn-url' then doing 'bzr push' should work
<wolever> The work I stared was pulled from another SVN repository (which I don't have +w to).
<wolever> So that won't help me here.
<wolever> I've checked out the new repository with `bzr co http://...`, but I don't know how to copy from one to the other (or even if that's the right thing to do)
<radix> why not just publish the bzr branch? the SVN users from the first repo aren't going to get much benefit with respect to merging and stuff, if you create a completely separate SVN repository
<wolever> radix: It would be lovely if I could, but "everyone else" (for some value of "everyone else") uses SVN
<wolever> That, and I don't have access to the server (apart from `ssh://...` access)
<radix> are you trying to fork the project, or somehow allow the original developers to get access to your branch and be able to merge it?
<radix> if the latter, the best format for them will probably be a patch
<wolever> I've forked a project, and now I want to give the people I'm working with access to what I'm doing
<radix> ok
<radix> I'm not sure if it's possible, but I guess you could create a new SVN repository ("svnadmin create" IIRC) and try pushing your branch to it
<wolever> A patch won't work because the changes are significant and I'm not sure if the original project is still being developed.
<jam> wolever, radix: Is it possible to 'svndump' a repo you don't have +w to?
<radix> It's an "svnadmin" subcommand, which gives me the impression it requires local access
<jam> radix: that was my guess
<jam> and a general problem with a SVN repo
<jam> if they aren't using it, nobody gets to
<wolever> jam: I believe so... At least, I've used svnsync to do it
<radix> ah, well
<jam> wolever: right, you could svnsync their repo
<jam> but I don't know how they would get your changes back
<radix> ah, ok
<jam> you could sync, 'bzr svn-push' into your mirror
<jam> but then you have an SVN repo they can't *really* use
<wolever> Ok, lemme try with svn-push
<wolever> The problem with merging is that it complains that the two repos don't share a common base, and when I give it one, I get nothing but conflicts:
<wolever> bzr co file:///svn/repo foo; cd foo; bzr merge -r 1..$HEAD /bzr/repo/
<wolever> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
<wolever> Err, and a `$ bzr svn-push file:///tmp/svn/` came before that
<lifeless> wolever: indeed, they are separate repositories; svn repos have a UUID in them
<wolever> Well, yes... It would make me very happy if there was something I could do about that, though
<lifeless> given that you have forked, why not encourage the folk you are working with you use bzr? might give a better all-around result. You don't need any server access to publish your branch
<lifeless> s/server a/special server a/
<wolever> lifeless: As I mentioned, I'd love it if I could do that, but as I'm sure you know, getting people to switch RCSs isn't that easy
<wolever> What with everyone knowing how to use SVN, SVN's integration with $IDE... etc, etc
<lifeless> true true
<bpeterson> buno, lifeless: I get the SSH error when I'm pushing to code.python.org. It hangs, so I use ^C and get this exception.
<lifeless> bpeterson: can you ssh into code.python.org and look in your ~/.bzr.log please
<bpeterson> I will have to email the administrator
<lifeless> oh
<lifeless> you don't have ssh access?
<bpeterson> I'm too new to be trusted. :)
<lifeless> !
<lifeless> ok
<lifeless> what are the last few lines before the exception in your local ~/.bzr.log
<bpeterson> You know Barry Warsaw?
<lifeless> yes indeed
<bpeterson> where's the log again?
<lifeless> ~/.bzr.log
<lifeless> or run bzr --version and it will tell you
<bpeterson> ah
<bpeterson> http://bzr.pastebin.org/41171
<lifeless> ok
<lifeless> its failing attempting to unlock() the remote repository
<lifeless> which means it failed earlier and this is masking the real error
<lifeless> I will wager, oh, a chocolate bar, that this is a permission error on the remote server
<bpeterson> It works ~1/3 of the time
<lifeless> oh
<lifeless> probably not that then
<lifeless> lets find the real error
<beuno> that's why I recommended trying again
<beuno> we get that sometimes at the office
<beuno> :)
<beuno> haven't been able to track it down yet
<bpeterson> I've been doing this for about the past week, so you can be sure I've tried again and again.
<lifeless> if you look at the bzrlib.branch module
<lifeless> the line 1625 should be in a finally block
<lifeless> disable that line - put a # and a pass line after it
<lifeless> this will mean we need to break-lock after a successful push but should let us see the real error
<bpeterson> Barry sent me the log: http://www.python.org/ftp/python/bzr.log
<lifeless> I think we need to make the client code change I proposed
<lifeless> there is too much noise from the protocol down-grade errors
<bpeterson> Ok, I'll try that
<lifeless> do you know a good python text indexer
<lifeless> pylucence looks painful to ask people to build
<bpeterson> the annoying thing is I don't get errors now
<lifeless> at all ?
<lifeless> on repeated pushes even ?
<bpeterson> no, it happily says "pushed revision 39547"
<bpeterson> I'm doing another push now
<beuno> lifeless, my personal guess with these errors is Memory ones
<beuno> the branches I've got them in, now that I've got my main server on bzr.dev, I get Memory errors sometimes
<beuno> but people at work don't even tell me anymore when it happens, they just push/pull again
<beuno> so I haven't been able to pin-point it
<beuno> is it possible the server doesn't have enough memory at the moment, and it gets masked by the smart server?
<beuno> (would explain the randomness of it)
<bpeterson> would that show up in the server log?
<beuno> I don't know enough about the smart server to know if it would  :/
 * bpeterson has another successful push
#bzr 2008-06-07
<bpeterson> could the problem be in unlocking?
<lifeless> yes
<lifeless> or some interaction
<lifeless> please file a bug
<bpeterson> ok, will do
<bpeterson> thanks for the help
<beuno> yay!  loggerhead revision view down from 2.9sec to 0.2
 * beuno commits
<bister> Is there a way to configure a repository to accept only signed commits?
<lifeless> beuno: nice
<lifeless> thatch: hi; you might have an answer to this... is there a good, low-dependency python IR/text indexer around ?
<thatch> not aware of one... but that's not an easy problem to solve (especially if you need multilingual stemming)
<thatch> what do you need one for?
<lifeless> searching bzr repositories
<lifeless> you know bonsai for instance, or fisheye
<thatch> ok
<lifeless> I don't see why the core storage should be the web apps domain
<lifeless> I can easily imagine nice text clients
<thatch> I think I looked at Lupy and PyLucene a while back but haven't particularly used either
<beuno> argh, loggerhead on LP slowly dying again...  :(
<lifeless> beuno: when can we start deploying your zpt branch
<lifeless> ignoring fancy css etc its better already
<lifeless> thatch: have you seen the template engine discussions going on here
<beuno> lifeless, I'm mainly doing some cleaning, so, if I put a good amount of hours this weekend, I can probably have something up for review on your monday morning. Not sure if mwhudson__ will have time to review it though
<lifeless> I imagine it will be a priority for him :)
<beuno> well, I'll make sure first thing monday, to do any tweaks needed
<thatch> lifeless: nope, I don't think I've been in #bzr for a week.  I can check the logs, was it today?
<beuno> I also cleaned up all the deprecated methods, so it won't be hanging from a thread everytime bzr gets updated on LP
<beuno> lifeless, css and all visual goodness is delayed til we know what 2.0 will actually look like, so we can have something accordingly
<beuno> basically, colors and some other visual elements will change a bit from the last draft
<beuno> better CSS should make rendering faster too. There are a lot of areas we can still easily improve performance-wise
<beuno> I even have an evil idea to get rid of the sqlite cache completely, but I still have to go over it with mwhudson__
 * beuno commits, pushes, and goes to dinner
<lifeless> thatch: basically the loggerhead template enginge is largely why its slow
<lifeless> beuno knows more
<lifeless> I think they looked at a couple of others but found zpt is actually leanest/fastest
<lifeless> beuno: I have been encouraging removal fo the cache for a while ;P
<toyto1> hello guys, where I can download a paramiko?
<spiv> toyto1: http://www.lag.net/paramiko/
<toyto1> thanks spiv, got it already :)
<spiv> toyto1: great :)
<keir> how impossible would it be to add custom diff support to bzr? for e.g. storing XML files where custom diff / merge handlers must be used and bzr should not interpret the data
<toyto1> guys i run this in my local computer
<toyto1> bzr init-repo --no-trees sftp://toytoy@192.168.2.10/home/toytoy/repositories/
<toyto1> bzr init sftp://toytoy@192.168.2.10/home/toytoy/repositories/testing
<toyto1> then in the other computer I try
<toyto1> bzr checkout sftp://toytoy@192.168.2.10/home/toytoy/repositories/testing testing-local
<toyto1> how can i checkout the code or the whole testing project scripts?
<toyto1> when I try to go to $PWD/testing-local/ i thought the scripts of the project will be residing in there
<toyto1> how to do that?
<lifeless> keir: we have that
<lifeless> keir: we disambiguate delta-storage and user-diffs
<lifeless> delta storage is currently always a binary-safe line orientated delta
<lifeless> but user diffs are pluggable
<lifeless> toyto1: init creates a tree or branch, it doesn't add files
<lifeless> toyto1: you need to:
<lifeless> do a checkout
<lifeless> copy your files in
<lifeless> do bzr add
<lifeless> bzr commit
<lifeless> then in your testing-local checkout you can do bzr update and it will get the files
<toyto1> lifeless: let's assume that there are 3 computers involve where the sftp:sftp://toytoy@192.168.2.10/home/toytoy/repositories/ would be the server that has the script repo
<toyto1> let's say in my local pc that has the scripts located in /home/www/testing/*where my scripts of project*
<toyto1> and i'm on that directory then issuing this command to server
<toyto1> bzr init-repo --no-trees sftp://toytoy@192.168.2.10/home/toytoy/repositories/
<toyto1> and
<toyto1> bzr init sftp://toytoy@192.168.2.10/home/toytoy/repositories/testing
<lifeless> that will have made a branch at sftp://toytoy@192.168.2.10/home/toytoy/repositories/testing with no commits in it
<lifeless> you can run 'bzr log sftp://toytoy@192.168.2.10/home/toytoy/repositories/testing' to see this ;P
<toyto1> i see i'll try
<toyto1> lifeless: let's say at first i'm going to cd /home/www/testing
<lifeless> it doesn't matter where you cd to
<toyto1> I won't do bzr init myrpoject anymore right?
<lifeless> init URL only affects URL
<toyto1> instead i'll use this
<toyto1> bzr init-repo --no-trees sftp://toytoy@192.168.2.10/home/toytoy/repositories/
<toyto1> in that way, i want to decentralized the scripts of the project. did I follow the idea?
<lifeless> I think you are confused about what init does
<lifeless> it creates an *empty* branch, it does not *add your data to it*
<toyto1> lifeless: can you do me a favor so that I can clearly understand it, can you tell me step by step with it involving the
<toyto1> bzr init-repo --no-trees sftp://toytoy@192.168.2.10/home/toytoy/repositories/
<toyto1> command
<lifeless> toyto1: where are your existing scripts
<toyto1> my friend told that in that way, we can decentralized the scripts
<toyto1> okay
<toyto1> let's say here in my local pc
<toyto1> it's in
<toyto1>  /home/www/testing
<lifeless> ok
<lifeless> cd /tmp
<toyto1> ok
<toyto1> then
<lifeless> bzr checkout sftp://toytoy@192.168.2.10/home/toytoy/repositories/testing
<lifeless> cp -a /home/www/testing/* .
<lifeless> bzr add
<lifeless> bzr commit -m 'import scripts'
<lifeless> oh hmm, missed a command
<lifeless> bzr checkout ..
<lifeless> cd testing
<lifeless> then cp -a
<lifeless> and so on
<toyto1> let me try :)
<keir> lifeless, is it possible to tell bzr to never merge? or to use external merge programs?
<lifeless> keir: the former not as such; the latter I think so, or at least, one can write a plugin to enable that
<lifeless> (which is not quite the same thing, I know)
<keir> hmm, ok. i am envisioning a system where a textual merge is strictly incorrect and should never be attempted... so bzr needs to be extended to do this?
<Peng> There's an extmerge plugin.
<lifeless> I believe we have all the necessary machinery
<Peng> (I think that's its name.)
<lifeless> some assembly required
<keir> yup, ok.
<lifeless> which is to say you can get what you want without patching bzr itself, or deep voodoo
<lifeless> but I may be wrong :P
<keir> alright. it's ok if i have to patch bzr, i was just curious
<lifeless> :)
<toyto1> lifeless: it says
<toyto1> Committed revision 1.
<toyto1> after issuing the bzr commit -m 'import testing scripts'
<lifeless> right
<toyto1> and then what's next after it?
<lifeless> now, go somewhere you want to get a new copy of the scripts - your third machine
<toyto1> lifeless: okay let's say in this computer again but in different directory
<lifeless> sure
<lifeless> cd there
<toyto1> lifeless: let's say in my /home/mypc/Desktop/repo <- im here now
<lifeless> and do bzr checkout ...
<toyto1> ok trying...
<toyto1> wow it's there already ;)
<toyto1> and now since i'm in this director /home/mypc/Desktop/repo/testing
<toyto1> let's say i'll edit test.txt
<toyto1> after I will bzr commit -m 'i did edit test.txt'
<toyto1> will it automatically sync with the scripts from the server?
<toyto1> or update that script also?
<lifeless> it will write to the database on the server
<lifeless> in a file in .bzr there
<lifeless> on the other machine, where you have done bzr checkout, you can do 'bzr update' to sync
<toyto1> lifeless: wow ;) I get it thank you so much :)
<toyto1> now i can bzr diff sftp://toytoy@192.168.2.10/home/toytoy/repositories/testing too right?
<toyto1> hmm it doesn't return or say anything since I edited and commited one of the file there
<toyto1> after issuing bzr diff sftp://toytoy@192.168.2.10/home/toytoy/repositories/testing
<lifeless> you can just do 'bzr diff'
<lifeless> and it will tell you whethe ryou ahve edited anything or not
<toyto1> lifeless: it doesn't tell anything. Again, i tried modifyng one of the scripts. But after modifying it, when i issue bzr commit -m 'modifying the 3rd script'
<toyto1> it goes to the server opening sftp
<toyto1> then updates the script and says
<toyto1> Commited 3
<lifeless> sure
<lifeless> thats what I would expect
<lifeless> modify the script but don't commit
<lifeless> then run 'bzr diff'
<toyto1> ah i'll try
<toyto1> ah i see so lifeless, it will  show bzr diff if not yet commited right?
<lifeless> yes
<toyto1> hence if commited, then it will update there and finalize it.
<lifeless> is that what you wanted to know, or something else?
<toyto1> ah i see, thanks lifeless...
<toyto1> yeah that's it
<toyto1> when I try to unlink test.txt
<toyto1> then bzr diff it shows the contents
<toyto1> and says it was removed...
<toyto1> then when i issue bzr commited -m 'removed test.txt'
<toyto1> it did open a log file
<toyto1> then how other developers would see that log?
<lifeless> 'bzr log'
<lifeless> also 'bzr log -v'
<toyto1> bzr diff sftp://toytoy@192.168.2.10/home/toytoy/repositories/testing
<toyto1> ah i see
<toyto1> so bzr log lifeless, underneath to it, it does go to the server and gets information on their right, then it will return back to the user by just that 'bzr log'
<lifeless> yes
<lifeless> if they do not have a checkout you can do 'bzr log URL'
<toyto1> bzr log URL (URL can be from sftp)? because I found most examples using http
<lifeless> yes
<toyto1> hmm lifeless back to the /tmp/testing directory
<toyto1> when i try bzr log sftp://toytoy@192.168.2.10/home/toyoy/repositories/testing
<toyto1> it says
<toyto1> onbzr: ERROR: Not a branch: "sftp://toytoy@192.168.2.10/home/toyoy/repositories/"
<lifeless> you made a spelling error I think
<lifeless> toyoy is not how you spelt it earlier
<toyto1> hehe yeah
<toyto1> lifeless: 0-0 wow ! :)
<toyto1> love it, thanks for your help. I understand it now. my friends tutorial seems to be chatty and confusing x(
<toyto1> thanks for your brief tutorial. I love it ;)
<lifeless> my pleasure
<gour> finally, svn-1.5 next week
<gour> 'new' life for bzr-svn
<lifeless> finally
<lifeless> I have removed the last weave_store reference
<nxvl> hi
<nxvl> i'm having problems uploading to lp's bzr
<lifeless> go on
<nxvl> i'm trying to bzr push lp:terminator
<nxvl> as it says on the code page
<nxvl> but it's trying to upload via http
<nxvl> which is not working
<lifeless> have you told bzr your lp username ?
<nxvl> and i do that how?
<Peng> bzr launchpad-login
<nxvl> with bzr whoami?
 * nxvl tries
<nxvl> woohoo
<nxvl> thanks
<nxvl> i didn't knew about the new bzr changes
<nxvl> i didn't upload anything since "bzr push bzr+ssh"
<nxvl> thanks
 * nxvl HUGS lifeless and Peng 
<Peng> You could've still manually done that.
<Peng> lp: URLs are just simple shortcuts.
<Peng> They translate to http if you're not logged in, or bzr+ssh if you are.
<nxvl> :D
<nxvl> thnz
<nxvl> thnx
<mathrick> hiya, how do I add subtrees to a branch?
<mathrick> I have it in rich-root-pack already
<mathrick> mathrick@hatsumi:~/elisp$ bzr join --reference dvc
<mathrick> bzr: ERROR: Cannot join dvc.  Trees have the same root id.
<mathrick> huh?
<mathrick> they're most definitely two different trees
<LarstiQ> but their root ids could be the same
<edreamleo> Hello all.  bzr version numbers after merges are causing great confusion with the Leo and IPython projects.  Somebody on the Leo project said "if everyone starts with rev 505 and does some stuff and commits on after another you can't all get 506." which makes sense to me.  Is this issues documented anywhere?  If not, I think you could help lots of people, including me, if you did so.
<Peng> What?
<mathrick> LarstiQ: howso?
<mathrick> edreamleo: no, each of the trees will have its own rev 505
<mathrick> depending on how you merge, the other "505s" will end up as different revisions in your tree
<mathrick> revno is only meaningful for a single tree
<mathrick> what matters cross-tree is that the revisions are the same
<LarstiQ> mathrick: before there was rich root support, all the root ids (fileid of /) were TREE_ROOT
<mathrick> LarstiQ: oh
<mathrick> LarstiQ: how can I change that?
<LarstiQ> mathrick: import bzrlib.branch; bzrlib.branch.Branch.open('.').basis_tree().path2id('/')
<mathrick> the top-level repo is under my control
<LarstiQ> mathrick: hmm, been a while
 * LarstiQ knows how to set if through the bzrlib api, but not sure on what the procedure is in converting an older branch
<edreamleo> mathrick: it seems that rev numbers aren't documented.  It would be "soothing" to newbies if we could understand where rev numbers like 507.2.2 came from.  True, bzr log does show the renumbered branches, but I think a discussion in the docs somewhere would help.
<LarstiQ> edreamleo: revnos are determined by the lefthand side ('mainline') of the revision DAG of a branch
<LarstiQ> edreamleo: as an aside, revids (and not revnos) globally uniquely define a revision. See bzr log --show-ids for example
<mathrick> edreamleo: hmm, is that really an issue? It only shows up in commit logs for merge revisions, where you can immediately see it's a merge
<LarstiQ> edreamleo: Merged revisions, the indented ones in bzr log output, get dotted revnos, the first number is the same as the revno of the revision in the current branch where they branched from.
<mathrick> otherwise the whole merge will be just 506 in your tree
<mathrick> LarstiQ: if you can give me a snippet to set it on a fresh tree, it's no problem, I can just replay commits onto the new branch
<LarstiQ> mathrick: on a fresh tree created with a rich root format, it should already be rich.
<mathrick> aha
<LarstiQ> mathrick: you don't want to keep your revisions?
<edreamleo> mathrick: It's "really" an issue only in the sense that it confuses newbies.  True, the log is about as clear as it could be.  The problem is, that newbies think there recently committed changes went away, depending on what the "main" revno is, and newbies then don't think to look at the log.  I strongly suspect the revnums are fine, it's just a learning problem with bzr.  But I know for sure that it is confusing for several sets of n
<mathrick> LarstiQ: I do, but can't I merge/replay them from the old tree?
<LarstiQ> mathrick: you can merge them, 'replay' made me think of something different
<mathrick> although to be honest, in that particular tree I don't care all that much, as long as functionally equivalent revs are present, it's just my conf dir
<LarstiQ> mathrick: you should be able to do something with moving things to a subdir, then merging into a new tree and removing everything to the root, or some such
<mathrick> "removing everything to the root"?
<mathrick> edreamleo: your message got truncated
<mathrick> after " several sets of"
<LarstiQ> mathrick: sorry, 'removing' is ambigious
<LarstiQ> mathrick: that should be 'moving everything back to'
<edreamleo> mathrick: sorry about that.  Some forums like one-liners.
<edreamleo> mathrick: It's "really" an issue only in the sense that it confuses newbies.  True, the log is about as clear as it could be.
<edreamleo> mathrick: The problem is, that newbies think there recently committed changes went away, depending on what the "main" revno is, and newbies then don't think to look at the log.
<edreamleo> mathrick: I strongly suspect the revnums are fine, it's just a learning problem with bzr.  But I know for sure that it is confusing for several sets of newbies.
<LarstiQ> edreamleo: have you seen the revision ids with --show-ids?
<mathrick> edreamleo: ah, so you mean they branch at 504, commit "foo" at 505, merge someone else's tree where 505 is "bar", then wonder why they still don't have the bar in their tree, since 505 is "foo"?
<edreamleo> mathrick: yes, I believe that something like that is what is confusing folks.
<mathrick> edreamleo: that is a problem when you think of "the" repo and checkouts, instead of a set of DAGs
<edreamleo> To repeat, once people think to look at the log they are probably going to be reassured
<mathrick> edreamleo: however, how do they find out 505 is "foo" and not "bar" if not through the log?
<edreamleo> Interesting.  Afaik, dag's are never mentioned in the docs.
<mathrick> I guess a little technical aside mentioning DAGs and how trees being DAGs means they can be non-identical yet equivalent could help
<edreamleo> mathrick: here is the original report on http://groups.google.com/group/leo-editor
<edreamleo> I committed the leoSettings.leo file with a couple of vi emulator changes as revision 509.
<edreamleo> Later, with Edwards updates the leoSettings.leo changes moved to revision 511 and the revision description that I entered is gone.
<edreamleo> That's the essence of the report.  Does that make any sense to you?  I'm totally confused :-)
 * LarstiQ starts up X and a browser
<mathrick> edreamleo: this one? http://groups.google.com/group/leo-editor/browse_thread/thread/a207aa1ba5247363
<edreamleo> mathrick:  yes, that's the thread
<mathrick> edreamleo: ok, did you commit on a branch and pushed, or committed on a checkout?
<edreamleo> my workflow is to commit and push
<mathrick> the two look similar, but are fundamentally different when it comes to commits
<mathrick> edreamleo: aha, then indeed you will never get the same revnos if there's been intermediate traffic on the target branch
<mathrick> edreamleo: can I have your mainline branch URL?
<edreamleo> mathrick: https://code.launchpad.net/~leo-editor-team/leo-editor/trunk
<mathrick> edreamleo: ah, yes, I suppose you have looked at the log already?
<mathrick> if no, bzr log https://code.launchpad.net/~leo-editor-team/leo-editor/trunk | less
<LarstiQ> edreamleo: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#understanding-revision-numbers
<LarstiQ> edreamleo: and also 1.2.2, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#id19
<edreamleo> LarstiQ: thanks for these urls!
<LarstiQ> edreamleo: np :)
<mathrick> LarstiQ: I suppose specifically mentioning implications of merges in http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#understanding-revision-numbers would help, tho
<edreamleo> mathrick: Aha.  I have only looked at my local log...
<LarstiQ> mathrick: yes, patches appreciated :)
<LarstiQ> mathrick, edreamleo: or something for http://bazaar-vcs.org/FAQ
<mathrick> LarstiQ: ok, how do I contribute to the FAQ?
<LarstiQ> mathrick: I think the FAQ is just a wiki page
<mathrick> ah
<LarstiQ> at least, I can't find it in the bzr.dev source tree
<LarstiQ> mathrick: for the user-guide, bzr.dev/doc/en/user-guide/zen.txt
<mathrick> mhm
<mathrick> edreamleo: out of curiosity, what is your local log like? The revisions should stay intact there
<edreamleo> Thanks all.  I'll post this discussion on the thread I gave above on leo-editor.  I think it will help.
<edreamleo> mathrick: it looks the same as the global log to my untrained eyes.
<mathrick> oh, do you have an URL?
<LarstiQ> edreamleo: http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#id27 might also be of use
<LarstiQ> edreamleo: you can do things like bzr diff -r -3..-1 for example
<LarstiQ> edreamleo: the key thing to take away here is that what uniquely identifies a revision is the revision _id_ (revid for short, example: pqm@pqm.ubuntu.com-20080606135624-1ambbf8pct52xfh8) and a revision _number_ (revno for short, simple integers for mainline revisions, or dotted for merged) is just a convenient shorthand in a particular branch
<edreamleo> LarstiQ: thanks.  I'll post this to leo-editor.
<LarstiQ> edreamleo: the former is always the same for a particular revision, the latter can change if the mainline changes. (I locally commit 505, someone else can merge that into their 505, then mine will probably be 504.1.1)
<LarstiQ> edreamleo: also practice with `bzr log --show-ids -r -3..-1` and then `bzr diff -r revid:<a revid here>..revid:<and likewise here>`
<LarstiQ> edreamleo: that should give your users/developers a better grasp on the differences I hope.
<edreamleo> LarstiQ: Excellent: practical usage tips will certainly help.
<LarstiQ> edreamleo: and as mathrick said, if people fear their changes have been lost, have a good look at the log output and search for merged revisions. (You can search for a commit log with `bzr log -m <pattern>`)
<LarstiQ> edreamleo: oh! And `bzr missing`
<LarstiQ> edreamleo: bzr missing will compare two branches and tell you which revisions the one has the other hasn't.
<edreamleo> Ok.  Enough for now.  This is plenty for us newbies to digest.  Again, many thanks.
 * LarstiQ stops :)
<LarstiQ> edreamleo: feel free to ask more questions later on.
<mathrick> LarstiQ: http://bazaar-vcs.org/FAQ#head-c45efef970ac690a0e997fbc904c3ea989e3fcea <-- looks good?
<mathrick> hmm
<mathrick> that merge messed up my history somehow
<mathrick> I get revnos such as -3 now
<bpeterson> lifeless: are you there?
<Pieter> revision numbers suck
<mathrick> I recreated it, and I still can't get a tree with root id other than TREE_ROOT
<mathrick> if I pull from the existing branch onto an empty tree, I will get the same id
<LarstiQ> mathrick: looks good to me
<LarstiQ> mathrick: ah yes, the root id is only set after the first commit
<LarstiQ> Pieter: they're perfectly fine if you know what they are
<mathrick> yeah, and if I commit, the branches become unmergeable
<LarstiQ> ok, let me see if I can figure out how to do this
 * LarstiQ will be afi for a couple of minutes
<mathrick> if I commit after merge, I get this:
<mathrick> deleted
<mathrick> working tree is out of date, run 'bzr update'
<mathrick> Committed revision 1.
<lifeless> hi
<lifeless> LarstiQ: can blender edit art of illusion files ?
<LarstiQ> lifeless: never heard of art of illusion before, no clue what fileformats it supports
<Keybuk> did something change in difftools?
<Keybuk> I'm sure that bzr diff --using=meld used to open one window with the changes
<Keybuk> now it opens one per file
<Keybuk> in fact, I don't have difftools installed -- did --using find its way into bzr proper?
<spiv> Keybuk: since 1.1rc1 according to NEWS
<Keybuk> but it runs multiple tools for each file, rather than just one? :-(
<Keybuk> ah, installing difftools makes it use just one :p
<spiv> Sounds like a bug to me, but I don't use --using.
 * spiv -> bed
<antoranz> Hi, Guys!
<antoranz> I'm having problems installing the bzr plugin for eclipse on hardy
<antoranz> can anybody help me?
<antoranz> when I try to configure it, I get a line of errors on top (not the bzr-xmloutput plugin problem, though)
<antoranz> http://www.pastebin.ca/1041360
<weigon> hmm, how can I fix a "RevisionNotPresent: Revision {...} not present in "revisions.kndx"."  in a bzr merge ?
<slangasek> lifeless: so I used cvsps to do a one-time conversion of an old CVS package repo to bzr, and afterwards someone noted that the contents of the bzr branches don't actually match what was tagged in the CVS repo...
<slangasek> lifeless: halp :)
<emgent> heya
<bpeterson> lifeless: are you there?
<Verterok> moin
#bzr 2008-06-08
<db-keen> I never noticed this before: I just branched using bzr-svn and it reported branched through revision 26 of a repository at revision 25. Is it always +1 ?
<Odd_Bloke> db-keen: Are you sure that there aren't 26 revisions somewhere in the repository?
<Odd_Bloke> I'm just heading to bed, but that'd explain it.
<Odd_Bloke> Anyhoo, jelmer is the man to ask.
<Odd_Bloke> Night!
<Jc2k> db-keen: are there 26 in svn. and 25 in bzr?
<Jc2k> (sorry, its later i can't tell if i'm ready it right :P)
<Jc2k> gah
<Jc2k> reading it right, evn
<db-keen> Odd_Bloke, Jc2k: yeah, I've checked and double checked, 26 in bzr, 25 in svn
<Jc2k> i think if there is a branching operaion (e.g. svn cp from to) then the revision numbers will be different
<lifeless> svn revnos are repository wide
<lifeless> bzr revnos are  branch wide
<lifeless> you could for instance have 2000 commits in an svn revno, but one branch with only 10, if you bzr branch that bzr will show 10
<db-keen> lifeless: but I have an extra revision in bzr, not the other way around
<lifeless> oh
<lifeless> offhand, no idea.perhaps svn is 0-based?
<slangasek> not in my experience, it isn't
<Toksyuryel> pretty sure bzr adds the +1 whenever you branch
<db-keen> perhaps it does, I just never noticed
<Toksyuryel> I think that is what I read in the docs, not completely sure I remember it correctly though
<lifeless> 'branch' isn't an action for bzr - two branches one made from another with no commits, have the same revnos
<lifeless> branch is an action for svn, but it also adds a revno
<lifeless> perhaps its an svn copy to make a branch?
<slangasek> that's correct, but how does that fit?
<jelmer> 'evening
<jelmer> db-keen: if you branched the root of the svn repository, that's correct
<db-keen> jelmer: ah, perhaps that's why I never noticed, it's much more common to just branch trunk
<Toksyuryel> oh wait I am thinking of merge
<Toksyuryel> when you merge the revno is bumped
<radix> Toksyuryel: technically, it's when you commit
<Toksyuryel> radix: when you commit obviously, but I was thinking of other times the revno is bumped; a merge is one of those times
<radix> Toksyuryel: no, it's only when you commit.
<radix> Toksyuryel: Just running "bzr merge" doesn't actually modify the branch - it doesn't add a revision
<radix> You have to "bzr commit" the merge for it to actually be added to the branch, in the form of a new revision
<Keybuk> radix: though it'd be nice if merge did commit ;)
<radix> weirdo :P
<lifeless> you kike unreviewed code that much?
<lifeless> s/k/l
<radix> lifeless: I recommend dvorak
<chandlerc> anyone know exactly how bzr-svn branches are "supposed" to work?
<jelmer> chandlerc, how do you mean?
<chandlerc> ie, the whole subversion branching scheme
<jelmer> chandlerc: See "bzr help svn-branching-schemes"
<chandlerc> i've gotten a weird error with my bzr-svn repository, and i'm wondering if i just set it up incorrectly... (sorry for the bounce.. dunno what my internet is doing)
<chandlerc> i just read that
<chandlerc> ;]
<chandlerc> but how should it look from the bzr side?
<jelmer> if you'd just like to check out one branch in svn, branching schemes shouldn't be erelevant at all
<chandlerc> currently, all development is done on mainline, but I'm sure that'll change down the road
<chandlerc> do you just arrange the paths locally of your bzr branches the same way as the subversion branches are?
<chandlerc> or does it only look at the url you push to?
<jelmer> there's no requirements as to how you arrange it locally
<chandlerc> jelmer: here is the error i'm getting: http://pastebin.org/42285
<jelmer> chandlerc: That's unrelated to branching schemes
<jelmer> You seem to be trying to create a new branch in svn
<chandlerc> ok... i'd still like to understand them, but not right now
<chandlerc> and i'm not, i'm running "bzr push"
<jelmer> but you're pushing into a svn repository?
<chandlerc> yes, but its one i've been pushing too
<chandlerc> to too. ;]
<tethridge> anybody heard of a clear case plugin for bzr?
<jelmer> chandlerc: but the location you're pushing to doesn't contain a branch yet apparently
<jelmer> chandlerc, You may have to use "bzr svn-push" rather than "bzr push"
<jelmer> since the branch doesn't exist yet
<chandlerc> i'm very certain it does
<jelmer> bzr is trying to run mkdir since it can't find that directory
<chandlerc> Related branches:
<chandlerc>     push branch: svn+https://inc.googlecode.com/svn/parser/trunk
<chandlerc> ...
<chandlerc> # bzr push
<tethridge> what is the technical difference between pull and merge?
<chandlerc> its the same URL i've been using that command with for 2 months now
<lifeless> pull follows one path in the dag
<lifeless> merge combines two branches that are separate in the dag but started from some common point
<tethridge> does pull autocommit?
<lifeless> nothing autocommits
<tethridge> to the local branch
<tethridge> ok
<lifeless> pull replaces the current branch tip
<lifeless> but no new commit object is created
<chandlerc> jelmer: its one of the more bizarre errors because it started happening without anything changing (that I know of...)
<jelmer> chandlerc: What does "bzr branching-scheme svn+https://inc.googlecode.com/svn/parser" return?
<tethridge> I find it strange that when I "update" my local mirror of a project that I commit the change
<tethridge> I've just been entering a "updated from trunk" message.  Is that what you guys do?
<chandlerc> unknown command
<chandlerc> jelmer: btw, i'm following the 0.4 release branch, not using fixed releases
<jelmer> chandlerc: 'bzr svn-branching-scheme..."
<chandlerc> jelmer: Not a branch
<chandlerc> for both parser and parser/trunk
<lifeless> tethridge: if you have a local mirror, why are you using update & not pull ?
<tethridge> well, to be honest, I was confused by whether I should do a merge or a pull.
<tethridge> I guess I should be doing a pull
<jelmer> chandlerc: hmm, google branch appears to be disallowing operations on the repository root
<tethridge> I'm not sure why I need a local mirror
<tethridge> why not just have a task branch for each task?
<lifeless> tethridge: sure, you can do that
<tethridge> is it just a speed thing?
<chandlerc> jelmer: would this have been a change on their side to break this, or in how bzr-svn is doing things?
<brandon_rhodes> Is there an easy way to have bzr give me a "bzr log" output with diffs included?
<tethridge> so if I'm not connected I could create task branches
<chandlerc> jelmer: or in how i'm doing things w/ bzr-svn
<brandon_rhodes> Or do I have to run "bzr diff" over and over and over?
<tethridge> so nobody knows of a clear case plugin?
<lifeless> tethridge: well, I don't know why you are doing $whatever you are doing :P
<tethridge> I think I have it figured out now
<tethridge> it takes a little bit to switch modes from using something like svn
<lifeless> brandon_rhodes: I don't think there is at the moment
<lifeless> tethridge: so I think a more useful pull/merge/update explanation for you is:
<jelmer> chandlerc: I'm not sure
<lifeless> 'pull' is used to maintain an exact copy of another branch.
<lifeless> 'merge' is used to combine someone elses work into your branch
<jelmer> chandlerc, you may want to run "bzr selftest --starting-with=bzrlib.plugins.svn" to make sure your checkout of bzr-svn works ok
<brandon_rhodes> lifeless: drat.  Thanks for the answer, though. :-)
<lifeless> 'update' is used when two people are sharing a branch (and thus works like update in cvs/svn)
<chandlerc> jelmer: no such option: --starting-with
<jelmer> chandlerc: s/--starting-with=bzrlib.plugins.svn/^bzrlib.plugins.svn/
<tethridge> lifeless, I don't really see a difference between pull and update
<tethridge> I see what you mean between pull and merge
<Keybuk> tethridge: pull is different if you branch, instead of checkout
<Keybuk> it pulls changes from one branch into another
<lifeless> tethridge: say there is a branch at URL
<lifeless> tethridge: no working tree, just a branch.
<tethridge> ok
<lifeless> tethridge: to work on this you can either make a new branch, hack, and then integrate your work into the branch (via push, or by doing a checkout+merge+commit)
<lifeless> tethridge: or you can work directly on the branch, by doing a checkout
<lifeless> in the latter case you get a local working tree, and unless you specified --lightweight, a mirror of the branch, but bzr keeps it synchronised with URL, any change made locally is made to URL too
<lifeless> if two people both do 'bzr checkout URL' and then one of them commits
<lifeless> the other one can't commit - because their local working tree does not contain the changes introduced by the others commit
<lifeless> to get those changes they do 'bzr update'
<tethridge> I see
<lifeless> which synchronises their local working tree version with the current branch tip of URL
<tethridge> which workflow do most projects use?
<lifeless> (and if there is a local mirror branch object, it is synced too). Finally, if they had done an offline commit in the checkout, it gets turned into a pending merge.
<tethridge> that makes sense
<tethridge> I'm almost finished reading the tutorial, but that helps
<tethridge> not tutorial, user guide
<lifeless> generally the gatekeeper for a project - the person running trunk - does all the commits to the trunk
<lifeless> if there are multiple gatekeepers, then they will have a shared branch -- s ingle branch that the gatekeepers all have checkouts of
<chandlerc> jelmer: i'm really hoping to get a good setup going w/ googlecode btw, hoping to get a not insignificant blog post written up about it
<lifeless> features are normally done on different branches (made by doing 'bzr branch')
<chandlerc> jelmer: to that end, if there is something that needs to be tweaked on their side, let me know! =]
<tethridge> I remember reading recently on planet ubuntu about launchpad having something like bugbuddy.  For some reason I thought it was something different though.  You guys know what I'm speaking of?
<jelmer> chandlerc: no, I think there's nothing that has to be changed on that side
<tethridge> I can't find the post now
<lifeless> chandlerc: I saw a blog from a googler about git-with-gcode
<jelmer> chandlerc: To be sure you may want to check with a released version of bzr-svn
<lifeless> chandlerc: I found that amusing knowing what bzr-svn can do :P
<chandlerc> ;]
<tethridge> the blog post was mentioning how the conversation about whether or not to approve the bug was in launchpad, which sounds like what bugbuddy does
<lifeless> bpeterson: hi
<chandlerc> lifeless: i'm going to try and do bzr-svn justice, although my usage is light so far, i'm hoping it'll get increasingly heavy
<lifeless> bpeterson: I'm in sydney, ETIMEZONE last night
<jelmer> chandlerc: Cool
<bpeterson> lifeless: regarding the TooManyConcurrentRequests on ssh error: #125784
<lifeless> yes
<jelmer> chandlerc: I'm happy to help trying to get it to work for you
<chandlerc> =D
<chandlerc> it's been working great until the other day when this error started showing up
<chandlerc> quite odd
<bpeterson> lifeless: I'm in the US
<lifeless> anyhow
<lifeless> I don't have new info for you
<lifeless> have you tried andrews patch?
<bpeterson> no
<bpeterson> I hope I can merge it cleanly!
<chandlerc> jelmer: http://pastebin.org/42288
<lifeless> jelmer: what does openchange use for text indices
<chandlerc> i don't think any of those are my problem...
<jelmer> lifeless, what would we need text indices for ? We don't have a server yet :-)
<jelmer> chandlerc, that looks ok
<lifeless> jelmer: for answering client folder searches
<chandlerc> jelmer: btw, bzr pull fails with the Not a branch error, but no traceback, its just the push that crashes
<chandlerc> jelmer: but i'm really mystified as it clearly is a branch... the parent and push branch...
<jelmer> chandlerc, please try running with -Dtransport
<chandlerc> k
<chandlerc> which will provide the best information? the push or the pull? or the svn-branching-scheme?
<jelmer> lifeless: I don't think we do search yet
<lifeless> k
<chandlerc> jelmer: err... nm, none of those commands gave any additional output wth -Dtransport
<jelmer> chandlerc, it's writting to ~/.bzr.log
<chandlerc> doh, my bad
<chandlerc> i remember than now of course... ok, which one would you like, or all of them?
<chandlerc> http://pastebin.org/42290
<chandlerc> that's push, and pull...
<jelmer> chandlerc, can you try "bzr pull svn+http://inc.googlecode.com/svn/parser/trunk" ?
<chandlerc> http://pastebin.org/42292
<jelmer> without the s
<chandlerc> doh
<chandlerc> sorry
<chandlerc> missed that
<chandlerc> yup, that worked
<chandlerc> is it my subversion?
<jelmer> I suspect a SSL certificate expired or something
<chandlerc> mm, lemme try doing an https something via svn
<jelmer> python-subversion doesn't pass that information on yet but just returns an error
<chandlerc> bingo
<chandlerc> wow, so simple...
<chandlerc> ahhh, now i get a much more interesting failure
<chandlerc> so how would i set two different branching schemes for two different "modules" in my subversion repo?
<chandlerc> i have svn/parser/{trunk,branches,tags}, but also svn/wiki which doesn't have the {trunk,branches,tags} scheme
<chandlerc> when i 'bzr push' to svn/parser/trunk, it inspects the svn/wiki area, and errors because branches is missing...
<jelmer> you can't use a different branching schemes within the same repository
<chandlerc> that's... a problem for googlecode
<jelmer> chandlerc: but every project has its own repository
<chandlerc> yes, but every repository has a "wiki" directory
<chandlerc> with no trunk, branches, or tags
<bpeterson> lifeless: Andrew's patch works for me! Can we get it applied?
<chandlerc> so if the project wants branches...
<jelmer> The fact that "branches" is required is a bug in bzr-svn
<chandlerc> http://pastebin.org/42294 is the traceback
<chandlerc> but i'd really like to be able to bzr branch 'svn+https://inc.googlecode.com/svn/wiki' ... will that not work?
<jelmer> chandlerc, bug 235301
<ubottu> Launchpad bug 235301 in bzr-svn ""bzr: ERROR: libsvn._core.SubversionException" committing to SVN after top-level "branches" directory has been removed" [Undecided,New] https://launchpad.net/bugs/235301
<jelmer> chandlerc, "bzr branch svn+http://inc.googlecode.com/svn/wiki" works fine here
<chandlerc> mk... so i just can't "branch" the wiki root
<chandlerc> which is fine honestly
<jelmer> wiki root?
<chandlerc> sorry, so i can't bzr branch from that URL, and then svn-push into a different path to create a subversion "branch"
<chandlerc> because it doesn't follow the branching scheme
<jelmer> you _can_ branch from that URL
<chandlerc> yea, i misspoke, its pushing a new subversion branch that i was anticipating breakage
<jelmer> no, that shouldn't be a problem either I think
<chandlerc> ? then what does the differing branching schemes do?
<jelmer> it's relevant for merge tracking
<chandlerc> hmmm, ok
<chandlerc> i think i follow that
<jelmer> branching schemes should go away in the future
<chandlerc> cools, simpler is better. =D
<jelmer> I'm considering just hiding them for 0.4.11 since they appear to cause more confusion than they're worth
<chandlerc> hehehe
<chandlerc> any ETA on the bug? its a blocker for me, i'd just like to know.
<chandlerc> additionally, if i can help work up a patch for it, i'd be happy to
<jelmer> not sure, haven't had time to look into it yet
<jelmer> I'll see if I can fix it for 0.4.11
<chandlerc> =D
<chandlerc> it'll sadly break 90% of googlecode projects.
<chandlerc> i'm gonna poke at it some, but i may get lost in the python (not my strongest language)
<jelmer> If there's anything I can help with, let me know
<lifeless> bpeterson: could you mention that in the bug
<jelmer> The sun appears to be coming up here in .ie though, time for some sleep
<jelmer> g'night *
<lifeless> beuno: just remembered, you did see my plugin-info plugin announcement right ?
<lifeless> night jelmer
<chandlerc> sweet, fixed it
<lifeless> grats
<lifeless> open sores wins again
<Keybuk> I dislike this time of year
<Keybuk> the Sun stays up and fools you into thinking it's mid evening when in fact it's closer to midnight
<Keybuk> then, after you get a bit of darkness to get a few hours decent work done
<Keybuk> it comes up again
<LaserJock> heh
<lifeless> back on SST huh ?
<Keybuk> yeah
<Keybuk> clearly my personal timezone has already made the shift from management to development
<Keybuk> even if my employment status hasn't yet caught up
<lifeless> :P
<Keybuk> which reminds me
<Keybuk> really must write my job description
<toyto1> hello guys, any help? I tried branching Tortoise for Windows XP by 'bzr branch https://code.launchpad.net/~amduser29/tortoisebzr/trunk'
<toyto1> after it i issue command 'python TortoiseBZR.py' but got an error saying 'Failed to find bzrlib module! Include the path to bzrlib in PYTHONPATH environment...'
<toyto1> I set the PYTHONPATH to 'set PYTHONPATH=C:\Program Files\Bazaar\lib' but still it shows that error
<toyto1> any idea?
<lifeless> what is in C:\Program Files\Bazaar\lib
<lifeless> specifically is there a C:\Program Files\Bazaar\lib\bzrlib ?
<toyto1> first, thanks for reply lifeless. oh no, actually I didn't find bzrlib under ...\lib directory
<toyto1> I found this library.zip, does it contains the bzrlib? let me check
<lifeless> if the library has bzrlib in it
<lifeless> then put the library on the path - C:\Program Files\Bazaar\lib\library.zip
<toyto1> oh yeah, I found a directory named bzrlib inside that library.zip, so I need to extract it in that directory under ..\lib?
<toyto1> ah i see
<toyto1> okay trying...
<lifeless> I don't use windows
<lifeless> so can't offer more than generic help for you though, sorry
<lifeless> markh is doing a lot on this stuff I believe
<markh> it will need to be in your "global" environment, so processes like explorer.exe see the env var
<markh> just setting it at a command-prompt will not work properly
<toyto1> indeed me too :( my friends wants me to try it in windows.
<toyto1> markh: what do you mean setting in the command prompt?
<markh> how are you setting the PYTHONPATH variable?
<toyto1> so something like going to My Computer by right clicking it... blah2... way.
<markh> ok - sorry - I just re-read the above.  It sounds like you are having trouble with registration anyway.
<toyto1> yeah, I set the PYTHONPATH thru command prompt, I set actually under the My computer... Advance... Environment variables but the path is C:\
<markh> so, once you set the variable, you try and re-execute the 'python' command?
<markh> in a command-prompt?
<lifeless> speak their name and they appear; the wonders of the net.
<markh> :)
<toyto1> markh: actually I did just under command prompt, it executse exlcuding that error, but when I hit the carriage return there's a Message box so I just click 'OK' but it does execute
<toyto1> ah markh it says The procedure entry point ?PyWinObject_AsHANDLE@@YAHPAU_OBJECT.... something like that
<toyto1> but after clicking ok the TurtoiseBZR.py executes its scripts
<markh> bugger - it sounds a little like the pywin32 install is screwed up :(
<markh> oh - right-  you are trying to use tbzr with a binary install of bzr itself
<markh> that might be a struggle :(
<toyto1> markh: oh, that's a bug? ah what do you mean by that?
<markh> iiuc, tbzr basically expects to be running from a source distro of bzr
<lifeless> markh: completely separate to the current discussion you might like to send commits for the stuff you are doing to the bazaar-commits list; we encourage contributors to do this as a way of getting visibility
<lifeless> re: binary install - the 'binary' of bzr has only a small subset of the regular python libraries
<lifeless> it should be possible to do an add-on installer to add what tbzr needs as well as tbzr itself etc etc, but I don't believe anyone has done that so far
<markh> lifeless: yes, I do need to do that - I'll be making some announcement this week, then next week I go to sydney to work with a few of the guys
<lifeless> markh: including me ;P. Though the vf merge and stacking will be consuming me
<markh> lifeless: oh cool :)  I'm not sure who you even are ;)
<lifeless>  /who lifeless
<markh> non-obvious nicks ;)
<markh> pidgin doesn't know what /who means :)
<lifeless> oh, right click and info on my nick?
<lifeless> (gui clients, feh) :)
<markh> :)  Ahh - cool - will be good to meet!
<markh> so yeah, we do need better binary "packaging" story on Windows IMO, especially keeping plugins in mind
<lifeless> yup
<lifeless> alexander basically designed it all
<lifeless> and AFAICT his design is sane, but noone stepped up to do actual packages
<markh> I'm wondering if py2exe is a good idea if we really want plugins to be seamless.  An alternative is to install a (basically) full stand-alone Python tree, running from source code, with a few front-end .exe files that are actually the entry-points.  Kinda 1/2 way between py2exe and a source distro.  Possibility is things like eggs etc would work seamlessly
<markh> but I've no firm ideas or opinions
<markh> IIUC, setuptools already provides a tool to generate such executables
<lifeless> I have a bad opinion of eggs; but perhaps they are the best solution for windows.
<lifeless> broadly though many plugins have dependencies that are a superset of pywin32+bzr
<lifeless> e.g. they want 'patch' or 'pysvn' or '...'
<markh> eggs or not, the idea is that it looks alot more like a "normal" python distro, so any way of getting packages on is likely to work, or nearly work :)
<lifeless> so however we approach it we need the act of 'install plugin X' to also 'install missing deps for X'
<Keybuk> what's cheese?
<markh> ideally yeah, but I fear with py2exe, some plugins would fail to work even if you manually attempted to install all plugins
<markh> sorry
<markh> install all deps
<lifeless> to my mind, the py2exe thing isn't really a problem as a result, because we can pickup missing standard library modules as part of their dependencies
<lifeless> markh: are there other causes for failure that I'm not aware of then ?
<markh> what happens when a plugin needs an obscure python lib module we didn't include in the .zip file?  Or we just ensure the entire lib is there?
<lifeless> (I guess I should be more explicit - if we did what py2exe/freeze do on a per-plugin basis, then subtract the set we know ship in the bzr py2exe .zip, we get the extras)
<toyto1> markh: I uninstalled bzr, the package with Windows_Installer_bzr.exe, then install the bzr-1.5.win32-py2.5.exe
<toyto1> would that be fine? I try going to command prompt and issuing 'bzr' but it is now not recognize, how to make it recognize or use bzr in that way?
<lifeless> markh: right, I'm saying that the .zip for a packaged plugin potentially includes std library modules too.
<markh> toyto1: so you need to say "python c:\path\to\bar"
<markh> lifeless: right - if it is OK that only plugins which have had the special "packaging for windows" magic done before they can be used, I'd expect that would work fine.
<toyto1> markh: what path, only for python? I already set the path PATH=C:\Python25;%PATH%
<markh> windows doesn't look at the shebang line
<markh> sorry - /path/to/bzr
<lifeless> markh: so I think that installing plugins by 'bzr branch' can only be expected to work for source installs of bzr and folk willing to manually install deps. binary installs (both unix and windows) should work with the recommended $target binary package of bzr
<markh> so "c:\src\bzr\bzr", assuming that file exists
<markh> (the source distro of bzr has the entry point without a .py extension)
<markh> lifeless: right - I guess I need to understand the scope of plugins better
<lifeless> markh: Its pretty broad.
<toyto1> markh: Sorry I didn't notice it but found the 'Start -> Program Files -> Bazaar -> Start bzr' then it shows me the command prompt at directory C:\Python25\Scripts
<lifeless> markh: bzr-svn is one of the most cool plugins I know of.
<lifeless> (in terms of technology, and in terms of what it allows users to do)
<toyto1> so setting or adding like PATH=C:\Python25\Scripts;%PATH% would recognize 'bzr' in command prompt, isn't it?
<markh> toyto1: no - the cmd prompt doesn't consider a file named 'bzr' could be executable
<lifeless> no, windows needs a .bat or .com or .exe file to do that
<lifeless> setup.py can create a bzr.bat
<lifeless> uhm
<lifeless> python setup.py build --in-place
<lifeless> not sure if that will work, but it is worth a shot
<markh> I don't recall doing any build at all :)
<lifeless> markh: we don't require one.
<lifeless> markh: but you can if you wish, to build the C accelerator modules.
<toyto1> markh: ohmm I have that notion because when I try installing the bzr as package w/o python, then trying at command prompt issuing bzr it works actually but I unisntalled it. let me try
<lifeless> one advantage of binary installs is that the C modules are prebuilt
<markh> toyto1: yes, the binary install installs a bzr.exe
<markh> I expect that windows users will very rarely run from source unless they are interested in hacking on bzr itself
<lifeless> yup, me too. But we should keep it easy to do, to make casual contribution straight forward.
<markh> It is far far easier to make the decision to run from source on a linux box.  IMO we want to avoid saying "to do X, you must be running from source" on Windows if we can (which isn't to say anyone is planning that or anything :)
<toyto1> markh: ah its now recognize at command prompt after I append C:\Python25\Scripts at Environment Variables
<markh> right - I guess its finding the bzr.bat
<lifeless> markh: oh, completely agree, for unix too. source installs should only be needed for development-of-bzr.
<lifeless> markh: I think every bzr dev will agree :)
<kumi_> Well, I run source on windows because the official release is broken :)
<toyto1> markh: and now when I try to python TortoiseBZR.py the error that I told you that shows with 'OK' button is now gone. Thanks guys :)
<markh> cool :)  The next thing will be to check it actually works with explorer :)
<lifeless> kumi_: you have filed bugs?
<kumi_> Nope, it was that merge bug you called my attention to
<kumi_> You stated it was already fixed in HEAD so I didn't bother
<toyto1> markh: ohmm I tried editing a file, then right clicking it then I clicked BZR Diff it says 'BZR Error ... Unknown Diff Command'
<toyto1> any idea?
<lifeless> kumi_: oh right
<lifeless> kumi_: I thought you means some specific to windows errata
<kumi_> well there is a slight win32 bug I noticed. The included start_bzr.bat in bzr.dev calls bzr.exe, which doesn't exist
<lifeless> ah interesting
<lifeless> if there isn't a bug, having one would be good
<kumi_> where do I file it?
<lifeless> launchpad.net/bzr
<markh> hrm
<markh> toyto1: I'm not sure where that message would come from - its in a message box?
<kumi_> https://bugs.launchpad.net/bzr/+bug/238277
<ubottu> Launchpad bug 238277 in bzr "tools/win32/start_bzr.bat in bzr.dev branch incorrectly calling bzr.exe" [Undecided,New]
<fdv> Hi. I'm still trying to convert an svn repo to something else, bzr being the first choice. I have run into a problem, though, that several revisions are broken in the svn repo, and generate errors when one tries to check them out. Does anybody know whether it's possible to make bzr-svn ignore some revisions and how that would work?
<fdv> (that is, running bzr branch)
<lifeless> fdv: oh interesting
<lifeless> fdv: actual svn corruption?
<fdv> lifeless: yes, it is :p
<lifeless> fdv: I think the usual answer would be to do a svndump, svnfilter them out, then restore the dump
<lifeless> fdv: if you can't do that, i think you'd need to raise a question on questions.launchpad.net/bzr-svn
<lifeless> I am sure noone has needed this facility to date; and it has implications with the revision mapping logic
<toyto1> markh: yeah, python error related. I think it shows that error because the bzr was not recognize under python scripts, what do you think? because after I reinstalled that bazaar package installer w/no python then install the bzr-...pythonwin32.exe it's okay now
<toyto1> I mean okay that it doesn't show that message prompt anymore.
<fdv> uh
<fdv> pain :p
<fdv> lifeless: ok, thanks, then I might have a solution, at least :)
<markh> toyto1: does it work though?
<toyto1> but my problem now is using that tortoise with Bzr Commit and Bzr Commit says Uknown command commit/diff
<toyto1> nah :( even I have already installed the paramiko and pycrypto libraries
<fdv> lifeless: yes, I'd think it raises some issues
<lifeless> my spam filters die on weekends
<lifeless> I feel a strong urge to violence to spammers
<toyto1> I tried under command prompt and it's okay actually. I did commit and diff or issuing bzr command and successfully interacted to the server w/ repositories
<markh> toyto1: that error message could be due to any error, and tbzr sadly doesn't indicate any details about the error :(
<markh> (I found where it comes from, and it isn't pretty :)
<kumi_> maybe your .bzr.log has a clue as to why
<toyto1> markh: what do you think where it came from? I have no idea actually, since I assume it would work since I assigned globally to the environment variable %PATH% the C:\Python25\Scripts where bzr resides
<toyto1> knowing the bzr would be recognize as a command
<toyto1> kumi_: may I know where that .bzr.log resides? I use the Windows explorer oh is it in the .bzr directory?
<markh> toyto1: its an "internal error" in tbzr itself, not related to bzr itself.  Its not getting as far as executing any bzr commands.
<markh> IIRC, the log file will be in your "My Documents" folder
<markh> I doubt it will have anything useful, but its worth a look :)
<toyto1> markh: let me check it. :)
<lifeless> 'bzr --version' will list the log file location
<kumi_> yep, look for "Bazaar log file" in the output :)
<kumi_> BTW, the tortoisebzr README says "To see debugging output run python tortoise-bzr.py --debugging-output"
<markh> sadly that error message comes from a bare 'except' clause that doesn't log or display or do *anything* with details about the error :(
<toyto1> guys kindly take a look at this page -> http://pastebin.org/42313
<toyto1> that's the log file I found under my documents folder
<kumi_> maybe that's the wrong location, try bzr --version as was suggested
<kumi_> mine is not in My Documents, but in C:\Documents and Settings\user\bazaar\2.0
<toyto1> kumi_: ah yeah kumi_ that's the location actually the bzr --version showed to me.
<markh> so, I'm guessing another dependency is missing :(
<markh> try executing: "python.exe -c "import commands.CommitCommand"
<kumi_> I get a traceback when I run the TortoiseBZR Diff command from the commandline
<markh> I see:
<kumi_> "C:\bin\Python25\python.exe" "C:\bin\bzr.dev\bzrlib\plugins\tortoisebzr\TBZRCommand.py" /command:TBZRDiff /filepath:"C:\Temp\BZR57A3.tmp"
<kumi_> that results in:
<markh> Traceback (most recent call last):
<markh>   File "<string>", line 1, in <module>
<markh>   File "commands\CommitCommand.py", line 48, in <module>
<markh>     import gtk
<markh> ImportError: No module named gtk
<kumi_> gah n/m
<toyto1> markh: ah i see, what gtk is that do you think? let me check it.
 * kumi_ disappears into slumberland
<clemente> Hi, I'm seeing âAttributeError: 'GitRepository' object has no attribute '_format'â. See http://pastebin.org/42314
<clemente> jelmer: I think it may be after your change in revision 16 to the plugin âgitâ
<toyto1> now clicking the BZR Diff works, but BZR Commit still an unknown commit command
<markh> it kinda sucks, but the only thing I can suggest it to get a command similar to 'python.exe" "C:\...\TBZRCommand.py" /command:Commit /filepath:"commit.tmp"' working, so you get the same error (commit.tmp must exist with the full path of each file you want to commit per line).  Once you see the same error, we can then modify a .py file so it actually prints the error itself
<AfC> clemente: the bzr-git capability is still very young...
<markh> I know it shouldn't be this hard :(  We are working on fixing it, but I'd expect it to be at least a few weeks before I've something to show for myself.
<clemente> AfC: however it's the best I found for moving from git to bzr
<clemente> Although the other methods also didn't work
<AfC> That's a surprising endorsement to hear.
<AfC> clemente: (yeah, I ran into the same problem. I still have one project whose history is abandoned. Someday I hope to convert it and merge/graft/rebase/pray-to-the-gods/sacrifice-a-small-goat/whatever together to the just add it all at once I was forced to do instead)
<clemente> Can't you import the history with git-fast-export + bzr fast-import ?
<clemente> I run into encoding problems due to invalid UTF-8
<toyto1> markh: is it /command:Commit or /command:TBZRCommit ?
<markh> it looks like TBZRCommit, yeah
<markh> indeed, it looks like XYZYCommit would also work (ie, first 4 chars can be anything :)
<toyto1> markh: thanks, i'll try
<toyto1> markh: it says 'python.exe Unable to Locate Component .... This application has failed to start because libglib-2.0-0.dll was not found. Re-installing the application may fix this problem'
<toyto1> where I can get that dll by the way? any idea?
<markh> ack - so I guess that is part of gtk or something :(
<lifeless> thats bzr-gtk yes
<toyto1> I see. that would be PyGTK ? which interacts to gtk2 library isn't it?
<lifeless> installing bzr-gtk and adding it to the path will work
<lifeless> yes, gtk and glib are kindof twinned :)
<toyto1> lifeless : ah so installing it let me try
<toyto1> lifeless: it's still 'Unknown Commit Command' but I found that libglib...dll and it's under Application Data\bazaar\2.0\plugins\gtk\_lib\gtk-2.0\gobject
<clemente> I have installed latest bzr in a local directory which now has its ./bin, ./lib, ./man. Now how do I run this instead of the system bzr?
<lifeless> clemente: put that bin directory on your path ahead of wherever your system bzr is
<toyto1> and issuing the 'python TBZRCommand.py /command:TBZRCommit /filepath:"%USERPROFILE%/Desktop/bzrtemp.tmp"' would still say that the lib is not found
<lifeless> toyto1: like I say, I don't use windows, so I'm not in a good position to help :(
<toyto1> lifeless: oh sorry :)
<markh> toyto1: try adding Application Data\bazaar\2.0\plugins\gtk\_lib\gtk-2.0\gobject to your PATH
<markh> just at the cmdprompt is fine: set PATH=%PATH%;Application Data\bazaar\2.0\plugins\gtk\_lib\gtk-2.0\gobject
<markh> (obviously the fq path is needed)
<clemente> lifeless: Then the old bzrlib from /usr/share/pyshared/bzrlib will be used
<lifeless> clemente: have you tried? we have some logic for handling this
<lifeless> clemente: alternatively, just put the source directory you downloaded bzr from on your path
<lifeless> the bzr there will pickup the bzrlib there automatically
<clemente> : /n/bzrbzr ; PATH=/n/bzrbzr PYTHONPATH=/n/bzrbzr bin/bzr
<clemente> bzr: WARNING: bzrlib version doesn't match the bzr program.
<clemente> .... bzrlib from ['/usr/lib/python2.5/site-packages/bzrlib'] is version (1, 5, 0, 'final', 0)
<toyto1> markh: it works fine but when the window showed up, clicking the commit button after I provided a message prompts an Uknown error saying 'NoneType' object has no attribute 'encode'
<lifeless> clemente: when I run from source I usually just do 'bzr branch <> local_path'; 'ln -s ~/bin/bzr local_path/bzr' and that works fine
<markh> toyto1: is there a traceback?
<clemente> lifeless: Well, for me it works if I do this:   PYTHONPATH=/n/bzrbzr/lib/python:/usr/lib/python2.5:/usr/lib/python2.5/lib-dynload /n/bzrbzr/bin/bzr
<lifeless> clemente: ouch; well time for a shell alias I guess
<clemente> Just executing ~/bin/bzr still uses the system bzrlib
<clemente> Or better look for a clean solution...
<toyto1> markh: where I can find the traceback?
<toyto1> markh: the error won't show if I check the 'commit locally'
<lifeless> clemente: the problem is that 'setup.py install' splits the command and the library
<lifeless> clemente: which is why I suggested pointing at the source, not the 'installed copy'
<toyto1> markh: however if I try to bzr log to the server, there's no commit or changes happens, only at that local directory/file even I tried again right click the directory -> BZR Commit
<clemente> lifeless: ok, that's true, by using the source directly you save problems
<beuno> lifeless, the plugin-info announcent from a few months back?
<lifeless> beuno: yes; it is rather relevant to the plugin stuff ;P
<toyto1> markh: when I edit a file, let's say test.txt, then right click that file BZR Commit will show the window, then I click the commit locally (because it will show that error stuff if not)
<lifeless> beuno: but I had _no_ feedback, felt a bit like it went into a vacuum
<toyto1> markh: after that, I again right click the file -> BZR Commit -> and it works okay but when I 'bzr log sftp://URL' to the server, the file was unchanged :(
<beuno> lifeless, ah, it's perfect from what I'm working on. I thought I had answered, but I'll find the thread and reply. It's definetely something that should get implemented. If got merged into the docs though, didn't it?
<lifeless> beuno: uhm, docs stuff was different; the plugin has a command to scan plugins
<lifeless> :!bzr plugin-info .
<lifeless> search(1.6.0dev0) from . supplies commands("index","search"), control formats(), checkout formats(), branch formats(), repository formats().
<lifeless> :!bzr plugin-info ../../loom/trunk/
<lifeless> loom(1.4.0dev0) from ../../loom/trunk/ supplies commands("combine-thread","create-thread","down-thread","loomify","record","revert-loom","show-loom","up-thread"), control formats(), checkout formats(), branch formats("Loom branch format 6","Loom branch format 1"), repository formats().
<beuno> lifeless, ah, I *did* miss the announcement then
<markh> toyto1: now tbzr is actually asking bzr to do something, that log might hold some clues
<lifeless> Message-Id: <1204311754.28682.80.camel@lifeless-64>
<lifeless> beuno: as in 'stuff should get implemented, I did the freaking thing'
<beuno> lifeless, heh, yeah. Branched it, I'll reply and try to help you get some movement there. Now, it's almost 6am, so I'm off to be for a while.
<beuno> s/be/bed
<beuno> night!
<lifeless> jelmer: is svn://gwalcmai.vernstok.nl/bzr/trunk you ?
<lifeless> beuno: gnight
<toyto1> markh: i'll send the log and that problem to tbzr
<toyto1> markh: I just notice the tbzr doesn't put any logs or report logs under .bzr.log isn't it? I notice it just now, because everytime I do something with tbzr the log file doesn't change
<toyto1> else, if i do some stuffs at command line, then the log file changes
<vila> lifeless: ping, a couple of questions regarding webdav/list_dir()/stat()
<vila> lifeless: I've now implemented list_dir for webdav, but the test suite now fails because it want stat() also. I'm pretty sure packs doesn't requires stat() (list_dir was required for clearing obsolete_packs.
<vila> the current transport API has several flaws here: stat() usage is more or less implied if the transport is writable, it seems to be used to allow S_ISDIR and may be file  size (at least remote seems to only implement file_size and chmod bits only)
<vila> thoughts ?
<vila> and once again, I wish a plugin could say: this test would fail with this set of parameters
<vila> so that I can say: webdav does not implement delete_tree and copy_tree for example
<vila> which AFAIK are not used by bzr
<lifeless> well
<lifeless> delete_tree and copy_tree are implemented on the base class I thought, in terms of other ops
<vila> hurray ! You're not asleep yet :)
<lifeless> so webdav has no reason to not have them
<lifeless> yes stat is implied, what remote does is indeed sufficient
<vila> lifeless: yup, but the base implementation needs a way to distinguish between files and directories which stat() provides
<vila> I can find a work around to implement only file_size and dir bit in the chmod bits but only for apache2 (AFAICT after tests against apache2 and lighhtp, the later having more bugs that make it even harder to support for the webdav plugin)
<vila> lifeless: oh, I misread " is indeed sufficient" as "is indeed *not* sufficient"
<vila> So a work-around for apache2 as said above will be ok ?
<vila> I'll try to report bugs against lighttpd then.
<lifeless> sounds reasonable to me
<vila> lifeless: good.
<aantn> hello
<aantn> how can I apply a patch generated with bzr diff?
<aantn> when I use bzr patch I get the following
<aantn> http://rafb.net/p/W8hLCl96.html
<Odd_Bloke> aantn: Why are you using 'diff' and 'patch' to communicate changes?
<aantn> Odd_Bloke: Its from a person who's interested in getting involved and just made their first change to the code
<aantn> Odd_Bloke: I figured out how to apply it; I needed to specify the right directory
<fredreichbier> hi all ;)
<Odd_Bloke> aantn: If both parties are using bzr, there are better ways to communicate changes than diff/patch.
<aantn> Odd_Bloke: do you mind explaining?
<Odd_Bloke> However, I need to grab a shower before heading off to cook for 30 people, so now is probably not the best time for me to help you out.
<aantn> Odd_Bloke: fair enough
<Odd_Bloke> aantn: Briefly, you want to use 'bzr merge', because it will retain history (whereas a dumb diff/patch won't).
<aantn> Odd_Bloke: I know, but this is for a minor ten line patch
<Odd_Bloke> aantn: OK, I'd still tend to use 'merge', if only because it (a) doesn't require remembering how to create and apply patches properly, (b) retains history (however little of it there may be), and (c) will have much better conflict resolution if you do get problems.
<Odd_Bloke> Anyhow, now I'm really *GONE*.
<aantn> Odd_Bloke: ok
<aantn> thanks for the advice
<Pieter> so there's no real way to work with patches like git and mercurial allow you to?
<Jc2k> Pieter: define "work with patches"?
<Jc2k> there is a "bzr patch" command in bzrtools that i've never used before
<Jc2k> there are also cherry picking and shelves to help break a patch up into pieces, i guess.
<lifeless> Pieter: bundles are patches+rich metadata that transfer all history, merges etc
<lifeless> Pieter: they can send a single commit, or an entire branch
<Pieter> lifeless: how can they send a single commit? it always tries to send all commits differing from my upstream
<lifeless> Pieter: bzr send -r -2..-1
<lifeless> that will create a cherrypick, with enough data to ensure it can be applied whether or not they have the basis available
<Pieter> lifeless: ok, but if I merge that it doesn't keep my commit message
<lifeless> Pieter: yes, that is a current limitation of bzr - what happens is that the cherrypick is not put into the merge graph
<lifeless> Pieter: the commit message *is* in the repository of the person that merged it, but all our current revision graph pointers are transitive
<lifeless> cherrypicking is on the fairly-high-TODO-list to put a comprehensive solution in place for. Unfortunately the semantics of merge while clear to a human, are not clear at the algorithmic level [in the present of cherrypicking even more so]
<lifeless> or to put it another way: when we fix cherrypicks to be better, the bundles that are created today can give better results immediately
<lifeless> gnight
<lifeless> tomorrow, I shall teach search to query the index.
<lifeless> anyone wanting extremely early previews - pull my commit diffs off the commits list :P
<lifeless> actually, I'll push it to lp:~lifeless/+junk/bzr-search now
<toyto1> lifeless: any idea why I receive bzr: ERROR: Path(s) are not versioned: "testing.txt"
<mathrick> lifeless: will it eat my data if I run it on my repo?
<mathrick> hmm, it doesn't do anything for me
<mathrick> no errors, but no results either
<MvG> Someone willing to review http://tinyurl.com/3zbfun related to bug #128496? Or what's the normal workflow here?
<ubottu> Launchpad bug 128496 in subversion "Unable to open native working tree with non-ascii filenames" [Undecided,New] https://launchpad.net/bugs/128496
<vila> MvG: the normal workflow for the bzr-svn plugin is to have jelmer informed, since he participated to the bug discussion, I think he is :) If not having mention his name should be enough to summon him
<dato> Pieter: hm
<dato> Pieter: I fixed bug 219042 without knowing you had too
<ubottu> Launchpad bug 219042 in bzr-fastimport "fast-export doesn't export right" [Low,Triaged] https://launchpad.net/bugs/219042
<dato> Pieter: I did the same as you first, but there're cases when that can go wrong
<dato> Pieter: http://dpaste.com/55476/
<fredreichbier> what's wrong with this hook? http://paste.pocoo.org/show/65053/
<MvG> vila: The diff in the tinyurl above is against bzr.dev, not bzr-svn.
<MvG> So it's the bzr workflow I'm interested in.
<vila> MvG: ha, sorry, missed that, then maling bazaar@lists.canonical.com is the first step, if you think it's ready to be merged (doest it include tests for example) you can put [MERGE] in the subject, anyway, mailing the list will at least get the discussion started
<vila> s/maling/mailing/ s/doest/does/ s/$/typos are accepted, don't worry/
<MvG> vila: OK, the I'll do so once the full test suite runs here have completed and I know there were no failures introduced by this patch.
<vila> ok, extra bonus points if you had a test failing without your patch and succeeding with it
<MvG> vila: Hmmm... tricky, as such tests would require a locale besides the default POSIX locale to be supported and installed. That's not a requirement I'd make in a test.
<vila> MvG: Mention that in your mail then
<MvG> And writing tests supposed to expectedly fail on most systems except those in a specific locale seems like a bad idea as well.
<MvG> OK, will do.
<afflux> hi. I have a "trunk" bzr repo and I created a branch for it. Now I did changes to my branch and the trunk was changed too. I merged the trunk stuff to my branch using "bzr merge $trunk". My problem is now the following: my branch was merged into the trunk and some parts of it were changed.
<afflux> Finally, my parts were removed again. So now, I want to re-use my old branch. I want to use the current trunk as a new "base" and re-start to diverge from there.
<afflux> how do I do that? Doing "bzr pull $trunk" fails with "bzr: ERROR: These branches have diverged. Use the merge command to reconcile them."
<MvG> I'm not sure I understood you correctly, but if you want to re-start to diverge from some other branch, it would seem sensible to create a new branch.
<MvG> "bzr pull --overwrite" might do the same thing, looking at its documentation.
<afflux> MvG: looks good, thanks!
<fredreichbier> are there apps like loggerhead for other languages, e.g. php?
<fredreichbier> a question to bzrlib: how do i get a complete diff between two revisions?
<beuno> fredreichbier, let me cook that up for you real quick
<fredreichbier> :)
<beuno> fredreichbier, something like this should work: http://paste.ubuntu.com/18544/
<fredreichbier> thank you very much :)
<beuno> you're very welcome
<beuno> Verterok, mornin'
<Verterok> beuno: mornin'
<lifeless> mathrick: check in .bzr/bzr-search/indices
<mathrick> lifeless: it has things like 0408nfiguration0176
<mathrick> that seems a bit garbled
<lifeless> it has \x00 delimiters
<lifeless> use a binary safe viewer, e.g. vim or some versions of less
<lifeless> its a very crude index at the moment, see DESIGN for some notes
<lifeless> (but thanks for giving it a spin and trusting it wouldn't eat stuff!)
<thumper> morning
<mathrick> lifeless: hehe, you're welcome
<mathrick> I always appreciate cute tools like that
<lifeless> you can also use bzrlib to query it
<lifeless> no query language at the moment so its -
<lifeless> from bzrlib.plugins.search.index import open_index_url
<lifeless> index = open_index_url('.')
<lifeless> terms = dict(index.all_terms())
<lifeless> mathrick: if I can ask, what branch did you index?
<lifeless> bzr itself, a project of yours?
<mathrick> my project
<mathrick> a very small one, too
<lifeless> cool
<mathrick> lifeless: ah, I used bzr search
<lifeless> it probably returned near-instantly
<mathrick> yeah
<mathrick> what is the syntax for search?
<lifeless> well, I'm writing that bit now (my sign-off comment was that that bit was next) :P
<lifeless> I'm going to do the most trivial thing to start with - a list of terms, and just do a set union
<lifeless> hi thumper - holiday for me today :P
<thumper> lifeless: yeah, I know
<thumper> lifeless: doesn't stop you being here though, does it?
<lifeless> so I'm going to do what I did yesterday - play WoW, and when on a bird, code a search plugin for bzr
<thumper> on a bird?
<lifeless> long distance travel
<chandlerc> is there a bisecting plugin for bzr?
<lifeless> yes, bzr-bisect
<chandlerc> sweet... part of bzrtools, or separately available?
<lifeless> just separate
<lifeless> its on the plugins page, packaged for debian/ubuntu too
<chandlerc> k
<chandlerc> hmm, any particular reason lots of stuff in the bazaar gentoo overlay doesn't have amd64 keywords?
<lifeless> I don't know what that means
<chandlerc> in gentoo, packages are marked with keywords to indicate what "platform" they are available for
<Jc2k> chandlerc: why would python stuff need to special case for amd64?
<chandlerc> Jc2k: it shouldn't which is why i don't know why its *only* exposed for x86
<lifeless> chandlerc: most of bazaar is pure python
<Jc2k> packaging bug :p
<chandlerc> unfortunately, the existing gentoo paradigm requires opting into each and ever platform explicitly
<lifeless> chandlerc: sounds like a bug to me
<mathrick> chandlerc: that's a good question for #gentoo, asking anyone else is a bad idea
<chandlerc> well, the gentoo overlay is managed by bazaar folks, not gentoo folks
<mathrick> ah
<chandlerc> lifeless: i'll file a bug with that project on launchpad suggesting to always use the same set of platform keywords as python
<lifeless> chandlerc: please do
<lifeless> chandlerc: its actually gentoo folk that manage it - gentoo folk interested in bazaar AIUI
<chandlerc> fair enough, but i suspect there may be more gentoo folks interested in bazaar here than in #gentoo. ;]
<lifeless> indeed ;P
<chandlerc> potentially because i'm here, and not there... oh the joys of a tiny distribution
<beuno> lifeless, Loggerhead would rock with a good search plugin, so you can count on me implementing it as soon as it's usable  (that would eliminate the last need for a sqlite cache, fulltext indexing)
<mwhudson> beuno: but there's still the second-to-last (files changed between revisions) to go :)
<beuno> mwhudson, absolutely, and good morning
<mwhudson> hi
<beuno> I was thinking that if the current way of getting diffs works out to be a winner, we can do the same for history navigation
<beuno> and get the files changed on a per-revision basis
<beuno> and maybe get rid of the cache that way
<beuno> until bzr can provide that information fast enough
<mwhudson> yes that's definitely something to consider
<beuno> mwhudson, I've been cleaning the branch up lately, and, even though I still have to tweak some things, if you could start reviewing it, it would help me quite a lot :)
<mwhudson> beuno: ok, i'll have a look in a bit
<beuno> mwhudson, cool, thanks. I'll be around the following hours working on this.
<lifeless> beuno: well grab the plugin, patches appreciated
<beuno> lifeless, it's already out there?
<lifeless> a sketch yeah
<lifeless> lp:~lifeless/+junk/bzr-search
<lifeless> there is plenty of surface area
 * beuno branches
<beuno> any luck on the python text indexing library?
<lifeless> see DESIGN :P
<lifeless> when did for x in y: else: get added?
<beuno> lifeless, interesting, you're pretty deep into it already
<lifeless> beuno: indeed there would not be much point asking for patches until ~ where it is now
<beuno> right, I was under the impression it was more of an idea than 1k of code  :)
<lifeless> well
<beuno> I'll play around with it and hopefully be able to provide some patches to it
<lifeless> its the weekend, and I did not get much coding on the last flight :P
<Verterok> mornin'
<Verterok> lifeless: Hi
<lifeless> hi
<Verterok> lifeless: about the fulltext indexer, I just found: http://swapoff.org/wiki/pyndexter
<lifeless> http://swapoff.org/wiki/pyndexter/docs/pyndexter.indexers.builtin :(
<Verterok> http://swapoff.org/browser/pyndexter/trunk/pyndexter/indexers/_builtin.py
<lifeless> oh god it uses pickle
<Verterok> it's that too bad?
<lifeless> its possibly ok
<lifeless> we'd have to write our own backend from the looks of it anyhow
<lifeless> (or have it be local disk only)
<lifeless> and it doesn't have any idea of expoential backoff on storage
<vila> woot! webdav plugin passing bzr tests again :)
<lifeless> grats
<vila> the plugin test server itself need to be fixed though I used a local apache2 test server (with the local_test_server plugin) to validate the new implementation, but that should be easy and can wait tomorrow :)
<lifeless> beuno: a good thing to work on would be to extend the term posting lists created such that file texts, file paths etc are getting indexed
<lifeless> thats really quite orthogonal to the 'engine' work
<beuno> lifeless, sure, I'll take a look at it and see if I can move forward
 * beuno adds that to his ToDo
<mwhudson> jelmer: hey, do you know if pysvn is prone to giving you unicode strings?
#bzr 2009-06-01
<lifeless> moin
<igc> morning
<beuno> Peng_, jusy sasw your reviews
<beuno> thanks
<Peng_> Oh, you're welcome.
<beuno> I wonder what that TooManyConcurrentRequests thing is about
<Peng_> Soo. Anyone got IPv6 access? Run an IPv6 bzr server?
<beuno> too crazy for me  :)
<Peng_> I missed my medication and wound up setting up an IPv6 tunnel on my server. :D
<lifeless> beuno: TMC is a masking error
<lifeless> beuno: it means that some code is trying to make smart RPC calls a after an error left the smart connection in a bad state
<lifeless> beuno: e.g. attempting to unlock a lock after the server bailed
<lifeless> beuno: -Dhpss can be a useful way to get some info on it
<beuno> lifeless, ah
<beuno> hrm
<Peng_> lifeless: Oh, thanks.
<lifeless> fixing it requires finding the fault,and correcting it so that when this failure occurs it leaves the connection in a good state
<lifeless> bb is down :(
<beuno> I wonder how to get loggerhead to do that for me
<lifeless> beuno: try:except; :P
<lifeless> beuno: there is another possible cause
<lifeless> beuno: which is using a single connection from threads
<lifeless> beuno: smart connections do not overlap requests, you need separate connections if you want to make a second request before the first is finished
<lifeless> or finally, if you have a generator response, you need to exhaust the generator before making new requests
<Peng_> lifeless: You mean a multithreaded server or a multithreaded client?
<lifeless> Peng_: user of a connection
<Peng_> Wait, where does TMCR happen? Client or server?
 * Peng_ 's brain isn't fully engaged today.
<lifeless> Peng_: could happen on either, but in practice clients have a much larger surface area to get wrong
<Peng_> FWIW, the subject of this is https://code.edge.launchpad.net/~beuno/loggerhead/serve-config/+merge/6821#comment17559
<Peng_> I just realized that there might be two smart servers in play which...is totally confusing.
<lifeless> there are two in play
<lifeless> where is the exception coming from
<lifeless> the bzr client, or loggerheads client ?
<Peng_> lifeless: bzr client.
<Peng_> I think.
<lifeless> do this
<lifeless> start loggerhead in one terminal
<lifeless> run  bzr log in another
<Peng_> Yeah, that's what I did. The bzr client is the one that displayed the traceback, but it's possible it got it somewhere else. Or something.
<lifeless> so that means that the client is leaving a hpss connection in a bad state
<lifeless> run with -Dhpss
<lifeless> its likely getting an error from loggerhead
<lifeless> though I didn't know that loggerhead provided hpss calls over its http connection
<Peng_> lifeless: It doesn't, yet. Though there's a branch up about it.
<Peng_> Like I said, my brain is pretty fried right now.
<lifeless> Peng_: does this branch do that?
<lifeless> soliciting for reviews of
<lifeless> https://code.launchpad.net/~lifeless/bzr/Commands.hooks/+merge/6936
<Peng_> lifeless: No.
<lifeless> Peng_: in any event, if the exception is in the client, debug the client
<lifeless> you'll find a bug there for sure; once fixed we can see whats wrong with loggerhead
<lifeless> and as I said before -Dhpss is a good starting point
<lifeless> that said, if you're fried. Go sleep.
<lifeless> igc: ^ if you have a few that branch would love a review
<igc> shall do lifeless - consider it done
<lifeless> igc: thanks
<igc> i.e. I'm about to spent today reviewing all I can
<igc> bbiab
 * igc lunch
<tc-rucho> I have a little question that I should know, but since I've heard bzr now uses git's packs.... bzr tracks files? or content? I mean if it tracks content with solid renaming
<lifeless> tc-rucho: bzr does not use git's packs.
<lifeless> tc-rucho: bzr tracks file names and content separately; it has excellent renaming support.
<tc-rucho> lifeless: http://bazaar-vcs.org/BzrVsHg#Mercurial%27s%20Earlier%20Advantages   then what's that?
<lifeless> a wiki page?
<tc-rucho> ....
<lifeless> :) seriouslly, give me a sec to refresh my memory
<tc-rucho> I mean that about "Git's format - packs"
<lifeless> the page is accurate, as it says 'similar to'
<lifeless> git's packs are a different format to bzr's packs
<lifeless> they are conceptually similar
<tc-rucho> ok, the question of the million. If I take a file with history, split it in two, then save in 2 different files; will bzr track that it's just a reallocated content or treat this as new coded being entered into the repository?
<tc-rucho> (git would track the content and this would keep history of every single line in the two resulting files)
<lifeless> currently bzr considers it new content
<lifeless> we have a plan to address this
<lifeless> igc: thanks; I hadn't seen your reply
<igc> lifeless: np
<lifeless> I think of New Features as things for developers-using-bzr, not plugin authors so much
<lifeless> and that plugin authors should be reading 'Internals'
<lifeless> igc: replied - thanks for catching all the little noise in that patch
<igc> lifeless: cool. I'll take a look. As I said, it looked pretty promising so I'm keen to get it through review
<lifeless> I'm fading right now
<lifeless> but if you have any questions feel free to chat here for faster turnaround
<bialix> does it only for me http://doc.bazaar-vcs.org is not available?
<bialix> main site works ok
<bob2> wfm
<Peng_> me too
<awilkins> Question : (sorry, I know I could read the source), are all commit times stored UTC and presented local-time?
<Peng_> Hm.
<Peng_> awilkins: Well, by default they're presented in their original time zone
<awilkins> So, if I commit at 0800 on a server in PDT, when I pull that revision to UTC the time will still say 0800 and not 0000 ?
<awilkins> Oops, 1600 (confusing!)
<Peng_> ISTM that on disk, a UTC timestamp and the offset from UTC are stored.
 * awilkins has the opportunity to test this
<Peng_> awilkins: Look at $ bzr cat-revision -r 123
<Peng_> awilkins: What do you mean, "pull that revision to UTC"?
<awilkins> Peng_: Pull the revision into a branch hosted on a box running in the UTC timezone (or rather, GMT. Which is BST at present anyway)
<awilkins> Although I think UTC should be a valid locale.....
<Peng_> awilkins: The local time zone won't change the revision's data.
<Peng_> awilkins: Like I said, ISTM that the UTC timestamp + time zone offset are stored on disk. With that information, bzr can display it using the orignal time zone, local time, or (theoretically) anything else; it's all the same time, so it doesn't matter.
<awilkins> Peng_: No, but does it change the presentation of the commit time ; - will 0800 PDT display as 1600 in the BST zone (because that's when it happened)
<awilkins> I'm checking this now
<awilkins> Ok, the logs have zone into
<awilkins> info
<Peng_> Yeah.
<awilkins> Right, so logs jsut display the time + zoneinfo
<Peng_> awilkins: From "bzr help log": "  --timezone=ARG        Display timezone as local, original, or utc."
<awilkins> I think my questions are probably more about qlog now then
<Peng_> I definitely don't know anything about that.
<awilkins> And qlog seems to do it right by me - it uses local
<Peng_> You could compare with "bzr log" to see what qlog doe -- yeah.
<awilkins> Ok, I'm glad that's all in order :-)
<awilkins> lifeless: ?
<awilkins> Who else is a loom-person?
<AfC> Does anyone know off-hand if there is a newer version of push_and_update than 0.2dev around?
<awilkins> lifeless: ?
<cdecarlo> hi, a friend and I are working on a project together and we decided to go with a decentralized with a shared mainline workflow, however, I want to work on more than one machine, I can do that right? I'm coming from svn and the only way to do that there is to make a lot of commits, but with bzr I can just treat my working copy both ways, peer-to-peer for me and team colaboration for us, right?
<beuno> cdecarlo, yeap
<cdecarlo> beuno: thanks
<cdecarlo> beuno: and that's b/c bzr isn't tied to a repos in the way svn is right? each working copy I have is a repos in itself?
<beuno> cdecarlo, exactly
<beuno> as long as you use "bzr branch" and not "bzr checkout" to get the branches
<cdecarlo> beuno: sweet
<mattl> hey, can anyone recommend a bzr hosting service that isn't launchpad or savannah? :)
<LeoNerd> What's a "hosting service"..?
<LeoNerd> bzr doesn't need anything special on a server.. Anything you can HTTP from, or FTP/SFTP to will suffice..
<mattl> right, but i'm thinking of something which also provides trac and backs things up, etc.
<LeoNerd> hmm.. personalyl I've never had much luck with trac against bzr.. It doesn't quite understand it
<LeoNerd> And for backup I just use rsync. Though probably I should use bzr push
<awilkins> Wait for July and Launchpad goes OSS....
<awilkins> (apart from the bestest bits, alas)
<luks> what will that solve?
<awilkins> Not much
<awilkins> Well, it might give me some more options
<awilkins> twas directed at mattl
<mattl> awilkins: code hosting part won't be free software.
<mattl> which is why i'm looking at non-launchpad options.
<luks> I know, but "wait for LP to go OSS" doesn't seem as a very useful answer to "recommend a hosting service"
<mattl> heh
<mattl> i might be waiting a while
<luks> what's wrong with a regular web hosting, though?
<mattl> i want a bug tracker too. ideally one that can actually work with bzr.
<luks> sourceforge? if you don't mind a crappy bug tracker :)
<mattl> heh.
<awilkins> BugsEverywhere, but I have my reservations about how useful the in-tree-tracker model is
<mattl> same problem as launchpad.
<luks> I'd still just setup my own trac
<awilkins> Sourceforge has an OSS version
<mattl> doesn't need to be bugs in bzr... just something that can see that, for example, a commit message that closes a bug.
<awilkins> You could write a hook that pokes at Trac's XMLRPC
<awilkins> Last time I tried something with that I was pleased at how easy it was
<luks> you could also just add a link to the trac comment when you close a bug
<mattl> well, i am wondering what tracbzr does...
<luks> and from the other side you have many local bzr tools
<awilkins> qbzr has a "fixes" entry in it's commit dialog - which trackers does that work with?
<luks> awilkins: bzr commit --fixes just stores metadata about the bug urls, nothing else
<awilkins> Aha, it goes with te fixes arg for commit
<awilkins> luks: Is there a hook that has access to that data?
<luks> it's in the revision object
<luks> so any hook can access that
<dvheumen> hey, I wanted to try bzr-svn, but I got an error about the module 'tdb' not supporting the attribute 'open'. I couldn't find anything on the gmane mailinglist search. Anyone got an idea?
<awilkins> Needs a newer tdb version? What OS are you on?
<awilkins> And how did you install bzr-svn?
<jelmer> dvheumen, you need a new version of tdb or to deinstall tdb?
<dvheumen> jelmer: hey, I think it was your package I used, from the archlinux AUR repository
<jelmer> dvheumen, I don't do archlinux packaging, I'm upstream
<dvheumen> jelmer: ow okay, than I'm confusing you with someone else ... no matter :P
<dvheumen> jelmer: I'll try finding a new tdb package, tnx for the info
<mattl> luks, awilkins... thanks for your help :)
<dvheumen> jelmer: what version should I minimally have?
<jelmer> dvheumen, Git snapshot from after december I think
<dvheumen> okay
<rotund> Can someone tell me if there's a way to have a file in VCS, but I ignore updates unless explicitly asked to update it?
<rotund> I know it's a weird request, but there's files generated by the IDE that really should never need to update.  They also contain window positions and recently used lists.  Obviously, we don't care about those.
<jelmer> rotund, I don't think there's anything like that at the moment
<luks> can't the new wt views do something like that?
<luks> e.g. svn (or at least tortoisesvn) has a ignore-on-commit changelist
<luks> which is not processed by status/diff/commit unless you explicitly ask it to
<rotund> jelmer: Thanks.  That's what I thought.
<rotund> what's a wt views?
<dash> morning
<dash> i'm trying to reacquaint myself with the use of loom
<dash> i've got a codebase in an svn repo that's been copied from the original project's repo
<dash> i.e., one revision was copied, no history is shared between them
<dash> i'm using bzr-svn and I want to develop a set of patches that can be applied to my current branch, and then adapted for application 'upstream'
<dash> do I understand correctly that to produce a series of patches like that, i'd do 'up-thread' for each, commit my changes, then do 'down-thread' and use the diff result as the patch?
<adaran> does anyone here use bzr on windows? i'd like to know how ssh works with (using the windows installer package)
<sidnei> adaran: you'd use putty, much the same way it's setup for subversion
<adaran> sidnei, i don't have putty installed - and yet it seems to work "out of the box"
<sidnei> adaran: oh, it might be using paramiko then
<sidnei> which is a python library for ssh
<adaran> sidnei, i simply installed it and i can do bzr ls bzr+ssh://foo.bar just fine - which, of course, bothers me =)
<LarstiQ> adaran: bzr has support for multiple ssh providers
<dash> does the windows install use paramiko?
<adaran> LarstiQ, that's fine. i just need to find out which one it uses at the moment and see if it's secure enough
<LarstiQ> adaran: openssh and putty at least, but what might be going on is the bundled pycrypto+paramiko in this case
<LarstiQ> adaran: try to supply -Dtransport and look at .bzr.log?
<LarstiQ> dash: the all in one installer? I'd certainly think so
<sidnei> im pretty sure the installer bundles paramiko (im working on setting up a nightly build for the installer and it's a requirement)
<LarstiQ> sidnei: cool
<adaran> LarstiQ, where'd that .bzr.log end up?
<luks> bzr version should tell you
<adaran> in "My Documents"
<adaran> oh boy..
<vxnick> is --no-trees implied when running bzr init-repo? I haven't used it on an old repo but I don't see the files in its directory
<LarstiQ> adaran: bzr --version will say, it differs over windows versions afaik
<adaran> LarstiQ, it's using paramiko, it seems
<LarstiQ> vxnick: it does. Long time ago it didn't.
<vxnick> LarstiQ: thanks
<LarstiQ> vxnick: see `bzr reconfigure` if you want to change that.
<vxnick> don't want to change it, just wanted some clarification :)
<LarstiQ> ok :)
<adaran> hmm, where am i supposed to put my keys btw?
<adaran> on windows, that is
<LarstiQ> I don't know with bare paramiko
<luks> paramiko uses the putty key agent
<LarstiQ> adaran: it's not mentioned in the userguide?
<adaran> LarstiQ, i'll go have a look
<luks> Pageant
<LarstiQ> luks: pageant, or is that something else?
<LarstiQ> ah
<jam> anyone know if there is a new qbzr version?
<jam> I thought that 0.10 or 0.9.10 was due "real soon now"
<jam> but I don't think it has been released yet
<jam> btw, jelmer didn't mark subvertpy 0.6.6 as a release on https://edge.launchpad.net/subvertpy, but I see it as a tarball in http://samba.org/~jelmer/subvertpy/
<jam> Anyone know why?
<jam> I suppose he didn't put 0.5.4 in  https://edge.launchpad.net/bzr-svn
<jam> And I *know* that exists...
<dash> Crud
<dash> is there no way to rename threads in a loom?
<LarstiQ> jam: 0.6.1 is the last bzr-svn release I'm aware of
<jam> LarstiQ: which brings up a good point, are we supposed to be switching from the 0.5.x series to 0.6.x?
<jam> I'm pretty sure I packaged 0.5.4 for bzr-1.14
<jam> (since that was the state of the release script.)
<LarstiQ> jam: I've uploaded 0.6.1
<LarstiQ> jam: johnf has been doing the ppa for bzr and bzrtools, I've been doing bzr-svn
<LarstiQ> jam: I have no clue about windows installers
<LarstiQ> jam: but yeah, I'd go with 0.6.x
<jam> hmm... it seems we still only have qbzr-0.9.8 in the ppa
<LarstiQ> bzr-gtk is also old
<jam> LarstiQ: what about subvertpy 0.6.6 ?
<jam> I saw a release on jelmer's web page
<jam> but it doesn't seem to be tagged in whatever trunk I have
<jam> hmm.. and we only have 0.6.1 in the ppa
<LarstiQ> jam: I'm not taking care of that (yet)
<LarstiQ> jelmer might be at pinkpop right now
 * LarstiQ looks at the subvertpy changelog
<LarstiQ> jam: there was no bzr-svn 0.6.1 release either I could find btw
<LarstiQ> jam: I'm willing to take responsibility for subvertpy too. I'll ask jelmer about 0.6.6, and clearer announcing in general
<jam> sure
<jam> As for 'clearer announcing' I don't often remember from email
<jam> so just having things tagged in the appropriate overview page works best for me
<LarstiQ> jelmer pinging me on irc works best for me :)
<jam> well, I have to package about 4 different ones for the bzr release...
 * LarstiQ nods
<LarstiQ> jam: I notice https://edge.launchpad.net/~subvertpy/+archive/ppa has 0.6.1 only too
<jam> oh, and do you know if he has a "0.6-mirrored" like 0.5?
<jam> The windows build host has messed up dns
<jam> so I have to manually register every domain name I want to access
<LarstiQ> subvertpy or bzr-svn?
<jam> so having everything on LP helps me a lot
<jam> bzr-svn
<LarstiQ> trunk is atm, but that's not stable
<LarstiQ> (stable, as in pointing to 0.6 always)
<jam> right, I just saw that
<jam> I don't care specifically about 0.6
<jam> just 'trunk'
<jam> in the past he had switched to having everything hosted at people.samba.org rather than lp
<jam> he seems to have switched back
<LarstiQ> jam: no, hosting is at samba, lp mirrors
<jam> LarstiQ: at one point, jelmer had it to
 * LarstiQ nods
<jam> "bzr branch lp:bzr-svn" would actually download from samba
<jam> I don't know *how* he made that work, but it did
<jelmer> jam: remote branches
<LarstiQ> jam: oh, https://code.edge.launchpad.net/~jelmer/bzr-svn/0.6 does exist
<jelmer> jam, which is different from mirrorred branches
<jam> sure
<jam> anyway, /me => lunch for now
<LarstiQ> jelmer: we just discussed subvertpy 0.6.6 not being clearly tagged/if it should be packaged (windows installer/ppa)
<LarstiQ> jelmer: do you want me to take care of subvertpy for the bzr ppa too?
<jelmer> LarstiQ: I've fixed the tag for 0.6.6
<jelmer> LarstiQ: If you can, that would be awesome
<LarstiQ> jelmer: sure.
<LarstiQ> jelmer: should I start on 0.6.6 now, or are there reasons to stay away from it?
<jelmer> LarstiQ, no, 0.6.6 should be fine
<LarstiQ> k
<jelmer> LarstiQ, actually, it seems there's enough changes to do a 0.6.7
<LarstiQ> ok :)
<LarstiQ> jelmer: should I also care about https://edge.launchpad.net/~subvertpy/+archive/ppa ?
<jam> jelmer: so I should use 0.6.6 for bzr-1.15?
<jelmer> jam: Ideally 0.6.7, which I've just pushed
<jelmer> and tagged
<jam> seems to be going
<LarstiQ> jelmer: do you use something for release automation?
<Kissaki> you can't ignore changes on a tracked file, right? eg, never commit that file anyway (so you don't have to deselect it each time)
<LarstiQ> Kissaki: correct. You could unversion it.
<LeoNerd> I've often wanted a "bzr freeze PATH" command
<LarstiQ> Kissaki: or perhaps an appropriate idiom is to version a template, copy, edit and ignore for local use.
<LarstiQ> LeoNerd: what would that do?
<LeoNerd> Yup. exactly for that use case... that a repo contains a template config file for general use. Each checkout on a machine edits it for local use
<LeoNerd> A "bzr freeze"ed file is never looked at, presumed to always be pristine
<LarstiQ> ah
<Kissaki> k, thx
<LeoNerd> "bzr stat" will not show changes, "bzr commit" will not submit it
<LarstiQ> you might be able to pull that off with a plugin
<LeoNerd> Offhand I can't quite think on the behaviour what might happen if upstream has a patch for it.. Do we attempt to merge locally anyway, or just ignore it?
<LeoNerd> It suggests the commands 'freeze PATH', 'unfreeze PATH' and 'frozen' (to list them)
<Kissaki> the file not being selected for commit would be enough really...
<LarstiQ> Kissaki: -x
<Kissaki> hm?
<LarstiQ> Kissaki: bzr commit -x filetoexclude
<Kissaki> ah, hmm
<LarstiQ> Kissaki: if aliases work per branch, you could alias commit to that
<LarstiQ> not sure, and seems a bit risky to me
<Kissaki> well, -x doesn't even work for qci
<LarstiQ> the requirements keep mounting! :)
<LarstiQ> Kissaki: file a bug on qbzr
<LarstiQ> personally, as I said, I'd reevaluate wether the file needs to be versioned in the first place
<Kissaki> yes, it has to... But I think that setting I changed doesn't even change the proj file itself... :P
<Kissaki> -h doesn't list -x for qci, so it's probably supposed to be that way
<LarstiQ> Kissaki: hmm, I'd think it's an oversight for qci
<luks> yes, it's just a missing feature
<LarstiQ> Kissaki: oh boy, a (VS) project file?
<LarstiQ> yeah, those things are irritating
<Kissaki> yep
<jelmer> LarstiQ, I hope to use moap at some point
<LarstiQ> jelmer: ah
<LarstiQ> jelmer: I had  http://liw.iki.fi/liw/unperish/ in mind, hand't heard of moap before
<LarstiQ> jelmer: liw coincidentally (and some other .fi Debian people) I'm meeting up with this week in Amsterdam. If you want to join us you're welcome.
<jelmer> LarstiQ, I hadn't seen unperish before :-) I like the idea behind moap but it doesn't work well enough in practice, I'll give it a try
<jfroy> jelmer: sorry it took so long, finally updated https://bugs.launchpad.net/bzr-svn/+bug/342065
<ubottu> Ubuntu bug 342065 in bzr-svn "KeyError due to missing file id while running bzr check on SVN repository" [Undecided,Incomplete]
<jelmer> LarstiQ, sounds like fun
<jelmer> bleh, somebody should make up a word for gezellig in English
<jelmer> jfroy, thanks
<LarstiQ> jelmer: kodikas, viihtyisÃ¤, seurallinen; according to my dictionary ;)
<adaran> i've been trying to branch or checkout a remote repository on windows xp. however, after downloading all the data, the tree is built (according to the status message), after which only a ton of gibberish is put out in my console. can anyone tell me why?
<sidnei> never seen that before
<adaran> trying with torquoise bzr now, see if it makes any difference. i've had RAM problems before (apparently, 1,25 GB page file were needed, which is an awful lot to download and extract ~ 50 MB of data to 500 MB), but i've had no more warnings about that when making the last attempt
<adaran> same error with the GUI
<LarstiQ> adaran: could you pastebin that?
<adaran> LarstiQ, no, it's too large
<adaran> LarstiQ, I need to find a way to capture the head of it first. it seems to dump a lot of binary data
<adaran> LarstiQ, i get python repr()'s of some binary stuff
<LarstiQ> adaran: that certainly sounds wrong
<adaran> LarstiQ, shouldn't bzr produce a log?
<LarstiQ> adaran: yup. `bzr --version` tells you where it's stored
<adaran> aw, shit. it's grown to 200 MB and notepad can't open it :P
<adaran> LarstiQ, http://pastebin.com/m18f9561 -- there
<adaran> LarstiQ, bzr check on server runs fine
<ddaa> Hopefully, this the appropriate place to rant about hg.
<ddaa> I'm trying it on a new project
<ddaa> and boy, is their "log" feature broken.
<ddaa> I understand why they spend so much time destroying their history with queues and rebase kind of gross stuff.
<ddaa> The reason is that log just displays everything flat, in order in which it got into the repository, no merge hierarchy.
 * ddaa feels better
<fullermd> Pfft.  You're missing the point, man.  It's FAST.
 * ddaa hits fullermd with a plank studded in spiky and rusty nails
<ddaa> fullermd: thanks for helping my catharsis :)
<fullermd> I've sometimes thought the rabid joy of gitk springs from the same well, actually...
 * Kinnison grins
<ddaa> Kinnison: hello you cuddly red-haired man.
<ddaa> hgk does help, but then this "flat log" attitude then engenders the "fast forward pull on no divergence" idea, which just completely screws away the notion of a mainline.
<fullermd> Well, they dovetail.
<ddaa> The log breakage engender a whole view of how to do dvcs, which is just WEAK.
<fullermd> If your tool doesn't do anything useful with the first parent path, it won't aim at workflows which preserve it, which makes it useless, which makes it not preserved, which...
<Kinnison> ddaa: salut
<fullermd> 's why trying to explain across that divide just ends up with both sides looking puzzled.
<ddaa> It produces a tool that makes people think "let's do the svn dogpile branch thing, except distributed".
<ddaa> fullermd: actually, you can prove this is a bad idea by pointing that some implications are absurd.
<fullermd> Only to people who care about and pay attention to theory   :p
<ddaa> Specifically, the idea that people should not do small frequent commits because it pollutes the logs.
<fullermd> Oh, they can do small frequent commits.  You just use rebase to squish them together logically later.  See how easy it is?
<ddaa> You do not need to pay attention to theory to find value in "oops, I have done shit in the last 30 min, let's do revert"
<ddaa> fullermd: that precludes early sharing of work.
<fullermd> Nah, you just tell all your peers to rebase on your new rebase.  That's what distributed means, isn't it?
<ddaa> No it isn't.
<ddaa> I need to finish this presentation about "Why Bazaar is better"
<ddaa> Or "Advanced Bzr"
<ddaa> To explain all the non-obvious stuff that people new to do DVCS just don't see.
<dash> yes, the ability to get a clean trunk log is the #1 reason I decided to sue bzr over hg
<dash> s/sue/use/
<sevenseeker> I might not be looking in the right places, but where are good docs on bzr-svn workflows?
<rbriggsatuiowa> is there a way to do a bzr ignore that is only local?
<rbriggsatuiowa> to my working copy?
<ddaa> rbriggsatuiowa: no, there isn't.
<rbriggsatuiowa> alright - thanks
<jelmer> sevenseeker, whatever workflow works for bzr itself should work for bzr-svn generally
<fullermd> rbriggsatuiowa: You can add per-user ignores, but they affect any of your branches.
<rbriggsatuiowa> that's fine
<sevenseeker> ok, I am doing this wrong then.  I did 'bzr checkout foo' and then I can't branch from foo with 'bzr branch foo foo_branch'
<ddaa> Actually, my distaste for hg just crossed the line where I'm willing to discard history instead of waiting for someone to fix bzr-hg.
<rbriggsatuiowa> I have one config file I don't want checked in when I'm on our production machine
<jelmer> sevenseeker, what about it doesn't work
<jelmer> sevenseeker, ?
<rbriggsatuiowa> where do I add the per user ignore?
<fullermd> rbriggsatuiowa: That's in ~/.bazaar/ignore I believe.
<abentley> ddaa, rbriggsatuiowa: .bzrignore doesn't have to be versioned.  So if *none* of the ignores need to apply to others, you can do that.
<rbriggsatuiowa> thanks
<dash> the other nice thing about bzr is that you can do almost everything without having to change your thinking from svn :)
<sevenseeker> jelmer: let me clean this out and try again... troubleshooting I did silly things I think
<ddaa> Anyway, let's try this thing. Maybe I'm going to realize that I do not actually care about clean mainlines.
<dash> quelle horreur
<ddaa> Actually, I can't help it... I do care.
<ddaa> (wow, it took me all of one minute of pondering)
<sevenseeker> jelmer: no .svn or .bzr in any workingcopy dir
<sevenseeker> jelmer: this was via 'bzr co http://foo.bar/svn/foo'
<jelmer> sevenseeker, that should create a .bzr directory in the checkout
<sevenseeker> ok it did, just not further down... I was expecting .svn dirs for some reason (habit I guess)
<jelmer> sevenseeker: bzr only creates a control directory in the root
<sevenseeker> ok, so if I want to split up then I just do smaller checkouts?
<jelmer> sevenseeker: "bzr co --lightweight" will create .svn directories
<sevenseeker> can I bzr branch off of subdirs then?
<jelmer> sevenseeker: yeah, you should be able to
<sevenseeker> ok, I will try this... thanks a bunch
<jelmer> sevenseeker: I'm not entirely sure though, it only works because of the nature of svn if it does
<beuno> jelmer!
<jelmer> beuno: Hey!
<jelmer> back in .ar?
<beuno> jelmer, hi
<beuno> yes!
<beuno> :)
<beuno> it's cold
<beuno> but feels-like-home cold
<beuno> so not too bad
<beuno> how about you?
<sevenseeker> jelmer: success! thanks again
<jelmer> beuno, It's actually not too bad here, though not as good as bcn
<jelmer> sevenseeker, np
<beuno> jelmer, did you see my comment about your broken branch?
<beuno> the loggerhead-smart one
<jelmer> beuno, yeah, just tried to submit using a bundle
<jelmer> maybe that'll work better
 * LarstiQ hugs ddaa 
<jelmer> I suspect I have a broken repo somewhere though not sure how it was corrupted
<LarstiQ> adaran: aha
<adaran> LarstiQ, there may be memory problems
<LarstiQ> adaran: could you try `bzr reconcile` instead/next to `bzr check`?
<adaran> LarstiQ, copying the repository (in a zip) to windows works, then i can branch it locally on the machine
<LarstiQ> adaran: ah, and maybe save a copy of that zip?
<LarstiQ> adaran: which bzr version is this?
<adaran> LarstiQ, checking
<adaran> LarstiQ, won't be able to hand out a zip, sorry
<adaran> LarstiQ, commercial stuff
<LarstiQ> adaran: that's fine
<adaran> LarstiQ, 1.3.1 on the server
<adaran> LarstiQ, latest windows release on the client
<LarstiQ> reproducability is the main thing.
<LarstiQ> adaran: ok
 * ddaa hugs LarstiQ back
<adaran> LarstiQ, i'm thinking it may be memory
 * LarstiQ wonders if it is bug 347979
<ubottu> Launchpad bug 347979 in bzr "KnitCorrupt listing _KnitGraphIndex when pulling" [Undecided,New] https://launchpad.net/bugs/347979
<LarstiQ> ddaa: I have recently started using hg (for sphinx), hadn't figured out how to use log properly yet, postponed it in the hope I'm missing something.
<ddaa> LarstiQ: I'm pretty sure you're not missing something.
<LarstiQ> you make me think so too.
<ddaa> A lot of strange thing the git/hg folks care about make sense once you realize they are working around a broken log...
<ddaa> and going in direction that would be wrong with a working log.
<LarstiQ> not having a mainline does make some things simpler/faster.
<ddaa> Sure. Not tracking dir renames too.
<LarstiQ> fair enough.
<ddaa> A lot of things are simpler when you only solve half the problem.
<ddaa> I think the bzr people as a community are really bad at explaining what those things are that they are solving better than the competition.
 * LarstiQ nods
<adaran> LarstiQ, what's with the huge memory usage as well? i've seen my page file go up to 1,4 GB or so for a 450 MB source repository
<adaran> LarstiQ, is that a bug or "normal"? it seems a bit much
<LarstiQ> adaran: let me dig up a mail/bug for you
<LarstiQ> adaran: short answer, right now, that's about to be expected I'm afraid.
<ddaa> LarstiQ: BTW, did you mean "simpler/faster" to implement, or to use?
<LarstiQ> adaran: https://bugs.launchpad.net/bugs/109114
<ubottu> Ubuntu bug 109114 in bzr "commit holds whole files in memory" [Medium,Confirmed]
<LarstiQ> ddaa: program model/implement. No claims about that being a simpler user model or not.
<LarstiQ> ddaa: I'm personally unconvinced by the rebase arguments that an unrebased history will become unwieldly.
<ddaa> It does become unwieldy when your log is broken.
<LarstiQ> ddaa: _but_ bzr does have performance problems due to issues related to the mainline
<jelmer> beuno, I think I'm going to just recommit
<LarstiQ> ddaa: mainly the O(history) topological sort for the dotted revnos numbering
<LarstiQ> or well, possibly less if you can find a merge point faster
<beuno> jelmer, cool, thanks
<ddaa> LarstiQ: mainly, that translates into "log is slower", right, or does it commonly affects other operations?
<LarstiQ> ddaa: log
<ddaa> So, the alternative is "broken log" and "slower log".
<LarstiQ> ddaa: igc did a lot on this front, one change is to not display non-mainline revisions by default
<LarstiQ> ddaa: ie, bzr log -n1 vs bzr log -n0
<ddaa> There would certainly be value in having a hierarchical log that does not show dotted revnos
<LarstiQ> ddaa: surely git/hg people must deal with their log some way?
<ddaa> AFAICT, they deal with it by requesting that people do not make frequent commits, or collapse their commits. Witness jelmer.
<adaran> LarstiQ, does bzr really use readlines() et. al. when handling binary files?
<luks> I was really surprised that git log is not even topologically sorted by default, it uses the commit date
<ddaa> They are happily throwing away half of the baby with the bath's water, and think it's fine because the remaining half baby is better than what they had before.
<LarstiQ> adaran: I don't know on which object that is a readlines() method, but yes.
<ddaa> luks: AFAICT hg log is not sorted either, it just print stuff in repository order, which HAPPENS to be topologically sorted.
<LarstiQ> ddaa: well, already having data in sorted order is nice of course :)
<adaran> LarstiQ, makes it - on the outside - look as if bzr is very bad at handling large files and/or binary files. =/
<LarstiQ> adaran: I don't directly see that, binary lines are still lines.
<LarstiQ> adaran: and the differ works on (binary) lines.
<adaran> LarstiQ, yes, but i was more referring to the fact that there are a lot of copies floating around
<ddaa> It's sorted in a way that depends on how the repository was built (the sequence of "pull" commands), but I'm not sure how much it matter in practice.
<LarstiQ> adaran: yes, there are multiple file copies around during commit. This is indeed bad for files that don't fit in memory that many times.
<ddaa> I mean, it's not topologically sorted in a way that only depends on the structure of the history.
<ddaa> (as bzr log is)
<LarstiQ> ddaa: ah
<luks> it just makes the numeric revision ids unusable
<luks> but it doesn't really affect the log otherwise, as far as I know
<LarstiQ> luks: they're still stable within one repository though?
<ddaa> well, it does affect it, but since it's already half unusable by virtue of not being hierarchical, it does not make thing substantially worse.
<luks> sure, but not across multiple repositories
<luks> even if used in the same branch, with the same head revision
<pygi> hi
<beuno> pygi, hi
<beuno> I replied to your email  :)
<LarstiQ> adaran: jam said he'd look at possibly having a different codepath for those big files, but didn't follow up. You could comment and ask if there is any progress?
<LarstiQ> luks: right
<LarstiQ> luks: so less usable than bzr revnos, but still of some use
<adaran> LarstiQ, i will drop a comment. though at the moment, it seems tempting to find out how git and others do it, for example
<pygi> beuno: I saw, thank you sir!
<pygi> beuno: I just came home, was about to respond later on that I agree with locations.conf stuff
<LarstiQ> adaran: sure
<jam> LarstiQ, adaran: I have been invoked, but I don't know the start of the thread
<LarstiQ> jam: sorry, let me fill you in
<beuno> pygi, how was your trip back?
<pygi> beuno: it was ok, thank you :)
<adaran> jam, don't even attempt to step out of the circle!
<pygi> beuno: I just wished I don't have a cold, freaking air conditioning!
<LarstiQ> jam: adaran is experiencing http://pastebin.com/m18f9561 on a pull/branch. Zipping it up, copying and unpacking doesn'y.
<LarstiQ> jam: with 450mb files, and earlier MemoryErrors if I got that right, the suspicion is memory usage.
<LarstiQ> sorry, at least one file of size 450mb
<adaran> jam, LarstiQ i should add that i can branch locally just fine, and remotely (network) on my linux machine. i'm having issues on a virtual machine with windows XP and 378 MB of ram, pagefile < 1,2 GB
<beuno> pygi, yeah, it was brutal
<LarstiQ> jam: so I dug up bug 109114
<ubottu> Launchpad bug 109114 in bzr "commit holds whole files in memory" [Medium,Confirmed] https://launchpad.net/bugs/109114
<adaran> LarstiQ, sorry again, the whole repos is 450 MB or so unzipped, 50 MB bzr transfer, 100 mb zipped. let me find the largest file...
<jam> I would be rather surprised to get a KnitCorrupt when there is really a MemoryError
<LarstiQ> jam: which isn't exactly the issue right now, but anyway
<pygi> beuno: Oh well, at least we got some things done, setup a plan for further work and stuff :p
<pygi> and it was great to finally meet all of you :)
<adaran> jam, LarstiQ largest file is 181 MB, text file with short lines
<LarstiQ> jam: bug 347979 seemed a closer hit, but not really helpful
<ubottu> Launchpad bug 347979 in bzr "KnitCorrupt listing _KnitGraphIndex when pulling" [Undecided,New] https://launchpad.net/bugs/347979
<beuno> pygi, absolutely. Enjoyed it as well
<jam> adaran: even better, does the file have a final newline?
<LarstiQ> jam: other than the immediate issue at hand, adaran has some concern about bzr handling big files
<adaran> jam, yes. \r\n
<jam> LarstiQ: sure, I've mentioned some specifics in 109114
 * LarstiQ nods
<jam> and certainly ways we could improve bits
<LarstiQ> jam: so now we've arrived at the jam invocation :)
<jam> which essentially resolves into.... we'd like to change some bits as according to 109114, to avoid splitting and joining over and over again
<adaran> LarstiQ, jam well the other concern is, i've known people that keep their whole $HOME in VCS'es. if it's only a few GB, it's a bit unconventional - but a breeze to backup and replicate
<jam> adaran: we shouldn't have to keep the content of *all* files in memory at once
<jam> just one at a time
 * LarstiQ nods at adaran 
<jam> So the total size of GB isn't terrible
<jam> It is the 181MB single large text file of small lines that would be killing you for 'commit'
<jam> though it shouldn't effect things like 'pull' very much
<adaran> LarstiQ, jam it looks as if that'd be hardly possible with bzr at the moment - if you had a large picture - which is something you'd want to put in a repository if it was part of an app or a project anyway - you'll run into trouble, especially on a small server with little ram
<jam> adaran: well, someone is exploring versioning all of 'debian', which is approx 7.5M files
<adaran> jam, i'm having problems branching and checking out. there's no way for me to tell well though, if i'm running out of memory or not.
<jam> (num files, not num bytes)
<adaran> jam, would be nice if it fit on a few floppies though =)
<adaran> jam, but few big files in there! even if they included binary packages, i'd be rare to see a file above 40 MB or so
<jam> adaran: your KnitCorrupt traceback is gzip telling us we don't have a valid gzip stream
<adaran> jam, my other suspect was that embedded python ssh library somehow messing up, but since i'm - at the moment - paid to work instead of fixing bugs in bzr, i decided not to pursue that end, sorry =/
<jam> adaran: the embedded ssh lib uses pyCrypto as the ssl handler, and I would be quite surprised if that was specifically buggy
<jam> not to mention that I use paramiko many times a day
<jam> and have never seen corruption
<jam> though it is possible that paramiko is getting a memory error and then supressing it
<jam> causing us to see a short read that looks corrupted
<jam> or something like thta
<jam> that
<adaran> well, unlikely, yes. but other than that, you haven't run into the error i've encountered a lot, or it would be fixed, i'd assume =)
<jam> adaran: true, though I don't often version 100+ MB text files, either :)
<adaran> jam, it's a "test-case" db dump =)
<Tak> jelmer: http://img39.imageshack.us/img39/3043/mdannotate.png
<jelmer> Tak, AWESOME
<jelmer> Tak, Seriously, that's way cool
<Tak> :-D
<beuno> jam, any ideas on what this could be: http://paste.ubuntu.com/186006/
<beuno> not sure if I should file a bug or not
<beuno> branch seems broken
<jam> beuno: well, if it wasn't loggerhead I would say it was a ghost issue
<jam> but IIRC loggerhead shouldn't have any, right?
<beuno> all commands error out
<beuno> right, no ghosts AFAIK
<jam> Otherwise, it might be:
<jam> 4392 Canonical.com Patch Queue Manager 2009-05-29 [merge]
<jam>      (jam) Fix bug #373455, allow --dev6 repos to stack.
<ubottu> Launchpad bug 373455 in bzr "brisbane-core doesn't support stacking but should" [High,Fix committed] https://launchpad.net/bugs/373455
<jam> And some issues wrt missing parent inventories and stacking
<beuno> it's not --dev6 though
<beuno> its 1.9-r-r
<jam> beuno: sure, but see: https://code.edge.launchpad.net/~jameinel/bzr/quick-fix/+merge/6948
<jam> in case you are using the latest bzr.dev
<beuno> I'm on 1.15
<jam> beuno: if you are using bzr.dev or bzr nightlies, you might try reverting to 4391
<beuno> bzr nightlies stopped working  :(
<beuno> jam, did that rev get into 1.15?
<jam> beuno: I don't think so
<jam> otherwise 1.15 would have gc stacking :)
<Tak> oops, forgot one of the cooler parts - http://img39.imageshack.us/img39/5305/mdannotates.png
<beuno> I wonder if I broke it when doing the upgrades
<jam> beuno:  so the traceback makes it seem like the workingtree thinks it is on revision: 'argentina@gmail.com-20081223183723-7vgehy3i4p6cr1lu'
<jam> but that revision isn't in your repository
<jam> which seems pretty strange
<jam> are you using a lightweight checkout?
<beuno> htm
<beuno> hrm
<beuno> no, it's a branch
<beuno> now
<beuno> my loggerhead repo b0rks with bzr check
<jam> with a shared repo that you copied from elsewhere? and missed other stuff?
<beuno> it's a shared repo
<beuno> and I upgraded it to 1.9-r-r
<beuno> check breaks with: http://paste.ubuntu.com/186013/
<beuno> reconcile went through it just fine
<beuno> jam, any ideas on how to get out of that mess  ^
<jam> beuno: find a repository with the text key: ('wsgitest.py-20080612051902-5y0zpdi6fhxgun6z-1', 'jelmer@samba.org-20090529150418-05on2fgizfqs77fj')
<jam> and have it inserted...
<jam> it looks like you have a revision which mentions a file text which does not actually contain that text
<jam> which is sort of bad
<beuno> jam, just an FYI: https://code.edge.launchpad.net/bzr/+activereviews
<beuno> maybe you know it already
<beuno> and the bug you filed it so figure out what needs merging
<jam> beuno: I didn't specifically, but in that case, I would recommend changing the link that exists here:
<jam> https://code.edge.launchpad.net/~bzr/bzr/trunk
<jam> I'm not sure why it gives "24 branches proposed for merging"
<jam> or how you are supposed to reach +activereviews via the web ui
<Peng_> You can get to +activereviews from https://code.edge.launchpad.net/bzr
<mxpxpod> when you do a bzr mv with bzr-svn, will it preserve history of those files?
<jelmer> mxpxpod, yes
<mxpxpod> jelmer: thanks
<ddaa> Oh joy! I can combine hg-fast-export.py and bzr "fast-import" to move history from hg to bzr.
<ddaa> it gets the order parents the wrong way around, but otherwise it looks like it works
<beuno> jelmer, did you manage to re-push your smart server branch?
<jelmer> beuno, yeah, but no luck; launchpad seems to ignore my merge requests
<jelmer> (probably because it isn't able to deal with the bundle)
<jelmer> so I'm just going to do the recommit in a few minutes
<jelmer> from a fresh clone
<beuno> jelmer, cool. I assigned the bug to you
<jelmer> oh, I wasn't aware there was a bug open :-)
<ddaa> mh, rename data is lost in the process :(
<jelmer> jam, Interesting results from bencode
<rowinggolfer> I am uncertain as to whether I need to file a bug over a recurring problem I am having.
<rowinggolfer> http://pastebin.ubuntu.com/186084/
<rowinggolfer> everytime I make a push, bzr hangs.
<rowinggolfer> with a "too many concurrent requests" error.
<rowinggolfer> I push again... account is locked (naturally)
<beuno> rowinggolfer, could you upgrade to a newer version of bzr?
<beuno> and see if it still happens?
<rowinggolfer> the command line returned for the lock is incorrect.
<beuno> 1.6 is quite old
<rowinggolfer> I'm on intrepid.
<rowinggolfer> beuno: one quick question.
<beuno> rowinggolfer, use the PPA: https://edge.launchpad.net/~bzr/+archive/ppa
<rowinggolfer> thanks I will.
<rowinggolfer> beuno: one quick question
<beuno> shoot
<rowinggolfer> I installed ssh-server on this machine.
<rowinggolfer> and that seems to co-incide with this problem
<rowinggolfer> ie. 105 commits went ok.
<rowinggolfer> the last 15 have all had this issue
<rowinggolfer> my keys wouldn't be messed up perhaps?
<rowinggolfer> I can't see they would be the same?
<beuno> can you ssh with no problems?
<rowinggolfer> to other machines, yes.
<rowinggolfer> do you mean to a launchpad server?
<beuno> yes
<beuno> try: sftp://bazaar.launchpad.net
<rowinggolfer> sorry, how would I try that?
<beuno> sorry
<beuno> try: sftp bazaar.launchpad.net
<rowinggolfer> beuno - yes. no probs.
<rowinggolfer> ok.. I'll upgrade my bzr.
<rowinggolfer> thanks.
<beuno> rowinggolfer, that way at least we can confirm the bug  :)
#bzr 2009-06-02
<Peng_> beuno_: ping
<beuno_> Peng_, hi!
<Peng_> beuno: About bug 247162, my patch makes it (mostly) valid, but wrong if the server's time zone isn't UTC, thanks to bug 376842.
<ubottu> Launchpad bug 247162 in loggerhead "atom feed does not validate" [Low,Triaged] https://launchpad.net/bugs/247162
<ubottu> Launchpad bug 376842 in loggerhead "Loggerhead is time zone-naive" [Undecided,New] https://launchpad.net/bugs/376842
<Peng_> \o/
<lifeless> ola
<beuno> hey lifeless
<rowinggolfer> beuno: problem solved. thanks.
<rowinggolfer> do you want me a file a bug, so you can claim some karma?
<rowinggolfer> ;)
<beuno> rowinggolfer, heh, I'll take the moral karma
<thumper> lifeless: hi
<thumper> lifeless: you working today?
<lifeless> yes
<thumper> jam: ping
<mwhudson> beuno: i guess we should create a milestone thingy for the next loggerhead release
<beuno> mwhudson, yes!
<beuno> codename?
<beuno> Peng_, is bug 358336 still valid?
<ubottu> Launchpad bug 358336 in loggerhead "SQL cache directory isn't deleted on shutdown" [Undecided,Confirmed] https://launchpad.net/bugs/358336
<Peng_> beuno: Yes.
<spiv> Good morning.
<beuno> Peng_, can you set it to triaged?
<mwhudson> beuno: can you rename milestones?
<beuno> mwhudson, maybe. I wouldn't bet on it. We could just say 1.16
<beuno> and put some pressure to release it for 1.16  :)
<mwhudson> beuno: heh, ok :)
<beuno> I'll create the 1.16 series
<beuno> with a 1.16rc1 milestone
<beuno> and a 1.16 as well
<Peng_> beuno: ok
<beuno> thanks
<beuno> I'm trying to clean up our bugs
<bob2> eep, poor savannah
<mwhudson> beuno: you're certainly sending me a lot of mail :)
<beuno> Peng_, mwhudson, milestone 1.16rc1 created, target away!
<beuno> "no bug left un-triaged" campaign
 * Peng pokes at Peng_.
<beuno> mwhudson, doesn't pastedeploy take care of bug 333755
<ubottu> Launchpad bug 333755 in loggerhead "serve_branches script needs way to configure the public URL to the web server" [Undecided,New] https://launchpad.net/bugs/333755
 * Peng_ shrugs
<mwhudson> beuno: https://bugs.edge.launchpad.net/loggerhead/+bug/240508 is suggesting something like log --line, not a small diff i think
<beuno> mwhudson, also, if you can tell me what bug 334615 is about, I'd be greatful  :0
<ubottu> Ubuntu bug 240508 in loggerhead "Files view should show one-line change line per directory/file" [Undecided,Won't fix]
<ubottu> Launchpad bug 334615 in loggerhead "Doesn't invalidate cache when ghosts filled" [Undecided,New] https://launchpad.net/bugs/334615
<beuno> jelmer, feel free to target branches at 1.16rc1 as well
<beuno> especially the stuff you need for debian
<mwhudson> beuno: i can't really remember the details for https://bugs.edge.launchpad.net/loggerhead/+bug/334615
<ubottu> Ubuntu bug 334615 in loggerhead "Doesn't invalidate cache when ghosts filled" [Undecided,New]
<beuno> mwhudson, maybe we can just set it to incomplet?
<mwhudson> beuno: ok
<jelmer> beuno, will do
<beuno> it's ironic how everything gets black if you do your job
<jml> jelmer: ping
<jelmer> jml: Hello
<jml> jelmer:
<jml> jelmer: I'm just being bitten by BZR_DEFAULT_INTERFACE not being in bzrlib.remote -- do you know anything about this?
<jml> jelmer: hmm. never mind. my bzr-archeology-fu is weak.
<jml> man, it's too hard to search for a thing being deleted.
<lifeless> jml: yes; I have 'plans'
<jml> I've got some code that uses 'remote.BZR_DEFAULT_INTERFACE' -- I'm trying to figure out how the hell it ever worked at all, and what changed to make it not work.
<AfC> I love it when that happens: "how does this work?"; "why is this working?"; "this _shouldn't_ be working!"; "how did this *ever* work?!?"
<lifeless> jml: as a starting point, r.texts.iter_lines_added_or_present_in((key for key in texts.keys() if key[0] == tree.path2id('__init__.py'))
<jbalint> hey! is there a command to apply a patch
<cody-somerville> path -p1 < ./patch.diff ? :)
<lifeless> jbalint: there is a patch command in bzrtools, but as cody-somerville says you can just apply normally ;)
<jbalint> yeah, patch crashes for me on windows :(
<jml> lifeless: did remote.py used to be a package?
<jml> (grammar sucks)
<lifeless> jml: oh, I thought it was a package
<lifeless> jml: so remote.py :)
<lifeless> jelmer used to have something like it as a plugin I thought
<jml> nfi how this worked
<lifeless> ciao
<pygi> vila: greetings :p
<vila> pygi: Hey !
<pygi> vila: howa re you doing? :)
<vila> pygi: fine thanks, I slept a lot this week-end :-)
<pygi> happy you :P
<pygi> vila: I didn't :p
<hypest> hello fellows. I must be missing the correct keywords as I cannot find information on whether it is possible to move a line of revisions into a new branch. Any help?
<Peng_> hypest: What do you mean by "move" and "line of revisions"?
<hypest> I decided that the latest 3 "trunk" commits, should really have their own branch. So I want these 3 revisions to form a new branch
<lifeless> bzr branch trunk newbranch
<lifeless> cd trunk && bzr uncommit -r -3
<hypest> lifeless: that will probably do the job. I'm generally "afraid" of even thinking of using undo procedures, so that didn't cross my mind :). Thank you ;)
<vila> abentley: ping, bzrtools tests abort with: ImportError: cannot import name test_fetch_ghosts, sounds like a missing file
<abentley> vila: thanks.  fixed and pushed.
<vila> abentley: pulled. thanks
* lifeless changed the topic of #bzr to: Bazaar version control system | 1.15final released 22 May, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<moldy> hi
<jelmer> hi moldy
<jelmer> Peng, I've updated the smart-server branch but I have no idea how to get launchpad to update the diff for the merge request
<Peng_> jelmer: I don't either.
<beuno> jelmer, Peng_, apis, blah
<beuno> nothing on the web UI yet
<beuno> jml is working on it
<Peng_> Loggerhead should probably always use a read-only transport.
<Peng_> jelmer: Will keeping the smart server around have any RAM implications?
<jelmer> Peng_, AFAIK It shouldn't since it is stateless
<Peng_> I guess I should check and find out.
 * Peng_ kicks bug 348308.
<ubottu> Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] https://launchpad.net/bugs/348308
<lifeless> Peng_: some, nothing major as a client
<lifeless> as a server it will discard branch objets etc too
<Peng_> lifeless: ok
<Peng_> Hello! serve-branches's VSZ is 560 MB branching bzr.dev.
<Peng_> "bzr branch" bombed out, and serve-branches's VSZ went down to 400 MB.
<Peng_> Mental note: smart-server-2/loggerhead/history.py:63: DeprecationWarning: bzrlib.progress.ProgressBarStack was deprecated in version 1.12. klass=bzrlib.progress.DummyProgress)
<lifeless> Peng_: file a bug
<Peng_> lifeless: About bzr branch or the progress bar thing?
<jelmer> lifeless, moin
<lifeless> Peng_: both
<lifeless> jelmer: gnight ;)
<jelmer> lifeless: subunit is in sid now, in case you're interested in having it synced to ubuntu
<lifeless> jelmer: I am
<lifeless> jelmer: it should automatically while karmic is open
<jelmer> lifeless, ah, don't mind me then :-)
<lifeless> jelmer: are there any remaining packaging bugs for it ?
<jelmer> lifeless, All the ones I came across (except for manpages) are fixed in the debian packging branch
<lifeless> have you a branch for upstream for manpages?
<jelmer> lifeless: I haven't bothered to write manpages yet
<lifeless> jelmer: oh right ;)
<lifeless> I thought you had from that comment
<Peng_> My "bzr branch" error was bug 372881.
<ubottu> Launchpad bug 372881 in bzr "bzr cannot branch from rocketfuel" [Critical,Confirmed] https://launchpad.net/bugs/372881
<Peng_> fwiw
<visik7> can I setup a repository to be autochecked out when I commit over it ?
<beuno> james_w, ping
<beuno> jelmer, hi
<jelmer> beuno, moin
<jelmer> visik7, not sure I understand what you mean
<beuno> jelmer, where do I get a branch to test work on the UI for: https://code.edge.launchpad.net/~jelmer/loggerhead/foreign/+merge/6952
<jelmer> beuno, if you have bzr-svn you can for example use svn://svn.gnome.org/svn/gnome-specimen/trunk
<beuno> I'll install it
<Jemsquash> I have a shared repository and some branches within this shared repository. Is there any way to compare these branches? bzr (q)diff works within a working tree but not between branches.
<visik7> jelmer: when I commit over a remote branch I would that the remote branch run a checkout on a local directory on the remote machine
<jelmer> visik7, I think there is a plugin for something like that, but it might only support push
<visik7> called ?
<jelmer> Jemsquash, bzr diff -rbranch:../path/to/other/branch
<jelmer> visik7, push-and-update or something like that
<Jemsquash> thanks jelmer I'm being a numb nut. Having looked at the docs again I assume --old and --new will do the same?!?
<jelmer> Jemsquash, not sure, I've never used them
<Jemsquash> hmm I've tried the --old and --new and it only seems to work at the top level folder. I can't see any reference to -rbranch:... within the diff documentation.  Where would I find reference to this in the docs?
<Jemsquash> I've done a search for rbranch on bazaar-vcs.org and not found any references. What's the best way to add documentation for this? Should I raise a bug report against the documentation? Can I do a checkout of the docs & add it myself?
<jelmer> Jemsquash, look for the "branch" revision specifier
<jelmer> "bzr help revisionspec"
<bialix> vila: around?
<vila> bialix: yup
<bialix> vila: bonjour
<vila> bialix: hello :)
<bialix> did you help to Gary at the sprint with loggraphprovider refactoring?
<Jemsquash> Thanks Jelmer I see where I went wrong with the documentation now, both online & command line help.
<bialix> Gary has changed internal structure of data about branches to improve test coverage, but this is introduce several regressions as well
<bialix> Gary offline, so I've thought you could be aware of this
<vila> bialix: sorry, no, we talk about tests but we didn't pair so I don't know what he changed :-/
<visik7> how can I assign a working tree to a branch ?
<Peng_> jelmer: Why is the bencode revision serializer preferred over RIO?
<visik7> I got bzr update
<visik7> bzr: ERROR: No WorkingTree exists for...
<jelmer> Peng_,  better apparent performance and can handle funny characters in e.g. property names
<Peng_> jelmer: Okay, cool. :)
<cody-somerville> jelmer, ping
<cody-somerville> jelmer, Can you take a look at http://launchpadlibrarian.net/27405730/live-helper-trunk-log.txt ?
<jelmer> cody-somerville, That's an outdated version of bzr-git
<jelmer> cody-somerville, known bug, fixed upstream
<visik7> can I checkout in a different place instead of . ?
<jelmer> visik7, create a working tree you mean?
<visik7> yes
<jelmer> visik7, I think you mean a lightweight checkout?
<visik7> yes
<visik7> but I dunno why it doesn't work
<visik7> jelmer: http://dpaste.com/50548/
<jelmer> visik7, does /var/www/vhosts/catellani.net/httpdocs/ contain a branch?
<visik7> no
<jelmer> visik7, then I don't see how that command should work
<visik7> I don't understand
<visik7> I want to checkout the working tree in a different location than .
<ddaa> visik7: where is the branch you want to checkout?
<visik7> webdav
<ddaa> bzr checkout --lightweight webdav where_you_want_the_working_tree
<ddaa> --files-from is something different
<ddaa> Actually, I have no idea what --files-from is for, but I am sure it's not for what you are trying to use it.
<visik7> ok I think I got it
<visik7> bzr checkout --lightweight . /destination
<ddaa> that can work too, if the current directory is a branch (it contains a .bzr/branch)
<visik7> current dir is the repository
<ddaa> bzr cannot checkout a repository
<ddaa> it can only checkout branches
<ddaa> branches can be stored in a common repository
<ddaa> Hope that makes sense.
<visik7> yes I mix repository and branches
<visik7> sorry
<ddaa> Np, the hg and git folks are quite mixed up about those concepts, which makes it a bit harder for us to explain the distinction.
<visik7> yea yea I know the difference the fact is that I usally doesn't use a bzr repository so I mix the 2 names
<bialix> jam: I'd like to chat one day about diff header encoding
<visik7> oh man, my last sentence was a complete mess - maybe I should think about what I'm typing
<visik7> :P
<fullermd> i
 * fullermd stabbies his mouse.
<bialix> is there mac os x experts?
<jam> hi bialix
<jam> Sorry about the delay
<bialix> hi jam
<bialix> np
<jam> (I've had some experience with mac os x, but I wouldn't claim to be a "expert" )
<bialix> but I have to go very soon
<jam> sure
<bialix> q about mac os
<jam> bialix: so in my initial impression, I would say that "bzr diff" should output strings in terminal_encoding
<jam> and "bzr diff > file.txt" should output them in user_encoding
<bialix> do you know is X mandatory to use PyQt/Qt on Mac?
<jam> bialix: Qt has a native port on Mac
<jam> unlike gtk
<bialix> hmmm
<jam> which has an 'in progress' direct port, but the standard install uses X
<bialix> people still asking in lp answers of qbzr about installing qbzr on mac
<bialix> btw, I'm releasing 0.10 today
<bialix> jam: I know you already build windows installers; I hope you will package 0.10 to 1.15.1
<bialix> jam: about diff: what the best way to deal with "undecodable" filenames then (characters out of current codepage)?
<jam> bialix: for 'diff' I would just use .encode(..., 'replace')
<jam> which replaces 'illegal' characters with ?
<bialix> yep, I agree
<bialix> I'm just thinking about keep them in utf-8 maybe for === line
<jam> I would also like to see a command line arg "bzr diff --encoding=XXX"
<bialix> just --encoding could be confusing
<bialix> maybe
<jam> I believe a line like '===' is strictly for our purpose, so we can do what we want
<jam> the +++ and --- will be interpreted by patch
<jam> which is a bit trickier
<bialix> yes
<jam> but I don't really think we want to do multiple forms if we can get away with it
<bialix> this is why I think sometimes user should control encoding
<bialix> btw, I have one more use case for this
<bialix> bzr diff > out.diff; bzr patch out.diff -> failed for non-ascii
<jam> (also because we can't tell the difference between "bzr diff >out.diff" and "bzr diff | less")
<jam> bialix: that could be the 'patch' reader's fault. I really don't know the details.
<SamB> jam: indeed
<jam> certainly I think it would expect to read the patch in user-encoding if it had to pick something.
<SamB> that's why you should start your OWN pager
<SamB> (when stdout isatty
<SamB> )
<bialix> I believe `bzr patch` invoke patch utility under he hood
<jam> bialix: possibly, but I know we have patch parsing capability inside bzrlib
<jam> we use it to ensure that the patch preview from a merge diff ~ matches the actual content requested
<SamB> jam: oh, neat!
<SamB> I didn't know that thing was secure
<bialix> well, bzr patch is from bzrtools
<jam> bialix: if it is bzrtools, it almost definitely invokes 'patch.exe'
<SamB> jam: I doubt it
<jam> SamB: well, it is a bit loose, because email clients like to do bad things to text
<SamB> I don't think I have a patch.exe
<bialix> *I* have
<SamB> I bet it invokes =patch
<SamB> (that's a zshism ;-)
<bialix> :-)
<jam> :
<jam> :)
<jam> anyway, there is certainly bzrtools/patch.py which has a "run_patch()" function
<SamB> it means "patch as found along PATH"
<SamB> right now I get: /usr/bin/patch
<jam> bialix: so... I have the feeling that this is also heavily dependent on what version of 'patch.exe' you have, and what it considers as the 8-bit string => Unicode mapping
<SamB> some of you might /bin/patch.exe or something, dunno
<bialix> jam: maybe
 * SamB wonders why bzr diff was so slow to fail in his home directory from a cold start ...
<jam> SamB: If I was to guess, it would be the time to import all the python code we need to run
<jam> which is known to be extra bad from cold start
<jam> since python likes to stat every possible permutation for a given file
<bialix> jam: I have to run; I hope we can continue later
<jam> (everywhere on sys.path, + foomodule.so, foo.so, foo.pyc, foo.py, etc.)
<jam> bialix: suer
<jam> sure
 * bialix -> run
<SamB> jam: oh
<SamB> you seriously think it's just statting?
 * SamB wonders why statting all that would be slow anyway ...
<SamB> doesn't Linux cache the directory ?
<SamB> maybe they should introduce a multistat call };->
<jam> SamB: it also depends how long 'sys.path' is, etc.
<jam> I won't guarantee that is "all" it is doing.
<jam> But that is somewhat of what we've seen for "cold cache" performance.
<jam> just 'time python -c ""' is pretty slow in cold-cache situations
<SamB> might be interesting to oprofile that
<SamB> with kernel symbols
<mneptok> OH NOES! CANUCKIANS!
<FurnaceBoy> lol...
<FurnaceBoy> you've been reading my journal, Mr Burns
<mneptok> Exclusivement chez Bell.
<emmajane> mneptok, OY! I resemble that remark!
<mneptok> emmajane: go back to playing hockey and pretending you have a democracy. >:P
<FurnaceBoy> heh
 * mneptok hugs his former country-mates
<emmajane> mneptok, it's not a democracy, it's a constitutional monarchy! sheesh!
<FurnaceBoy> mneptok, why'd you ever leave!
<FurnaceBoy> and... whatever..  it works!
<mneptok> FurnaceBoy: -40. 'nuff said.
<FurnaceBoy> mneptok, wuss
<mneptok> (oh, and the fact that there were no longer valid .ca work permits in our home)
<FurnaceBoy> mneptok, come on, it rarely gets below -30, at least here. (TO)
<FurnaceBoy> ah, that's more like it.
<mneptok> i was in .QC
<FurnaceBoy> ah lovely!
<mneptok> it gets to -30, but with the Francochill, it feels like -40
<FurnaceBoy> well if you didn't feel comfortable...
<FurnaceBoy> you should have come here. beautiful day today.
<FurnaceBoy> perfect.
<FurnaceBoy> all the pluses of being in Canada, but not being in QC. (Though I have nothing against QC or anything French)
<mneptok> it's 73F here and *dry* (like every day)
<FurnaceBoy> yeah... but...
 * FurnaceBoy drops it.
<FurnaceBoy> ok
<FurnaceBoy> so I can't push to my private branch on LP.
<FurnaceBoy> says diverged
<FurnaceBoy> but nothign I do (pull --overwrite, merge, bleh) does anything to help
 * mneptok summons poolie, jml, abentley, and the other Usual Bazaar Suspects
 * FurnaceBoy bets it's something simple. 
 * FurnaceBoy is bzr n00b
<FurnaceBoy> but I have succeeded before.
<abentley> FurnaceBoy: Have you committed after the merge?
<FurnaceBoy> i actually committed before, then did a pull --overwrite, then committed again ... all in my frenzy to succeed
<FurnaceBoy> does that make sense?
<abentley> FurnaceBoy: You say merge didn't work.  Did you commit after the merge?
<FurnaceBoy> no, before.
<FurnaceBoy> merge did nothing, that's all.
<abentley> FurnaceBoy: After you merge, you must commit.
<FurnaceBoy> says Nothing to do, in fact.
<FurnaceBoy> hm ok.
<FurnaceBoy> so i should uncommit anything I did.
<FurnaceBoy> then merge. then commit.
<abentley> FurnaceBoy: No.
<abentley> Just merge and commit is enough.
<abentley> FurnaceBoy: Try typing "bzr missing :push" in your local copy.
<FurnaceBoy> ok. I'll turn the machine on again and retry all this. will be a little while
<FurnaceBoy> thx
<elmo> hey, anyone want to summarize the current status/support for nested trees?
<elmo> abentley: ^- maybe?
<abentley> elmo: The status will be much clearer in a few hours.
<ddaa> Hey. I'm doing an initial push over bzr+ssh of a moderately small project, and it looks like it's stalling at the very end.
<ddaa> bzr 1.15 on both ends
<ddaa> Is that a known issue or what?
<ddaa> looks like there's something stalling badly on the ssh level
<ddaa> i.e. ctrl-C takes ages to drop into the debugger
<ddaa> while doing "self._write_to.write(bytes)", where self is SmartSSHClientMedium(connected=True, username=None, host='intuition', port=None) and len(bytes) == 72707.
<ddaa> There's no reason that sending 72k should take any time at all. Is there any known trick to deal with ssh connections that get bogged down?
<tc-rucho> hello, I've been wondering, how do I config the max length of user name for bzr blame?
<tc-rucho> the default max length seems to be 7
<ddaa> maybe the "bzr gannotate" command in the bzr-gtk plugin will make you happier.
<ddaa> tc-rucho: ^
<tc-rucho> I'm gonna check that out
<tc-rucho> I've been messing with bzr for a while now and would like to know if bzr is capable of tracking the file where a content came from as well as the commit where that content was originally introduced in the repository
<LarstiQ> tc-rucho: it's not entirely clear to me what you mean with that. Bazaar tracks file renames.
<tc-rucho> LarstiQ: do you have hg arround?
<tc-rucho> I'll show you by example what I mean
<LarstiQ> tc-rucho: sure
<bialix> tc-rucho: you can pastebin desired output of hg
<tc-rucho> bialix: good idea, I'll do that, LarstiQ, hang on, will format everything nicely
<LarstiQ> aww, I was hoping for an interactive tutorial :)
<tc-rucho> LarstiQ: if you prefer it that way.. I'll go on
<LarstiQ> tc-rucho: whatever works for you
<bialix> bah
<LarstiQ> he'll come back
<bialix> terminator?
<LarstiQ> bialix: has been doing so for a while now, why stop? ;)
<bialix> :-)
<thumper> jam: ping
<thumper> jam: I'm heading afk for about 30-40 minutes, but I'd like to talk to you about stacked bbc branches later
<tc-rucho> ok my weechat crashed miserably, I'm back
<LarstiQ> tc-rucho: wb
<tc-rucho> LarstiQ: http://dpaste.com/50702/
<tc-rucho> LarstiQ: see how it tells me what file did that content come from
<bialix> I suspect this is because hg support file copies and therefore hg mv == hg copy+hg remove, while in bzr mv is atomic operation
<bialix> and bzr does not support file copies yet
<abentley> elmo: current status is that we haven't reached agreement yet on how it should be implemented and I'll be taking a couple weeks off from working on it.
<elmo> abentley: ok, thanks for the update
<LarstiQ> tc-rucho: what do the 0 and 1 signify?
<tc-rucho> LarstiQ: they are the revision short alias (there's also the hash)
<LarstiQ> tc-rucho: doh, 0 based revnos, right
<tc-rucho> and  tc <- me
<tc-rucho> ;)
 * LarstiQ nods
<LarstiQ> tc-rucho: locally it was 'larstiq', so I figured ;)
<LarstiQ> tc-rucho: in bzr I'd do, bzr mv file1.txt final.txt, bzr ci, bzr log -v final.txt
<bialix> tc-rucho: IIUC git will track content even better, and should show you in annotate that second half of the file originated from file2.txt, not from final.txt
<tc-rucho> LarstiQ: and it only tells you the revision and the commiter, nothing more
<tc-rucho> right, git does it awesomely, but it's not an option here... multiplatform project needs multiplatform repo
<LarstiQ> tc-rucho: bzr annotate doesn't show the filename information, but the data is there because bzr explicitly tracks renames, so log -v will tell you
<bialix> tc-rucho: will you need to work with non-ascii filenames?
<tc-rucho> bialix: I hope not
<bialix> you're lucky
<LarstiQ> tc-rucho: (optionally) displaying the filename might be nice, but I think space is already constrained
<bialix> because hg has some "problems" there
<LarstiQ> tc-rucho: with qannotate and gannotate, on highlighting a line you'll also see which files the diff touched
<LarstiQ> tc-rucho: is that sufficient for you?
<tc-rucho> LarstiQ: need to try that out
<tc-rucho> and figure out where do I get it from
<sevenseeker> anyone have some ideas on how to effectively branch from a machine in a private network that you can't reach?
<bialix> tc-rucho: what's use case for this info?
<tc-rucho> bialix: keeping an intuitive tracking of code origins and where some file regarding that content was renamed
<tc-rucho> bialix: maybe bzr can just do that too, but I'm not familiar with it yet
<LarstiQ> sevenseeker: depending on how strict you mean can't reach, that would by definition be impossibble
<dash> sevenseeker: just copy the directory somewhere accessible, i guess
<bialix> tc-rucho: bzr mostly tracks files, not its content
<bialix> maybe I'm too used o bzr way, but I can't imagine why I need to know how that file was named year ago
<LarstiQ> it's still the same file, the name might just be different
<bialix> yep
<LarstiQ> tc-rucho: I think bzr can provide you with the information you want, but it does things differently than hg
<bialix> you can even swap names of 2 files, and bzr won't be confused
<tc-rucho> bialix: that's nice
 * bialix agrees with LarstiQ: bzr does things a bit differently; but file copies support will be great
<tc-rucho> bialix: I like how hg let's me know what file, name, and commit, a certain piece of code of a current file was introduced
<bialix> jelmer: does you have a chance to discuss file-id aliases and file copies support at last sprint?
<tc-rucho> I haven't found my way to do that in bzr yet
<bialix> tc-rucho: I understand
<jelmer> bialix, no, we mostly looked at shorter-term things
<bialix> this info looks nice
<tc-rucho> ah, forgot to mention, it also keeps track of the original autor of certain content
<jelmer> bialix, and with lifeless not there it would've been hard to discuss path tokens
<bialix> original author?
<Isaiah> tortoisebzr doesn't work on mapped drives?
<bialix> Isaiah: I guess it disabled by default for network drives, check config
<sidnei> Isaiah: i believe you can enable that, but it's disabled by default
<tc-rucho> bialix: right, well, bzr does that too, but anyway
<bialix> jelmer: I understand
<Isaiah> bialix and sidnei, Ah ok that make sense
<Isaiah> Let me check the config
<Isaiah> Ah, why didn't I see that before! Thanks again!
<bialix> tc-rucho: I guess it's more or less differences in workflow or preferred style for using vcs
<bialix> and this is more fundamental to select vcs than just compare features or speed or whatever
<tc-rucho> right
<LarstiQ> tc-rucho: a two step way you would do that with bzr cli would be `bzr annotate final.txt; bzr log -p -r 2`
<bialix> and hg clear winner here, because it require 1 step only. heh
<LarstiQ> or whichever revision you're interested in knowing which file it was
<LarstiQ> tc-rucho: or even `bzr st -r 1 final.txt`
<LarstiQ> bialix: right
 * bialix will file a feature request for qannotate
<dash> Hmm
<sevenseeker> I use key entry via ssh for a server, can I use that key with bzr+ssh access?
<dash> yes.
<dash> any of you use emacs dvc?
<dash> i'm trying to figure out how to pass arguments to 'bzr diff' in it
<sevenseeker> can I use '-i <key>' like with ssh?
<thumper> jam: ping
<jam> hi thumper
<thumper> jam: can I skype you about stacking?
<jam> sure
<sabdfl> hey folks
<sabdfl> everyone make it home safely?
<jam> sabdfl: I did :)
<thumper> jam: bug 382795
<ubottu> Launchpad bug 382795 in launchpad-code "mirror-branch using too much memory" [Critical,New] https://launchpad.net/bugs/382795
<thumper> hi sabdfl
<sabdfl> hi thumper, jam
<sabdfl> glad at least you two made it :-)
 * jelmer waves
<dorins> Hello
<dorins> I have two bzr branches: 'upstream' and 'feature'. feature is branched from 'upstream' and has 3 additional revisions. I want to pull the last two revisions from 'feature' to upstream'. Any pointer on how to do that?
<dash> being lazy and not wanting to figure out new commands, i'd make a new branch from feature, 'bzr uncommit', then merge it to trunk.
<moldy> dorins: bzr merge -r ?
<moldy> dorins: i'm a bzr newbie myself, that's my best guess ;p
<moldy> dorins: bzr help merge and bzr help revisionspec
<davidstrauss> dash: but uncommit will remove the latest revision
<davidstrauss> dash: and dorins wants the last two revisions
<dorins> moldy: I was trying to do this with bzr pull. If I use merge, wouldn't I loose the history from 'feature'? I mean the revisions from 'feature' would be combined into a single revision in 'upstrem'.
<davidstrauss> dorins: You should cherrypick merge "-r -2..-1"
<dash> davidstrauss: only from the current branch
<dash> that's why i said make a new one first :)
<dorins> dash: the revision I'm trying to skip is not the last revision
<davidstrauss> dorins: merge will not lose history
<moldy> dorins: i don't think you lose history, but don't take my word for it -- if in doubt, just try it
<dash> dorins: ah.
<dorins> davidstrauss: ok, I'll try merge.
<dorins> Thanks guys.
<davidstrauss> dorins: merge will give you a merge revision on upstream that has two subrevisions representing the content of the merge
<dorins> davidstrauss: interesting. what happens with the subrevissions if I then push 'upstream' to a svn repository?
<davidstrauss> dorins: I'm not sure about that, but bzr generally has pretty non-lossy integration with svn
<ddaa> dorins: they remain in your local repository
<ddaa> if you independently branch from svn, they become "ghost revisions"
<ddaa> that is, revisions that are referenced from revision in the repository, but that are not themselves in the repository
<ddaa> you can then use "bzr fetch-ghosts" to fill them in if you have subsequent access to a repository that contains them
<ddaa> (hopefully jelmer will not correct me, these are mostly informed guesses)
<dorins> ddaa: not sure I really get what "ghost revisions" are. Do you mean svn doesn't treat them as individual revisions?
<ddaa> I mean, if they are bzr commits, then they are not in the svn repository
<ddaa> Generally, svn does not know much about merges.
<ddaa> bzr-svn can record the revision id of the latest merged revision
<ddaa> in the svn metadata of the merge commit
<dorins> ddaa: ok
<dorins> Is there other way to cherypick revisions besides merge?
<ddaa> bzr does not track cherrypicks for you, only full merges
<ddaa> so cherrypick with merge is essentially the same as cherrypick with diff+patch
<ddaa> in other words, once you are doing cherrypicking, you can use whatever tool you like (partial merge, shelve, kdiff3), it makes no difference
<ddaa> But, if at all possible, you should strive to do full merges only. That will make you life, much, much easier.
 * ddaa -> bed
<dorins> I understand. My problem is that after cherypicking revisions with merge, and then pushing to svn, svn doesn't know about the individual revisions that I cherypicked
<dorins> so people using regular svn clients don't see the individual revisions that I pushed to svn, instead they see a single merge revision.
<lifeless> moin
#bzr 2009-06-03
<bob2> do any dvcses aside from darcs have superfly cherrypicking?
<fullermd> I think arch did OK.
<fullermd> Probably not as good as darcs though, since it's fundamentally first-class in darcs.
<ronny> fullermd: last time i checked arch was rather broken
<ronny> and i dont think it got any better
<beuno> mwhudson_, any ideas why tests now always fail for me in LH (on all branches, so it's not the broken tests)?
<beuno> http://paste.ubuntu.com/187005/
<beuno> jelmer, hi
<jelmer> beuno, hello
<beuno> jelmer, quick question
<fullermd> Well, AFAIK it's not moving anywhere.  But it still sorta cherrypicked OK   :p
<beuno> jelmer, when was bzrlib.foreign introduced in bzr?
<lifeless> 1.13/1.14
<beuno> jelmer, just to figure out if I have to bump the min bzrlib version
<beuno> ok, I do then
<beuno> thanks lifeless
<jelmer> beuno, good question, I think it was 1.11
<jelmer> lifeless, that late?
<igc> morning
<beuno> hi igc
<igc> hi beuno
<beuno> jelmer, I'm not sure what to expose on the UI for this
<beuno> as in
<beuno> I have no idea what this is: (('203ae883-c723-44c9-aabd-cb56e4f81c9a', 'trunk', 230), BzrSvnMappingv3(TrunkBranchingScheme(0)))
<jelmer> beuno, So in that particular case the interesting bit would be "trunk" and 230
<beuno> jelmer, so it's not key value pairings, just values with no explanation to them?
<jelmer> beuno: You can call use the second part of the tuple to get a key/value representation
<jelmer> What is returned is a tuple with foreign_revid and mapping
<jelmer> foreign_revid is specific to the foreign vcs
<beuno> jelmer, could we refactor this so it gives us the key:value entries directly?
<beuno> that way it's very clear what should be exposed  :)
<jelmer> beuno, mapping.vcs.show_foreign_revid(foreign_revid) will return a dictionary with key/value pairs (all strings)
<jelmer> that's what's used for "bzr log"
<jelmer> you might also be interested in mapping.vcs though, e.g. for displaying a git/svn/hg/etc icon
<jml> hey, bzr people.
<beuno_> grr
<jelmer> moin jml
<jelmer> wb beuno
<jelmer> beuno, did you see those last few lines?
<beuno_> jelmer, saw: 20:30 < jelmer> you might also be interested in mapping.vcs though, e.g. for displaying a git/svn/hg/etc icon
<beuno_> las
<beuno_> last
<jelmer> beuno_, yeah, that's right
<beuno_> jelmer, it's starting to get more complex than exposing it on the UI
<jelmer> beuno: Perhaps we should focus on just the foreign rev info first, and other fancy stuff like icons later
<beuno> jelmer, sounds good
<beuno> can you update the branch to ad that
<lifeless> jelmer: I was sure it was in by then, and a later than actual answer is still useful :)
<lifeless> jelmer: $ rmadison subunit
<lifeless>    subunit | 0.0.2~bzr66-1 | karmic/universe | source, all
<jelmer> lifeless, \o/
<jelmer> beuno, will do
<FurnaceBoy2> abentley, thanks for your suggestion earlier, but I am still stuck: http://pastebin.ca/1445563
<FurnaceBoy2> abentley, thanks for your suggestion earlier, but I am still stuck: http://pastebin.ca/1445563  ; I have committed my changes before this
<lifeless> FurnaceBoy2: if you want your local branch to overwrite the solaris10-port, add --overwrite to your push command, just once.
<FurnaceBoy2> hm, ok. i think i have succeeded by doing that in the past, I wonder why it didn't occur to me this time.
 * FurnaceBoy2 goes to try
<FurnaceBoy2> ok that certainly pushed.
<FurnaceBoy2> thanks
<jelmer> beuno, sorry, phone call. I'm working on the foreign revid stuff now
<jelmer> beuno, lp:~jelmer/loggerhead/foreign
<lifeless> igc: ping
<beuno> jelmer, thanks, dinner, but will look at it later
<lifeless> igc: I'd like to try and convince you to change the core iter_changes and put excludes into it too :)
<beuno> lifeless, your evil plan worked
<lifeless> beuno: which one was that?
<jelmer> lifeless: +1
<igc> lifeless: I've come to the same conclusion
<lifeless> \o/
<igc> lifeless: trying to do it as a decorator is too fragile w.r.t. locking
<igc> and consistency
<lifeless> igc: it will also tend to trigger full inventory scans from dirstate, I suspect
<igc> its just more work, but hey, that's ife
<jml> how much memory can I expect bzr 1.14 to use when cloning a 1.2 GB branch stacked on a 450MB branch?
<lifeless> jml: a few hundred MB probably
<jml> limited on-production experimentation suggests 4.5GB+
<lifeless> jml: bugger a file
<jml> lifeless: cool.
<beuno> lifellif"get slightly involved and then get sucked in/obbssessed"
<jml> lifeless: will do that, but would like to experiment locally first.
<lifeless> beuno: :) with loggerhead?
<lifeless> I think it was loggerhead I tried to do that with
<cody-somerville> jelmer, ping
<jelmer> cody-somerville, hi
<cody-somerville> jelmer, using the latest bzr-git, 0.3.2, locally I get a different error
<cody-somerville> http://pastebin.ubuntu.com/187048/
<jelmer> cody-somerville, what git repository was this again?
<cody-somerville> git://git.debian.net/git/debian-live/live-helper.git
<jelmer> cody-somerville: Hmm, that looks different indeed. Any chance you can file a bug report?
<cody-somerville> jelmer, sure. bzr-git on launchpad?
<jelmer> cody-somerville, yep
<jam> igc: ping
<igc> hi jam
<cody-somerville> jelmer, filed as lp #382993
<ubottu> Launchpad bug 382993 in bzr-git "AttributeError: children when performing git-import" [Undecided,New] https://launchpad.net/bugs/382993
<jam> igc: I was hoping you would get a chance to run some Usertest stuff on Jelmer's most recent bencode serializer code
<jam> We really need to come up with a disk format for 2.0 rather soonish
<igc> jam: that's on my list for today
<lifeless> I'm still on check FWIW
<lifeless> spiv: are you copacetic on network deltas?
<igc> jam: the main thing I need is a patch/branch with all the proposed bits including a placeholder format, e.g. development8-rr
<igc> jam: jelmer did exactly that fro me to benchmark the rio stuff
<igc> jam: to test on OOo, I also need 36 hours to generate a repo in the proposed new format
<jam> igc: I'm pretty sure he had a --dev7-rr format
<jam> also, I would expect converting from --dev6 => --dev7 would be much faster
<jam> and it could be mysql, it wouldn't have to be OOo
<igc> jam: great. I'll take a look at his latest patches
<igc> yes, mysql would be faster. I don't have it converted to development6 yet though.
<igc> jam: can you upload a converted repo for me?
<lifeless> jelmer: I don't see the index problem
<lifeless> jelmer: care to fix?
<jelmer> lifeless, I tried, but couldn't easily find out where the unicode objects were being introducecd
<lifeless> what was their value?
<kizzo> Is there a way to specify the ssh port to use when pushing something to your private branch?
<lifeless> bzr+ssh://host:port/...
<jelmer> lifeless, checking
<kizzo> So instead of "bzr push lp:~kizzobot/blah/blah", the location would be "bzr+ssh://launchpad.net:22/..."?
<kizzo> I'll try it out now.
<lifeless> kizzo: uhm
<lifeless> kizzo: the default port for lp/bzr+ssh is 22, so it should Just Work
<lifeless> kizzo: what are you seeing happen?
<lifeless> (and it would be bzr+ssh://bazaar.launchpad.net:22/~kizzobot/blah/blah)
<kizzo> My /etc/ssh/ssh_client specifies a default port of NOT 2222.
<lifeless> interesting
<lifeless> ok
<kizzo> Oh wait .. s/NOT//
<lifeless> so the above should work
<kizzo> Yeah.
<lifeless> and please file a bug that lp: isn't forcing the port
<jelmer> cody-somerville, looks like a symlink target that's been changed to include an extra /
<kizzo> Yeah I would think so too.
<kizzo> I think it is actually..
<kizzo> kizzo@crashtest:~/work/new-bindings$ bzr push bzr+ssh://code.launchpad.net:22/~kizzobot/+junk/python-bindings
<lifeless> in fact, bzr+ssh should possibly force the port
<kizzo> ssh: connect to host bazaar.launchpad.net port 2222: Connection timed out
<kizzo> hmm
<lifeless> not code.launchpad.net - bazaar.launchpad.net
<jelmer> lifeless, a bit related, it also looks like "bzr index" doesn't like ghosts
<lifeless> redirectors in the middle will give you grief
<lifeless> kizzo: another thing you could do, in ~/.ssh/config
<lifeless> Host bazaar.launchpad.net
<lifeless>   port 22
<SamB> lifeless: why should it force the port ?
<cody-somerville> jelmer, does that mean an easy fix?
<jelmer> lifeless, node is (<bzrlib.btree_index.BTreeBuilder object at 0xa8c528c>, ('1545',), u'p  mapping.py')
<lifeless> SamB: because there is a well known port
<jelmer> cody-somerville, not sure yet
<kizzo> lifeless: Oh ok that works - thanks.
<kizzo> And specifying the port in the URL successfully works.
<SamB> lifeless: wouldn't that be a major abuse of the URL syntax ?
<lifeless> SamB: no
<SamB> it's not necessarily the case that ALL ssh servers run on that port ...
<lifeless> SamB: naturally
<SamB> there may be situations where a SINGLE machine has MORE THAN ONE
<lifeless> SamB: I think you have misinterpreted what I said
<SamB> lifeless: what did you mean ?
<lifeless> SamB: If a user tells bzr 'bzr+ssh://host/' bzr should be attempting to connect to port 22
<SamB> oh, sure!
<SamB> that's not forcing, that's defaulting!
<lifeless> SamB: so it should be forcing the port when it invokes ssh
<SamB> oh
<SamB> you mean it should pass the default port on to SSH
<lifeless> no, I mean it should tell ssh the port to use, always.
<SamB> instead of just assuming that SSH has the default default?
<lifeless> right
<kizzo> SamB: I think lifeless is saying that it would be bad if the bzr tool itself was always forcing the port to be 22, and not letting the user specify another port.
<lifeless> jelmer: is that a path in your tree?
<SamB> kizzo: I'm pretty sure that's what I was trying to say to lifeless ...
<jelmer> lifeless, mapping.py is, not the "p  " bit
<kizzo> Oh nvm haha.
<lifeless> jelmer: p is path
<lifeless> jelmer: its the entry type
<jelmer> lifeless, ah, right
<lifeless> so
<lifeless> search should be ghost friendly, as long as the ghosts aren't required to calculate deltas - which they must not be
<spiv> lifeless: copacetic on network deltas?  I only just woke up, so I'm hardly copacetic on anything right atm ;)
<lifeless> jelmer: what are you indexing?
<jelmer> lifeless: anything
<lifeless> jelmer: line 978 of index.py
<lifeless> can you insert
<jelmer> lifeless, it's looking very similar to the reconcile text ghost handling bug
<lifeless> === modified file 'index.py'
<lifeless> --- index.py    2009-01-21 07:59:57 +0000
<lifeless> +++ index.py    2009-06-03 01:29:17 +0000
<lifeless> @@ -975,6 +975,9 @@
<lifeless>          if document_key in self._document_ids:
<lifeless>              return self._document_ids[document_key]
<lifeless>          next_id = str(self.document_index.key_count())
<lifeless> +        value = "%s %s %s" % document_key
<lifeless> +        if type(value) is unicode:
<lifeless> +            import pdb;pdb.set_trace()
<jelmer> lifeless, (Pdb) print document_key
<jelmer> ('p', '', u'mapping.py')
<kizzo> When you do something like "bzr branch lp:whatever", what is the expanded version of "lp"?
<moldy> hi
<moldy> dumb question: how do i restore a deleted file?
<jelmer> lifeless, unrelated question, could it be that bzr is fixing the formatting of InventoryEntry.symlink_target
<lifeless> jelmer: peng filed this as a dev6 specific bug
<jelmer> lifeless, the bzr-search thing you mean?
<lifeless> jelmer: can you give me the backtrace for that?
<lifeless> kizzo: its the result of an xmlrpc call
<moldy> i have committed the deletion and done other changes since then
<lifeless> moldy: bzr revert -r <rev that had the file> FILENAME
<jelmer> lifeless, http://pastebin.ubuntu.com/187068/
<moldy> lifeless: thanks! is there any better way to find <rev> than to read through the logs?
<lifeless> moldy: bzr log -v | less , /FILENAME  :)
<lifeless> moldy: (for now)
<moldy> lifeless: ok, i see. thank you!
<lifeless> jelmer: pull trunk
<jelmer> lifeless, I can confirm that works, thanks!
<jam> igc: lp:///~jameinel/bzr/bencode_serializer
<jam> That should be the latest version of the serializer, with all the bits sewn together
<jam> well, once it finishes uploading :)
<jam> I think the machine with my mysql conversion is offline right now, I'll see what I can do
<kizzo> Hmm why is "bzr branch lp:~kizzobot/+junk/python-bindings" talking SSH?  (I have a packet sniffer running and seeing the traffic).
<kizzo> I'm under the impression that I'm branching FROM launchpad - why would SSH be involved?
<Peng_> kizzo: Why shouldn't it?
<Peng_> kizzo: If you've run "bzr launchpad-login", lp: expands to bzr+ssh://bazaar.launchpad.net/
<kizzo> Peng_: It's a public branch.  Like, anyone should be able to get it.
<kizzo> hmm
<lifeless> jelmer: cool
<Peng_> kizzo: Anyone can get it. If they haven't logged in, it'll use http.
<Peng_> Who what works?
<igc> jam: thanks
<jam> igc: just make sure you run 'make' :)
<igc> jam: and thanks for the reivews as well
<igc> jam :-) will do
<igc> the numbers tend to stand out if do forget :-)
<igc> s/if/if I/
<xnevermore> I'm trying to use bzr-svn to create a subversion repo on a remote server and push my bzr branch to it. I tried using "bzr svn-push svn+ssh://server.com/home/username/svnrepos/project", but got "bzr: ERROR: No repository present"
<jelmer> xnevermore, a repository ahs to alreday exist
<jelmer> and I need to fix my spelling
<xnevermore> jelmer: do you know what the svn command for that is?
<jelmer> xnevermore, on the remote server: svnadmin create /path
<lifeless> jelmer: bzr init --svn svn+ssh://server.com/home/username/svnrepos/project would be cute :)
<lifeless> jelmer: and the api definitely supports it:)
<jelmer> lifeless, the remote one doesn't unfortunately
<SamB> lifeless: well enough ?
<lifeless> SamB: EPARSE
<jelmer> lifeless, locally "bzr init-repo --subversion" already works
<SamB> the API may believe it supports a thing, but it might not actually be possible to make it work in a real situation ...
<lifeless> SamB: I don't see why it wouldn't
<lifeless> SamB: or I wouldn't have said that the api supports it ;)
<SamB> lifeless: that's usually on account of not having tried and failed ;-)
<lifeless> SamB: are you arguing hypothetically, or from experience with this particular api ?
<xnevermore> jelmer: ok, i issued that command, then issued the svn-push command, but got "bzr: ERROR: These branches have diverged. Use the merge command to reconcile them."
<lifeless> jelmer: how does it fall down for you?
<SamB> lifeless: hypothetically, I guess
<SamB> I haven't tried and failed either
<jelmer> xnevermore, you need to push to somewhere inside of the repository, e.g. URL/trunk
<lifeless> SamB: 'nuff said
<SamB> but the way jelmer keeps doing it I wouldn't have been surprised either way
<jelmer> lifeless, the API for creating a repository requires you to specify a local path
<lifeless> jelmer: whose api
<jelmer> lifeless, The SVN one
<SamB> oooh
<lifeless> jelmer: I was meaning 'ssh host svnadmin ...'
<jelmer> lifeless, The only API that works with svn+ssh://, svn:// and http:// doesn't allow creating repositories
<SamB> for once it's not bzrlib's fault
<jelmer> lifeless, ahh
<lifeless> jelmer: which you have enough data to do
<jelmer> lifeless, Yeah, I guess we could do that
<SamB> jelmer: certainly it could try
<SamB> what does svn+ssh need from a remote anyway ?
<xnevermore> jelmer: cool, thanks. that worked fine
<lifeless> SamB: it uses libsvn locally with a remote url
<lifeless> SamB: as opposed to the bzr rpc server
<SamB> lifeless: I meant, what does libsvn need from the remote ...
<jelmer> SamB, it needs svnserve present on the remote server
<lifeless> just like bzr really, except our serve is a subcommand
<jelmer> svnserve should be an alias for "bzr serve --svn"
<lifeless> that would be cool in a strange sort of way
<thumper> jelmer: http://launchpadlibrarian.net/27418534/ubuntu-tweak-master-log.txt
<thumper> jelmer: still awake?
<Peng_> So, um, how do bzr serve --git and --svn work? Do they serve native git/svn branches over the git/svn protocols? Bzr branches?
<Peng_> How do you check if a transport is read-only?
<spiv> Peng_: there's .is_readonly() on the transport object
<Peng_> spiv: Oh, that's simple and obvious. Thanks.
<spiv> Peng_: of course, a transport may think its read-write and then get PermissionDenied from all write ops ;)
<lifeless> .readonly is a misfeature
<lifeless> I advise against using it
<lifeless> it really just reflects that a particular transport will deny *all* write operations, not that *any given* operation will succeed
<spiv> Peng_: so the reliable way is to actually try writing and be prepared to catch errors :)
<Peng_> I'm interested in making sure the transport is read-only, not making sure it's not. :)
<lifeless> Peng_: context?
<Peng_> lifeless: Loggerhead, both in general, and specifically for serving .bzr/smart.
<lifeless> Peng_: I'm not sure why you would care there?
<lifeless> is there any reason loggerhead shouldn't be able to write when its serving, just as bzr:// can  ?
<Peng_> That's a good point. Still, it doesn't allow configuring that (yet), and it should default to read-only.
<lifeless> sure
<lifeless> I'd make sure bzr serve's facility for configuring this is reused directly
<Peng_> Thanks to how "bzr serve" works, it already is.
<Peng_> "bzr serve" passes a transport to Loggerhead; if --allow-writes was not passed, it's read-only.
<Peng_> But start-loggerhead and serve-branches are still around, and the latter takes arbitrary URLs.
<lifeless> jam: ping
<Peng_> Making Loggerhead writable is spooky and totally cool.
 * igc lunch
<lifeless> Peng_: for sex, have clients at the trunkof the branch get updates pushed via ajax when someone commits via loggerhead
<Peng_> It's totally cool that pushing from a bzr client -> bzr+http server -> bzr server works, right?
<lifeless> Peng_: yes
<Peng_> :)
<kizzo> lifeless: Thanks.
<Peng_> Do you think it's worth running a bzr+http server?
<Peng_> Especially since that entails running an old version of bzr that actually works?
<jml> lifeless: so, regarding the memory thing I mentioned earlier
<Peng_> I'm not sure what percentage of that was a serious question and what was whining.
<jml> lifeless: http://paste.ubuntu.com/187123/ has a traceback I got from doing C-\ while the memory was climbing
<jml> lifeless: can you please help me file a good bug for this, now that I can reproduce the error locally?
<lifeless> sure
<lifeless> let me look
<spiv> Peng_: yeah, sorry about that, that bug is on my todo list...
<lifeless> so that particular point is in index processing
<lifeless> and you don't have the C extensions built
<lifeless> first thing, see if they make a difference.
<lifeless> jml: secondly, grab jam's memory profiler tool
<lifeless> and use it when you break in
<jml> I wonder why they aren't built. I'm running from the nightly ppa
<lifeless> jml: I may be wrong
<lifeless> import bzrlib._btree_serializer_c
<jml> it's not there.
<jml> 1.15+4368+109 should be recent enough, right?
<lifeless> bug in the ppa builds
<lifeless> I'll file it
<jml> thanks.
<Peng_> spiv: <3
<jml> hah, I don't even have pyrex installed.
<Peng_> Actually, I wasn't just whining. Branching bzr.dev's entire history over bzr+http would probably make my server catch fire.
<pygi> Peng_: with what format ?:)
<Peng_> pygi: 1.9.
<pygi> Peng_: try with brisbane? :)
<Peng_> pygi: Not possible. If I upgrade my bzr+http server to a version that supports bbc, it'll also suffer from bug 348308.
<ubottu> Launchpad bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged] https://launchpad.net/bugs/348308
<Peng_> Obviously I could set up two servers, but that'd be a pain.
<Peng_> And anyway, trying it means risking an OOM.
<jml> hmm. rate of climbing seems slower, but it's still over 1g.
<lifeless> time for the memory profiler
<jml> hurh, it's not using the c module
 * jml bangs the box a couple of times.
<jml> hmmmmm.
<jml> now that I'm using C extensions, seems to be capped at ~721MB
<lifeless> thats still high
<lifeless> if you could build and use jams profiler that would be good
<jml> lifeless: sure thing. where does it live?
<lifeless> lol http://mac.wareseeker.com/free-john-arbash-meinel/
<lifeless> (spam search hit in google)
<lifeless> https://lists.ubuntu.com/archives/bazaar/2009q2/056433.html
<lifeless> ^ jml:
<jml> ta
<jml> lifeless: interested at all in the pure python data?
<lifeless> jml: not really.
<lifeless> choosing battles etc
<vila> hi all
<spiv> Gar, why does PQM not want to send me failure mail...
<lifeless> No handlers could be found for logger "bzr"
<lifeless> Permission denied (publickey).
<lifeless> bzrlib.errors.ConnectionReset: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<spiv> Ah, right.  Ok.
<spiv> I guess the PQM user isn't properly set up to cope with lp: URLs :/
<lifeless> spiv: rt it?
<ronny> jelmer: im kinda missing how i should store objects i created in a dulwich repo, any hints on what im missing?
<ronny> ah, found my issue
<ronny> searched the wrong file for that
<jml> lifeless: did you go to jkakar's commandant talk?
<balor> How do I throw out all the changes in my current working directory?  i.e. rebase on current HEAD.
<Peng_> balor: ..."bzr revert"?
<balor> Peng_: thanks
<Peng_> Oh, good.
<johnf> I've written an init script for bzr server. Should I submit a patch to bzr or should I just put it in the debian package?
<vadi2> I
<vadi2> *I'm trying to setup bzr over svn with bzr-svn, and thought the process was to make a new folder and use bzr-svn import --trees into the new location. But I accidentally did "bzr init" not in the new folder, but in the current svn one.
<vadi2> the svn repository is huge and it's doing "something" - is that something wrong and should I cancel?
<jelmer> vadi2, hi
<jelmer> vadi2, init in the svn one?
<jelmer> vadi2, doesn't sound like what you'd want
<vadi2> yeah, after a long while it gave "bzr: ERROR: Already a branch: "."."
<vadi2> But I'm having a problem getting it to import into my proper folder now though
<vadi2> http://paste.pocoo.org/show/120769/
<jelmer> vadi2, You're importing from a svn repo into a svn repo?
<vadi2> why's that
<vadi2> I did "bzr init" in yorba3 folder
<jelmer> vadi2: That creates a branch, not a repository
<jelmer> vadi2: A svn repository contains multiple branches
<jelmer> you don't need to run "bzr init" before svn-import
<vadi2> What would be the proper way?
<jelmer> vadi2, don't running anything at all
<jelmer> just "bzr svn-import yorba yorba3"
<jelmer> or "bzr svn-import --trees yorba yorba3" if you want working trees
<vadi2> Sorry. What folder to run that in?
<vadi2> http://paste.pocoo.org/show/120770/
<jelmer> vadi2, I think you may have a incomplete .bzr directory in Programs/ ?
<jelmer> It should be run in Programs, ideally yorba3 should not exist yet
<vadi2> no, don't have a .bzr in Program
<vadi2> *s
<vadi2> going to try deleting yorba3
<vadi2> "No repository present: "file:///home/vadi/Programs/"" :/
<vadi2> I'm using the stock jaunty version of bzr-svn though, not the ppa one because bzr-gtk breaks
<jelmer> maybe try in a different directory
<jelmer> e.g. bzr svn-import /path/to/yorba /tmp/yorba3
<vadi2> $ bzr svn-import --trees /home/vadi/Programs/yorba /tmp/yorba3
<vadi2> bzr: ERROR: No repository present: "file:///home/vadi/Programs/"
<vadi2> there is no repository in 'Programs', that is correct. Not sure why it's not looking at the "yorba" folder
<jelmer> vadi2, Does yorba actually contain a subversion repository?
<jelmer> vadi2, is there no .bzr directory in yorba?
<vadi2> there is a repository (svn log works) and there is no .bzr
<vadi2> maybe I have a broken bzr-svn? getting the proper version installed without upgrading bzr was tricky.
<jelmer> vadi2, don't know
<awilkins> vadi2: Perhaps try bzr svn-import svn+file://home/vadi/Programs/yorba yorba3  ?
<vadi2> http://paste.pocoo.org/show/120773/
<jelmer> vadi2, that suggests there really isn't a svn repo in yorba
<vadi2> But I have .svn in it and "svn log", "svn status" work okay
<jelmer> vadi2: That suggests there's a subversion working tree there, not a repository
<jelmer> vadi2: I think you want either 'bzr branch yorba yorba3' or 'bzr svn-import url-to-svn-repos yorba3'
<vadi2> I'll try the first. It's very big to download again
<vadi2> Thanks for your help, I'll try it in a bit.
<jelmer> vadi2, it won't retain much of the data that 'svn co' downloaded
<vadi2> o
<vadi2> alright.
<jelmer> vadi2, bzr downloads all of the history of what you're branching, svn only keeps the last revision
<vadi2> right
<beuno> jelmer, hi!  just took another stab at your foreign branch
<beuno> but it tracebacks
<beuno> added the tb to the merge proposal
<beuno> james_w, hi
<jam> spiv, lifeless: I missed this last night, but PQM fails with both lp: urls and bzr+ssh://bazaar.canonical.com/ ones
<jam> I think they changed the firewall rules
<jam> But #is never really came up with an answer
<jelmer> beuno, that's odd, I can't see how we could get there without setting foreign_revid somehow
<jam> i just switched to http://bazaar.launchpad.net
<vila> jam: using http:// urls is the answer
<vila> jam: and hi :)
<beuno> jelmer, yeah, I tried to fiddle with the code, but didn't figure it out either
<jam> hey vila
<jam> It is *an* answer
<jam> I don't think it should be *the* answer
<jam> Perhaps the LOSAs feel differently
<vila> jam: I agree with you, but it's the only answer that works :)
<jam> I wonder if they didn't change PQM so that it actually thinks it has a launchpad user account
<jam> and now it is trying to log in
<vila> do you mean you used to be able to use lp: URLS ?
<jam> whereas before lp:/// urls were resolving to http
<jam> vila: I configured it and had it working for at least 2-3 months
<vila> jam: that's so unfair ! So I was really the only one hanging pqm while using them :-)
<jam> vila: I think you hung pqm, then they "fixed" it, so I could use it
<jam> then they broke it again :)
<vila> jam: I thought "they" fixed it twice, so I'm more cautious now about that :)
<moldy> hi
<moldy> why does bzr st only show directories with status unknown, but not the files inside those directories?
<stani> how can I retrieve the revision number from python from a bazaar repository
<stani> ?
<beuno> stani, you have the revision id?
<beuno> stani, take a look at: http://bazaar-vcs.org/Integrating_with_Bazaar
<jelmer> beuno, argh, I'm so stupid
<stani> I have a path and I want to get the revision number so I can construct a temporary version number for my package: package-0.2.bzr192
<jelmer> beuno, fix pushed
<beuno> jelmer, thanks
<stani> bueno: thanks, I'll try that
<beuno> stani, so you need the tip?
<beuno> it should be explained there
<stani> bueno: hmmm doesn't seem to work
<stani> bueno: http://www.pasteall.org/5894/python
<stani> bueno: I thought afterwards I could do b.revno()
<beuno> stani, you need to open the branch
<beuno> Branch.open('....
<jam> moldy: we don't recurse into unknown directories because often that would be foolish
* You're now known as ubuntulog
<jam> consider a "build" directory with hundreds of unwanted files
<stani> bueno: thanks, stupid mistake of me
<moldy> jam: i would like to see that there are hundreds of unwanted files
<moldy> jam: without having to run ls on every directory with status unknown :) there is no option to request recursion?
<jam> moldy: it was an explicit design decision, if you can present a use case for changing it, then please describe it to su
<jam> moldy: bzr ls --recurse
<jam> sorry "bzr ls --recursive"
<moldy> "bzr st --recursive" would save me that additional command
<moldy> i might want to add the directory, but not its contents
<stani> beuno: what is the python equivalent to 'bzr export', it doesn't seem to be mentioned on that page
<jam> stani: you can generally look in bzrlib/builtins.py to see what a command does, and how to translate that into direct python calls
<timour> Guys, I need help with BZR 1.15.
<timour> I have Kubuntu 9.04, fresh install.
<timour> When I run any BZR command I get:
<timour> "No handlers could be found for logger "bzr"
<jelmer> timour, is your ~/.bzr.log writable?
<timour> jelmer, checking ...
<timour> jelmer, weird, no, it is:
<timour> -rw-r--r-- 1 root root 18K 2009-06-03 17:22 .bzr.log
<timour> jelmer, should I chown it and make it writeable?
<jelmer> timour, yeah
<visik7> does bzr serve implement a wsgi interface ?
<timour> jelmer, great, it worked, thanks a lot!
<jelmer> visik7: bzr serve --http uses wsgi internally
<visik7> but can I attach bzr serve to mod_wsgi ?
<jelmer> visik7: You can attach loggerhead to mod_wsgi I *think*
<visik7> if setup loggerhead do the server automatically checkout latest revision ?
<visik7> or also without loggerhead
<visik7> I mean does a non-dumb server provide autocheckout ?
<jelmer> visik7, not sure I'm following
<visik7> I'm referring to http://doc.bazaar-vcs.org/bzr.0.18/server.htm
<visik7> if I push using a dumb server the branch is not checked out
<visik7> I was asking if with a non dumb server the checkout is performed
<jelmer> visik7, ah
<jelmer> visik7, no, that's not the case yet
<visik7> :(
<visik7> I need a way to auto checkout on push
<visik7> and the push-and-update plugin is not a viable solution
<jelmer> there's a plugin that can do that over ssh
<jelmer> ah
<jelmer> visik7, I don't think there's anything that can do that atm
<jelmer> visik7, Somebody needs to add that feature to the smart server
<visik7> smart server ?
<jelmer> visik7, yeah, what bzr+ssh:// and bzr+http:// use under the covers
<visik7> oh the non dumb
<visik7> :)
<visik7> ok and bzr serve is hookable ? with a custom plugin to get this thing ?
<jelmer> I don't know
<visik7> ok thanks anyway
<jelmer> lifeless, ping
<awilkins> I've been trying to get lifeless for days, is he alive?
<awilkins> (hmm, that was a humourless pun on his name...)
<beuno> awilkins, he was around yesterday, yes
<andrew> What do I need to have in order to be able to tab-complete bzr commands? (Ubuntu 9.04)
<awilkins> andrew: Seems to just work here, I'd never thought about it
<beuno> andrew, it works by default
<andrew> For example, if I type in: bzr st[tab], it starts giving me file names
<beuno> andrew, that's odd. It shouldn't happen
<andrew> But since it does happen, what can I do to fix it?
<awilkins> Remove and reinstall the bzr package?
 * awilkins is embarassed to propose this windows-onian method
<andrew> awilkins: tried that, no luck
<andrew> awilkins: ha, don't be embarassed, I tried that already as it was suggested by somebody else
<visik7> how can I run the following command from a python script: bzr update
<visik7> =
<visik7> ?
<LarstiQ> andrew: is completion enabled in the shell you're using?
<LarstiQ> andrew: bash on Debian for instance, has it disabled by default
 * LarstiQ heads to the dojo
<andrew> got it fixed thanks to evand. Apprently I didn't have a ~/.bashrc ...
 * andrew blames likewise-open for that messup
<ddaa> Here's an idea for promoting bzr.
<ddaa> It's the dvcs for test-driven development and continuous integration.
<ddaa> Write test, write implementation, commit, merge parent, repeat.
<dash> ddaa: I would like to believe that
<dash> Hmm.
<dash> how's that different from the competition
<ddaa> Other dvcs, with their anemic log functionality discourage frequent commits on feature branches and frequent merges.
<dash> well, that matches my experience
<ddaa> Because that creates a lot of very small commits that end up making the mainline log unusable.
<dash> i specifically picked bzr over hg because of the ability to get a clean trunk log
<bob2> eh
<dash> like i was used to in svn
<bob2> bzr and git now have the same log output
<SamB> bob2: eh?
<ddaa> bob2: meh?
<dash> bob2: interesting.
<ddaa> bob2: you mean hg changed its log output to highlight the mainline?
<SamB> maybe if you use --first-parent or whatever ...
<bob2> no idea what hg does
<ddaa> Ah, I mean git.
<ddaa> You mean git log now only shows the mainline?
<ddaa> and has an option to show a hierarchical log?
<bob2> --graph, iirc
<ddaa> I dunno git, but I know that with hg's "fast forward pull on no divergence", you cannot get a clean mainline even if you want to.
<ddaa> I know jelmer reported that samba folks asked him to stop frequently merging trunk into his branch because it polluted the log.
<stani> What is the equivalent of 'bzr export DEST' in python? Is this done with a WorkingTree or a Branch?
<dash> ddaa: right, that's the key missing feature in hg as far as I can tell
<dash> I did have an hg user tell me it was possible once
<dash> but it's not the normal mode of operation
<ddaa> I'm pretty sure that's not going to change now.
<dash> sure.
<luks> can't you just always fetch+merge?
<ddaa> Their community is too used to the way it works now to change at this point.
<dash> luks: not if there's no divergence.
<luks> hm, interesting
<SamB> huh, git at least has an option for it!
<jelmer> SamB, defaults matter unfortunately
<SamB> jelmer: yes, they do
<dash> especially unfortunate defaults
<SamB> but at least with git you CAN do it if you get asked to
<luks> well, I think git people see the history differently than bzr people
<ddaa> Anyway, I think that can be a useful sales script.
<luks> in git it's a set of patches, basically
<SamB> you know ?
<ddaa> luks: and they are sooo wrong.
<luks> but they seem to like it
<ddaa> but I have yet figured the right arguments to explain it clearly.
<luks> flat log / rebase / etc.
<SamB> luks: er, well, it's not a set of patches
<SamB> but sometimes they use it to store a pile of patches
<luks> SamB: not technically, but they treat it that way
<SamB> which it isn't at all good for
<SamB> really
<ddaa> luks: I believe git folks like it because either 1. they have hugre trees and require git performance or 2. they do not know any better.
<SamB> I honestly wish there was some kind of git/darcs hybrid where you could keep that "set of patches" in a darcs-managed area on top of a git-managed history ...
<Isaiah> ddaa: Or they use github ;)
<luks> I can see that maintaining a mainline in the kernel wouldn't be easy
<luks> but I think it would work better for most other projects
<ddaa> SamB: the mental model of a tool's community is important. It dictactes a lot of the detail choices that form the day to day experience with the tool.
<ddaa> luks: I believe the kernel has a strong culture of "lines of development", it's just that there are basically two kinds of people: those have the conceptualization skills required to see past git's quirks, and those that don't care.
<ddaa> Less polarized projects may have more people in the middle area, where they build a workflow and mental model informed by the quirks of git's ui.
<ddaa> I'm also a bit irked by how hg's documentation confused "changeset" and "revision".
<SamB> anyway, it isn't always bad if things that were in feature branches end up in the mainline ...
<ddaa> SamB: explain what you mean.
<SamB> well, it depends on how noisy they were, mostly ...
<ddaa> That's my point.
<ddaa> The DVCS for TDD must support extremely chatty branches.
<SamB> oh.
 * SamB wishes the kernel used more TDD
<SamB> well, in the sense that tests would be nice
<SamB> not in the sense that I think anyone should stop trying to think about the correctness of their code ...
<ddaa> SamB: it's not clear it's at all possible for kernel development. Most of the problems are with hardware quirks.
<SamB> ddaa: hmm.
<luks> I imagine testing hardward interaction must be fun
<SamB> well, it'd still be nice if there were more tests for the things that can be tested, you know?
<SamB> the kernel isn't ALL drivers
<SamB> and some of the drivers aren't for devices, even
<luks> yeah, but that's usually the patch that is broken
<luks> and should be properly tested
<luks> er, s/patch/part
<SamB> it'd be handy to have a provided test harness even without the tests, actually ...
<ddaa> You need test, otherwise how do you know that your test harness works? :)
<mthaddon> abentley: so the verdict on nested trees is that it's not in the immediate future - do you know if it'll be in bzr 2.0 and what the timeline for that is?
<ddaa> For crissakes, can we very much please have it for bzr 2.0?
<abentley> mthaddon: I don't know whether it'll be in 2.0.
<SamB> ddaa: well, okay, I meant without many tests
<abentley> mthaddon: I'm not sure what timeline you mean.
<ddaa> It's a major differentiating feature, IMO it's worth delaying 2.0 until it's done and stabilized.
<mthaddon> abentley: I was meaning when 2.0 is expected to be released, but if you're saying it might not be in 2.0, then I guess it's a moot point
<mthaddon> but fwiw I'd agree with ddaa
<abentley> ddaa: It's currently in the design stage.
<abentley> mthaddon: There will be a 1.6 release.  2.0 could be the next release after that.
<mthaddon> ok, thx
<abentley> sorry, 1.16, not 1.6
<ddaa> abentley: That's good to know, but it does not contradict my position: it's a major differentiating feature, and it's worth delaying 2.0 for it, so it will have the exposure it deserves.
<ddaa> There's only one shot at 2.0, so you must make it count.
<abentley> ddaa: All other DVCSes have it, so it can only be a differentiating feature by being awesome.
<ddaa> if you are referring to hg forests
<ddaa> (or git equivalent)
<ddaa> it's about as advanced as config-manager
<SamB> abentley: what the heck do you mean that all other DVCs have it?
<ddaa> meaning that IMHO it sucks major balls
<SamB> and I don't think it's that great in any of them at the moment ...
<ddaa> the only thing that's close is svn externals, and AFAIK no dvcs is even close to this level of seamlessness.
<abentley> SamB: Mercurial has the forests extension, Git has submodules.  (I shouldn't have said they "all" have it.)
<SamB> and who uses them ?
<SamB> especially who uses submodules ?
<ddaa> But that's a good point.
<ddaa> "All other dvcs claim to have it, although they have only some half-assed implementation, so the promotion impact of having it in bzr is consideradly lessened".
<SamB> I remeber once someone actually had a problem while using them and asked a question about it in #git
<SamB> but I don't remember if the problem was actually related to them or not
<ddaa> SamB: I'd bet submodules suck, but we're talking perceptions here.
<ddaa> abentley: OTOH, that means that NOT having nested trees for 2.0 can be a perceived weak point for bzr.
<SamB> ddaa: perhaps only by someone who hasn't actually heard anything about how git's work ...
<ddaa> According to this line of though, 2.0 should implement some minimal support for nested trees.
<bialix> ddaa: do you aware of scmproj?
<ddaa> SamB: which is the case of essentially anyone who's choosing a new DVCS.
<ddaa> bialix: nope
<SamB> ddaa: eh?
<bialix> this is plugin emulated nested trees
<ddaa> SamB: most people who are switching their project to a DVCS have only the vaguest ideas of the specifics of each tool. That why they usually end up just picking the fastest, because that's a difference they can measure.
<bialix> I'd like to reuse some abentley work
<abentley> ddaa: And *that*'s what 2.0 will address.
<ddaa> bialix: is it usable in production
<ddaa> abentley: I know that's the *main* goal of 2.0.
<bialix> ddaa: nested trees is better
<ddaa> bialix: abentley just said that nested-trees are "in the design stage"
<bialix> yes
<bialix> and this makes nested trees better
<bialix> scmproj is poor emulation. it works but have some problems
<ddaa> abentley: but I also think that the 2.0 release should pack the maximum punch possible.
<ddaa> bialix: I hardly see how "something that's in the design stage" (implicitly, not something that's usable) can be better than something that works today.
<bialix> git submodules is also work today, altough you guys very hardly on it
<ddaa> Two different discussions.
<ddaa> One hand: what's the right way to do it.
<ddaa> Other hand: perception of potential adopters or switchers.
<ddaa> As past experience has shown, they have very little overlap.
<ddaa> Since the perception is that git and hg have a form of nested trees.
<ddaa> The question is whether scmproj can be used to convincingly argue that bzr has feature parity.
<bialix> I've designed scmproj based on forest/submodules and past nested trees spec.
<bialix> but it need more love
<bialix> I'd say it could be used to check different variants for implememting real nested trees
<bialix> but I'm not aware someebody is using it aside me and AmanicA
<bialix> so there is too little user feedback
<bialix> is it usable? more or less. Could ut be better -- definitely
<bialix> but all people waiting for real nested trees, so I'm doubt scmproj is vital alternative
<ddaa> So we're still stuck without a viable conterparts for forests/submodules.
<cdecarlo> I need to use a non-standard port to connect to my comuper over ssh, how do I use bzr+ssh:// to connect to a different port?
<ddaa> Which I think should not be the case in 2.0.
<cdecarlo> *computer
<bialix> ddaa: we also still don't have versioned properties
<ddaa> You mean file properties?
<bialix> today they called rulkes
<bialix> rules
<ddaa> I do not know what you are talking about.
<ddaa> And I like to think I know a thing or two about version control...
<bialix> abently: does lp:bzr/1.15 is valid submit branch for BB?
<bialix> ddaa: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#rules
<ddaa> bialix: so you say this should be supported by metadata (not unlike revision properties) that have versioned text (like source files).
<bialix> no, I don't say anything
<bialix> this is not file properties
<ddaa> I say, let's just stick that in a source file and be done with it.
<bialix> the problem is these rules currently is not propagated
<ddaa> It's not ideal, but there's a precedent with .bzrignore
<bialix> many devs think it's wrong approach
<ddaa> and the alternative are all pretty bad
<bialix> and I understand why
<ddaa> Well, I guess they have thought of an alternative I haven't thought of.
<bialix> but.. at the end of the day there is still nothing in bzr
<ddaa> Right. The bzr dev are sometimes too focused on doing the Right Thing, to the point of sometimes not doing anything.
<bialix> :-/
<ddaa> See what happened with tags.
<bialix> tags are bad
<ddaa> They are certainly inelegant.
<bialix> they definitely better than .hgtags
<ddaa> Do they solve their target use case?
<ddaa> I think so.
<dash> huh. why are tags bad?
<bialix> until you start change tags and merging them
<ddaa> bialix: the point is that when you start to think about merging tags, you go mad.
<bialix> today it's nightmare
<bialix> I wonder how git does tags merge
<jam> bialix: git has conflicts on tags pretty much the same as us
<dash> merging tags sounds like a thing that shouldn't work at all
<jam> dash: it is more the idea that both people have tag "foo" but they disagree on the value
<jam> how do you resolve that?
<bialix> jam: in git tags are objects
<jam> bialix: they are just refs
<jam> not versioned objects
<jam> refs/tags/XXX IIRC
<ddaa> I had the chance to participate in many a restaurant discussions about tags merging with lifeless and the folks, and once you started to think about merging and conflicts it became horrendously tricky in terms of user interface.
<dash> jam: it would not hurt my feelings if that just failed outright
<jam> ddaa: of course, then someone wants to delete a tag and have it propagate
<bialix> ddaa: you know today bzr simply stops
<bialix> there is absolutely no UI to merge tags
<jam> I believe the current state for bzr is that you can do "bzr pull" which will keep your local tags and "bzr pull --overwrite" which will use the remote tags
<jam> but merge doesn't have the same options, etc.
<ddaa> that's fine
<ddaa> at least the tags are there, and people no longer obsess about "bzr is missing tags"
<ddaa> and since nobody has solved the problem any better, it's not net drag on adoption
<bialix> jam: git's tags has additional metadata: who create tag and when. why bzr don't have it?
<bialix> ddaa: so, using your classification, bzr has nested tree support today: from scmproj plugin.
<bialix> it's almost equally ugly as in hg/git and it kinda works
<ddaa> does it kinda work equally to hg/git?
<jam> bialix: Because it wasn't part of the requirements that Martin put together when he created basic tag support
<bialix> ddaa: you can get, update, commit, push easily entire nested construct. and perform more complex actions like in git
<ddaa> if it's not any worse than hg/git solutions, then I say let's have 2.0 and big partay!
<bialix> ddaa: other actions require more work
<jam> bialix: also, git tags don't *always* contain that info
<jam> I just tested it
<jam> and I create .git/refs/tags/test-tag which just has a sha1 in it
<ddaa> BTW, can we have 2.0 partay for DVCS geeks in Paris?
<ddaa> Or alternately, can I have an invitation?
<ddaa> I miss having beer with you folks.
<bialix> jam: I was under impression git tags should have additional metadata. maybe I'm wrong
<bialix> from some presentation about git. There is 4 basic objects in git: blob, tree, commit and tag
 * bialix has to go
 * bialix waves
<cdecarlo> I needed bzr+ssh to use a non-standard port so I created a ~/.bazaar/authenication.conf file and configured the proper settings but I'm not sure if it's reading the file? is there a way to be sure
<jam> too late, I guess. but git *also* has "signed tags" which *do* have extra meta info
 * ddaa goes back to his "getting rich by startup founding" business
<dash> are you secretly paul graham?
<ddaa> I wish.
<ddaa> But if I were I would alread have solved the getting rich part.
<ddaa> I would probably be working on some unlikely project such as "getting famous by changing how the world does rich text editing".
<dash> yes please
<ddaa> dash: for a couple millions euros, I'll happily abandon my current project and start working full time on this.
<ddaa> one-time expense!
<cdecarlo> my authentication.conf file isn't being accessed, is there some secret I don't know about?
<Clint> why am i getting this, and how do i make it better?
<Clint> bzr: ERROR: The method _generate_inventory is not supported on objects of type KnitPackRepository.
 * ddaa watches helpless has texmacs is switch to git after the Savannah disaster.
 * ddaa watches helpless as texmacs is switching to git after the Savannah disaster.
<ddaa> No discussion, request for input, or consideration of alternatives.
<ddaa> Clint: presumably because you are using some plugin that does not work with your version of bzr.
<mattl> ddaa: we're moving to bzr after the Savannah problems, so any help you can give Clint on this would be very helpful.
<Clint> ddaa: i will elaborate then. i did a bzr svn-import, got three "branches" from that, cloned them into subdirs of a --rich-root repo, and tried to join --reference them
<Clint> the first worked, the second two give me that error
<ddaa> Please paste the end of your .bzr.log in a pastebin
<ddaa> I won't be able to solve it for you, but somebody else might.
<ddaa> But I am questioning the usefulness of your doing join in this case. I doubt this will achieve the result you wish.
<Clint> ddaa: http://paste.debian.net/37963/
<Clint> okay, what am i misunderstanding?
<ddaa> What do you want to achieve by joining the branches imported from svn?
<Clint> ddaa: mattl wants to be able to clone the rootdir and get all three
<ddaa> You should write a small script using the "bzr branches" command.
<ddaa> from bzrtools
<mattl> Clint: is this turning into a nightmare?
<ddaa> Also, I bet the error you have comes from using 'join --reference', nested trees do not really work.
<mattl> okay.
<ddaa> They are very experimental stuff.
<mattl> Clint: let's just have a stable tree, experimental tree and trunk tree.
<mattl> 3 seperate ones
<ddaa> They are the equivalent of svn externals. You could use the scmproj plugin for this functionality.
<mattl> would everyone need that plugin to check out?
<ddaa> only to checkout the combination
<ddaa> you do not need it to use branches individually.
<mattl> yeah, that's too much for people to have to do
<mattl> individual branches then
<Clint> done
<ddaa> sorry about the inconvenience, but you cannot really do partial checkouts or whole repo checkouts (as you do with svn) with any DVCS
<mattl> yeah, just getting my head around it all.
<mattl> been in CVS/SVN for about a decade, and used bzr for er.. 48 hours
<ddaa> hope you'll like it
<mattl> lots of people telling us to use git and hg
<mattl> but like bzr, our project is soon going to be a GNU project
<beuno> mwhudson_, I'd like to unblock my LH reviews today if possible
<jelmer> beuno: hi
<beuno> jelmer, hi again
<jelmer> beuno, if there's anything else I can do to unblock the foreign revid stuff, please let me know
<beuno> jelmer, I think it's enough for me to tweak and land
<beuno> will get to it at the end of my day
<jelmer> beuno: sweet
<Clint> is the rich-root format mature enough for sanity?
<jelmer> Clint: Yeah, the 1.9-rich-root format is stable and mature
<jelmer> Clint, the 2.0 format will be rich root only
<Clint> jelmer: i seem to have trouble reading it with bzr 1.5
<jelmer> Clint, well, yeah, bzr 1.5 doesn't support 1.9-rich-root
<jelmer> Clint, it should support --rich-root-pack though, which was introduced in bzr 1.0
<Clint> jelmer: okay
<jelmer> Clint, why do you need rich roots though?
<Clint> jelmer: bzr svn-import; am i able to discard the svn stuff after that to release the rich-root requirement?
<jelmer> Clint, no, unfortunately not
 * Clint sighs.
<jelmer> Clint: The multiple formats thing is a mess :-( I would recommend using rich-root-pack if you're stuck with 1.5
<jelmer> This'll all go away with 2.0, where we'll have a single format
<jelmer> not that that helps you now
 * Clint nods.
 * SamB wonders how you can be stuck with 1.5 ... then remembers that it doesn't help if *you* have the latest release but none of the people who want to pull from you do ...
<Clint> having different trouble with 1.13 instead of 1.5 as well
<jelmer> SamB, lenny has 1.6
<jelmer> s/1.6/1.5
<Clint> (and 1.13 in backports.org)
<SamB> jelmer: oh. you mean people actually run stable?
<SamB> ... I suppose that might be the case :-(
<abentley> jelmer: Please stop sending bzr-gtk merge directives with revision serializer format 9.
<jelmer> abentley, Am I still doing that?
<jelmer> I'm using the same version of bzr to send bzr-gtk merge requests as I use to send bzr.dev merge requests
<abentley> jelmer: Yes, you're still doing that.
<abentley> Your message re: "Use Revision.get_apparent_authors rather than deprecated
<abentley>         Revision.get_apparent_author." does that.
<abentley> jelmer: Are you storing your bzr-gtk stuff in the same repository as your bzr.dev stuff?
<jelmer> abentley: Ah, no
<jelmer> abentley, the bzr-gtk one is a development6 repository
<jelmer> So I guess I should downgrade that to 1.9-rich-root
<jelmer> abentley, thanks
<abentley> jelmer: A real development6?  Or your new dev6 with RIO?
<jelmer> abentley, no, a real development6 repository, at least that's what "bzr info" says
<jelmer> ("Shared repository with trees (format: development6-rich-root)")
<jelmer> hmm
<jelmer> downgrading to 1.9-rich-root fails though, with an error about subtrees
<abentley> jelmer: http://paste.ubuntu.com/187614/
<abentley> jelmer: It's definitely in some wacky format.
<jelmer> abentley: Hmm
<jelmer> I haven't done anything special in this repository though, except for upgrading to --development6
<jelmer> so I wonder how I ended up with the version 9 revision serializer
<lamont> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototy
<lamont> pes -g -O2 -g -Wall -O2 -fPIC -I/usr/include/python2.6 -c bzrlib/_patiencediff_c
<lamont> .c -o /build/buildd/bzr-1.15/./build/temp.linux-armv5tel-2.6/bzrlib/_patiencedif
<lamont> f_c.o
<lamont> bzrlib/_patiencediff_c.c:28:20: error: Python.h: No such file or directory
<lamont> interesting
<lamont> bzr 1.15-1 on armel
<jam> abentley, jelmer: bzrlib.chk_serializer.CHKSerializer.format_num == '9'
<jam> At least, that is my guess
<lamont> hrm.. probably something to do with build-depending on 2.4 and 2.5, while building with 2.6?
<jelmer> jam: ah, yeah
<jelmer> lamont, we depend on python-all-dev IIRC
<lamont> Build-Depends: debhelper, cdbs, quilt, python, python2.5-dev, python2.4-dev, python-central, python-docutils, graphviz, zlib1g-dev
<lamont> that's 1.15-1~bazaar1~hardy1 (speaking of which, what an ugly versio nmmber)
<abentley> jam: It looks like it's not registered in serializer.format_registry.
<cody-somerville> jelmer, any luck with that bzr-git bug? :)
<jelmer> cody-somerville: It turned out to be less trivial than I had expected, not sure what's causing it exactly yet
<jszakmeister> So, I think I found an interesting bug (or at least that's the way it appears).
<jszakmeister> SvnRepository derives from ForeignRepository which derives from Repository
<jszakmeister> SvnRepository inherits Repository's iter_inventories() method.
<ddaa> Hey. Got a showstopper problem with trac-bzr.
<jszakmeister> However, in Repository.iter_inventories() it's calling self._iter_inventories(), which is supposed to call SvnRepository._iter_inventories(), but appears to be calling Repository._iter_inventories() instead.
<ddaa> Not sure what's going on, but trac crashes when trying to compare a offset-naive datetime with an offset-aware datetime.
<ddaa> When trying to build the list of change dates.
<ddaa> Using bzr 1.15, Trac 0.11.4, and trac-bzr tip from launchpad.
<jszakmeister> It's like the method lookup is failing to find SvnRepositories _iter_inventories method.
<jszakmeister> It's very weird.
<ddaa> jszakmeister: usually, when I get this impression with python code, I find that I made myself confused. I suggest you look at it again tomorrow with a fresh mind.
<jszakmeister> Oh, no I'm not confused.  I dumped information from the code object... it's calling the wrong method.
<ddaa> Python does not do weird mysterious thing, and bzr and bzr-svn do not do inscrutable voodoo hack. It's almost certainly doing the obvious thing.
<jelmer> jszakmeister, that bugs already been fixed
<jszakmeister> jelmer: the one I filed or a different one?
<jelmer> jszakmeister, the one you filed
<jelmer> its fixed in the main bzr-svn branch
<jszakmeister> I saw that.  I pulled your branch, and now I get a failure elsewhere.
<jszakmeister> I'm getting this now: 'NoneType' object has no attribute 'get_record_stream'
<jszakmeister> And it appears it's not entering the right _iter_inventories() method. :-(
<jelmer> jszakmeister, can you pastebin the traceback?
<jszakmeister> Sure can.
<jelmer> jszakmeister, qbrowse works fine for me with the change fwiw
<jszakmeister> http://pastebin.com/m4d9df712
<jszakmeister> jelmer: are you running from a branch?  I've been trying to get it to work against a remote repository.
<jelmer> jszakmeister, against a remote repository
<jszakmeister> Weird.  I wonder what's up with my setup then?
<jelmer> bzr-svn 3030?
<jam> abentley: ping
<jam> Something is a bit funny with the codereview preview
<jam> namely: https://code.edge.launchpad.net/~jameinel/bzr/1.16-simple-win32/+merge/6984
<abentley> jam: pong
<jam> It is including vincent's changes
<jam> (Perhaps bzr trunk was not up to date when it generated the diff?)
<jam> I don't see a way to tell code-review to regenerate the diff
<jelmer> jszakmeister, ^
<jszakmeister> jelmer: 3029
<jszakmeister> lemme pull again
<abentley> jam: Code Review is branch-oriented.  If your branch is based on Vincent's, it thinks you're trying to merge the whole thing.
<jelmer> jszakmeister, 3029 should also include the fix
<jam> abentley: there is a single revision from my branch that isn't in trunk
<jam> it was only based on vincent's in that I branched from bzr.dev
<jelmer> jszakmeister, it looks like you're running an old version somehow
<jam> it even gets that right in the 'list of revisions' to be merged
<jam> My guess is that I submitted the request
<jam> inbetween the time that the mirroring script updated lp:bzr from http://bazaar-vcs.org/bzr/bzr.dev
<jam> and the time vincent landed his patch
<jszakmeister> jelmer: I don't believe so... I can see my debug lines in the output
<jszakmeister> I'll check and see if something else is being picked up though.
<abentley> jam: I assume you're talking about the review diff, not the preview diff.
<jam> abentley: sure 'Review diff'
<abentley> jam: Did you use bzr send? Code Review will take your review diff out of your merge directive verbatim.
<jam> I don't know what the difference is, specifically
<jam> abentley: no, I used the web
<jam> "propose for merge"
<jszakmeister> jelmer: I think you're right.  I have my soft link set up wrong.
<abentley> jam: A review diff is a diff against the LCA of the tip and the submit branch trunk, as generated by "bzr send"
<abentley> jam: it's shown at the bottom of the merge proposal.
<abentley> jam: a preview diff is a diff of the submit branch tip against a submit branch tip with the source branch tip merged into it.
<jszakmeister> You rock jelmer!
<abentley> jam: It is generated by MAD and is accessible from the "Diff against target" link.
<jszakmeister> I though I had another debug statement in bzr-svn, but it was in bzrlib.  The one I had in there *wasn't* being printed.
<jszakmeister> Thank you sir!
<jelmer> jszakmeister, np
<abentley> jam: I suspect what happened here is that your review diff was generated before lp's mirror of bzr.dev was updated.
<jam> abentley: my assumption as well
<jam> I filed bug #383346 about it
<ubottu> Launchpad bug 383346 in launchpad "code review has no way to force regenerating Review diff" [Undecided,New] https://launchpad.net/bugs/383346
<abentley> jam: You didn't file a bug about it being wrong?
<jszakmeister> No off to figure out how to teach qbzr not to look at the local repository for revision info, if you happen to be trying to browse an unrelated remote repo.
<jam> abentley: well that bug mentions that it is wrong, and probably due to the race condition
<jam> you can change the subject to whatever fits best in your mind
<abentley> jam: I think it's more important to get it right than to be able to regenerate it.
<jam> abentley: I don't think you can avoid the race condition
<jam> Though also in the bug I mentioned the possiblity of detecting it after the fact
<jam> (revs that were requested for review show up in the merge target)
<abentley> jam: We can at least perform a mirror immediately before generating the diff.
<ddaa> FFS, how can the datetime handling in trac-bzr even work with trace 0.11?
<jam> abentley: that would be possible, but still leaves open the issues with landing pieces of a multi-phase patch
<ddaa> It's out and out braindead. I cannot imagine how it could have passed even superficial testing.
 * ddaa blames jelmer
<ddaa> actually, bzr blames jelmer
<abentley> jam: Until there's proper support for base revisions or dependent branches, you can use bzr send for that.
<jam> abentley: or you could just detect that the set of revisions for review changed...
<jam> or have something easier than "Resubmit" to regenerate the diff
<abentley> jam: No, we should not.  People who are reviewing something should be reviewing the same thing.  Regenerating the diff breaks that, and makes people review the integration, not the change.
<ddaa> jelmer: dude, revision 60 http://bazaar.launchpad.net/~trac-bzr-team/trac-bzr/trunk/revision/60#tracbzr/backend.py
<ddaa> by default, timestamps are offset-naive, not utc!
<ddaa> jelmer: what were you trying to fix when you made this change?
<jelmer> ddaa: argh, not sure how that got in
<ddaa> I'll try reverting that in my trac, see if that makes it happier.
<ddaa> jelmer: that fixes it for me.
<ddaa> bzr merge -r60..59
<ddaa> jelmer: will you patch mainline for me?
<dash> oh man =/
<dash> i am getting an exciting error message with bzr 1.15
<dash> http://paste2.org/p/243728
<abentley> dash: It's the loom plugin being out of date.
<dash> aah.
<ddaa> abentley: darn, I was hoping it was bzr-svn so I could blame jelmer again ;)
<abentley> ddaa: We could blame jelmer because bzr-svn doesn't auto-update bzr-loom >:)
<ddaa> abentley: Deal!
<ddaa> And next, we'll blame jelmer for war in Palestine.
<dash> so i guess i get to try to fix it :)
<fullermd> Oh look, a big long thread of ranting on pgsql-hackers about git's lacking co [--lightweight]...
<jelmer> ddaa: You're welcome to do that yourself, we need more trac-bzr hackers :-)
<jelmer> ddaa: Otherwise, I'm happy to do it
<ddaa> jelmer: okay, sent my team application, approve it and I'll fix your mainline.
<jelmer> ddaa, welcome
<fullermd> I really hate launchpad sometimes.
<ddaa> jelmer: ur maine-coon r a fixed.
<ddaa> I mean mainline, not maine-coon sorry. I blame my inner lolcat.
<jelmer> ddaa, kthx!
<jam> thumper: ping
<thumper> jam: just on a call right now
<jam> thumper: np, just though I'd mention that my patches for gc stacking are up for review
<thumper> jam: excellent, thanks
<jelmer> jam: I'm wondering if maybe some of my later changes to bencode had an impact on performance
<jam> jelmer: I should have been using the very lastest version of your code for my testing
<jelmer> jam: I mean negative impact
<jam> which changes?
<jam> stuff like strtol?
<jam> instead of PyLong_FromString?
<jelmer> jam: The ones after I put up the patch for review
<jelmer> jam, yeah, that sort of thing
<jelmer> well, I would be surprised if strtol would be slower than PyLong_FromString
<jelmer> but I'm a bit surprised with the current performance given what I saw earlier
<jml> so, how does one actually _use_ py_memory_dump?
<LarstiQ> good question, a colleague of mine used it, I should look at how he did that
 * LarstiQ goes to sleep
<ddaa> jelmer: do you know why all the revision names are urlencoded?
<jam> jml: from memory_dump import scanner; scanner.dump_gc_objects('filename.txt')
<jam> from memory_dump import loader
<jam> m = loader.load('filename.txt')
<jam> etc
<ddaa> it's very annoying, because it encodes 1. the colon in special revision names 2. the slash name of branches in subdirs.
<jml> jam: thanks.
<ddaa> jelmer: I'd hack it away, but I'm afraid of breaking older trac releases.
<jam> jml: you can do the load in a separate process, in case you are already at, you know, 4.5GB of resident memory :)
<jam> though that dump will be a bit painful regardless
<jelmer> ddaa: It's a dvcs, use a separate branch :-)
<jelmer> the only other release we worry about is 0.10, and the main difference in that is the datetime stuff
<jelmer> abentley, is bundlebuggy running bzr.dev ? if so, any chance you can update it? The serializer 9 registration patch has landed
<abentley> jelmer: No, it's not.
<jelmer> abentley, is there some way I can force the format of the serializer
<jelmer> used in merge directives?
<abentley> jelmer: The only way to force the format of the serializer is to change the repository format.  Bundle format 4 copies this data verbatim.
<jelmer> abentley: okay, I'll fall back to manual patches for now then. Thanks
<abentley> jelmer: I'll upgrade BB to 1.16 when it comes out.
<salgado> hi there.  is it possible to recover from a corrupted .bzr/checkout/dirstate ?
<Peng_> salgado: You could just nuke .bzr/checkout and run "bzr checkout".
<salgado> all of a sudden one of my branches is giving me this whenever I do 'bzr <anything>': bzr: ERROR: The dirstate file (DirState(u'/home/salgado/devel/launchpad/mainline/.bzr/checkout/dirstate')) appears to be corrupt: trailing garbage: 'AAATMUexj0JHsY9'
<jelmer> abentley: Cool. I can survive with plain patches for a month or so.
<Peng_> salgado: (Um, that's assuming you're using a regular branch, not a checkout or something.)
<salgado> Peng, yes, this is supposed to be a regular branch.  will try that, thanks
<ddaa> jelmer: I savagely removed all the urllib.quote/unquote functionality, and it does not appear to break anything for me
<ddaa> while at the same time fixing my problems
<jelmer> ddaa, Yeah, the code badly needs a cleanup
<jelmer> ddaa, I've mostly been trying to keep it running for bitlbee/ctrlproxy
<ddaa> the ctrlproxy one is borked
<jelmer> yeah, I haven't had time for trac-bzr recently
<ddaa> I don't have time either really.
<jelmer> unfortunately there aren't a lot of alternatives to trac
<jelmer> redmine is nice but it's ruby
<jelmer> and I don't know ruby
<ddaa> I dunno either trac or redmine
<jfroy> jelmer: I'm having a weird problem with rebase
<ddaa> I'll upload my patch in a branch, and I'll let the crowd decide.
<jelmer> ddaa: did you try running the testsuite?
<ddaa> nope
<jelmer> jfroy, ?
<jfroy> I try to pull from a branch (remote svn branch), get a notice that the branches have diverged.
<jfroy> I try to rebase on to that same URL, and that does nothing
<jfroy> unless I forgot how to rebase...
<ddaa> jelmer: what's the magic command to run the test suite?
<jelmer> jfroy, are the urls for pull and rebase the same?
<jfroy> yes
<jelmer> ddaa: "trial tracbzr" / "nosetests tracbzr"
<ddaa> jelmer: it fails horribly
<ddaa> but I cannot be bothered to fix it right now
<jelmer> ddaa: did you verify that % and : in revision ids still work after removing the urllib.quote/unquote sutff?
<jelmer> vila, ping
<ddaa> jelmer: lol
<ddaa> I'd bet they don't
<ddaa> but I specifically want "current:" and friends not to be escaped
<ddaa> and I do not have any such revision handy
<jfroy> it prints "Started 2 unique searchers for 8 unique revisions" in the trace then exits with 0
<jfroy> however bzr missing says I'm missing 3 revisions
<jfroy> I could try rebase against a fresh local branch of the remote branch
<jelmer> jfroy, and missing also says that you've got extra revisions?
<jfroy> correct, 1 extra
<jfroy> which is actually a merge revision
<jfroy> yeah, rebase against a local copy of the remote branch yields the same result
<jfroy> urg, seems I'm hosed :/
<jelmer> jfroy, rebase skips merges
<jelmer> jfroy, known bug
<jfroy> but shouldn't I pick the 3 revisions I am missing from the remote branch, then rebase the merge on top of that new history?
<jfroy> *shouldn't it
<jelmer> jfroy, it's a known bug, it should handle the merge
<jfroy> I see
<jfroy> gotcha
<jfroy> mmm
<jfroy> I guess I can uncommit
<jfroy> the merge was clean, easy to re-do
<jfroy> pretty serious bug though :/
<jfroy> mmm
<jelmer> jfroy, even when it will support merges, they'd be quite prone to conflicts
<jfroy> uncommit actually puts merges back to pending?
<jfroy> yeah I guess it would....
<jelmer> yeah, it only changes the branch
<jfroy> need to revert it out
<jfroy> and then revert --forget-merges (why can't you do both at the same time...)
<mwhudson_> i think i want to refactor how loggerhead serves branch content
<jfroy> and well, would it be that prone to conflicts if the merged branch was orthogonal?
<jfroy> mmmm
<jfroy> bzr merge -r foo.. doesn't seem to be doing what I want
<jfroy> I thought this would mean "cherrypick from revisions foo to tip of branch being merged"
<jelmer> jfroy, bzr revert with no arguments does both
<jfroy> but it seems to be picking a lot more revisions than that
<Peng_> mwhudson_: Eh?
<jelmer> mwhudson_, ?
<jfroy> jelmer: oh?
<jelmer> mwhudson_, into a separate loggerhead.app thing?
<jfroy> that's not clear
<mwhudson_> Peng_: basically, i think we should always traverse to the branch, then see if the request is for .bzr
<mwhudson_> though i guess that doesn't work for repositories
<mwhudson_> '/.bzr/' in PATH_INFO is a bit gross
<jfroy> nevermind, bzr was sane, I was not :/
<ddaa> jelmer: here you have my shameless hack.
<ddaa> https://code.launchpad.net/~ddaa/trac-bzr/trac-bzr.ddaa
<ddaa> Mh... crap committer name... I'll fix that.
<dash> bloarg
<dash> so today my task is to merge some code into an svn repo that was copied out of it a month ago, into a separate svn repo
<dash> and hacked upon
<dash> i've got bzr branches of both now via bzr-svn
<dash> i wonder if it makes sense to try to replay any of the history
#bzr 2009-06-04
<mwhudson_> Peng_: bzr annotate http://bzr.mattnordhoff.com/bzr/loggerhead/cheezum/serve-branches explodes in an entertaining way :(
<Peng_> mwhudson_: Huh!
<mwhudson_> also nosmart+
<mwhudson_> $ bzr annotate nosmart+http://bzr.mattnordhoff.com/bzr/loggerhead/cheezum/serve-branches
<mwhudson_> bzr: ERROR: Transport operation not possible: http does not support mkdir()
<mwhudson_> whut?
<jelmer> mwhudson_, it's trying to get a lock
<Peng_> Oh, one of you has IPv6! Awesome! :D
<mwhudson_> oh
<jelmer> Peng_, that must be me
<mwhudson_> it's certainly very unlikely to be me
<mwhudson_> jelmer: why would it do that?
<Peng_> jelmer: If there was a prize for "First IPv6 HTTP request that isn't localhost", you'd win it. :D
<jelmer> mwhudson_, not idea
<Peng_> Unfortunately there's not.
<jelmer> *no idea
<mwhudson_> bzr annotate http://bazaar.launchpad.net/~mnordhoff/loggerhead/cheezum/serve-branches also fails
<mwhudson_> in a rather different way though
<Peng_> I can annotate the file in my local branch.
<mwhudson_> oh
 * mwhudson_ stabs historycache
 * jelmer is waiting for bzr to support gopher
<Peng_> I can do it over HTTP too.
<Peng_> That file has ugly history, FWIW.
<mwhudson_> so at some point launchpad's mirroring produced a broken branch
<mwhudson_> though actually, given that it's bzr+http, that's not so amazingly surprising
<Peng_> :>
<jelmer> thumper, moin
<thumper> jelmer: hi
<jelmer> thumper, you pasted a URL here earlier, what repository was that for?
<thumper> jelmer: I'm trying to remember...
<thumper> jelmer: I think it was another bzr-git failure
<thumper> a different one
<jelmer> thumper: Yeah, it was
<jelmer> thumper, it didn't include a URL though, so it was a bit hard to reproduce
<thumper> heh, oops
 * thumper thinks
<jelmer> thumper, mwhudson_: btw, what's the eta on a new bzr-git on lp? there's a couple of issues now that should be fixed
<mwhudson_> jelmer: no specific eta, i guess it's not too much work though
<thumper> mwhudson_: we could land it and roll it out
<thumper> mwhudson_: it is very contained
<mwhudson_> right
<mwhudson_> even i have privs to roll it out :)
<thumper> jfdi :)
<thumper> really?
<thumper> how?
<mwhudson_> yeah
<mwhudson_> this is a bad thing though
<mwhudson_> thumper: i can sudo importd on the relevant boxes
<thumper> ok, I don't want to know then
<igc> morning
<jelmer> moin Ian
<igc> hi jelmer
<lifeless> jelmer: pong
<lifeless> jml: yes
<jml> lifeless: were there any interesting outcomes?
<jelmer> lifeless, does subunit-stats work for you?
<jelmer> lifeless, it only recognizes a single test for me in a large stream
<lifeless> jelmer: checking
<lifeless> jml: 'even code you don't think will be reused will be reused' is probably the strongest message I took away
<lifeless> I have an unusual perspective though
<jml> :D
<lifeless> it was broadly:
<lifeless>  - bzr's structure is nice and landscape had a bunch of tools that would benefit being in that structure
<lifeless>  - it was too hard to reuse bzr's structure in situ
<lifeless>  - a 90% version [primarily bzr's ExternalCommand] was fast to TDD up
<lifeless>  - jkakar now wants the rest and is looking at actually reusing bzr's stuff :)
<jml> lifeless: thanks, that's a helpful summary.
<jml> lifeless: I guess bzr isn't going to start depending on commandant any time soon
<lifeless> happily, for various reasons I'd been cleaning this up, and there is a patch I've done which allows nuking all the builtin bzr commands
<lifeless> so you can have the infrastructure alone
<jml> \o/
<lifeless> jml: the other way is quite likely
<jfroy> jelmer: new bzr-svn assertion just started happening
<jfroy> https://bugs.launchpad.net/bzr-svn/+bug/383414
<ubottu> Ubuntu bug 383414 in bzr-svn "Assertion in iter_changes on path" [Undecided,New]
<jfroy> after I pushed a revision up
<lifeless> jml: seen my facebook feed for a link to the patch; I promised jkakar I'd link it to him after the talk
<lifeless> bzr.dev$ ./bzr selftest --no-plugins --subunit selftest | subunit-stats
<lifeless> Total tests:     183
<lifeless> Passed tests:    182
<lifeless> Failed tests:      0
<lifeless> Skipped tests:     1
<lifeless> Tags:
<lifeless> jelmer: ^
<jml> using facebook for *patches*
<jfroy> I can no longer pull, push or branch that svn remote branch
<jml> what the hell :)
<lifeless> jml: for links to merge requests actually, but yeh.
<lifeless> jml: hey, you guys bullied me into it.
<jml> :D
<jelmer> lifeless, also, does it really have to repeat all input to me?
<jelmer> lifeless, or is that perhaps related?
<lifeless> jelmer: you have a test that is managing to corrupt the output stream
<lifeless> jelmer: I've been thinking of changing the control emitters to start their output with \n
<lifeless> jelmer: which would insulate against this
<jml> lifeless: anyway, it sounds like commandant and bzr are both proceeding in a direction that will make my script-writing life much better. :)
<jelmer> lifeless: How can a test do that?
<jfroy> Urg, and I just ran into https://bugs.launchpad.net/bzr-svn/+bug/383415
<ubottu> Ubuntu bug 383415 in bzr-svn "AttributeError: 'SubversionTags' object has no attribute '_resolve_reverse_tags_fallback'" [Undecided,New]
<lifeless> jml: commandant's strengths are external commands and minimalism
<lifeless> jml: Personally, I'd hammer on bzrlib until its perfect for your needs :)
<lifeless> jelmer: say your stream is on stdout
<jelmer> jfroy, that one should be fixed now
<lifeless> jelmer: actually, just capture the first three tests or so
<lifeless> and pastebin
<jelmer> lifeless, http://pastebin.ubuntu.com/187766/
<jfroy> jelmer: ok
<jfroy> But yeah, that logwalker bug has just killed me dead
<jfroy> can't operate on the remote branches at all
<jfroy> I can try reverting bzr-svn revision by revision to try to find the one that introduced the problem
<jfroy> unless it's a new one...
<jelmer> jfroy: I doubt this is a regression
<jelmer> jfroy: I think it's a new problem, just looking at it now
<jfroy> I think it started happening after I pushed some changes to svn
<jfroy> and looking at the svn log
<jfroy> it also pushed a merged branch up
<jfroy> (I've since disabled that option, it seems to not be quite as well tested as it should be)
<jfroy> and it was doing "strange" operations, like copying a directory unto itself on svn
<lifeless> jelmer:  cat /tmp/t | subunit-stats
<lifeless> ... 1 fail
<lifeless> jelmer: debugging tip - if you see that, run through subunit2pyunit
<jfroy> e.g. copied foo/bar to foo/bar
<lifeless> ======================================================================
<lifeless> ERROR: samba4.rpc.samba3.sharesec on ncalrpc with seal,padcheck (dc:local)
<lifeless> ----------------------------------------------------------------------
<lifeless> RemoteException: lost connection during test 'samba4.rpc.samba3.sharesec on ncalrpc with seal,padcheck (dc:local)'
<jelmer> jfroy, I think I see where the problem is
<jelmer> lifeless, any idea what could cause that?
<jelmer> lifeless, ah, perhaps explanations of the result arent' allowed for skip?
<lifeless> should be
<jelmer> lifeless, yeah, looks like it refuses those:
<jelmer> test: foo
<jelmer> skip: foo [ foo ]
<jelmer> fails
<jelmer> test:
<jelmer> skip: foo
<jelmer> works
<lifeless> jelmer: well, subunit itself outputs explanations for skips
<lifeless> so its something more than 'not supported'
<lifeless> I don't think subunit knows how to deal with one-line explanations
<jfroy> jelmer: http://home.devklog.net/~bahamut/12191.xml, http://home.devklog.net/~bahamut/12189.xml
<jfroy> if that's of any help
<jelmer> jfroy, revno 3033 should fix it
<jelmer> jfroy, but thanks for providing such valuable bug reports
<lifeless> jelmer: its dyin on the fail
<lifeless> jelmer: the very first one, not the skip
<jfroy> jelmer: no, thanks for being so awesome :)
<jelmer> lifeless, Which fail ? :-)
<lifeless> oh, I was testing something :)
<lifeless> anyway
<lifeless> you're quoting in a way that subunit doesn't expect
<jfroy> jelmer: mmm, no joy
<jelmer> lifeless, what does it expect?
<lifeless> status:? NAME($| [)
<jelmer> lifeless, fail [\nfoo\n]\n ?
<lifeless> explanation*
<lifeless> ]\n
<lifeless> yes
<jelmer> so I have to have a newline after the [ ?
<jfroy> same backtrace
<jfroy> though it seems I can pull existing branches now
<lifeless> and then a final newline before the ]
<jfroy> can't branch though
<lifeless> but I'll accept a patch to handle your layout too
<lifeless> simplest to get you going will be to use the multiple line layout subunit does
<jelmer> jfroy: Can you paste an updated backtrace ?
<jelmer> lifeless, ok, I'll see if I can provide a patch for that
<jelmer> lifeless: We have lots of tests and usually only short explanations, this makes it a bit easier to read "raw" subunit streams
<jfroy> done
<lifeless> jelmer: I usually read the pyunit2unit output when debugging, as it has the lot
<lifeless> jelmer: but sure, room for variation
<jfroy> jelmer: so in PDB, prefixes is equal to the path that gets printed by the assertion
<jfroy> which means it did path = prefixes[0].strip("/")
<jfroy> probably not relevant :/
<jfroy> ascending is True
<jelmer> the from_revnum / to_revnum tuple is swapped somewhere, I'm trying to find out where
<jelmer> it usually doesn't matter, only if prefixes is not empty
<jfroy> it's not
<jelmer> from_revnum should be higher than to_revnum
<jfroy> from_revnum=12189 to_revnum=12191 in repository.py(1114)find_branchpaths
<jfroy> ditto for repository.py(1182)find_fileprop_paths
<jelmer> I think I've found the place where this is going wrong, just running the testsuite now to check that I didn't break anything else
<jfroy> same for find_branch_tips
<jfroy> might be in revids.py(243)get_branch_revnum
<jelmer> yeah, that's where I've swapped the two atm
<jfroy> (Pdb) p last_revnum
<jfroy> 12191
<jfroy> (Pdb) p last_checked
<jfroy> 12189
<jfroy> in there
<jfroy> layout is TrunkLayout(2)
<jfroy> project is the prefix
<jfroy> (same value as prefixes[0] in find_branchpaths)
<ddaa> jelmer: actually, I reverted my quoting hack in my server.
<ddaa> I had a broken link, apparently related to lack of escaping of "/" for a subdir branch.
<lifeless> jam: ping
<jelmer> jfroy, I've got a fix that should also improve performance in some situations
<jelmer> jfroy, but still one test failing
<jelmer> will push when I've fixed that
<jfroy> jelmer: all good
<jelmer> lifeless, oh btw, I've asked for a rename of bzr-rebase to bzr-rewrite on Launchpad
<lifeless> heh
<lifeless> so I've been thinking of doing a ground up recode
<lifeless> but not necessarily for good reasons
<jelmer> recode of rebase you mean?
<lifeless> yeah
<jfroy> huh
<jfroy> people will get confused even more
<jfroy> they're look for "rebase for bazaar"
<jfroy> *they'll look
<jelmer> lifeless: There's certainly a couple of improvements that can be made, I don't think there's much to gain in a rewrite from the grounds up rather than just fixing things gradually
<lifeless> jelmer: I've found it hard to get code that fixes peoples issues into trunk
<lifeless> jelmer: and there seemed to be a definitional tension
<jelmer> lifeless, I don't think it's unreasonable for me to refuse patches that break the testsuite.
<lifeless> jelmer: thats fine :), it was other ones
<lifeless> by definitional I mean 'rebase vs replay vs ...'
<jelmer> lifeless: So you're considering doing a rewrite based on a single discussion over an command parameter?
<lifeless> I have a dream of having a single command that supports all the history rewrite operations we need
<lifeless> jelmer: did I say 'not necessarily for good reasons'
<jelmer> lifeless: I don't object to having such a command, and I think bzr-rewrite would be a good place.
<jelmer> lifeless, I think it should be a different command from "bzr rebase" though, which is one of the reasons I asked for the rename of the plugin
<jelmer> jfroy, the rebase plugin already includes more than just the rebase command, so I don't think it's unreasonable to have a different name for it
<jfroy> That's true
<lifeless> jelmer: https://code.edge.launchpad.net/~jelmer/bzr-search/merge is still empty
<jelmer> lifeless, it was created using bzr send, I'll see if I can push to it manually
<lifeless> also file a bug
<jelmer> lifeless, pushed now
<jelmer> jfroy, pushed
<jfroy> jelmer: checking
<jfroy> success
<jfroy> you can close
<jfroy> jelmer: you, sir, are awesome
<jelmer> jfroy, :-)
 * igc lunch
<lifeless> jelmer: so what does lp:~jelmer/subunit/subunitrunner
<lifeless>  do?
<lifeless> spiv: ping
<lifeless> spiv: [network deltas, hopefully you're awake now]
<spiv> lifeless: yes, I'm awake :)
<lifeless> so for 2.0 we wanted to get network deltas gong
<spiv> (I don't think my problem is jet lag so much as getting over ubuflu... I'm not having any trouble getting sleep at appropriate times, I just seem to need a lot more sleep than usual.)
<lifeless> Yeah, I'm sleeping 9-10 hours, which is about 40% more than usual
<Peng_> "ubuflu"?
<spiv> Peng_: the UDS plague.
<mwhudson_> Peng_: the result of uds, where lots of viruses get together and have a party
<Peng_> And you people wanted to invite me! :P
<lifeless> its like an uberflu
<lifeless> but with a kiwi accent
<mwhudson_> there are compensations
<lifeless> interesting people
<spiv> mwhudson_: true, I don't know how else I'd be able to fill a large bucket of snot...
<Peng_> Factoring in everybody sleeping 40% more than normal, was UDS really good for productivity? :D
<fullermd> Well, that explains why I'm getting _less_ sleep than normal...  obviously the cosmic balance is being maintained.
<Peng_> Wait, I am too. Scary.
 * spiv -> food
<lifeless> spiv: so, are you still blocked onthe question you asked me monday week ago, or jam helped, or EILL
<spiv> lifeless: I haven't looked at it at all, actually, so not sure if I'm blocked :)
<spiv> lifeless: the UDS sprint was mostly on gc-stacking and nested-trees.
<spiv> This week has been pretty slow (EILL), but I have caught up on a few things and fixed a regression for jml.
<lifeless> yah
<lifeless> I'm struggling
<vila> hi all
<vila> lifeless, spiv: me too EILL, at least I need far more sleep than usual, so not really ill but...
<lifeless> abentley: FYI, hg is overhauling forests, 'subrepos' is what they are calling it
<bob2> is it going to be less silly?
<lifeless> who knows
<abentley> lifeless: I heard "nested repositories": http://bazaar-vcs.org/NestedTreesDesign#mercurial-nested-repositories
<lifeless> abentley: mpm is talking subrepos in IRC on and off at the moment
<lifeless> it may be a reference to cleaning up http://www.nabble.com/sub-repository-extension-td20345412.html
<lifeless> or may be new code; I don't know
<lifeless> blink
<Peng_> ?
<lifeless> just realised the time
<Peng_> Ah.
<Peng_> Oh, 06:47, when my logs rotate (but not on this day of the week).
<UUncia> What's the difference between checkout & branch?
<lifeless> when you commit in a checkout, the commit goes both locally in the checkout, and also in some other branch that the checkout was made of
<lifeless> its useful for maintainers of a project to all have a checkout of trunk
<lifeless> halt()
<Demosthenes> i want to start a new repo (tree?) and then import into it single files from multiple other repos while preserving the history for just those files. is that possible?
<Demosthenes> i'm basically combining a document from three diff repos, but first i want to import the existing ones while preserving the log
<sabdfl> hi folks - what's the status of initial commit and explicit-file commit with 2.0?
<awilkins> lifeless: Ping?
<awilkins> Pah, Australians. Always 12 hours ago.
<Kamping_Kaiser> pah.
<balachmar> Hi, I want to share my code using bzr and sftp. Now I have setup a repo, but on the server there is no code, just the history. How do I set it up in a way, that there is code on my server as well?
<awilkins> balachmar: Pushing via remote protocols does not update the tree
<awilkins> balachmar: There is a plugin that executes a tree update via ssh
<balachmar> ooh, I thought since, I didn't setup the remote tree with no-trees it would actually do it...
<awilkins> Pushing a tree over SFTP would be more costly than the remote machine writing the tree
<balachmar> is there a way to automate that? So that when I commit changes, the tree gets regenerated?
<awilkins> push-and-update plugin http://bazaar-vcs.org/BzrPlugins
<awilkins> Although there are thoughts about implementing it in the smart server rattling around on the mailing list
<balachmar> ok, will just do it manually for now then. Thanks for the info
<Peng_> Even now, you could probably use a hook in the hpss?
<RockyRoad> hi :)
<RockyRoad> I tried to use uncommit. It work on local copy, but I could not reflect it on launchpad. Is it possible ?
<RockyRoad> it works*
<luks> you can "push --overwrite" probably
<luks> but be careful with that
<cdecarlo> hi, I've set my authentication.conf to this: http://pastie.org/500323 but when I try to access my home computer with bzr+ssh://, it times out waiting on port 22? is there something wrong with the .conf?
<luks> I can't help you with authentication.conf, but I'd use ~/.ssh/config for this
<vila> cdecarlo: as luks said, .ssh/config is more appropriate, especially if you want port 2662 to be used
<cdecarlo> luks: It never occured to me to try that, thanks, I'm always interested in other ways to skin cats ;)
<cdecarlo> out of curiosity then, why then does bzr support those options in it's authentication.conf?
<vila> cdecarlo: authentication.conf purpose is different, it said: *if* you use port 2662 then user is 'colin', whereas .ssh/config allows you to say *if* connection goes to example.com then *use* port 2662
<cdecarlo> vila: ah
<cdecarlo> thanks
<vila> cdecarlo: the main purspose of authentication.conf is to provide some facilities to protocols *other* than ssh, .ssh/config and ssh agents are not available for all protocols :) But auth.conf doesn't even try to replace them
<vila> for ssh
<cdecarlo> that would make a great note in the user docs, does bzr use trac or something similar?
<vila> cdecarlo: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#authentication-settings says "SFTP can use either a password or a host key to authenticate. However, ssh agents are a better, more secure solution. So we have chosen to not provide our own less secure method."
<vila> cdecarlo: but if you can think of a better way to say that or other places where it should be pointed at, feel free to send a patch. The sources are under  the 'doc' directory in bzr
<pygi>  hi folks
<cdecarlo> vila: thanks, I'll try to think of something
<vila> pygi: hi
<nickoe> Hi
<nickoe> I can't seem to find out how I should setup a repo on a ftp server.
<nickoe> Can YOU help me?
<vila> nickoe: 'bzr init ftp://example.com/path/to/branch' should create a empty branch
<nickoe> vila, how should I then use t correctly?
<vila> bzr push ftp://example.com/path/to/branch from your local branch
<vila> 'bzr push ftp://example.com/path/to/branch' from your local branch
<nickoe> that is if I already got a branch on locally, right?
<vila> nickoe: yes
<nickoe> vila, then tha same data is locally and on the ftp, right?
<vila> except for the working tree, yes
<vila> uncommitted changes are not pushed either
<nickoe> Okay. But the fact that the working tree is not on ftp, means that you actually can't download a revision from the server?
<vila> nickoe: no, it means the ftp branch has no working tree, but it can be used to branch or pull from other clients
<vila> nickoe: if you never login with a shell on the ftp server, you don't care about the working tree
<nickoe> okay, so antoher user can use bzr checkout ftp://bla.com/path to get the latest revision, or?
<nickoe> Seems to be working now. vila thank you
<vila> nickoe: always happy to help (TM)
<nickoe> But why do I have to type the ftp password all the time? vila
<vila> nickoe: because your server requires a password ? :-)
<vila> nickoe: what os/version are you using ?
<nickoe> linux
<nickoe> ubuntu 9.04
<vila> nickoe: so authentication.conf is the way to go
<vila> nickoe: is sftp an option on the server side ? Or is the server not under your control ?
<nickoe> sftp not an option atm
<vila> nickoe: too bad, keys and ssh agents are more secure, anyway, have a look at http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#authentication-settings
<nickoe> yes I know, but not an option atm...
<nickoe> :-/
<vila> nickoe: is that server public or on a private LAN ?
<nickoe> well it is public, but the information on it is just temporary
<vila> nickoe: np, I was just trying to better understand your use case
<nickoe> k
<nickoe> But I will thank you once again
<jam> morning vila
<vila> jam: hi !
<rbriggsatuiowa> my unshelve command failed miserably
<rbriggsatuiowa> bzr: ERROR: exceptions.NotImplementedError: <property object at 0xee8d70>
<rbriggsatuiowa> I'm not entirely sure what's in my shelf - where can I find what the contents are?
<rbriggsatuiowa> cat .bzr/checkout/shelf/shelf1
<rbriggsatuiowa> nice
<jfroy> Morning.
<jfroy> I was wondering if there was a way to have bzr stomp all over my working tree when switching branch.
<jam> jfroy: ? you mean touch everything?
 * garyvdm is trying to catch up on email. I've had no internet since I got back from the sprint.
<pygi> garyvdm: :p
<pygi> I've told you not to cut the wires!
<garyvdm> haha
<jfroy> jam: sorry, I got dragged away
<jfroy> so my problem is that I have some branches which have file foo/bar versioned, and some later branches that do not (they generate foo/bar)
<jfroy> and when switching from a branch that generates foo/bar to a branch that versions the file, I get a content conflict
<jfroy> I'd rather just have bzr blow away files it needs to check out from the branch
<jfroy> I understand it cannot be default behavior, but a flag would be useful
<jam> jfroy: well, there is always "bzr switch; bzr reverT"
<jfroy> true
<jfroy> that's what I do right now, and it works well, but I'm lazy :p
<jam> bzr switch --hard ?
<jam> bzr switch --and-reset
<jam> bzr switch --and-revert
<dash> --nuclear-option
<jelmer> jam, ping
<jam> jelmer: pong
<jelmer> I'm looking at bug 246880 and wondering how it relates to the bug we worked on during UDS
<ubottu> Launchpad bug 246880 in bzr "ghost fetch issue: fail when fetching a text referenced by a live revision introduced by a ghost revision" [High,Triaged] https://launchpad.net/bugs/246880
<jelmer> the original error is different (line delta missing) but the reconcile problem should be fixed now
<jelmer> nevermind, enough other ghost bugs open :-/
<LarstiQ> evening
<garyvdm> evening LarstiQ
<pygi> garyvdm: reviewed my patch yet? :p
<LarstiQ> heya gary
 * pygi hides
<garyvdm> pygi: No :-( - Had no internet. Will do it Now!
<pygi> garyvdm: xD
<jelmer> Peng, is there anything that's enabled by --allow-writes atm or is it there in preparation of the smart server support?
<pygi> GaryvdM_Windows: !
<Snova> If I deleted a file in revision 5, and am now at revision 10, what is the best way to get that file again?
<jam> Snova: bzr revert -r 5 filename
<Snova> Thank you. :)
<unutbu> jam: thanks
<Noldorin> hi. i'm trying to create a branch on launchpad but am getting the following error:
<Noldorin> bzr: ERROR: Target directory "lp:darwindotnet/0.1" already exists.
<Noldorin> the branch clearly hasn't been pushed to yet.
<Noldorin> any ideas?
<garyvdm> luks: What are your thoughts who copyright is assigned to in the license headers in qbzr?
<garyvdm> If someone adds a new file, they should assign the copyright to them selves?
<mwhudson> Noldorin: try passing --use-existing-dir to push
<Noldorin> mwhudson: i'm attempting to branch directly to a separate launchpad branch. is that the wrong way to be doing it?
<mwhudson> oh
<Noldorin> (bzr branch doesn't have the --use-existing-dir option)
<mwhudson> well, i'm certainly not sure that that would work
<Noldorin> i see
<Noldorin> i wanted to do that mainly so i can link the local and master branches in sync
<Noldorin> but maybe i can do that another way?
<Noldorin> mwhudson: i haven't quite figured out how i linked the master and local branches for my devel branch!
<mwhudson> um
<mwhudson> what do you mean by local ?
<mwhudson> i don't see why you'd have two branches with perpetually the same content on launchpad
<Noldorin> local as in on my drive
<Noldorin> what do you mean perpetually the same content?
<Noldorin> mwhudson: ?
<mwhudson> oh
<mwhudson> Noldorin: have you come across bzr bind ?
<Noldorin> and master as in on launchpad
<Noldorin> mwhudson: no i haven't
<mwhudson> Noldorin: i think that's what you want
<Noldorin> ah i think you could be right.
<Noldorin> mwhudson: right, so i just tried bzr bind. it gives me the following error:
<Noldorin> bzr: ERROR: xmlrpc protocol error connecting to https://xmlrpc.edge.launchpad.ne
<Noldorin> t/bazaar/: 503 Service Unavailable
<Noldorin> sorry
<Noldorin> bzr: ERROR: xmlrpc protocol error connecting to https://xmlrpc.edge.launchpad.net/bazaar/: 503 Service Unavailable
<mwhudson> !
<mwhudson> maybe try again?
<mwhudson> that's definitely not supposed to happen
<garyvdm> launchpad is currently offline.
<Noldorin> yeah, i've already tried several times
<Noldorin> oh lol
<pygi> garry has spoken
<Noldorin> it must have gone offline just as i have been talking with you
<garyvdm> http://blog.launchpad.net/notifications/launchpad-offline-2200-2210-utc-4th-june
<Noldorin> never mind then
<Noldorin> garyvdm: thanks
<Noldorin> mwhudson: i think bind is my solution anyway. cheers :)
<garyvdm> Noldorin: lp's back up
<Noldorin> garyvdm: yeah, just noticed. cheers
<Noldorin> mwhudson: just ran bzr branch, and this error message truly seems to be strange:
<Noldorin> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~noldorin/darwindotnet/0.1/".
<Noldorin> because it certainly is a branch
<mwhudson> Noldorin: "https://code.edge.launchpad.net/~noldorin/darwindotnet/0.1" says "This branch has not been pushed to yet."
<mwhudson> Noldorin: sadly, "registering a branch" in the web ui doesn't actually create a branch that bzr can use
<Noldorin> but i want to initiate it by branching to it
<mwhudson> Noldorin: push your branch up first
<Noldorin> mwhudson: ah i see.
<Noldorin> will do then
<Noldorin> mwhudson: thanks. all seems to be working now :)
<mwhudson> Noldorin: hooray :)
<Noldorin> mwhudson: linked branches just seems to be turning BZR into SVN, but oh well...
<dash> Noldorin: that's the entire point :)
<Noldorin> (bound branches)
<mwhudson> Noldorin: well, a bit, yes
<dash> you can treat the results of 'bzr co'  and 'svn co' very similarly :)
<Noldorin> yeah, not that it's entirely a bad thing.
<Noldorin> it should work fairly well while i'm the only dev on this project at least
<Noldorin> dash: yeah, i suspected so
<tsmithe> hi - how would i go about using bzrlib to determine the timestamp of the initial commit of a given file? i've looked around in WorkingTree, Branch and Inventory, and haven't really found anything useful. also, weirdly, bzrlib.log.find_touching_revisions(b, w.inventory.path2id(p)) doesn't seem to work, where "b" is the BzrBranch object, w WorkingTree and p the str path.
<tsmithe> (as in, nothing is returned)
<garyvdm> tsmithe: I would think that find_touching_revisions is the right way to go (or something similar.)
<garyvdm> tsmithe: can you check that bzr log p gives you what you want?
<garyvdm> The last line of the output?
<tsmithe> yes, yes it does. the last line of the output is the commit message for the first commit.
<garyvdm> Ok - let me go look at bzrlib.log.find_touching_revisions
<tsmithe> i created w with WorkingTree.open, and b with BzrBranch.open; both on the same path.
<tsmithe> garyvdm: thanks
<pygi> garyvdm: you managed to review the patch!
<garyvdm> pygi: :-)
<pygi> congratulations :p
<pygi> garyvdm: btw. I found the atl solution ... I think :P
<pygi> jam ^_^
<garyvdm> pygi: I have not done much work on tbzr - so when I review the patch - I was reading the related code - so that I can also get to know it better.
<pygi> I still wish I had time to work on that :-/
<pygi> I think its a bit too complex for no real reason
<pygi> I might be wrong tho
<garyvdm> pygi: Cool.
<pygi> garyvdm: how is that cool? :p
<garyvdm> Pygi - there was a delay - The fact that you may have found a atl fix is cool :)
<garyvdm> The fact the you don't have time to work on it is not :(
<garyvdm> One day I'll invent a machine to give us more hours in a day...
<pygi> well, I've told you I'd use that to guard lambs...
<pygi> enough of technology :P
<pygi> s/take care/guard/
<garyvdm> tsmithe: you can use BzrDir.open_tree_or_branch to open the tree and branch in one command.
<tsmithe> i'll try that; thanks
<garyvdm> tsmithe:  Take a look at _filter_revisions_touching_file_id in log.py
<tsmithe> right, i'll do that too
#bzr 2009-06-05
<tsmithe> strangely, using open_tree_or_branch to simultaneously do the opening doesn't seem to help, and _filter... seems to depend heavily on already knowing the revision id. it seems a lot easier to do this using pysvn, but i suppose that may be because pysvn is an extra abstraction layer.. (and that doesn't help me as i'm using bzr)
<tsmithe> garyvdm: ^
<garyvdm> Yes
<garyvdm> Give me a sec
<tsmithe> no problem
<lifeless> awilkins: pong
<garyvdm> tsmithe: http://pastebin.com/m4e620ab5
<tsmithe> garyvdm: thanks - that didn't work when (as i was doing) i was opening the tree/branch with path "..". however, when i changed to ".", your code worked - so thank you. but that made me wonder whether find_touching_revisions would work in ".". it did. curious.
<Peng_> Hmm, Loggerhead is using more RAM than usual.
<GungaJin> What does '.. will create a repository within the new branch' mean? Aren't branches supposed to be stored IN repositories?
<mwhudson> Peng_: well i don't think _i've_ committed any code for weeks :)
<SamB> GungaJin: I think it means it will put the repository in the .bzr directory that is inside the branch's working directory
<GungaJin> man... it's so confusing that each vcs uses slightly different meanings for the same term...
<SamB> I'm not saying that that's the right way for it to say that ...
<SamB> just that that's probably what was meant
<dash> GungaJin: if they didn't, they'd be the same vcs probably :)
<GungaJin> well, it also says that 'bzr init' makes a directory a versioned branch...
<GungaJin> dash - not necessarily :)
<SamB> could make up new terms
<SamB> or take them all from monty python and red dwarf
<GungaJin> :)
<mwhudson> are you storing your gumby in a shared grail?
<Peng_> You know what's smart? Walking thousands of directories, 3 times. :X
<Peng_> mwhudson: Yeah, you're probably right. :P Let's blame jelmer, since he's not here! :)
<poolie> hello all
<spiv> poolie: hello!
<garyvdm> zzzz - time for bed
<poolie> jml: re review mail, why not open a bug and post the link to the list
<poolie> then maybe once you know, summarize what can be done
<poolie> as a workaround, if anything
<jam> jml: Is 'launchpad' or 'launchpad-code' the right place to submit 'code review' bugs?
<lifeless> lp-code
<igc> morning poolie, jam, all
<lifeless> hi igc
<igc> morning lifeless, spiv
<jam> lifeless: k, launchpad has the tag 'code-review', but I can migrate my bugs as appropriate
<jam> morning igc
<igc> hi jam - really well done of the bencode stuff
<jam> igc: thanks. Now if I can just get the patch to land :)
<jam> Just silly things like having an old GPL header
<jam> or Revision.parent_ids wanting to be a 'list' rather than a 'tuple'
<igc> jam: :-)
<jml> jam: launchpad-code also has the tag code-review
<jml> jam: in any event, you can *always* file bugs on 'launchpad'. matsubara or Ursinha will look at it, triage it & assign to the right subproject.
<poolie> hello igc!
<poolie> hello lifeless
<spiv> igc: Morning, I just reviewed your dirstate patch as it happens :)
<igc> hi spiv, just readng over your comments now
<igc> so spiv, a few things ...
<igc> I did really mean "is not False" - the attribute is tristate ...
<igc> where None means not yet set and False means "don't allow setting to True"
<GungaJin> How can I list all revisions on a branch?
<spiv> igc: hmm
<igc> spiv: and some low level dirstate tests do fail from memory if the limit is non-zero
<spiv> igc: I get that it's a tristate, but in that case wouldn't "is None" fit better?
<igc> I think they make changes and explicitly go and read the file content, or something like that
<spiv> igc: because setting to True when already True is pointless
<jam> spiv: thanks for all your reviews
<igc> spiv: is None would be better
<spiv> If it wasn't used in so few places and in such performance critical code I would've suggested using more explicit symbols for the tristate enum... True/False/None isn't a great fit.
<igc> spiv: I did benchmark keeping the lines around at the beginning, at least in Python code (my pyrex sucks)
<lifeless> dirstate code is fixable now
<lifeless> as we have a C version and a python version
<lifeless> if something canbe cleaner, just make sure that part has a pyrex version, and make the python one as clean as you like
<igc> spiv: it's faster not to do anything unless it's really needed, i.e. leave the reading until we know we need to do it
<poolie> jam: does your custom decoder try using a list rather than a dict?
<lifeless> and the pyrex version can be plan C
<poolie> if you did, it'd be getting fairly close to the minimal bytes, i think
<jam> poolie: The format change I made uses a list
<jam> the custom decoder doesn't use either
<jam> it just sets attributes on self
<jam> and then passes those to a Revision object
<igc> spiv: so my plan was to left the reading until just before we know we're about to make a batch of changes, say
<spiv> igc: fair enough (regarding keeping the lines), it might be worth a brief comment where you re-read them mentioning that, because it's a little counter-intuitive that repeating work is cheaper.
<poolie> i meant a bencode list, like l12:mbp@sourcefrog23:mbp@123g131983712983719837e
<jam> The pyrex bencode just uses whatever you told it to. The "lp:~jameinel/bzr/revision_bencode_decoder" is a more stateful "if key == 'message': self.message = self._read_string()" sort of thing.
<igc> spiv: either way, the current patch is a pretty nice performance improvement and the other smarts can come when I tune commit and other operations later
<igc> spiv: yes, good pointy
<igc> s/pointy/point/
<jam> poolie: Right, so the new disk format is a list of 2-entry lists
<jam> rather than a dict
<jfroy> how do I set the working tree of a branch (in my case a lightweight checkout of a local branch) to a specific revision?
<spiv> jam: Of [['revid', 'foo@bar-123'], ['author', 'Joe Example <...>'], ...] ?
<jam> jfroy: bzr remove-tree; bzr co -r X ?
<jam> spiv: basically
<spiv> jam: IIRC poolie's suggestion was to do away with the key-name elem entirely for the fields that are always present.
<jfroy> jam: what, you have top delete the tree?
<jfroy> there's no equivalent to svn up -r foo
<jfroy> *have to
<spiv> jam: so ['foo@bzr-123', 'Joe Example <...>', ...] for that example
<jam> jfroy: https://code.edge.launchpad.net/~mhammond/bzr/update-r/+merge/6980
<spiv> jam: which makes sense to me; even though the repeated parts should compress wonderfully it's still less raw text to validate when decoding.
<jam> spiv, poolie: So I think we can consider it.
<jam> I kind of like self
<jam> self-describing disk formats
<jam> when possible
<jam> also, it gives me *some* flexibility to change the order if we find something better
<jam> without completely nuking the reader
<jam> though... if we consider the exact bytes to be sanctified, then we'd have to be careful
<lifeless> jam - your read vs readlines tests
<lifeless> jam: are they done on many small files, or one huge one?
<jam> lifeless: that test is on one huge one
<jam> the memory consumption is about how many X we are of the largest file
<jfroy> bahamut$ bzr co -r 769 --lightweight carrier/ carrier-769
<jfroy> bahamut$ bzr revno carrier-769/
<jfroy> 794 <-- :(
<lifeless> jam: I think that test is not representative then. Because we can't really scale up that way anyhow.
<jam> we are pretty good about not holding the content of all files the whole time during commit
<lifeless> I'm about to mail a large file support proposal to the list
<lifeless> would appreciate your critique of it
<jam> lifeless: well, *today* we have about 5x memory overhead for committing the content of a no-eol file
<jam> so a 100MB file => 500MB during commit
<lifeless> jam: yes
<lifeless> and your work is key to making that tolerable
<jfroy> jam: fixing that issue would be awesome
<Peng_> I think Loggerhead is leaking bzr-svn-related things.
<jfroy> I have a few branches that take GBs of real RAM to check out.
<jam> jfroy: I have 2 patches up, which bring it down to 2x for --dev6 formats
<jam> jfroy: checkout != commit
<jfroy> oh? revno gives the tip revno all the time?
<jam> jfroy: 'bzr revno' is the branch revno, IIRC
<jam> not the WT revno
<jfroy> that's correct :|
<jfroy> "This is equal to the number of revisions on this branch"
<jfroy> soooo
<jfroy> bzr st says 'working tree is out of date, run 'bzr update''
<jfroy> bzr info says nothing
<jfroy> ahhh
<fullermd> Surely there's a better way to get a Revision from a revid than doing RevisionSpec.from_string('revid:' + revid), right?
<jfroy> version-info
<jfroy> completely unintuitive name
<jfroy> that command fails
<jfroy> I mean, it's name is a fail
<spiv> fullermd: repo.get_revision(revid)
<fullermd> I can get the repo from a Branch object, right?
<fullermd> jfroy: How funny that you're grumpy about revno right at this moment...
<spiv> branch_obj.repository, yeah :)
<fullermd> Oh, heck, it wants a RevisionSpec...
 * fullermd gets grumpy.
<fullermd> Oh well.  Silliness it is then.
<Peng_> Loading an 8 MB Dozer page is definitelt a good idea.
<Peng_> Such a good idea that I can't spell it!
<thumper> fullermd: why not repository.get_revision(revid)
<fullermd> Because I need a RevisionSpec, not Revision.
 * thumper sees spiv's response
<thumper> fullermd: for what?
<fullermd> Bah, send -o doesn't expand ~.  Hrmph.
<jam> fullermd: "bzr send -o ~foo" would be expanded by the shell, wouldn't it ?
<fullermd> Probably, but -o~foo isn't.
<jam> I suppose -o~foo might not
<fullermd> thumper: for https://lists.ubuntu.com/archives/bazaar/2009q2/059119.html
<fullermd> jfroy: See ^^
<spiv> fullermd: I wonder what happens if the current revid no longer exists on branch (e.g. make a lightweight checkout, then someone else uncommits the tip, then you try "bzr revno --tree" in the checkout)?
<jfroy> fullermd: eh
<jfroy> good enough
<jfroy> fullermd: you could add a "--both" flag
<jfroy> which would be suitable for an alias
<jfroy> like "revnoa" or whatever
<jfroy> (a -> all)
<fullermd> spiv: Not sure.  revision-info blows up in such cases...
<Pegasus_RPGAMD64> hello. If I've checked out a branch anonymously, what's the command to authenticate so I can check in?
<fullermd> jfroy: Well, _you_ could.  I just blew my bzr time for the rest of the month on that   :p
<spiv> fullermd: I'm not surprised...
<fullermd> Presumably version-info should grow something similar too...
<fullermd> Actually, version-info probably should DEFAULT to the tree rev, considering its aim.
<spiv> fullermd: makes sense to me, but I probably lean towards making revno and revision-info default to the tree rev too...
<fullermd> I wouldn't argue against that.
<fullermd> Having the option at least cuts down on my grumpiness a bit anyway.
 * igc lunch
 * spiv -> food, etc
 * spiv hopes this vicious sore throat goes away soon
<Pegasus_RPGAMD64> oh found it...bzr bind bzr+ssh://...
<Peng_> mwhudson: ping
<Peng_> Actually, I don't really need to ping you.
<jml> poolie: you available for a bzr related call?
<mwhudson> Peng_: :)
<Peng_> mwhudson: Running Dozer is fun! Especially the 20 MB page listing all of the lists! :D
<Peng_> Loggerhead seems to be leaking some bzr-svn-related stuff.
<Peng_> From when it scans the directories for branches.
<mwhudson> that sounds vaguely familiar
<Peng_> Yeah, it does.
<mwhudson> also, i'm tempted to say, NFM
<mwhudson> NMF
<Peng_> NMF?
<Peng_> Oh.
<Peng_> :D
<Peng_> If one of you enjoys looking at Dozer output for some strange reason, http://bzr.mattnordhoff.com/loggerhead/_dozer/index :D
<Peng_> A few hundred subversion-related things shouldn't account for much RAM, should it?
<mwhudson> depends what the things are, but no, not really
<mwhudson> Peng_: have you seen jam's py_mem_profile thingy?
<Peng_> mwhudson: SubversionAuthenticationConfig and SubversionException, FWIW.
<mwhudson> Peng_: those sound small indeed
<Peng_> mwhudson: I might've read the email, but normally I'm not interested in memory profiling, so I don't remember it.
<Peng_> Eh, I think the garbage collector keeps doing its job, making it difficult to analyze this. :P
<Peng_> Anyway!
<jml> spiv: thanks!
<spiv> jml: np
<spiv> jml: (although I'm not sure if my commit rights are adequate to land something on bzr.1.15, but I guess we'll find out soon...)
<jml> :D
<poolie> spiv, i think i asked spm to make access to all branches the same
<poolie> at any rate i don't see much value in having different privilege levels
<spm> spiv: poolie: we have 2 groups: bzr and bzr-release-mgr. bzr can ci to trunk; release manager to the versioned branches. aiui, it's been that way for a long time. it may be worth collapsing those to a single group? and/or revisiting the membership?
<spiv> spm: I think it's probably ok to let any committers commit to all branches, but poolie gets the final say.
<spm> spiv: given the trivial diff on those two groups? I'd agree; but as you say :-)
<spiv> For me the convenience of allowing a dev to cherrypick and land their own fix probably outweighs the "only RMs are fully trustworthy" paranoia.
<spiv> And yeah, given that most devs have also been RMs at some point I'd expect the difference between the two groups to be minimal (and confusing)
<spiv> jml: (it looks like PQM likes me)
<lifeless> there are only two groups because when I asked martin 'who do you want to be able to commit to <first release branch> he named a subset
<lifeless> its trivial to make it just one group
<jml> spiv: :)
<Peng_> So...the bencode repo format had worse performance than RIO, right? Why was it chosen?
<lifeless> igc: your dirstate patch
<igc> hi lifeless
<lifeless> igc: does it actually make saving faster, or does it just save under less circumstances, or both ?
<igc> both
<lifeless> cool
<lifeless> did my suggestion make sense?
<igc> yes, I'd liked it and it would be enough for status
<igc> i.e. for faster status
<lifeless> now
<lifeless> I have a planned change to dirstate
<lifeless> for windows
<lifeless> that will interact, do you have a minute to chat regarding this
<igc> sure
<lifeless> so to meet the dual constraints of windows fs limitations and bisection (for insanely fast 'st foo') I've proposed removing the single dirstate file
<lifeless> instead have a current pointer
<lifeless> and a directory of dirstates
<igc> ok
<lifeless> so we'll write to a new file when we do an update
<lifeless> and then link it into current, try to remove the stale one and  if that fails assume another process is currently using it
<igc> don't we write the lot out again anyhow now?
<lifeless> yes
<lifeless> a related but more complex change we could make
<lifeless> is to go to some sort  of journalling system
<lifeless> I don't think we have the time to do that for 2.0
<lifeless> but we do, if we focus, to do the simpler change of having a current pointer and many full dirstates
<lifeless> it may be that this doesn't really interact with your code at all; in which case cool
<lifeless> but I thought it was worth running it up the flagpole
<igc> lifeless: I think my change is independent and won't clash in any way
<lifeless> cool
 * spiv -> giving up for the day.  Have a good weekend everyone.  I should be over ubuflu by next week :)
<jfroy> bah!
<jfroy> cherrypicking is maddening
<jfroy> is there a revspec to specify "revision xyz up to tip of target branch"?
<jfroy> -r xyz.. does... bad things
<lifeless> jfroy: that should work fine; can you expand on bad?
<jfroy> it goes crazy and conflicts to all hell
<jfroy> I just want to merge the last 2 revision of A into B (A was branched from B)
<lifeless> well, its possible that the conflicts are genuine
<lifeless> do you get them if you apply the revisions as plain patches, or something similar?
<jfroy> No, there's no way those 2 revisions would conflict.
<jfroy> And not in the manner it's doing.
<jfroy> I'm getting content conflicts, file deletes and renames.
<jfroy> Those 2 revisions are simple edits to a few files.
<lifeless> sounds like the files were added independently to A and B
<lifeless> so bzr thinks they are different files that happen to be at the same path
<jfroy> B was branched from A.
<jfroy> and has 5 revisions more than A.
<jfroy> I want to bring the last 2 into A.
<jfroy> (skipping over the first 3)
<lifeless> I get that from your prior explanation. However, if you are getting content conflicts it [insert my 'sounds like' above]
<lifeless> spiv: you should be able to use pqm with lp branches now
<fullermd> A quick way to verify that it's not the .. would be to cherrypick the revs individually and see what you end up with.
<lifeless> jfroy: you can use 'bzr inventory --show-ids' to debug this
<jfroy> I'm pretty sure I'm just being stupid
<jfroy> with the merge command
<jfroy> and not understanding revspecs :/
<lifeless> jfroy: no, I think its something else. Humour me.
<jfroy> yeah, doing two merge with -c x and -c y worked fine
<jfroy> (where x < y and {x, y} are the last 2 revisions of the merged branch)
<lifeless> jfroy: ok, please file a bug
<jfroy> so, should merge -r x.. do the same merge>
<jfroy> *?
<lifeless> roughly
<lifeless> uhm, it won't include x
<lifeless> merge -r {x-1}..
<lifeless> the range x-1..x == -c x
<jfroy> yeah, that has a completely different outcome
<jfroy> whoa
<jfroy>   revision_id = _mod_revision.ensure_null(revision_id)
<jfroy> ...
<jfroy> thank you IRC
<jfroy> bzrlib/repository.py:2308: DeprecationWarning: NULL_REVISION should be used for the null revision instead of None, as of bzr 0.91.
<jfroy>   revision_id = _mod_revision.ensure_null(revision_id)
<jfroy> the merge basically deletes most of the files in the branch
<jfroy> however, -r (x-1)..y works fine
<lifeless> jfroy: definitely file a bug
<jfroy> will do
<lifeless> poolie: so 2.0
<lifeless> poolie: I agree we need eye on the prize; heck I've been chanting that mantra
<vila> hi all
<lifeless> poolie: but the total lockdown on formats (thanks jml btw, I hear thats your idea) means there will be an awful long time before things we fix shortly after are made available to users.
<poolie> hello vila!
<poolie> lifeless: let's not overcatastrophize the format thing
<lifeless> hi vila
<poolie> it's been a mess, it needs to be better, but we don't need to do anything stupid to just have less active formats
<lifeless> poolie: I don't mean to. Its unclear what we're signing up for is all; I know I'm not alone expressing concerns here.
<poolie> ok
<poolie> noted
<poolie> i have a sinking feeling about answering that mail on the list because it may cause a lot of partly-constructive chatter about the best way to develop software in general
<vila> igc: I have some troubles with usertest: 1) selftest is not passing, 2) I get http://paste.ubuntu.com/188798/
<fullermd> Obviously, the best way to develop software in general is to use bzr   8-}
<lifeless> actually, ignore my concerns here. Mark asked for one format in 3.0
<lifeless> poolie: and sure, we need to batch things up into larger amounts, get more network independence etc.
<lifeless> ok, I'm going to halt() now
<poolie> i guess briefly i see it as being a lot like an individual release
<lifeless> still somewhat sinusy but nearly well
<poolie> i'd desperately like to fix all the things you name
<poolie> but should we slip 1.16 til they're done? probably not, there's good stuff to get out
<lifeless> poolie: marks mail, april 16th or so 'scoping the ui...' talks about 3.x
<lifeless> poolie: I had confabulated that to be 2.x in my head
<lifeless> in 2.x we should do better than we have with plethora-of-formats
<poolie> i said the same thing to him, that though i'd love to do them we need to get 2.0 out
<lifeless> in 3x we're being asked to have one format for the life of the 3.x series
<fullermd> Just killing off poor roots takes care of probably 75% of that right there...
<poolie> the main point is: there should be a clear moment at which we have a new format and migrate people on to it
<poolie> we should not do it every two months, but if it turns out that by the end of 2009 say we have great new work that requires a new format i'm happy to call that 3.0
<poolie> i guess the secondary point is: somewhat larger steps, rather than dribs and drabs
<poolie> but that can be guided by experience
<h6w> Hey, what should I use to provide public access to my bzr+ssh repos?  For our svn repos we used the subversion apache module.  Is there one for bzr, too?
<vila> poolie: which is the whole point IMHO. That mail doesn't seem to take into account many decisions, already agreed upon by the team, but maybe not visible enough yet.
<vila> i.e. we don't want to get into rich-root/non-rich-root divergence ever again
<vila> for example
<lifeless> poolie: so what I'm saying is broadly 'yes', but that 3.x should be more guided by 'we think we have a <good period> of breathing room', and that during 2.x we can issue new formats still
<lifeless> poolie: [if we feel the tradeoffs are worth making]
<vila> lifeless: +1
<vila> forbiding experiments is definitely  counter-productive (as long as they don't make our users cry)
<lifeless> vila: I don't think anyone is suggesting forbidding experiments
<vila> a single dev format may restrict them a lot
<lifeless> vila: I don't think so; we should do them outside of core until we are fairly convinced, then roll them into the dev format.
<lifeless> vila: this is a constraint for 3.x; so we should get comfortable with it during 2.x
<vila> lifeless: outside of core as much as possible, I agree with that, I'm not sure *what* territory is covered by that though
<lifeless> vila: My feeling is that its tied to the size and scope of the change.
<lifeless> tweaking an API - short lived branch.
<lifeless> changing how big files are stored - plugin or long lived loom with the bits that we're sure of merged
<vila> I'm thinking about ubuntu as a branch and all installed packages as subtrees. status (implicit or explicit) may become to slow if recursion is on by default. That kind of problem is likely to have a lot of deep implications, to the point we may want to introduce some index (a la git),
<vila> now, we can introduce hooks where needed and still be able to do that from a plugin, but I don't think that will make it easier
<vila> s/to slow/too slow/ of course
<awilkins> lifeless: Did you read my post to the list about pbranches style branch management? Do you think it's feasible?
<lifeless> vila: so I think there are two things there; I've argued for a long time that working from '.' by default would be better. Anyhow if you have ubuntu in a single huge tree, status from . would be doable quickly via dirstate bisection
<lifeless> vila: separately, there is 'what is involved in doing status across subtrees'.
<vila> I was thinking about scanning the whole tree to update the dirstate with a tree that will trash the cache
<lifeless> vila: bzr status main/coreutils would only scan main/coreutils in the cache
<lifeless> and probably not pass the threshold to trigger a save
<lifeless> vila: and with subtrees coreutils would be a separate tree anyhow
<lifeless> vila: so there are two separate places we'd be listing all the subtrees:
<lifeless> a) dirstate
<lifeless> b) repository
<lifeless> they have different IO/compression needs. But nevertheless, what do you think we'd need to index?
<lifeless> awilkins: I saw it, haven't absorbed it. I think loom is not finished.
<lifeless> awilkins: and that many issues related to it are due to it not being finished, not due to the design.
<lifeless> awilkins: and further to that, that the design likely needs improving.
<vila> We tend to encourage a model where the user relies on bzr to check that it doesn't forget a modification when committing. So at some points, scanning the whole tree is required. We may transfer part of that check responsability to the user so that he decides to avoid scanning the subtrees
<lifeless> awilkins: I'm not at all convinced that heuristic full-topological support is good or needed. I think its hugely complex.
<lifeless> vila: abentley describes this as 'recursing upwards' in the nested tree docs.
<lifeless> vila: deciding whether in coreutils needs to go upwards *could* be policy. Or it could just never do it.
<vila> recursing upwards sounds evil to me, but I see where it can help here...
<lifeless> vila: so to commit a snapshot of all of ubuntu you'd explicitly cd to the root and commit
<vila> lifeless: got it
<lifeless> vila: [oh, and commit --norecurse or whatever would then just grab the last revid from subtrees rather than tryin to commit in them]
 * lifeless halts() for real
<vila> lifeless: that's evil too :-)
<vila> but a strange idea just came up: I think file system should handled a 'last modification date' for the tree (as opposed to the dir), but I don't hold my breath about that. Yet, that's basically what we need, so how about creating/deleting a file in the top level directory when we update the dirstate and use that as an hint ?
<vila> That's not perfect, but that will curely covers many needs...
<poolie> i really want to talk about the format thing but my batteries are going flat
<vila> poolie: plug yourself ! Enjoy your week-end :)
<jml> btw,
<jml> some people were asking a while ago about how to tell Launchpad to mirror a branch right away
<jml> http://paste.ubuntu.com/188831/ sketches out how to do that.
<fullermd> If you stay half-asleep all the time, is that like float-charging your batteries?
<jml> it relies on a branch of launchpadlib that I've written.
<vila> fullermd: staying half-awake all the time is very bad for battery life, go get some sleep :-)
<fullermd> I can't!  All the Canonical people are still oversleeping from ubuflu, so I'm stuck on short-time to keep the balance   :(
<vila> fullermd: it's ok, I catched up from ubuflu, I'll take care of the balance :)
<awilkins> ubuflu? Sounds like a disease that afflicts the dog that appeared at the end of the A-Team
<awilkins> "Sit Ubu, sit!"
<fullermd> I pity the flu.
<poolie> night all
<igc> night all
<Peng_> igc: Good night.
 * fullermd thinks that's quite enough hackage for one night...
<fullermd> Hm.  I have selftest failures...
<fullermd> test_two_files_different_versions_no_inconsistencies_bug_165071 fails for me on RepositoryFormat's 5, 6, and 7.
<wam> Hi, can I checkout all branches in a repo easily?
<bob2> not really
<jpds> wam: You mean all branches in a code.launchpad.net team's page?
<wam> so if you have a repo with several branches and want them all on your local dev folder too, do you just create a folder and co all branches seperately or do you bzr init-repo instead of mkdir?
<wam> jpds: don't know - I just have a repo with some branches and would like to checkout them all
<awilkins> You should init-repo
<wam> ok
<awilkins> Otherwise you will waste a lot of bandwidth
<bob2> if they are related
<bob2> (as in branches of each other)
<wam> awilkins: ack
<vadi2> jelmer: I've done svn-import on the svn repository on the server now, but it is complaining that what it got is not a branch: http://paste.pocoo.org/show/121138/
<RockyRoad> Hi  :)
<jelmer> vadi2: That's right, it would have imported several branches
<jelmer> vadi2: they're subdirectories of yorba4/
<vadi2> ah.
<RockyRoad> Would there be a way to set the "ancestor" of a branch, in order to do some later merges ?
<RockyRoad> My problem is somewhat similar to http://fourkitchens.com/blog/2009/01/19/creating-common-branch-ancestry-hard-problem
<RockyRoad> I'm pretty new to bzr but I'm trying to manually rebuild a project history from { CVS, then BZR }, to BZR.
<RockyRoad> I finished the CVS part, in a new project, call it B, at rev 10.
<RockyRoad> The project contents at B rev 10 is identical to initial commit of project A.
<RockyRoad> I pushed a copy of previous branches, in project A into project B, branch B.A .
<RockyRoad> Now the problem is that I can't merge any revision of B.A into B.trunk, bzr tells me: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<RockyRoad> I could do "bzr merge -r 1..2 lp:branchB.A"
<RockyRoad> there were conflicts, but I could resolve and commit.
<RockyRoad> but the problem remains for later merges, the branches are still not linked.
<jelmer> RockyRoad: I think you'd want -r0..2
<jelmer> what you were diong was a cherrypick, and bzr doesn't track cherrypicks yet, only "full" merges
<RockyRoad> jelmer: thanks, I didn't try that yet
<RockyRoad> 0..1 would work also ?
<RockyRoad> mmm there's something strange with revert
<RockyRoad> it modifies the files, and lets the revno unchanged
<RockyRoad> then a commit increases revno
<jelmer> RockyRoad: yes, that's intentional
<vadi2> jelmer: thank you!
<RockyRoad> jelmer: no way to go back ( I've pushed it to lp also :( )
<RockyRoad> ?
<RockyRoad> I tried uncommit earlier, and it doesn't work
<Peng_> jelmer: ping
<jelmer> Peng_: pong
<jelmer> RockyRoad: uncommit should take you back
<Peng_> jelmer: Hi. :) Um, I'm kind of sleepy, but earlier I noticed that Loggerhead is leaking SubversionException and SubversionAuthenticationConfig/
<RockyRoad> sorry to bother you with what you probably think basic
<Peng_> jelmer: (Seemingly from the code that scans directories for branches.)
<Peng_> Or something.
<RockyRoad> oh ... that's a "bzr revert" I need after uncommit !
<jelmer> Peng_: please file a bug
<jelmer> Peng_: leaking in what sense, btw ?
<Peng_> jelmer: Against which project?
<RockyRoad> the bzr pull "tip" confused me ....
<Peng_> jelmer: In the sense that it's the only suspicious thing I found in Dozer.
<jelmer> Peng_: depends, what sort of leaking is happening?
<Peng_> jelmer: I don't know. I'm dumb. But an ever-increasing number of them, currently 652, can't be good.
<Peng_> Hmm, I think it was 673 earlier.
<jelmer> Peng_: how are you seeing this?
<Peng_> jelmer: Dozer.
<Peng_> Oh, 832.
<Peng_> jelmer: http://bzr.mattnordhoff.com/loggerhead/_dozer/index
<RockyRoad> to resolve conflicts I need to specify each filename, is it normal ?
<Peng_> http://bzr.mattnordhoff.com/loggerhead/_dozer/trace/bzrlib.plugins.svn.auth.SubversionAuthenticationConfig http://bzr.mattnordhoff.com/loggerhead/_dozer/trace/subvertpy.SubversionException
<jelmer> RockyRoad: you can also use "bzr resolved --all"
<Peng_> I thought --all was the default.
<RockyRoad> ah  ... thanks again jelmer
<RockyRoad> jelmer: I'm not sure I "resolved" the conflicts the right way: current status shows all files renamed to *.moved, and the working files added
<RockyRoad> would the link between branches be lost if I cancelled this rename operation ?
 * Peng_ leaves.
<kirkland> hiya, vcs-import issues ....
<kirkland> https://code.edge.launchpad.net/~vcs-imports/qemu/qemu-kvm
<kirkland> wgrant pointed me here :-)
<LarstiQ> right
 * LarstiQ frowns at wgrant ;)
<kirkland> heh
<wgrant> LarstiQ: It's clearly a bzr-git issue, though.
<LarstiQ> kirkland: in this specific case, you don't want to ask about your vcs import
<LarstiQ> wgrant: yes, gimme a sec :P
<kirkland> LarstiQ: okay, i won't ask about my vcs import
<LarstiQ> kirkland: you want to ask jelmer about the bzr-git issue displayed
<cody-somerville> jelmer, Were you able to fix my bzr-git issue yet? ;]
<LarstiQ> kirkland: the bzr-git author can't jiggle the vcs-import, but he _can_ fix the upstream bzr-git problem
<kirkland> LarstiQ: cool, thanks.
<kirkland> jelmer: issues bzr-git importing qemu-kvm :-)
<jelmer> kirkland: I think that one is actually fixed but waiting for launchpad to upgrade to a newer bzr-git
<jelmer> cody-somerville: not yet, sorry
<kirkland> jelmer: cool, thanks
<kirkland> LarstiQ: back at you :-)
<LarstiQ> kirkland: my work is done I think, back to wgrant ;)
<kirkland> LarstiQ: heh
<cody-somerville> jelmer, Is there any way I can bribe you to fix it sooner? ;]
<LarstiQ> kirkland: or well, someone from lp vcs-imports, mwhudson maybe
 * wgrant is tempted to bounce it to CHR :P
<kirkland> LarstiQ: thanks; and that goes in #launchpad or #bzr ?
<wgrant> #launchpad
<wgrant> vcs-imports is a Launchpad thing. It just happens to use bzr.
<jelmer> cody-somerville: can you donate me some spare time ? ;-)
<cody-somerville> jelmer, That I don't have any of
<vila> RockyRoad: the link would not be lost, but the branches don't know that they are talking of the same files. When your resolve a name conflict (the ones that produce the .moved files), you're telling bzr which file you keep.
<vila> s/talking of/talking about/
<RockyRoad> vila: I could not revert renaming ... not sure now when
<mario_> hi folks, how are you doing?
<vila> RockyRoad: to track renames, bzr gives a file-id to each file when it first encounters it
<RockyRoad> I checked that there was no diff between .moved and main
<vila> RockyRoad: since you created your two branches indenpendently, the files are different as far as bzr is concerned
<RockyRoad> so what should I have done ?
<vila> if you intend to continue using the two branches, you'd better recreate the smaller one from the bigger one
<RockyRoad> why ?
<RockyRoad> oh sorry
<RockyRoad> did read correctly
<RockyRoad> didn't *
<RockyRoad> :D
<vila> RockyRoad: because further merges will respect your conflict resolution so the only changes that will be taken into account will be the ones to the file you kept (but some changes may lead to the same kind of conflict)
 * RockyRoad needs to read that a couple of times ...
<vila> RockyRoad: even better, try it with dummy branches
<RockyRoad> vila: I'm a bit lost. Did you read above what I'm trying to do (11:46 GMT) ?
 * vila re-reading that and the blog post you refer to
<RockyRoad> the blog talks about file-ids, doesn't give a solution
<vila> RockyRoad: well, in the general case, file-ids (in addition to tracking renames) guard against two people creating the same file for different purposes, clearly a conflict
<RockyRoad> then how do I tell bzr that 2 files are the same
<RockyRoad> ?
<RockyRoad> ( they are indeed )
<vila> you can't :-/
<RockyRoad> and the merge generated conflicts
<RockyRoad> So I couldn't have avoided the renames ?
<RockyRoad> The result is not bad however, according to bzr viz
<RockyRoad> the old branch revisions show up with a 0. prefix
<ddaa> actually, there are very good reasons that you cannot track renames, do merging and tell a vcs that two files created independently are the same.
<RockyRoad> and connected to whole history :)
<vila> RockyRoad: you could have avoided the renames by using the same file-id at 'bzr add' time by using the --file-ids-from
<ddaa> occasionally, you brash dvcs developper think they can solve the problem, and they body is usually found deep in a jungle of corner cases, their body devoured by cannibals.
<ddaa> s/you brash/a young branch/
<ddaa> s/young branch/young brash/
<ddaa> however, there's one thing that should be possible
<vila> RockyRoad: I realize that sounds a bit un-natural, but building history backwards is certainly not dvcs strong point (for any value of dvcs except darcs :-)
<RockyRoad> yep I thought it would be easier when I started ;)
<ddaa> which is define equivalence classes between files, to avoid repeated merge conflicts, but that would still lose a lot of annotate and log information.
<ddaa> vila: I'd be curious to learn something about the darcs2 model. I heard that they backtracked on most of the patch algebra magic kool-aid.
<ddaa> but it's kinda hard to come up with good "explanation for dvcs geeks" type of documentation for anything
<vila> ddaa: all my darcs knowledge is by darcs users, I've yet to encounter a darcs2 user :-)
<RockyRoad> vila: I never used bzr add in that case. The merge command caused it, with the renames.
<vila> RockyRoad: I understand that, but the '--file-ids-from' option exists only for bzr add :-) It would be highly non-trivial to add it to merge :)
<ddaa> s/highly non-trivial/so complex that nobody could even tell whether it's correct/
<RockyRoad> oh so your answer was more general than my case ...
<vila> RockyRoad: it's the closest I could think about avoiding creating two file-ids for the "same" file
<RockyRoad> It's very interesting.
<vila> Adding the option to fast-import may be easier and more useful though
<RockyRoad> My main point was to link the branches. It succeeded. Avoiding renames was more a theorical question
<vila> It may still need some help from the user if the file has been renamed since it enters bzr, but that may be manageable for small to medium sized project
<vila> RockyRoad: Oh yes ! You don't intend to update the old branches anymore !
<RockyRoad> no
<RockyRoad> it's more "memory"
<RockyRoad> s/more/for/
<vila> So have a look at 'bzr annotate' for the conflicted files, you may have lost some per-file history even if you still have a complete tree history
<vila> lost being too strong here, disconnected is closer
 * RockyRoad never used annotated yet
<vila> RockyRoad: did you merge the "old" into the "new" or the opposite ?
<RockyRoad> the old into the new
<vila> RockyRoad: Right, so if you're happy with what 'bzr qlog' or 'bzr viz' show, it's the best you can achieve
<RockyRoad> but new=B , which has history before the new ... quite complicated ;)
<vila> Well, it means the "old" history (with the 0. prefix) now appears as merged recently instead of preceding revision 1
<RockyRoad> yes
<vila> And that's exactly what you did (from bzr point of view) even if it's not exactly what happened
<RockyRoad> the newly created project then only described revisions actually older than the 0. branch
<RockyRoad> I'll add newer revisions after
<RockyRoad> bzr rocks :)
<beuno> It sure does!
<vila> :-)
<ddaa> RockyRoad: hint, try typing "bzr rocks" in a terminal.
<RockyRoad> Now next step should be fun: in project A the main branch had been itself split in two, each one doing some merges from the other ...
<RockyRoad> :)
<vila> beuno, get out of RockyRoad computer will you...
<RockyRoad> I wondered if he was a bot :D
<vila> jelmer: your 'Fix version in dev7 string' bundle is an empty patch
<jelmer> vila: yeah, Aaron already mentioned that as well
<jelmer> vila: I'm going to send an updated bundle soon
<vila> jelmer: sorry for the noise then
<vila> RockyRoad: the day bots are as full of life as beuno I buy one just for fun :)
<vila> a bot, not a beuno
<RockyRoad> lol
 * beuno for sale, only $699!
<vila> beuno-like-bots, the anti-HG2-Marvin :)
<gioele> hello
<ddaa> Anyone can point me to the part of the documentation that explains how to set up rule-based default push locations?
<ddaa> http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#configuration-settings
<ddaa> the ref manual is great, but it's hard to browse and not very link-friendly
<gioele> I want to use bzr to track binary large files with rare changes. Which repository format do you suggest?
<pygi> gioele: possibly brisbane core, as it'll be the only one supported in 2.0 as stable?
<gioele> pygi: I don't see brisbane-core as a good choice until 2.0 is released
<vila> ddaa: you should use locations.conf and the magic bit is push_location:policy = appendpath
<ddaa> Yep, I figured it all out. Thanks.
<ddaa> I was mostly complaining at how hard it is to locate this piece of information.
<ddaa> Although it's a bit of major bzr coolness.
<vila> gioele: if you prefer to stick with default formats, just use the default format. brisbane-core will help a bit, but large binary files with few changes are still not optimally handled anyway
<vila> ddaa: patches welcome ! :-)
<vila> jam: ping
<jam> hey vila, I'm going to be afk for about an hour
<jam> anything i can help you with quickly?
<ddaa> vila: maybe one day the formatting of the documentation will cross my itching threshold and I'll get the source and fix the stylesheet.
<gioele> vila: I suspect large binary files are not a priority, even for 2.0. Isn't it. It is understandable
<vila> jam: lol, right, so I'll call you next week
<jam> :)
<jam> yeah, we should get another phone call in. Want to say this time Monday?
<jam> (I could even go ~1 hr earlier if that works better for you)
<vila> jam: could that be one hour earlier... I hate it when you read what I typing before receiving it :-)
<vila> jam: I'll call you directly Monday then
<jam> k
<dash> good morning
<dash> i'm getting an exciting error from bzr svn-import
<dash> (which Twisted uses to mirror its svn repo into bzr branches)
<dash> http://pastebin.com/m7d105357
<dash> think updating to the latest version will be enough to remedy this?
<jelmer> dash: not sure
<jelmer> dash: could be
<dash> i suspect the culprit here is that I resurrected a deleted branch
<dash> at least, that's the only unusual thing I can think of here
<VSpike> Hi. I having a problem renaming a file that is shown as removed. It complains that the original is not versioned. http://pastebin.com/m1712a43e
<VSpike> Any ideas?
<dash> hmm. seems to give the same error on 1.15 and 0.6.1
<dash> would it help or hurt to use 'bzr branch' to import that branch into the repo?
<jelmer> dash: please file a bug
<dash> alrighty
<VSpike> Am I missing something really simple here?
<jelmer> VSpike: I think you need "bzr rename --after" or something like that
<dash> jelmer: #383980
<VSpike> jelmer: bzr rename is a synonym for "mv" and "move".  Also, if the old file is missing and the new file exists, it assumes --after
<VSpike> jelmer: that said, I've tried mv and rename, both with and without --after
<VSpike> jelmer: I did a whole set of them and that is the only one that failed
<dash> hm
<dash> looks like explicitly grabbing that branch made it work again
<ddaa> Ooooh
<ddaa> Now bzr log --line automatically add the [merge] tags
<ddaa> that I used to put in my commit logs for merge ever since... gnu arch...
 * ddaa claims fatherhood of this idea
 * mneptok files for child support
<ddaa> Come on, you could not tell a dvcs from a pot bong at the time!
<mneptok> is the "dd" in your nick for "Deadbeat Dad?"
 * ddaa admits he's got only the foggiest idea what "child support" and "deadbeat parent" mean and how that relates to anything.
 * ddaa uses google
<ddaa> mneptok: you can freely use my legacy in launchpad-bazaar code to support this child.
<mneptok> ddaa: great. more orphans. ;)
 * mneptok hugs ddaa 
 * ddaa hugs mneptok
<mneptok> et ... ca va?
<ddaa> on fait aller
<ddaa> resigned from the bank
<ddaa> working at home on some start up business
<ddaa> hence irc
<mneptok> excellent. best of luck, and have fun!
 * mneptok is sitting waiting for a .fi phone call before dealing with a bank
<RockyRoad> Hi again :)
<RockyRoad> I'm trying to compare revisions of different branches, something like (from branchB directory)
<RockyRoad> bzr diff --old=revno:5:lp:branchA --new=revno:6
<RockyRoad> what's wrong ?
<RockyRoad> without filename, I get no result , and with I get "Path(s) are not versioned"
<RockyRoad> I probably misunderstood the doc
<RockyRoad> this revisions identifiers
<RockyRoad> I tried also to replace lp: with bzr+ssh:/bazaar.launchpad.net , no luck
<jfroy> hello people
<jfroy> any recommendations on a tool to browse revisions across many related branches
<jfroy> well, more specifically, I'm interested in finding the set of revisions in a certain branch that have modified a certain set of files.
<jfroy> Wondering what tools are available to accomplish that.
<RockyRoad> I would do it from xmloutput + xpath ...
<RockyRoad> does it help jfroy ?
<jfroy> I'm not sure :p
<jfroy> Wish I had something like github's history view right about now >.>
<james_w> jfroy: qlog from qbzr can do some things like that I believe
<jfroy> yes, I've been using that
<jfroy> it's mostly working as expected
<jfroy> but it's not "great"
<jfroy> this stuff needs to be brought into Loggerhead...
<james_w> I agree
<jfroy> ok, let's try to be more simple
<jfroy> is there a tool / command to list all revisions in a branch that have touched a specific file
<jfroy> duh, log
<jfroy> brain not working right today
<ddaa> oh another thing where bzr is better than hg
<ddaa> bzr log is useful to see in which files were renamed
<ddaa> while hg log only present renames as add+remove.
<awilkins> Does Hg have copy?
<awilkins> Bazaar doesn't have copy
<ddaa> I do not know that it has copy. So I would guess it does not have it.
<ddaa> Otherwise I think I'd have heard of it.
<ddaa> I'm just inclined to think their "rename support" is just a quick patch over an anterior data model that did not support it.
<ddaa> But I'd love to be proven wrong.
<LarstiQ> I believe hg has copy
<LarstiQ> ddaa: hg blame -fun file
<LarstiQ> not exactly showing renames, but can help answer some of the same sort of questions
<ddaa> oh right, hg has copy tracking
<ddaa> I stand corrected.
<ddaa> now, I wonder how they handle that in merges
<ddaa> I believe one reason bzr does not have copy is there is no one right way to handle that in merges.
<ddaa> Actually no, since bzr has a real rename, it can decided just not to propagate changes across copies on merge.
<ddaa> But since hg does not have a real rename, I wonder what they do.
<LarstiQ> ddaa: one reason bzr does not have copy tracking is indeed because no consensus has been reached (or implementation) on how to handle copies on merges
<ddaa> I know it's beating a dead horse, but we could just decide NOT to propagate them.
<ddaa> it's simple to implement, unsurprising, and does to exclude other added value of copying: better log and annotate.
 * ddaa reflects that apparently his year at the bank taught him a lot about taking SOME decision on complicated technical problem.
<ddaa> s/does to exclude/does not exclude/
<LarstiQ> ddaa: I very much agree on the importance of taking decisions
 * LarstiQ is not an interested party when it comes to copy tracking though
<ddaa> it's quite important for bzr-svn
 * LarstiQ nods
<LarstiQ> yeah, that's the main driver I'm aware of
<ddaa> Oh also, another thing where hg sucks: it has non-standard option parsing: you cannot add options after positional arguments.
<ddaa> maybe not non-standard, but at least non-gnu.
<LarstiQ> old-style unix though
<ddaa> let them use sh, nvi, and rcs then!
<LarstiQ> where I hate that the most is in scp
<LarstiQ> scp file host: -l login? nooo
<ddaa> scp is a bit of a world unto its own when it comes to command-line parsing
<ddaa> would be nice if could catch up with the last 10 years in internet protocols development and support URIs...
<Youssef> hi all
<Youssef> I have a question
<LarstiQ> Youssef: sure
<Youssef> its about the documentation
<Youssef> I have made a user guide of Bazaar for windows
<Youssef> okay
<Youssef> and I will publish it over internet
<Youssef> but
<Youssef> i took 2 or 3 picture from the official website
<Youssef> do i have permission?
<Youssef> to do that?
<Youssef> LarstiQ ?
<Youssef> brb
<beuno> Youssef, sure, that's fine
<Youssef> really?
<Youssef> cool
<Youssef> thanks a lot
<Youssef> ++
<LarstiQ> gah
 * LarstiQ wanted to ask if he could at least mention it, if not contribute it back
<beuno> sorry  :)
<joschan> Hi. Is there s way to make a graphical represntation of my branches?
<beuno> joschan, using bzr-gtk
<beuno> you have "bzr viz"
<joschan> that's new? i have 1.12
<LarstiQ> joschan: it's old, but it requires the bzr-gtk plugin be installed
<LarstiQ> joschan: or the qbzr pluing for qlog if you prefer
<joschan> oh i am on windows. i need a linux machine with gui i see - thank you
<LarstiQ> joschan: no, qbzr is bundled with the Windows installer
<joschan> is there a way to just generate jpg files or something?
<LarstiQ> joschan: and you can run bzr-gtk on windows too
<LarstiQ> joschan: try `bzr qlog`
<joschan> LarstiQ: i get a gui on windows yes!
<LarstiQ> joschan: good :)
<pygi> LarstiQ: so-so, not perfectly yet
<pygi> (bzr-gtk on win)
<LarstiQ> pygi: it's not trivial, but it can be done
<pygi> LarstiQ: it will be trivial by the time 2.0 is out
<pygi> (or at least I hope so)
 * LarstiQ prefers more effort being put into qbzr/tortoise though
<LarstiQ> pygi: how are you going to accomplish that?
<ddaa> esp. tortoise
<pygi> LarstiQ: easy, by building a easy win installer for bzr-gtk :)
<ddaa> some people won't touch a vcs with a ten-feet pole unless it is "like tortoise".
 * LarstiQ nods at ddaa 
<pygi> ddaa: my interest in tortoise right now is mostly consisted of removing atl stuff
<ddaa> It does make me want to slap them with a less than perfectly fresh trout, but I guess it's their prerogative.
<LarstiQ> pygi: ok, so how am I going to motivate you to do that? :)
<LarstiQ> pygi: atl?
<pygi> LarstiQ: yes, right now we need visual studio pro for compiling Tortoise
<pygi> LarstiQ: gimme a big fat paycheck? :-P
<LarstiQ> ah
<LarstiQ> pygi: that, I can't do
<ddaa> what is "atl"?
<pygi> dash: a set of C++ classes for COM objects programming
<pygi> LarstiQ: then implement some feature for me :P
<ddaa> poor dash, he did not ask anything :)
<pygi> bleh
<joschan> Is there a way to generate an image file llike png instead of using a gui?
<dash> i thought about it though
<dash> but the i remembered what atl is
<pygi> ddaa*
<pygi> :)
<pygi> LarstiQ: actually, I have it almost ready :P I just need to fix one bug
<ddaa> joschan: there's a ancestry-graph thingy that uses graphviz
<ddaa> that will happily produce senselessly detailed and overcomplex ancestry graphs
<joschan> ddaa: thank you, i will try and find
<joschan> oh...
<pygi> LarstiQ: if you want to help with the bug, its most welcome :p
<LarstiQ> joschan: `bzr graph-ancestry`
<LarstiQ> joschan: not sure what visualisation you're after though
<pygi> (its not too-complex, I just need time)
<LarstiQ> pygi: what bug?
<joschan> LarstiQ: something that just works and is simple and does not depend on much. i do often switch machines and have limnux and windows
<pygi> LarstiQ: I need to reconstruct icons path on windows
<LarstiQ> joschan: that still doesn't say anything about the visualisation
<LarstiQ> pygi: ah
<LarstiQ> joschan: what are your visualisation requirements? what specifically are you wanting to visualise?
<dash> world peace
<pygi> cannot compute, please try something else!
<joschan> LarstiQ: i want the branch history
<LarstiQ> dash: http://www.nytms-se.se/
<joschan> anything graphical would be fine
<joschan> i saw the "network graph" on github
<LarstiQ> graphing the entire ancestry usually isn't very sensible
<joschan> it is just to understand my own version history better
<LarstiQ> joschan: could you point me at a github image you like?
<joschan> LarstiQ: i have no experience, what is better?
<ddaa> LarstiQ: Address Not Found
<LarstiQ> ddaa: gah, sorry. com, not .se http://www.nytms-se.com/
<LarstiQ> joschan: when I want to investigate my branching history, I usually use qlog or viz
<joschan> LarstiQ: a nice one is here: http://github.com/ginatrapani/todo.txt-cli/network
<LarstiQ> and just plain `bzr log` of course
<LarstiQ> ah hmm, that looks like it needs flash :/
 * LarstiQ reads http://github.com/blog/39-say-hello-to-the-network-graph-visualizer
<joschan> LarstiQ: viz would be an option if it simply runs anywhere, also qlog, nut i need something that just works
<LarstiQ> for what value of 'just work' don't they?
 * beuno has plans for loggerhead-viz
<LarstiQ> joschan: git works slightly differently than bzr, the closest analogue to github's network graph is running qlog/viz on multiple branches
<LarstiQ> beuno: good
<ddaa> actually that's something I occasionnaly wanted
<ddaa> But I'm not sure how much the viz layout algo would have to be modified to deal with multiple branches.
<joschan> which one woul run on linux and windows with less hassle installing, qlog or viz?
<joschan> i don't want to run into windows installing problems
<joschan> ok, i see, qlog already works now on my windows machine
<LarstiQ> joschan: qlog is easiest
<LarstiQ> ddaa: from `bzr help qlog`: bzr qlog ~/repo/branch1 ~/repo/branch2
<ddaa> oh, actually bzr vis seems to have the same
<LarstiQ> ddaa: and  viz has --all I think?
 * LarstiQ nods
<ddaa> yeah, it has the same, lovely
<ddaa> it was not there last time I looked
<ddaa> man, I so much fell behind
<ddaa> but otoh I could not longer take the bzr ml traffic.
<joschan> i think bzr qlog is fine. i can takeexpand and take screenshots, it helps a lot :-) did not know it is there
<joschan> s/takeexpand/expand it/
<LarstiQ> ddaa: yeah :/
 * LarstiQ keeps getting backlogged
<LarstiQ> joschan: ah right, sorry, should have mentioned that
<joschan> yes but it is also interesting to know about the other stuff, also "bzr graph-ancestry", i would love to try that
<LarstiQ> beuno: hmm, I'm looking on bitbucket for some visualisation I thought I saw there, can't seem to find it
<LarstiQ> joschan: you should have that command too on windows
<LarstiQ> joschan: though you might be missing graphviz itself
<LarstiQ> ooh
 * LarstiQ can use his lp openid to sign in on bitbucket
<joschan> LarstiQ: i just installed graphviz with the msi installer but bzr does not find it
<LarstiQ> joschan: you should be able to make it a two-step proces. `bzr graph-ancestry ancestry.dot; dot -Tpng ancestry.dot > graph.png`
<LarstiQ> joschan: on the bzr-gtk trunk that results in: graph.png: PNG image, 1657 x 12643, 8-bit/color RGBA, non-interlaced
<LarstiQ> joschan: so consider yourself warned, it can get huge :)
<ddaa> as in "turn your computer into a pancake huge"
<joschan> hehe
<fullermd> Wow, bzr can do that too??  I gotta get my syrup...
<joschan> where do i get that "dot" command?
<LarstiQ> joschan: it's part of graphviz
<LarstiQ> joschan: not sure how you invoke graphviz/dot on windows exactly
<LarstiQ> joschan: but it can convert what graph-ancestry produces when it's writing to .dot
<LarstiQ> joschan: I suppose if `dot` from graphviz is in PATH, then `bzr graph-ancestry foo.png` can do the invocation itself
<joschan> i found it in graphviz's bin dir
<joschan> and it produced a png
<joschan> :-]
<joschan> i will photoshop it and show you in an hour os so - takes ages opening *g
<joschan> s/os/or/
<GPHemsley> Is it possible to import/convert data from SVN into an existing Bazaar repository that already has data in it?
<LarstiQ> joschan: no kidding :)
<LarstiQ> joschan: that's the problem with trying to display that amount of information, it swamps you
<LarstiQ> GPHemsley: repository or branch?
<LarstiQ> GPHemsley: you can do `bzr branch url/to/branch/in/svn` if you have bzr-svn installed
<joschan> to be hnest i opend it with ms photo editor but i stopped it after 1 minute
<GPHemsley> LarstiQ: I want to merge in SVN history to an existing Bzr repo
<joschan> LarstiQ: i have some facts now: 1) don't open a png in ms photo editor - it could just hang 2) the png is really small
<LarstiQ> GPHemsley: I can be pedantic and say that is no problem at all, or guess that you mean branch instead of repo, and ask you to elaborate somewhat
<LarstiQ> joschan: hah
<GPHemsley> meh
<GPHemsley> this darn terminology
<LarstiQ> GPHemsley: it helps if you explain the situation in more depth, then it's clearer what is what
<LarstiQ> GPHemsley: are the bzr branch and the svn branch logically the same project?
<LarstiQ> GPHemsley: are you just interested in some random files?
<GPHemsley> LarstiQ: They don't share files, no
<LarstiQ> etc
<LarstiQ> GPHemsley: ok
<GPHemsley> LarstiQ: I want to start a new project/sub-project with Bzr and then move in other code from SVN at a later date
<joschan> LarstiQ: this is the png inserted into a google doc in original size: http://docs.google.com/View?id=d6snv7k_115ds3qrzfg
<LarstiQ> GPHemsley: how are your bzr project and svn code related in that case?
<LarstiQ> joschan: ooh, that's a cutely small ancestry
<GPHemsley> LarstiQ: They're two sections of the same project. They don't share code, but they're otherwise related.
<LarstiQ> GPHemsley: say, doc/ and src/, or a library that you contain in the using project?
<LarstiQ> evening Kinnison
<GPHemsley> LarstiQ: doc/ and src/ would be the better example,
<GPHemsley> I think
<LarstiQ> GPHemsley: do you already have code in bzr, or are you starting fresh?
<GPHemsley> right now? I'm starting fresh. But I didn't want to do it now.
<LarstiQ> GPHemsley: good, that is going to prevent us from taking the painful route then
<LarstiQ> GPHemsley: use bzr-svn to branch from svn (preferably at a level above what you're considering working on, so project/ instead of project/doc or project/src)
<LarstiQ> GPHemsley: then you at a later date you can just `bzr pull` or `bzr merge` from svn
<GPHemsley> LarstiQ: I think we'll have to back up, then, because I had trouble installing bzr-svn the last time I tried. :/
<LarstiQ> GPHemsley: aha. Well, I can try to help with that
 * GPHemsley is on a Mac.
 * LarstiQ is on a couch ;)
<GPHemsley> :P
<LarstiQ> but yes, Mac is the most difficult target. Still, it shouldn't be too hard, I hope.
<GPHemsley> me too
 * LarstiQ looks at the mac installer page
<GPHemsley> as I recall, something wouldn't compile right
<LarstiQ> GPHemsley: how did you install bzr?
<GPHemsley> the Mac installer
<GPHemsley> 10.4
<LarstiQ> GPHemsley: it claims to include bzr-svn
<LarstiQ> GPHemsley: what does `bzr plugins` say you have installed?
<GPHemsley> a number of things, but not bzr-svn
<GPHemsley> oh, wait
<GPHemsley> there's svn
<GPHemsley> well, that's deceiving
<GPHemsley> looks like it's there, then
<LarstiQ> GPHemsley: so what happens if you do `bzr ls svn://svn.gnome.org/svn/gnome-specimen/trunk` ?
<GPHemsley> ah, yes, this was the problem
<GPHemsley> the problem was with installing subvertpy
<LarstiQ> ok
<LarstiQ> hmm, that's not bundled?
<LarstiQ> it should be
<LarstiQ> and is indeed listed
<LarstiQ> according to http://bazaar-vcs.org/MacOSXBundle
<GPHemsley> bzr: ERROR: No module named subvertpy
<GPHemsley> You may need to install this Python library separately.
<LarstiQ> GPHemsley: if that's a recent bzr .dmg, it's bugged and the maintainer should be larted
<GPHemsley> heh
<LarstiQ> GPHemsley: if it's not, could you try the newest one?
<GPHemsley> the newest one is 1.15rc1
<LarstiQ> hmm, not that one then
<LarstiQ> does sound like the OSX maintainer needs some help
<LarstiQ> GPHemsley: the 1.14.1 one?
<GPHemsley> that's what I have
<LarstiQ> ok, it is bugged :/
<GPHemsley> heh, the 1.15rc1 doesn't even exist
 * LarstiQ wonders if there are instructions for how to build the .dmg
<GPHemsley> or, rather, the link is bad
<LarstiQ> and hence, how to build subvertpy
<LarstiQ> GPHemsley: could you fix it?
<GPHemsley> sure
<pickscrape> Hi, any idea how to view a diff of an item on the shelf?
<LarstiQ> pickscrape: hmm, not with shelve in bzr core.
<pickscrape> I did think that bzr diff -c shelf:<number> would be sensible, but it no worky
<pickscrape> --dry-run also just shows a sttus-like list of affected files, and -v made no difference
<pickscrape> I suppose the only way really is to just unshelve and inspect in the working tree, but that certainly isn't ideal
<GPHemsley> LarstiQ: Alright, links are fixed. Any luck with the .dmg?
<LarstiQ> pickscrape: I agree with you
<LarstiQ> GPHemsley: couldn't find instructions on it
<LarstiQ> GPHemsley: you could try to compile subvertpy yourself
<jfroy> yeah, the Mac packages are bad.
<jfroy> Even the 1.14 one for 10.5 has a broken subvertpy
<LarstiQ> GPHemsley: depending on the timeframe/effort you want to spend
<GPHemsley> LarstiQ: That's where I ran into trouble the last time
<pickscrape> I suppose I really should file a bug about it, if there isn't one already... I'll have a look. Thanks for answering, LarstiQ
<jfroy> it's probably easier right now to install from easy_install or source
<LarstiQ> jfroy: are you aware of how to build the .dmg?
<jfroy> building a package is not too hard, involves using an extension module for setuptools to make a mpkg
<LarstiQ> jfroy: seems doable
<jfroy> build_mpkg IIRC
<GPHemsley> feel free to walk me through it :)
<jfroy> Ah, it's bdist_mpkg
<twilight\> when doing a bzr upgrade in a shared repository, do I also need to perform the upgrade within each contained branch?
<jfroy> http://pypi.python.org/pypi/bdist_mpkg/
<twilight\> I wouldn't think so, but after upgrading the repo, bzr info within a contained branch says "Repository branch (format: unnamed)" (notice the "unnamed" format)
 * LarstiQ is a bit of an OSX outsider nowadays, but would like to see the installer in better shape
<LarstiQ> twilight\: yes/no
<GPHemsley> jfroy: Is there a command I can execute to install it?
<LarstiQ> twilight\: repository, branch and working tree formats can be independent
<GPHemsley> Or do I have to download it?
<pygi> LarstiQ: szi is on it, you need to be patient ;)
<LarstiQ> pygi: no, I need the build instructions to be clear and availabe so anyone can do it :P
 * GPHemsley is unfamiliar with the Pythong Egg format.
<pygi> LarstiQ: actually, the plan is to automate it afaik
<GPHemsley> heh... interesting typo
<twilight\> LarstiQ: is this documented somewhere?
<LarstiQ> pygi: fine too, as long as the Mac users do not get blocked on the maintainer having time
<pygi> LarstiQ: but its the same problem with windows so far xD
<GPHemsley> yeah, that's been kinda annoying in the past
<LarstiQ> twilight\: which part precisely? For the three formats, see `bzr info -v`
<GPHemsley> having the Mac packages being many weeks behind...
<LarstiQ> pygi: I'm not claiming Windows shouldn't be improved ;P
<twilight\> LarstiQ: hm, whether or not one has to upgrade each contained branch or just the shared repo
<GPHemsley> so... how do I install this bdist_mpkg?
 * LarstiQ gets reminded of something
<LarstiQ> twilight\: are these branches, no working trees?
<twilight\> LarstiQ: doing 'bzr info -v' within a contained branch (not-manually-upgraded) actually says "repository: Packs 6 rich-root (uses btree indexes, requires bzr 1.9)"
<twilight\> correct
<LarstiQ> twilight\: in that case, there are some formats where it isn't possible to distinguish which one it is unless you have a workingtree
<LarstiQ> twilight\: but anyway, they should work, upgraded or not
<pygi> vila: what's sidney's irc handle?
<LarstiQ> pygi: sidnei?
<pygi> LarstiQ: possibly :p
<LarstiQ> pygi: whois him ;P
<twilight\> LarstiQ: yup, i just wanted a format with the btree indexes, but in that case it seems like i'm good, thanks
<pygi> LarstiQ: I don't know his surname xD
<jfroy> sorry back
<LarstiQ> twilight\: yeah, that's a repository format property
<pygi> LarstiQ: he will have a lot of influence on windows builds ;)
<jfroy> GPHemsley: sudo easy_install bzr; bzr branch lp:subvertpy; cd subvertpy; sudo python setup.py install; cd ..; bzr branch lp:bzr-svn; cd bzr-svn; sudo python setup.py install
<jfroy> :p
<GPHemsley> heh
<jfroy> oh, right
<jfroy> .
<jfroy> so, bdist_mpkg is on pypi
<jfroy> so just do easy_install bdist_mpkg
<jfroy> then it will add a command to setup.py to build a package distribution
<LarstiQ> jfroy, GPHemsley: feel free to bug the mac maintainers, tell them I sent you ;)
<jfroy> do that for bzr, subvertpy, bzr-svn and any other plugin you want
<jfroy> then get the Mac OS X dev tools and use Package Maker to make a package that will install all the sub-packages
<GPHemsley> ah.... too much information at once
<GPHemsley> easy_install command not found
<jfroy> that's not good
<GPHemsley> heh
<GPHemsley> just another thing on that list :P
<jfroy> easy_install is bundled with 10.4 and later
<jfroy> no, it means your OS is busted or ancient
<GPHemsley> well, it's 10.4
<GPHemsley> latest point release
<GPHemsley> .11, I think?
<jfroy> then you should have it
<jfroy> along with Python 2.3 as the default system python
<jfroy> which is *too old* for bzr, mind you
<GPHemsley> 2.5
<GPHemsley> is what I have, IIRC
<jfroy> that's a custom install
<GPHemsley> probably, yeah
<jfroy> can't use that to make a 10.4 package
<jfroy> it's the biggest issue with 10.4
<GPHemsley> d'oh
<jfroy> on 10.5 it's relatively easy
<GPHemsley> but the packages released are for 2.5 and 2.6
<jfroy> yes for some distribution of Python that the package maintainer has chosed
<jfroy> *chosen
<jfroy> whereas the 10.5 package is designed to use the system interpreter
<GPHemsley> OK, well, despite easy_install not being found, it did the rest of those commands you had
<jfroy> I'm not familiar with the 10.4 package too much, it was maintained by someone else
<jfroy> maybe 10.4 didn't have setuptools....
<GPHemsley> except the install ones, I guess... :/
<jfroy> don't remember, 10.4 is ancient history for me :|
<GPHemsley> yeah, I know
<GPHemsley> I always get gypped with Mac stuff
<GPHemsley> I bought this computer in August 2007
<LarstiQ> 'gypped'?
<GPHemsley> 10.5 came out in, what, October 2007?
<GPHemsley> LarstiQ: I always buy stuff right before the new stuff comes out.
<LarstiQ> ah
<GPHemsley> I bought an iMac G5 in November 2005 and they announced the switch to Intel the next January
<LarstiQ> ouch :(
<GPHemsley> yeah
<jfroy> usually for OSes they have a grace period for updates
<jfroy> anyways, wait until 10.6 and grab it :)
 * LarstiQ needs to fix his g4 powerbook
<GPHemsley> that's the plan :)
<GPHemsley> I'm hoping to get a new iMac after 10.6 comes out
<pygi> GPHemsley: I heard they'll announce new architecture after you buy it
<GPHemsley> pygi: Yeah, that's the rumor.
<LarstiQ> pygi: tsk :p
<GPHemsley> they have replaced a lot of this MBP for free, though, so I can't complain too much
<joschan> I have a winows machine and I need python2.4 there for a legacy application. When I install bzr from the windows installer - will it disable or override the python 2.4 with 2.5 ?
<LarstiQ> joschan: won't touch it
<GPHemsley> my logic board died and they replaced it... then it died again the next day, and they replaced it... and then they replaced the battery recently
<LarstiQ> joschan: the all-in-one installer has python and bzr combined in one executable, doesn't touch system python
<awilkins> joschan: If you use the exe-flavoured installer, neither
<LarstiQ> joschan: the python-based-installer will work with the python version of your choosing
<jfroy> indeed
<joschan> LarstiQ: i was planning to use the exe stand alone installer
<joschan> i did not explain well
<jfroy> the Python windows installer that most packages use lets you choose which python you want to install into
<jfroy> based on registered python interpreters it finds int he registry
<LarstiQ> joschan: no touching of your system python then
<jfroy> IIRC
<joschan> how does it do ithat? with a virtual environment?
<GPHemsley> Ah, yes... this was the error I kept getting when I tried to install subvertpy the last time:
<GPHemsley> Exception: Subversion development files not found. Please set SVN_PREFIX or (SVN_LIBRARY_PATH and SVN_HEADER_PATH) environment variable.
<awilkins> joschan: The libraries are compiled into the exe as a resource
<joschan> or py 2 exe?
<joschan> ah i see - thank you!
<awilkins> GPHemsley: Windows or Linux?
<GPHemsley> awilkins: Mac
<LarstiQ> GPHemsley: you'll need an equivalent of a `libsvn-dev` package
<GPHemsley> I have it... but it doesn't see my settings for those env variables
<GPHemsley> no matter how I set them, it just ignores them
<LarstiQ> GPHemsley: how did you set them?
<GPHemsley> export, I believe
<jfroy> GPHemsley: Mac OS X comes with *no* header files.
<jfroy> You need to install the dev tools to get them.
<jfroy> if you're trying to use the system subversion librsries
<jfroy> *libraries
<jfroy> And, IIRC, 10.4 may not even have svn built-in :p
<jfroy> in which case, you need to get it yourself someway and set SVN_PREFIX to the install prefix of the subversion you picked
<jfroy> e.g. if it's a binary package, likely /usr/local, or if from MacPorts, then /opt/bin
<jfroy> */opt/local
<GPHemsley> I already have svn installed
<GPHemsley> I've been using it
<GPHemsley> and the dev files are somewhere, too
<GPHemsley> but when I try to set the variables, it ignores them
<GPHemsley> and says they're not set
<GPHemsley> (as above)
<jfroy> they're env variables, right
<jfroy> so export SVN_PREFIX=/usr/local (or whatever)
<jfroy> then python setup.py
<jfroy> bui;d
<jfroy> *build
<jfroy> etc
<joschan> i don't like magic! at least not on computers. on my girlfriend - yes!
<joschan> i said bzr init on directory that contains svn
<joschan> what happened?
<GPHemsley> jfroy: Meh... it's working now...
<joschan> it was even trying to connect to the svn server
<GPHemsley> oh, spoke too soon
<GPHemsley> collect2: ld returned 1 exit status
<GPHemsley> lipo: can't open input file: /var/tmp//ccoyGWiH.out (No such file or directory)
<GPHemsley> error: command 'gcc' failed with exit status 1
<LarstiQ> joschan: I'd say it would refuse because it is already a branch
<GPHemsley> jfroy: I'm pretty sure I used MacPorts to install the dev files
<joschan> there is a svnb plugin - can i disable this?
<joschan> s/svnb/svn/
<jfroy> GPHemsley: macports always installs the headers
<jfroy> since it builds from source and all
<jfroy> the error sounds weird ...
<GPHemsley> well, I set the variable using /opt/local and that's the error I get
<joschan> "bzr --no-plugins init" worked fine
<joschan> is there a --no-magic switch also ;-)
<LarstiQ> joschan: ehm, are you sure that is what you want to do?
<LarstiQ> joschan: coversioning a project can be valid, but it has very limited uses
<GPHemsley> jfroy: Is there a way to uninstall all the SVN stuff and start over, maybe?
<jfroy> GPHemsley: mac ports can uninstall with uninstall
 * LarstiQ is about to call it a night
<jfroy> you may need to update your dev tools as well
<jfroy> hard to say
<LarstiQ> joschan: with bzr-svn you can use bzr as an svn frontend, either `bzr log` etc in an svn checkout, or `bzr branch url/to/svn/branch` and it gives you a bzr branch converted from svn
<LarstiQ> joschan: with wich you can push back changes et all
<GPHemsley> jfroy: Oh, here's an interesting piece of information
<GPHemsley> MacPorts says I have subversion 1.6.2 installed, but svn is reporting it's 1.5.5
 * LarstiQ prods joschan 
<GPHemsley> jfroy: Any idea how to rectify that?
<LarstiQ> meh, need to sleep
<GPHemsley> LarstiQ: g'night
<GPHemsley> and thanks :0
<GPHemsley> :)
<LarstiQ> joschan: tell me what you were trying to do and how that went, I'll read it when I wake up
<LarstiQ> GPHemsley: np, good luck!
<jfroy> GPHemsley: seems like you have 2 subversions installed
<jfroy> maybe one in /usr/local and one in macports
<GPHemsley> jfroy: Indeed it does
<jfroy> could make a build system very confused...
<GPHemsley> nope, no /usr/local/bin/svn
<GPHemsley> jfroy: Heh. I have a brain and _I'm_ confused :P
 * GPHemsley sends find off to... well... find
<jfroy> which svn
<jfroy> (that is, run that command)
<GPHemsley> /opt/local/bin/svn
<jfroy> well there you go :p
<GPHemsley> where is MacPorts keeping its version, then?
<jfroy> if you don't care too much about, and have some free time, you could nuke (or move aside) /opt/local and install a fresh macports
<jfroy> in there
<jfroy> dunno what command you did to uninstall it
<jfroy> might have failed
<jfroy> or it might have been an inactive version
<jfroy> (since macports supports having multiple versions of the same port, but with only one active at a time)
<GPHemsley> wait... uninstall what?
<GPHemsley> oh
<jfroy> didn't you say you had uninstalled svn
<GPHemsley> I don't think so
<GPHemsley> what is /sw?
<GPHemsley> because I have /sw/bin/svn which is at 1.2.3
<GPHemsley> ugh, I gotta run
<GPHemsley> jfroy: Will you be here later?
<joschan> LarstiQ: I wanted to make a new repo aout of a direcotry structure and ignore all the .svn files in it. I could do it using the --no-plugins switch on bzr init and bzr add
<joschan> so i'm fine
<joschan> i don't want to mix, i want to abandon subversion
<jfroy> GPHemsley: sure
<jfroy> *Fink
<jfroy> ** /sw is Fink
<jfroy> joschan: I'd just use bzr-svn to branch the subversion branch.
<jfroy> you get to keep all the history
<jfroy> and you have a native bazaar branch moving forward
#bzr 2009-06-06
<poolie> jml or others, i'm just thinking about afc's suggestion that the format not be numbered 2.0
<jml> poolie: what's the alternative suggestion?
<poolie> well, his is to just give them arbitrary sequence numbers
<jml> interesting.
<jml> what's the advantage?
<poolie> well
<poolie> suppose we bump development-7 to be called 2.0 now
<poolie> what happens if (unlikely but possible) we discover we need to change it for the real 2.0
<poolie> also, it's a bit unfortunate that just saying "this is supported" requires a new name
<jml> "it never works the first time", right? :)
<poolie> that sort of thing
<jml> poolie: why is a name-change to indicate support level unfortunate?
<jml> does it affect the end-user, or is it more of a conflating-concepts thing?
<poolie> well, it requires some work for us and for our users
<poolie> so it's possibly waste
<jml> *nod*
<jml> from a #launchpad support perspective, formats matching release numbers _really_ helps.
<poolie> things like people asking why they can't read a particular branch?
<jml> yeah.
<jml> or why stacking doesn't work.
<jml> or what have you.
<jml> poolie: hmm. it would also make reading graphs like these easier -- https://lpstats.canonical.com/graphs/RepositoryFormats/ -- if we actually used the UI format name on the graph.
<poolie> mm
<poolie> the other thing there is that you're reporting the repository format, and there are various independently versioned components
<jml> yes.
<jml> subjectively, it feels like repo fmt is the one that bites most often.
<jml> we also report the branch format in a different graph.
<poolie> it's also the one that changes most
 * fullermd isn't sure he buys THAT...
<poolie> both most often and most substantially
<fullermd> I think we've had more branch formats...
<jml> fullermd: well, that's easy enough to verify/falsify.
<fullermd> Don't you go muddying the discussion with facts...
<jml> poolie: so I guess that wasn't a very conclusive discussion :)
<poolie> jml, actually it was a bit helpful
<poolie> i wrote an email
<poolie> i'd like if you would read it
<jml> I saw the email just after I hit enter :)
<jml> I'll read it now
<jml> poolie:  * a set of formats for which this is the best recommended format
<jml> is that supposed to be 'a set of versions' or similar?
<poolie> yes
<jml> cool.
<poolie> i'm going to sign off for a while
<poolie> what did you think, in a nutshell?
<jml> poolie: extremely helpful map of the problem space :)
<jml> poolie: I think 2.0mk1 or whatever would work well.
<poolie> 2.0 mark twain :)
<jml> poolie: not 100% sure about the creation UI.
<poolie> btw thanks (to whoever) made merge reviews quote the parent post
<jml> poolie: that's almost certainly abentley.
<jml> poolie: I think the thing w/ creation UI is that you should almost always never have to think about format in order to get the optimal experience.
<jml> but that's kind of a separate discussion.
<jml> "what does it take to get a supported format to be the default?"
<abentley> jml, poolie: It wasn't me, but it's in-line with my ideas.
<poolie> jml, i agree
<poolie> we could take the tack that we'll just always hide it so it doesn't matter how they're named
<poolie> but that's not realistic
<poolie> so we need to improve both sides
<jml> yep
<jml> so maybe a thing to think about with naming is, under what circumstances does a user need to identify a format?
<garyvdm> Has anyone here used guppy
<jml> anyway I really want to go and do Saturday things.
<jml> particularly, I want some yerba matÃ©
<poolie> me too
<garyvdm> is it possible to pass it an known object and see how big it is?
<LaserJock> I'm a little confused about the state of the bzr-git plugin
<LaserJock> http://bazaar-vcs.org/BzrForeignBranches/Git says the latest version is 0.3.2 but https://launchpad.net/bzr-git/+download just has 0.1.0
<Peng_> Dozer reliably crashes Firefox. Nice. :D
<jfroy> jelmer: I just got a fairly verbose exception from CachingRevisionMetadata
<jfroy> jelmer: 384192, similar to 324970
<johnjosephbachir> hello folks
<johnjosephbachir> i scoured the man file, i promise-- how do i ask a bzr binary what version it is? :)
<jfroy> johnjosephbachir: bzr --version
<johnjosephbachir> nope -- that's for the version of the tree i believe
<jfroy> no
<jfroy> try it :p
<johnjosephbachir> oh actually, it's not a flag
<johnjosephbachir> at least, it's not mentioned in the man page
<johnjosephbachir> (i was looking at --versionED)
<johnjosephbachir> whoops-- my bzr is barfing on an error, that's the problem
<johnjosephbachir> sorry for the bother
<johnjosephbachir> (although-- it is true that that flag isn't mentioned in the man page)
<jfroy> perhaps
<jfroy> it a relatively common option for all UNIX programs
<jfroy> (along with -v)
<garyvdm> johnjosephbachir: fwiw --version is mentioned in "bzr help global-options"
<johnjosephbachir> okay, cool
<GPHemsley> jfroy: You awake?
<jfroy> yeah
<GPHemsley> wow
<GPHemsley> when do you sleep?
<jfroy> not much :/
<GPHemsley> oh
<jfroy> and when I can :p
<GPHemsley> sorry to hear that :/
<jfroy> lol it's fine :p
<GPHemsley> but, on the other hand, not ;)
<GPHemsley> so what do you think of uninstalling both the fink and MacPorts versions of my SVN and then reinstalling via MacPorts?
<GPHemsley> do you think that will solve my problems?
<jfroy> it might
<GPHemsley> jfroy: Hmm... MacPorts even had trouble updating subversion
<GPHemsley> So I tried uninstalling it
<GPHemsley> Reinstalling it now (which will also bring it from 1.5.5 to 1.6.2)
<jfroy> yeah
<jfroy> I'm going to bed now, but, hopefully that will solve your problem
<GPHemsley> alright
<GPHemsley> thanks for your help :)
<jfroy> np
<LarstiQ> jfroy: thanks for your suggestion to joschan, unfortunately it seems he didn't pay attention :/
<Peng_> mwhudson or beuno: ping
<Peng_> Oh, right, it's Saturday. Oh well.
<mwhudson> Peng_: tentative hello
<Peng_> mwhudson: Good morning.
<mwhudson> Peng_: you're right about not being good at timezones then :)
<mwhudson> (it's 23:14 here)
<Peng_> :P
<Peng_> I always say "Good morning". For me, it *is* morning locally, but I'm probably gonna go to bed soon. :P
<Peng_> mwhudson: Anyway, the ping was just because I want bug #382765 to be on someone's radar, because Loggerhead uses a deprecated bzrlib API that may soon be removed from bzr.dev.
<ubottu> Launchpad bug 382765 in loggerhead "history.py uses deprecated ProgressBarStack" [High,Triaged] https://launchpad.net/bugs/382765
<Peng_> mwhudson: Kind of unnecessary, since everyone reads bugmail, but it's too late to take it back now. :P
<mwhudson> there's a branch about this right?
<Peng_> mwhudson: No.
<Peng_> mwhudson: beuno has a branch about other deprecated stuff, but not this.
<mwhudson> ah
<mwhudson> ah, i misunderstood your comment :)
<mwhudson> i'm fairly sure just deleting the stuff in loggerhead will be fine
<mwhudson> but i'll make sure on monday :)
<Peng_> mwhudson: Thank you. :)
<aboSamoor> Hi, I have a personal repository, I branched it on my laptop and desktop. Trying to push from my laptop I got this error "bzr: ERROR: These branches have diverged."
<sidnei> hey folks, im wondering if bzr supports specifying the revision in the url like subversion does, eg: 'bzr branch lp:something@123' to get revision 123 of lp:something
<jpds> sidnei: bzr branch -r 123 lp:something
<sidnei> jpds: yeah, that much i know, just wondering because subversion supports the alternative @rev format
 * sidnei considers filing a feature request
<LarstiQ> sidnei: it's been talked about in the past
<sidnei> LarstiQ: so what was the conclusion? yagni?
<LarstiQ> sidnei: don't clearly recall
<ddaa> knowing the bzr style it would probably end up being something pedantically correct like "lp:something?r=123"
<ddaa> Not that there is anything wrong with pedantic correctness.
 * LarstiQ heads to Amsterdam
<LeoNerd> $ bzr missing --remember sftp://cel/var/bzr/leo/perl/IPC-PerlSSH/
<LeoNerd> bzr: ERROR: no such option: --remember
<LeoNerd> ^-- what do I mean there..? I thought it had a --remember
 * LeoNerd goes for  vim .bzr/branch/branch.conf
<javaJake> Is there a way I can lock a folder or repo so that only one person can make edits? There's some areas in our repo that unforunately cannot be merged easily, so it would be nice if there's a way to "remind" others that committing is not allowed for a folder at that moment.
#bzr 2009-06-07
<mwhudson> jelmer: ERROR: test_push (bzrlib.plugins.git.tests.test_blackbox.TestGitBlackBox) seems to fail with on bzr-git tip
<mwhudson> http://pastebin.ubuntu.com/189938/
<mwhudson> (with dulwich tip, but somehow i don't think that matters)
<pattern> when i do a "bzr version-info" in /home/foo/xyz i get an error: "Format <RepositoryFormatKnit1> for file:///home/foo/bzr/.bzr is deprecated - please use 'bzr upgrade' to get better performance"
<pattern> but when i do a "bzr upgrade" in that directory i get:  "bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format."
<mwhudson> yeah, that sucjs
<mwhudson> pattern: are you using a shared repo?
<pattern> no
<mwhudson> oh
<pattern> just a local one
<mwhudson> pattern: pastebin what bzr info -v says?
<mwhudson> e.g. here http://pastebin.ubuntu.com/
<pattern> http://pastie.org/503222
<mwhudson> pattern: oh
<mwhudson> pattern: try running bzr upgrade :this
<mwhudson> um, maybe not that
<mwhudson> pattern: you have a bound branch, it seems?
<mwhudson> pattern: the format of the bound and master branch are different, i guess
<pattern> not really sure what i have, in bzr terminology
<mwhudson> try bzr upgrade :bound
<pattern> Format <RepositoryFormatKnit1> for file:///home/foo/bzr/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance
<pattern> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
<mwhudson> hmm
<mwhudson> mm
<mwhudson> does merge (maybe with --lca) losing executable bits sound familiar to anyone?
<Peng_> mwhudson: I lost the xbit on a file once. I assumed it was because I did something like "mv foo.OTHER foo".
<Peng_> I never actually tracked it down, though...
<mwhudson> Peng_: hmm
<mwhudson> Peng_: there's basically no chance that the files that lost x bits conflicted, though there may have been a conflict in the merge
<mwhudson> actually, i think what i did was either 'merge; revert; merge --lca; commit' or 'merge; remerge --lca; commit'
<Peng_> mwhudson: Oh, huh. I have no clue, then.
<Peng_> ...Ugh, what's wrong with my connection this time?
<mwhudson> ah well, i'll look again, on monday :)
<mwhudson> i think both files that lost the x bit moved in the merge, too
<mwhudson> which seems unlikely to be a coincidence
<Peng_> 800-900 ms ping to hop #2?! WTF?!
<Peng_> WTF is with me and Internet problems this week?
<mwhudson> Peng_: obviously you're getting subconsciously ready to move to .au or .nz
<Peng_> I've had problems with 2-3 different ISPs in different states in 1 week. :D
<Kamping_Kaiser> harsh, but fair
<treeform> hey guys my commit is taking for ever, can some one help diagnose the problem?
<Peng_> treeform: Local? Internet? Checkout? Branch? Is it really gigantic? Define "forever"? RAM usage? CPU?
<Peng_> Oddly, this barely feels worse than my 300 ms pings last time.
<Peng_> Darn, it's confusing ntpd too.
<treeform> Peng_: its my own remote server
<treeform> i dont think its high on ram or cpu
<treeform> its just taking for ever network wise
<treeform> packing flowing for 2 hours to change 12 files
<treeform> 12 python small files
<treeform> i estimate it could have uploaded over gig now
<treeform> on the server same thing
<treeform> no ram or cpu problems
<treeform> just open network connection
<Peng_> treeform: How large is the repo?
<treeform> 1.8Gb
<Peng_> treeform: It's possible it's doing an autopack, which in old versions (or any version over a dumb protocol) means downloading a nd re-uploading a potentially significant amount of data.
<Peng_> treeform: Check .bzr.log
<treeform> where would bzr log be
<Peng_> treeform: "bzr version" gives the location. Probably ~/.bzr.log.
<treeform> oh the client is on windows and server is on linux
<treeform> could that matter?
<lifeless> no
<treeform> server 1.8 , client 1.2
<treeform> i just downloaded the client
<treeform> maybe i got wrong one
<Peng_> Those are both rather old.
<lifeless> very
<lifeless> I'll leave it with you Peng_ :)
<Peng_> Wait, I was about to say that!
<Peng> Ugh, typing over that SSH connection was driving me nuts.
<treeform> i dont get the version numbers on the site
<Peng_> treeform: Huh?
<treeform> every thing from 1.15 to 1.6 is up for grabs
<Peng> treeform: 15 > 6
<treeform> The current stable version is 1.15final
<treeform> but server say i have 1.8?
<treeform> oh its 15 as in
<treeform> ok got it
<Peng> treeform: Check what's going on in .bzr.log on the client. If it says "Auto-packing repository", that's what's going on. If both the client and server were recent, auto-packing would occur server-side (if you're using the smart server).
<treeform> where would .bzr.log be on windows?
<Peng> treeform: I told you, ask "bzr version".
<Peng> Seriously, how do people SSH over a satellite connection without just hanging themselves? It's awful!
<Peng_> Anyway, whining about that is off-topic.
<treeform> http://dpaste.com/52384/
<treeform> the log is very very large
<Peng_> treeform: Scroll up to the last push.
<Peng_> treeform: Or commit, or whatever you were doing. :P
<treeform> commit
<treeform> i am not sure where it starts
<Peng_> The file includes both dates (in recent versions, anyway) and the command line.
<treeform> oh found it
<Peng_> lifeless! I was about to leave! :(
<treeform> there is tons of errors about locks
<treeform> it has "Auto-packing repository"
<treeform> so its autopacking 2GB of data?
<treeform> and resending it?
<Peng_> treeform: Some portion of it. Probably not all of it.
<treeform> i probably need to update bzr's
<treeform> and figure out smart server
<Peng_> treeform: What type of connection are you using to the server? SFTP? bzr+ssh?
<Peng_> God forbid, FTP?
<treeform> sftp
<treeform> bzr+ssh gives locking problems
<Peng_> Oh, huh.
<treeform> maybe its due to version being old
<Peng_> Could be.
<treeform> bzr+ssh is still not a smart protocol?
<treeform> only the bzr one is?
<treeform> but the server it runs does not support authintication?
<Peng_> treeform: All of the schemes that start with "bzr" are smart.
<treeform> so if i do get bzr+ssh working? it would give me smartness and authintication?
<Peng_> bzr+ssh simply uses SSH for auth.
<Peng_> ...As does SFTP.... :P
<treeform> yes
<treeform> i have all of the ssh setup
<Peng_> So switching to bzr+ssh should be easy.
<Peng_> I have no idea what your locking problems could be caused by, or if a newer version improves things. You should upgrade anyway, though.
<treeform> could i cancel this commit and try bzr+ssh
<treeform> should*
<Peng_> treeform: I wouldn't. It would waste all of the bandwidth you've already used.
<treeform> hmm
<treeform> but its been going for 2+ hours
<treeform> basically i was voiping with people
<treeform> and said ok ill commit this
<treeform> and ...
<Peng_> Well, I don't know, it's your choice.
<treeform> ok got the 1.15 on server
<Peng_> You could kill the commit, log into the server and run "bzr pack" on the repo.
<treeform> oh
<Peng_> Then you wouldn't have to do a significant autopack for a long time.
<Peng_> (Note: That would temporarily double the amount of disk space used. And it would probably use a lot of RAM, I dunno.)
<treeform> hmm only took 14 sec to do bzr pack on server
<treeform> with 1.15
<Peng_> Yes, well, local disks are a lot faster than the Internet. :P
<treeform> was there a new better knit format since 1.8 ?
<Peng_> treeform: The --1.9 format has new, smaller and faster indexes.
<Peng_> treeform: (As its name suggests, it was intorudced in 1.9.)
<treeform> ok
<Peng_> (And if I wasn't typing over this slow SSH connection, I'd fix that typo. :P )
<treeform> is it worth to switch and how would i switch to it?
<Peng_> treeform: You'd use "bzr upgrade --1.9". Obviously, all of your clients would have to be 1.9 or newer.
<Peng_> treeform: If the clients are new enough, there's not really any reason not to upgrade. It does improve performance, especially over dumb servers.
<treeform> lets see if it can upgrade 2GB worth of data
<Peng_> treeform: BTW, you should run bzr check and (if necessary) bzr reconcile as well.
<Peng_> treeform: before upgrading
<treeform> oh man
<treeform> allready started
<treeform> cancel?
<Peng_> treeform: Nah.
<Peng_> treeform: Well, it would still be a good idea to run check and reconcile after upgrading. And it'll be faster, to boot! :D
<treeform> because i am using new shiny format
<treeform> its done switching, checking now
<treeform> is there a big performance difference between bzr+ssh and bzr straight?
<Peng_> treeform: Nah. And anyway, regular bzr:// is unencrypted and doesn't support any form of auth. Use each where it's more appropriate, not out of performance concerns.
<treeform> using bzr+ssh gives this error on windows
<treeform> "the procedure entry point ___lc_collate_cp_func could not be located in the dynamic link library msvcrt.dll"
<treeform> this is in 1.15 just freshly downloaded
<treeform> on the windows client
<treeform> https://bugs.launchpad.net/bzr/+bug/341465
<ubottu> Launchpad bug 341465 in bzr "bzr linked version of msvcrt.dll is missing" [Undecided,New]
<Peng_> Oh, there we go.
<treeform> this is probalby i did not use bzr+ssh :)
<treeform> probably why*
<treeform> any advice?
<Peng_> I haven't touched Windows in like 5 years. :P
<Peng_> So, I don't know, sorry.
<treeform> yeah i whish i did not have to live with it either
<Peng_> You might be able to run bzr from source, but I don't know how easy that is on Windows. Plus performance would be worse.
<Peng_> I think it's worth adding a comment on that bug, that it still affects you in 1.15.
<treeform> random dll from the net does not have ___lc_collate_cp_func either
<Peng_> Try the mailing list or something.
<Peng_> I really don't know anything about Windows, and it's the weekend, so not many people are around.
<treeform> crap now sftp does not work too!!!!
<treeform> ill try restart
<treeform>  :)
<treeform> same dam thing
<treeform> oh i fixed it
<treeform> yey
<Peng_> You fixed it? How?
<treeform> i removed the svn plugin ( https://bugs.launchpad.net/bzr/+bug/341465/comments/2 )
<ubottu> Launchpad bug 341465 in bzr "bzr linked version of msvcrt.dll is missing" [Undecided,New]
<treeform> the trace lead to that
<treeform> too bad i dont have the trace any more
<treeform> other wise i would post it
<Peng_> Oh
<lifeless> treeform: its probably in your bzr log
<treeform> yes
<treeform> got it updateing
<Peng_> lifeless: Hi. :)
<lifeless> bzr --version will give you the path to the log
<lifeless> hi Peng_
<treeform> yeah i added it to commets
<treeform> maybe it could help some poor sole in the future
<Peng_> Ooh, subvertpy.
<treeform> its the svn2bzr stuff right?
<treeform> i dont know, i just hack folder, stuff works
<treeform> bzr+ssh feels faster
<Peng_> treeform: subvertpy provides Subversion bindings for Python. It's used by bzr-svn (and was, in fact, created by the author of bzr-svn for bzr-svn).
<treeform> but its just an physiology thing
<Peng_> treeform: bzr+ssh is faster than sftp.
<treeform> cool
<treeform> just commit some binary files
<treeform> 12megs
<treeform> it went in fine
<treeform> after the small 12 file commit that took 3 hours  1 minute and 9 second with sftp ...
<treeform> and faild
<Peng_> treeform: Well, that was thanks to the auto-pack.
<treeform> yeah
<treeform> what are some of the largest bzr repos people have?
<treeform> do they have Terabyte repos?
<Peng_> lifeless: Think that bug should be linked against subvertpy?
<lifeless> Peng_: bzr installer probably
<Peng_> lifeless: yeah.
<lifeless> Peng_: not sure what part should be responsible for doing the suckin of the dll
<Peng_> treeform: MySQL is probably the largest public project at the moment.
 * Peng_ shrugs
<Peng_> I'm sure Launchpad has statistics.
<lifeless> treeform: Theres nothing in our dataformats preventing scaling to terabytes of history
<lifeless> but there are limitations on individual file size
<Peng_> lifeless: What about hte inventory?
<treeform> my stuff is mostly 3d data
<treeform> like huge images and huge files of 3d model
<lifeless> treeform: bzr currently wants to hold up to 5 times the size of a single file in memory while committing or diffing it
<lifeless> treeform: we have some plans about how we might fix this
<lifeless> probably post 2.0
<lifeless> Peng_: inventory scales to 100K files+ in a single tree today
<Peng_> lifeless: Isn't dev7 down to 3 times for commit?
<lifeless> Peng_: once jams's patches land, and only dev7 which treeform won't be using yet.
<Peng_> Ah. Well, it's still progress in the right direction, right?
<lifeless> right
<lifeless> but better to be capped at (say) 5MB
<garyvdm> igc: ping
<RockyRoad> hi :)
<garyvdm> Hi RockyRoad
<RockyRoad> maybe you could help me ?
<garyvdm> Go ahead and ask. If I can't I'm sure someone else might be able to.
<RockyRoad> I was here friday, with a problem a bit complicated
<RockyRoad> I explained it here http://www.rocky-shore.net/misc/bzr-rebuild.html
<RockyRoad> I wondered if bzr rebase could help ?
<garyvdm> I'm reading you page
<garyvdm> There is a command half way down: bzr -r0..1 lp:branch_Bx
<garyvdm> should that be bzr *merge* -r0..1 lp:branch_Bx
<RockyRoad> right !
<RockyRoad> corrected
<garyvdm> RockyRoad - So the problem is that you can't push from A to B?
<RockyRoad> I tried to push to a subdir of Bx, that fails
<RockyRoad> because the parent branch is different
<garyvdm> Is these branches publicly accessible? - I think It will be much easier for me to look at the branches.
<RockyRoad> (i suppose)
<RockyRoad> sure
<RockyRoad> https://edge.launchpad.net/planet-drupal
<garyvdm> so which is A and which is B?
<RockyRoad> A is drupal-planet and B is planet-drupal
<RockyRoad> FYI http://drupal.org/node/476042
<RockyRoad> (so it's not  a fork !)
<garyvdm> RockyRoad: do you have qbzr installed?
<RockyRoad> bzr gtk and qbzr
<RockyRoad> I like bzr viz
<garyvdm> you can run "bzr qlog lp:drupal-planet lp:planet-drupal" to see a visualization between the two branches.
<RockyRoad> one project after the other, not together ?
<RockyRoad> bzr: ERROR: extra argument to command qlog: lp:planet-drupal
<garyvdm> Ah - what version of qbzr?
<RockyRoad> I have a lot of errors with qlog
<RockyRoad> qbzr 0.9.2-0ubuntu1
<garyvdm> Yes - It did not have that feature back then.
<garyvdm> I'll upload a screen shot for you
<RockyRoad> thx :)
<garyvdm> Now what command are you using to push from A to B?
<RockyRoad> bzr push lp:~m-baert/planet-drupal/planet-6-x
<RockyRoad> I'll pastebin all, one moment
<RockyRoad> http://pastebin.com/m30a5ff1c
<garyvdm> http://garyvdm.googlepages.com/log-planet-drupal.png
<garyvdm> You can get the latest qbzr from https://launchpad.net/~qbzr-dev/+archive/ppa
<RockyRoad> It's much nicer that what I have ! I will :)
<garyvdm> ok - so I think what you want merge A into B
<garyvdm> so go to your directory that contains B (lp:~m-baert/planet-drupal/planet-6-x ?) do bzr merge
<garyvdm> and do bzr merge lp:drupal-planet
<garyvdm> Check that it gets you what you want.
<garyvdm> And then push
<RockyRoad> but there's no common ancestor ...
<RockyRoad> oh yep
<garyvdm> brb
<RockyRoad> k
<RockyRoad> planet-6x$ bzr merge lp:drupal-planet
<RockyRoad> Nothing to do.
<RockyRoad> revno = 25
<RockyRoad> Is there a way to bring my branch from drupal-planet to planet-drupal history ?
<garyvdm> sorry - bzr merge *lp:planet-drupal*
<garyvdm> These names are very confusing
<RockyRoad> I've no rights on drupal-planet, I have on planet-drupal
<garyvdm> But you don't have to create a whole new project.
<RockyRoad> ?
<garyvdm> You can just create a new branch lp:~rockyroad/planet-drupal/trunk (or dev or fork :-P)
<RockyRoad> I couldn't agree with the person who "administrates" drupal-planet and related projects
<garyvdm> if you push to  lp:~rockyroad/planet-drupal/trunk - then it will show up in the branches list for planet-drupal
<RockyRoad> but the "old history" I added ?
<RockyRoad> drupal planet starts from my trunk rev 3
<garyvdm> You can bring that in with bzr merge *lp:planet-drupal*
<garyvdm> Earlier I said bzr merge lp:drupal-planet - that give you "Nothing to do. " because it an older branch of lp:~m-baert/planet-drupal/planet-6-x
<RockyRoad> from planet-drupal checkout directory ...
<RockyRoad> sorry I need time to figure it out
<garyvdm> brb
<RockyRoad> k
<RockyRoad> what may be a trick is that I built a newer project (planet-drupal) to store older history (CVS) before a clone of drupal-planet
<igc> hi garyvdm
<RockyRoad> s/trick/pitfall/
<RockyRoad> hi igc
<garyvdm> Hi igc
<garyvdm> RockyRoad - I think you need to try figure what you merge into what. qlog branchA branchB branchC can help you alot with that.
<garyvdm> igc: Bazaar Explorer overlaps alot with qmain.
<igc> hi guys
<RockyRoad> I can't see it very clearly yet ... what kind of connection does qlog do between branches ?
<igc> garyvdm: I certainly took a lot of its design from qmain
<garyvdm> It shows how their revision histories relate
<igc> well, the discussion around qmain at least
<garyvdm> igc - I not against a split effort. I would just like to discuss it.
<igc> garyvdm: sure. Apologies for not discussing it more before I threw it together
<igc> garyvdm: the orginal focus was prototyping the menu I wanted in bzr-eclipse
<garyvdm> And would still like to do qmain - because there are things that we will be able to do with qmain that will be more difficult.
<igc> garyvdm: by all means
<garyvdm> Like integrate log into qmain.
<igc> garyvdm: right, I was looking for a lightwieght wrapper/shell because that best simulates the experience ...
<igc> that users of qbzr-eclipse and TortoiseBzr will get
<garyvdm> So, If I understand you correctly, bazaar-explorer is really experimental?
<igc> garyvdm: at this stage, yes
<igc> garyvdm: but I'm using it for development and dogfooding it
<igc> so I expect it to rapidly improve
<igc> garyvdm: in fact, it's almost finished in one sense ...
<igc> I really do want it to be lightweight ...
<garyvdm> Ok - cool.
<igc> and for most of the energy to go into the q* commands themselves
<garyvdm> So I've been thinking alot about the idea that I posted as a response to one of your mails.
<igc> garyvdm: going further, I'd be interested in pushing any smarts in explorer down into q* commands even
<garyvdm> Thats great.
<igc> garyvdm: tell me more about your idea
<garyvdm> So my idea is now something like this. I create a "api" in qbzr where you can say wrap this bzr command, and show fields x, y, z on the dialog.
<igc> garyvdm: yes!!
<igc> garyvdm: I was thinking of code generating creating Qt forms
<igc> but your idea - dynasmic lookup of the Command objects - is better
<garyvdm> It will try and what type of field it, so for say a revision spec field, it will show a revision selector, but will may have to provide it some extra information.
<igc> right
<garyvdm> e.g. for push, it must show revisions from the current directory (or what was provided by -d), but for pull, it must show the location you entered.
<garyvdm> That will make adding a new command only a couple of lines of code.
<igc> excellent
<garyvdm> Right now though - I'm batteling to decide what to work on :-)
<igc> garyvdm: here's some simple ideas if they help
<igc> as I said, I've been dogfooding, trying to go command line cold turkey ...
<igc> some limits of our q* GUIs ...
<garyvdm> Ha ha - I've tried that a couple of time ...
<igc> in qadd, I can do the equivalent of add foo/bar when foo is unversioned
<igc> s/can/can't/
<igc> I can only add all of foo
<igc> so qadd needs a button like ...
<igc> Expand Directories
<igc> a second example ...
<igc> I can't use qmerge to merge a merge directive easily
<igc> as the 'branch selector' insists on a directory
<garyvdm> That should be easy to fix.
<igc> garyvdm: there's lots of little stuff too ...
<igc> qbind and qunbind are essential
<igc> and both probably really simple (a few hours each I hope)
<garyvdm> qbind/qunbind/qswitch are the type of commands that my api would make realy easy to do.
<igc> garyvdm: exactly
<igc> garyvdm: but the bind ones at least arguably need to be slightly nicer than generic, e.g.
<garyvdm> re qadd: what I would like is for directories to have twisties so you can expand them.
<igc> bind takes an optional location now
<igc> qbind ought to say something like ...
<igc> [X} Bind to existing location: ...
<igc> [ ] Select a new location
<igc> and picking the seconf radio button ought to enable an entry field
<igc> qunbind ought to be a simple yes/no dialog even
<igc> garyvdm: quncommit is another one that ought to be easy ...
<igc> [X] Uncommit last revision
<igc> [ ] Select an earlier revision...
<garyvdm> qunbind could be just when you select revert from the qcommit dialog.
<igc> garyvdm: probably, though it also needs to be separate I think
<igc> garyvdm: qunbind will turn something from a bound branch into an unbound branch in Explorer
<igc> so it probably needs to be a button on the Bound Branches tab of a repo
<garyvdm> I meant - the qbind dialog should look like revert dialog initiated from qcommit.
<igc> garyvdm: ah - sorry, I'm yet to see that one :-)
<garyvdm> and the code for that is implement is a very reusable fashion.
<igc> nice to hear
<garyvdm> brb
<garyvdm> About qadd
<garyvdm> what I would like is for directories to have twisties so you can expand them.
<garyvdm> To do that
<igc> +1 to that
<garyvdm> currently we have 3 directory/tree browsers. The working tree widget used in qcommit/qadd/qrevert. The qbrowse widget, and the qbzr (aka qmain) widget.
<garyvdm> I would like to see them refactored into one.
<igc> garyvdm: I'm not across enough of the qbzr code but ...
<igc> sound good to me
<garyvdm> igc: can I ask for some none-tech advice?
<igc> garyvdm: fwiw, I'd like to see ...
<igc> qbzr have a widgets directory as well as a lib one
<igc> so the widgets are more easily discoverable
<garyvdm> Ok
<igc> I've started doing that in bzr-explorer
<garyvdm> Currently there are only 2 that are designed to be reuseabe.
<garyvdm> log and working tree
<igc> garyvdm: non-tech advice?
<igc> fire away
<garyvdm> And the currently unmerged into trunk revision selector
<igc> yes please
<garyvdm> I can't decide what to work on.
<RockyRoad> I wouldn't like to disturb in your busy developers chat (qbzr rocks :), but I still need some help. Somebody else maybe ? jelmer what about rebase ? My problem is exposed here: http://www.rocky-shore.net/misc/bzr-rebuild.html
<garyvdm> I started working on tests for log at uds
<garyvdm> There is alot more test that should be written for qlog
<garyvdm> Fix bugs?
<garyvdm> Work on api for creating command?
<garyvdm> Work on refactoring directory/tree widgets into one.
<garyvdm> I cant decide.
<igc> garyvdm: there's no right answer :-)
<igc> but here's my view ...
<igc> pick whatever gives end users most value
<igc> if the bugs are stopping users from working, they become #1
<garyvdm> ok
<igc> garyvdm: fwiw, what helps me most is the sort of stuff above ...
<igc> because each one of them means "back to command line"
<igc> garyvdm: I feel that once we get those sort of rough edges smoothed out ...
<igc> then more people will start using our GUIs and they'll gain more momentum
<igc> and more developers to help us improve them
<garyvdm> Yes
<igc> garyvdm: so, stepping back a second ...
<garyvdm> If I work on the api - it may save other developers, and increase the momentum.
<igc> my vision is for each IDE and shell to have the same Bazaar menu ...
<igc> and for the menu options to be very lightweight code calling out to q* (and optionally g*)
<igc> putting together menus in most environments is easy
<igc> writing code behind them is hard
<garyvdm> Yes - I agree that is the way to go.
<igc> garyvdm: so my preferred order for things is ...
<igc> 1) get coverage so menu options do something
<igc> 2) look at streamlining the commonly used dialogs
<igc> 3) the rest
<garyvdm> Ok - so for me -
<igc> garyvdm: I think your API idea is excellent
<garyvdm> 1) fix bugs
<garyvdm> 2) command api
<garyvdm> 3) tree/dialog refactoring
<garyvdm> Cool - thanks for the advice
<igc> sounds good
<igc> 1 makes users happy and 2+3 will help build momentum
<garyvdm> I was looking forward to meeting you at uds, and disappointed when I found out that you weren't going to be there. But I understand why.
<igc> garyvdm: :-(
<igc> I hear the sprint was great
<igc> and would have *loved* to be there
<garyvdm> Did you see I signed your book. On one of the back pages :-)
<igc> I'm yet to receive that stuff
<garyvdm> :-(
<igc> but I'll look for your name when I do :-)
<garyvdm> Ok - thanks for the chat - I'm going to work on a bug, and then go visit my Dad.
<igc> garyvdm: my pleasure. I should get some sleep :-)
<RockyRoad> thanks garyvdm, good luck
<garyvdm> RockyRoad: I also want to help you still if you have some time
<RockyRoad> you probably need to keep all these good ideas fresh in mind and go on with qbzr. I can understand that
<garyvdm> I do want to help you
<RockyRoad> k
<RockyRoad> to refer back to my drawing http://www.rocky-shore.net/misc/bzr-rebuild.html (A/B less confusing names ?)  what I understand of merging lp:planet-drupal into lp:planet-drupal/planet-6-x/ is merging B rev5 into By rev25, which looks like reverting to Bx rev 9.
<RockyRoad> I don't want to revert to that state !
<RockyRoad> although I'm ok to rebuild all from the start if needed
<RockyRoad> also, I have no problem pushing lp:~m-baert/drupal-planet/6.x (Az) into lp:~m-baert/planet-drupal/6x-mich (Bz), but the problem I could have is to merge it into Bx or Bxy.
<garyvdm> can you run bzr qlog lp:~m-baert/planet-drupal/planet-6-x lp:drupal-planet lp:planet-drupal
<garyvdm> and tell me when It has loaded.
<RockyRoad> loaded
<garyvdm> rev 5 from lp:drupal-planet != rev9 from lp:planet-drupal
<garyvdm> It has rev9 merged into it
<garyvdm> rev 5 from the yellow line
<RockyRoad> drupal-planet rev5 is nothing special
<RockyRoad> planet-drupal rev5 reflect drupal-planet/6x/ rev 9
<garyvdm> If i understand correctly, the yellow line (lp:drupal-planet) has changes that you want to merge into the black line (lp:planet-drupal / lp:~m-baert/planet-drupal/planet-6-x)
<RockyRoad> not really
<garyvdm> Oh
<RockyRoad> the black line is a copy of lp:~sweetdave/drupal-planet/6.x
<RockyRoad> th yellow line is what I added
<RockyRoad> (old history + tags)
<garyvdm> I see that
<garyvdm> You want to merge the black line into the yellow line?
<RockyRoad> I pushed lp:~m-baert/drupal-planet/6.x as lp:~m-baert/planet-drupal/6x-mich , but it's not connected
<garyvdm> Ok - let me have a look at thems
<garyvdm> *them
<RockyRoad> I need to build a common ancestor
<RockyRoad> not reverting to previous development stage
<RockyRoad> those 0.x revisions in yellow are added recently to describe older project steps
<RockyRoad> so logically, I would prefer to see them _below_ rev 1 in black
<RockyRoad> but the connection line is fine
<garyvdm> Ah - so you want to change them into one history?
<garyvdm> Yes - you can do that with bzr-rebase
<RockyRoad> this part is ok, but I'd like to connect
<RockyRoad> lp:~m-baert/planet-drupal/6x-mich to the same history
<RockyRoad> because I will need to merge its rev 24 after black rev 25
<RockyRoad> there's not much difference in code, but i'd like to keep its revision logs
<RockyRoad> on my graph, I showed a lot a "manual merges" , which can't appear in qlog, because they didn't use bzr merge, and were often partial
<RockyRoad> it's explained in rev logs
<garyvdm> So you've got 3 options 1. Merge black in to yellow an push that your dev focus (yellow then becomes your main line).
<RockyRoad> yellow is the main line
<garyvdm> 2. Merge yellow into black  - and push - black stays you main line
<garyvdm> or
<RockyRoad> yellow and black are fine as is
<garyvdm> use rebase so that the black line follows on from rev 3 of the yellow line.
<RockyRoad> I just miss a third color
<RockyRoad> I thought about rebase, but I couldn't understand well if it was the thing I needed
<RockyRoad> and how to use
<RockyRoad> it
<RockyRoad> rebase 6x-mich to planet-6x
<RockyRoad> If I didn't merge black25 in yellow trunk, it's just because it's not ready yet, from a dev point of view
<RockyRoad> I could merge easily its rev 9, so I guess there's no problem to merge rev 25
<RockyRoad> that because I used from planet-trunk$ bzr merge -r0..1 lp:planet-drupal/planet-6x
<garyvdm> Yes
<garyvdm> How come you created the .moved files?
<RockyRoad> with this exact step
<RockyRoad> merge -r0..1
<RockyRoad> a matter of file-id that vila explained me in detail friday
<garyvdm> Ok
<garyvdm> I wonder if it is possible to specify when you do a cvs import to specify that it must use the file ids from an existing branch?
<RockyRoad> it's not a big issue, humans could quickly see the files are identical
<garyvdm> but if you do bzr log file, or bzr annotate file, the history will stop at that merge.
<RockyRoad> As I understood, it's intentional to forbid that
<RockyRoad> (file-id trick)
<RockyRoad> it's not a big problem
<garyvdm> So I think what I would want to do is redo the cvs import, and get it to use the bzr file-id's
<garyvdm> Then you can rebase the start of the black line on the the end of the new cvs import.
<RockyRoad> My problem is not here
<RockyRoad> I need to link a _third_ branch
<garyvdm> Oh - which is?
<RockyRoad> lp:~m-baert/planet-drupal/6x-mich
<garyvdm> but that is exactly the same as lp:~m-baert/drupal-planet/6.x
<RockyRoad> yep
<RockyRoad> just copied in the new project
<garyvdm> What do you mean by link?
<RockyRoad> something like merge -r0..1
<garyvdm> But they are the same - so you don't have to do any thing.
<RockyRoad> I need a common ancestor between planet-drupal/planet-6x and planet-drupal/6x-mich
<RockyRoad> to be able to do future merges
<garyvdm> You don't need to do any thing.
<garyvdm> You will be able to merge.
<RockyRoad> ok I retry
<RockyRoad> It sounds like it could do it but but renames+add again
<RockyRoad> that's more an issue at this stage
<garyvdm> RockyRoad: No - if you make a change to lp:~m-baert/planet-drupal/6x-mich, and one to lp:~m-baert/drupal-planet/6.x, you should be able to merge one into the other with out any problems.
<RockyRoad> http://pastebin.com/d711d6fd7
<RockyRoad> I don't need to merge 2 copies of the same branch that I own
<RockyRoad> I don't think so ...
<RockyRoad> oh no the moves don't concern the program files, it's ok
<RockyRoad> doc subdir is all my own
<RockyRoad> these are "ordinary" conflicts
<RockyRoad> but I find it mysterious why I can do it here what I couldn't on other branches ...
<RockyRoad> old command: bzr merge -r 1 lp:~m-baert/planet-drupal/planet-6x
<RockyRoad>  # bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<garyvdm> Ok - I said lp:~m-baert/planet-drupal/6x-mich was the same as lp:~m-baert/drupal-planet/6.x
<RockyRoad> from  planet-trunk
<garyvdm> lp:planet-drupal/planet-6x and lp:~m-baert/planet-drupal/6x-mich are differnet - although they do have a common ancestor.
<garyvdm> Let me look further at the errors
<garyvdm> So David Giard manualy added doc.
<garyvdm> Had he done a merge (or a cherry pick merge) from your branch, then there would not be a conflict.
<RockyRoad> No
<RockyRoad> oops
<garyvdm> Because he did it manually, the file id's of the doc folder are differnent
<RockyRoad> no problem
<RockyRoad> That's interesting
<garyvdm> Ok - I must go
<garyvdm> I hope I was a help
<RockyRoad> ok thanks a lot for your patience and help :)
<RockyRoad> I'll force a commit right now to check ..
<garyvdm> It's a pleasure.
<Glenjamin> hey guys, is there any way to set the default external diff options?
<ddaa> use an alias
<Glenjamin> can i alias diff to di --diff-options=whatever ?
<LarstiQ> Glenjamin: yes
<LarstiQ> Glenjamin: see `bzr help alias`
<Glenjamin> excellent, thanks
<Glenjamin> i read the help, it doesnt mention replacing default commands
<cody-somerville> Glenjamin, I just tried it, like you could have, and it lets you set aliases that override default commands
<LarstiQ> cody-somerville: I suppose an example could be included that does that
 * cody-somerville nods.
<LarstiQ> cody-somerville, Glenjamin: either of you interested in submitting a patch that does that?
<FryGuy-> is it normal for bzr resolve to need to specify the full file name for each file to resolve?
<LarstiQ> FryGuy-: instead of what?
<FryGuy-> just doing bzr resolve
<FryGuy-> maybe it's just a windows problem
<FryGuy-> i think i recall that there are a few places where wildcards don't work properly
<LarstiQ> FryGuy-: if you want to resolve a specific file, `bzr resolve path/to/file`, if you want to autoresolve what you can, just `bzr resolve`, if you want to force everything, `bzr resolve --all`
<FryGuy-> hmm
<LarstiQ> FryGuy-: if you're expecting that `bzr resolve` clears all conflicts, maybe the detection thinks it can't resolve yet
<LarstiQ> that, or you might indeed have found a bug
<FryGuy-> well in this case, i don't know how i can resolve it
<LarstiQ> FryGuy-: could you pastebin `bzr conflicts` output?
<FryGuy-> this happened at work, i'm trying to reproduce it
<FryGuy-> k i got it
<FryGuy-> http://pastebin.com/m4efe2a77
<FryGuy-> on my work computer i've also gotten into cases where the conflict on switch happens, and it completely breaks the locks
 * LarstiQ blinks
<LarstiQ> FryGuy-: and what is someproject
<LarstiQ> ?
<FryGuy-> http://pastebin.com/m27652c7c
<FryGuy-> there's how I reproduced it
<FryGuy-> er, excluding ilne 5
 * LarstiQ can reproduce that on Debian too
<LarstiQ> FryGuy-: so yeah, you certainly found a bug there
<LarstiQ> FryGuy-: however, if you explicitly `bzr resolve someproject`, that should get you out of the immediate situation
<asabil> hi all
<LarstiQ> FryGuy-: I'm trying to make the case for reproducing it somewhat smaller
 * LarstiQ tries an alternative approach
<LarstiQ> FryGuy-: http://pastebin.com/d6453183c
<LarstiQ> FryGuy-: there is a chance that the switch mechanics are different, but I believe the bug is in shared code
<LarstiQ> ah, there are some differences
<mwhudson> jelmer: thanks for the bzr-git test fix :)
<mwhudson> are any bazaar developers working today? :)
<pygi> mwhudson: its sunday :p
<mwhudson> pygi: nonsense!
<pygi> mwhudson: uh, actually, I just lied
<pygi> its monday
<mwhudson> pygi: and has been for nearly 11 hours now!
<mwhudson> anyway, i figured things out myself
<pygi> mwhudson: no, only 47 minutes
<pygi> mwhudson: that's cool, share the findings :p
<mwhudson> pygi: bzr tests fail with an old subunit around
<mwhudson> (not very exciting)
<pygi> indeed :p
#bzr 2010-06-07
<jelmer> lifeless: hi
<poolie> hi igc, spiv, https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=udd
<poolie> hi all
<igc> hi
<jml> poolie, hi
<poolie> hi there jml!
<jml> poolie, you should unify some accounts: https://www.ohloh.net/search?q=martin+pool
<poolie> oh ok
<poolie> i did a bunch of them the other week
<poolie> jml, when was that stakeholder meeting going to be?
<jml> poolie, 21 June, 1800UTC
<poolie> ok
<poolie> igc, spiv, https://edge.launchpad.net/bzr/+milestone/2.2.0
<poolie> https://bugs.edge.launchpad.net/bzr/+bugs?field.searchtext=&orderby=-number_of_duplicates&search=Search&field.status:list=NEW&field.status:list=INCOMPLETE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&field.importance:list=HIGH&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<poolie> blah
<poolie> which is high priority bugs by number of dupes
<spm> new bug. LP needs shortly (cryptic) get request fields for sharing searches. Won't Somebody Think Of The IRC Channels!!!!
<spm> shorter. even.
<AfC1> Why does the Ubuntu package "bzr" depend on "bzrtools". Shouldn't that be "recommends" or something?
<jelmer> AfC: it doesn't depend on bzrtools
<jelmer> AfC: it's in the Recommends in the original debian package and as far as I can tell that hasn't been changed in ubuntu
<AfC> Oh. Have I done something wrong, then? I just did "apt-get install bzr" on a (very) fresh system and it dragged in bzrtools. I was a bit surprised by that
<poolie> i think apt is configured to install recommends by default
<jelmer> AfC: apt-get installs Recommends by default these days
<poolie> there's a way to change this-
<AfC> ew
<poolie> jelmer do you think https://bugs.edge.launchpad.net/bzr/+bug/481748 is now ready to implement based on the list discussion about revision specs in urls?
<ubot5> Launchpad bug 481748 in bzr-builder "revspecs in recipes should be part of the URL (affected: 1, heat: 6)" [Low,Triaged]
<poolie> hm
<jelmer> poolie: yeah, I think so. Though that'll also need some generic work on supporting extra arguments in URLs
<poolie> it's a bit hard to find
<jelmer> AfC: aptitude -R will ignore recommends
<jelmer> I'm not sure if -R will work for apt-get
<AfC> jelmer: thanks, will try that
<AfC> brb
<lifeless> jelmer: hi?
<lifeless> jelmer: I'm back off out in a minute, perhaps more content than ping, and I'll reply when I get back :)
<poolie> afc, you can set something in /etc if you want this permanently
<poolie> cheerio lifeless
<lifeless> hi poolie
<lifeless> poolie: I think I have the same hardware issue you had
<poolie> hi there!
<lifeless> loose cpu heatsink
<poolie> ah, really?
<lifeless> my games machine is powering off frequently
<poolie> after yours was posted across the tasman?
<lifeless> yes
<lifeless> :(
<poolie> erk
<lifeless> it was -very- occasionally doing it first
<lifeless> and I've inspected the CPU heatsink, and one corner screw is loosish
<poolie> i'm still waiting for the 2GB DDR3 to come in so i can get it rebuilt
<poolie> mm mine were too
<lifeless> its a twist-lock thing
<poolie> and i just kind of shrugged
<poolie> right
<lifeless> but that one won't lock firmly
<poolie> exactly
<lifeless> yeah
<lifeless> I'm going to take a little time tomorrow
<lifeless> and drop this in to get addressed
<lifeless> also
<poolie> heh i just found in my office the other day one of the special torx keys to tighten an ia64 heat sink
<lifeless> we've put an offer in on a house
<poolie> _that_ won't come loose :)
<poolie> congrats
<spiv> Ooh :)
<lifeless> so I need to do a little run around dance for that with lawyers, inspectors etc
<StevenK> lifeless: Nice!
<poolie> mm
<poolie> so we had a look here into https://bugs.edge.launchpad.net/bzr/+bug/582157
<ubot5> Launchpad bug 582157 in Bazaar "pull from launchpad is slow (affected: 1, heat: 6)" [High,In progress]
<poolie> without really reproducing it
<lifeless> poolie: long story short - I'll be around on basically .au hours tomorow
<poolie> istm there are two classes of problems here
<poolie> ah you're not working so i won't bother you with it
<lifeless> poolie: cool, thank you for pulling on the string
<poolie> ok, np
<lifeless> no, no bother
<lifeless> its not like Canonical has traditional boundaries
<poolie> ok so the two classes are: things where we know we're going slower than we should; and secondly things where we are unexpectedly slow
<poolie> this bug would be in the second class
<poolie> we have some ideas for shots in the dark that are probably useful anyhow, and for improving debuggability/supportability
<lifeless> I can't wait for steams Linux port.
<lifeless> one thing I thought of doing
<lifeless> as a fairly immediately useful thing
<poolie> after that, i'm going to put this back to incomplete
<lifeless> was to make a per-invocation server side log
<poolie> mm
<poolie> so the ideas were
<poolie> 1- use a socketpair to the ssh client, not a pipe
<lifeless> that is, $ISO16whatever-$PID.log in ~/.local/bzr/ or some such
<poolie> - not proven to fix this but a generally good idea; may alleviate poor blocking behaviour
<poolie> ok
<poolie> that's good too
<lifeless> and then get that cherrypicked into LP production, add -Dhpss on the server side and get the logs synced every 5 minutes or so
<poolie> 2- when TERM=spiv, server sends its hpss log over stderr so you can see on the client where it thinks it's spending time
<lifeless> so we could see chunking, groupcompress stats etc
<poolie> 3- log into that how much cpu time we spend per request
<poolie> right
<poolie> this would be quicker than getting it off lp via losas etc
<lifeless> I like the idea of getting more data
<lifeless> I think we should aim for getting more data all the time
<poolie> 4- print a few more stats at the end: number of rpcs, number of ~mtu and <<mtu read() responses
<lifeless> so that when someone says 'man it was slow this morning', we can see why
<lifeless> that doesn't conflict with getting more in an immediate mode like you are describing
<poolie> right
<poolie> and i think that's it
<lifeless> I agree that that bug should be used for 'lp is slower than bzr+ssh in general'
<lifeless> I'm not sure where 'bzr+ssh around the world is slower than bzr+ssh locally' should go, if anywhere.
<lifeless> [one theory about bzr+ssh performance is window choking on the tcp links - I was doing tcptrace analysis with spm a couple weeks back on this]
<poolie> ah
<poolie> that's possible
<lifeless> on spm's recommendation I filed an RT ticket to increase the buffer limits on chokecherry or whatever the server is
<poolie> crowberry?
<lifeless> its in the lp queue if you want to dig it up
<poolie> i wish the machine list page was up to date
<lifeless> $suitablemachinename
<poolie> and did you actually find anything from tcptrace?
<poolie> i was just wondering if there was a machine like that
<lifeless> was something a little suspicious, then PPing
<lifeless> then looming
<lifeless> that said, changing on crowberry live isn't the best place to test theories
<poolie> using a socketpair may help there
<poolie> right
<lifeless> so we'll want to repurpose tungsten probably
<lifeless> to be a testbed
<poolie> something tcp related would be compatible with different people observing very different results
<lifeless> I'm not sure why a socketpair would help
<poolie> i think that they allow partial reads while a pipe does not
<lifeless> interesting
<poolie> imbw
<poolie> oh the other possibility is that it's load-related on the server
<lifeless> holy cow steam installs fast on SSD
<lifeless> yes, load is a big concern
<poolie> under windows?
<lifeless> cedega
<lifeless> more detailed logs would let us ascertain the concurrent bzr processes, and their activity, after the fact
<StevenK> lifeless: What were your thoughts as bzr's TestCase as a fixture?
<lifeless> *blink*
<lifeless> StevenK: what do you mean
<StevenK> lifeless: Context is your comment on this MP: https://code.edge.launchpad.net/~stevenk/launchpad/poppy-sftp-test-isolation/+merge/26717
<vila> hi all
<spm> hey vila!
<vila> spm: _o/
<thumper> what is the simplest way to get a time zone aware datetime object for the revision time?
<thumper> a revision has a timestamp and timezone
<thumper> is there a simple way?
<vila> thumper: My memory may be a bit dusty, but I think I recall that the timezone and datetime should be supplied both or none of them
<vila> thumper: so, short answer: no
<thumper> is the timestamp of the revision in UTC or local time?
<vila> gee, let me check, I'd say UTC, but I'm sure there are tests for that
<vila> thumper: I was wrong, it's in local time (AFAICS)
<thumper> vila: I think I'm going to agree with your first answer
<thumper> vila: it is UTC
<thumper> if I go: datetime.utcfromtimestamp(r.timestamp) it is right
<thumper> where r is a revision object
<vila> thumper: you checked that with a timezone != 0 ?
<thumper> I'm not sure why a timezone is also recorded
<thumper> r.timezone is 43200
<thumper> hang on
<vila> it's a shame it's not better documented anyway :-/
 * thumper is a little frustrated
<thumper> it seems to be UTC
<thumper> even though a timezone is recorded
<vila> hmm, so I looked at the wrong place and we may have bugs there..
<vila> but looking at how log process that, yes, it seems to be UTC
<sivang> hi
<sivang> so, I have 2 branches who have diverged for some unclear reason.
<sivang> nor merge or dif --old shows anythinig useful,
<sivang> besides that my current branch is all extra to the push location - which was not like this before my laptop commit.
<sivang> How to solve this?
<jelmer> sivang: have you tried "bzr missing" ?
<jelmer> that should tell you the revisions that are present in one branch but missing in the other
<mwhudson> vila: when are you arriving in cambridge?
<vila> mwhudson: tomorrow, around ~14h30 if all goes well
<mwhudson> vila: ok
<sivang> jelmer: I have, it suddenly shows me that all of the commits on the local branch I am working on are extras
<parthm> mgz: thanks for the bzr-grep patches. i am going through no-match-fast path right now.
<jelmer> sivang: that certainly explains why it's giving you that error
<sivang> jelmer: right, but how is that that suddenly all those revision are extra?
<sivang> jelmer: this wasn't so a day before.
<sivang> jelmer: so it seems the only way to solve this is to rebranch
<jelmer> sivang: Have you perhaps rebase your branch or something like that?
<sivang> jelmer: not that I know of.
<sivang> jelmer: This should be explicit enough for me to remember, from a bzr user POV
<sivang> :)
<sivang> jelmer: I'm rebranching, this takes too long to resolve with no apparent stuff to merg
<sivang> jelmer: e.g. merge says there's nothing to do
<C-S> ls
<C-S> parthm: are you there?
<parthm> C-S: hi
<feckser> in .bzr/repository/indices I have many duplicate files.  Can I unlink or hard link them all?
<feckser> and not break anything?
<maxb> feckser: This should not be the case
<maxb> feckser: I suggest pastebinning the output of 'ls -lR .bzr/repository/' so people here can understand the situation better
<feckser> maxb: what should not be the case?  There should not be binary duplicate indices?
<maxb> It's pretty unexpected, yes
<feckser> http://www.pastey.net/137418-3kta
<maxb> feckser: What? All your concern is about 4 60-byte files?
<maxb> stop worrying
<feckser> maxb: they obscure the duplicate list.
<feckser> They make it harder to process removal of duplicates.
<maxb> huh?!
<feckser> When I perform a search for duplicates they are always returned.
<maxb> So? Why does this bother you?
<feckser> It makes the process of finding and removing unwanted duplicates harder
<feckser> and that was only an example.  There are more in other bzr repositories.
<maxb> Unless you can find duplicates of substantial size, I feel this is a non-issue
<feckser> maxb: it is not just about finding duplicates in bzr repositories, it is about finding them all my files.
<feckser> some of the directories under ~ are bzr repositories.
<maxb> Make your dupefinder ignore .bzr then
<feckser> inore list
<feckser> it has no ignore list
<maxb> Personally, I see no problem with Bazaar happening to produce identical byte content in a few small files as an implementation detail
<feckser> I did not say it was a Bazaar problem.  I asked whether I can delete them without harm.
<maxb> Answer: no
<feckser> Can I hard link them without harm?
<feckser> The duplicate finder (fdupes) smartly considers multiple links to same file as not duplicates.
<vila> feckser: don't ever hardlink these files, they contain the signatures (and appear to be empty in your case). If you start signing your commits... they won't be empty anymore
<feckser> vila: so as long as I don't sign, they can be hard linked or removed?
<vila> feckser: no, their presence is mandatory
<feckser> vila: hard linked?
<vila> feckser: if you hardlink them, you will be doomed the day someone in the project sign a commit
<exarkun> it really sounds like you want fdupes to have an exclusions list :)
<vila> feckser: besides, new ones will be created when the repo is repacked
<meoblast001> hi
<meoblast001> i'm having more issues with obtaining the directory of a branch
<meoblast001> this result.branch.base isn't cutting it anymore
<meoblast001> because "filtered-154314860:///bzr/~mysticgalaxies/citrine-blender/" is not a file path
<meoblast001> at least not to me it isn't
<meoblast001> hm, a lot of stuff is undocumented
<meoblast001> i can't even find Branch.base in the docs
<lifeless> meoblast001: branch.base is in the api docs
<lifeless> pydoc bzrlib.branch
<lifeless> ...
<lifeless> :ivar base: ...
<lifeless> meoblast001: that filtered: prefix is the soft chroot I was telling you about
<lifeless> meoblast001: and why taking a suffix is needed, or unwrapping the filtering
<lifeless> meoblast001: or, taking a config option from the branch (which I think is preferrable anyway)
<lifeless> meoblast001: but you'll know what works best for your needs
<meoblast001> lifeless: oh, why wasn't it in these docs http://people.canonical.com/~mwh/bzrlibapi/bzrlib.branch.BzrBranch7.html
<meoblast001> hm, those seem to be personal docs
<meoblast001> nvm
<lifeless> http://people.canonical.com/~mwh/bzrlibapi/bzrlib.branch.Branch.html
<meoblast001> ah
<lifeless> looks like a bug in pydoctor
<meoblast001> config option?
<lifeless> its showing inherited methods
<lifeless> but not inherited variables
<lifeless> attributes I mean
<lifeless> meoblast001: config option - setting a key in branch.conf that you can look for
<meoblast001> lifeless: does Bazaar call plugins with .bzr as the working directory or is there something i need to use to set and get keys in branch.conf?
<lifeless> branch.get_config()
<meoblast001> hm, undocumented
<lifeless> its a decorator
<meoblast001> decorator?
<lifeless> I think
<lifeless> ah no, it is genuinely undoced, I'll fix
<meoblast001> lifeless: does that return a bzrlbi.config.Config?
<meoblast001> bzrlib*
<lifeless> bzrlib.config.BranchConfig
<lifeless> which has get_config, set_config etc apis
<meoblast001> lifeless: i seem to have a limited array of options
<meoblast001> i see no get_config or set_config
<meoblast001> i see get_user_option
<meoblast001> but not even a set_user_option
<lifeless> http://people.canonical.com/~mwh/bzrlibapi/bzrlib.config.BranchConfig.html
<lifeless> there is a set_user_option
<lifeless> and get_user_option
<meoblast001> ah, at top
<lifeless> as well as typed methods for email, signature checking, aliases and so on
<meoblast001> lifeless: so i want to use those, correct?
<lifeless> in your plugin you want to use get_user_option
<lifeless> you can just set the value in branch.conf with a text editor
<meoblast001> result.branch.get_config().get_user_option ('blahblahblah')
<lifeless> yep
<meoblast001> since the return value of that get_config() is still sort of ambiguous
<meoblast001> ok, thanks
<lifeless> generally speaking that will return None if the option isn't set
<mgz> ah, a lifeless.
<mgz> did you suggest I look at testrepository for my traceback matcher thing?
<lifeless> yes
<lifeless> testrepository.tests.matchers.MatchesException
<lifeless> needs a little more suger
<lifeless> sugar
<mgz> will grab and look at.
<mgz> hm, yeah, that's looking at exc_info
<lifeless> possibly it should be built via composed subclass/equality style matches for each element of the tuple
<mgz> which isn't a bad thing in general, but in this case we care about how the strings actually get passed through to the final stream
<mgz> having something that takes an input of extract_tb style tuples might be okay though
<meoblast001> lifeless: ok, thanks... and i should have the config option set manually?
<lifeless> yes
<TresEquis> lifeless: how goes the househunt?
<lifeless> great
<TresEquis> cool
<maxb> So, if you have a branch, stacked on another branch, and the base branch has been upgraded to 2a but the stacked one is still 1.x .... can you recover?
<lifeless> yes
<lifeless> upgrade the stacked one
<james_w> lifeless: testr is pretty cool, thanks
<lifeless> james_w: thanks!
<lifeless> I'm glad you like it
<james_w> lifeless: I'd prefer different output, like a big green light when all the tests pass
<lifeless> james_w: I'd be delighted to incorporate patches
<lifeless> if you wanted to include an arduino control module to drive a traffic light, we could even include that
<james_w> heh
<lifeless> did you see that?
<james_w> I saw one that did lava lamps
<james_w> I ported soupmatchers to use the discovery stuff today, makes for a pretty nice setup.
<lifeless> awesome
<lifeless> could you comment on the testtools bug about how that hangs together ?
<james_w> I find the output on failure a little unpleasant, but can live with it
<lifeless> or in some fashion write it up? That would be _most_ useful
<james_w> sure
<james_w> lifeless: if you could review the merge proposal that would be great
<lifeless> which one ?
<lifeless> bah
<lifeless> which one ?
<james_w> lifeless: https://code.edge.launchpad.net/~james-w/subunit/discovery/+merge/26893
<lifeless> thanks!
<lifeless> I shall peruse
<lifeless> james_w: ah, I see
<james_w> lifeless: feel free to suggest alternative implementation strategies, it was more of an exploratory hack, but it works :-)
<lifeless> so TestProgram can take the name of a callable
<lifeless> or callables
<lifeless> one way to do discover would be:
<lifeless> make a series of callables, assign them to global names
<lifeless> globals()[thunkN] = lambda:loader.discover(arg, pattern=options.discover_pattern)
<lifeless> or something like that
<lifeless> I don't think what you've done is all that ugly
<lifeless> have a play, see what you think
<lifeless> if you decide that the current stuff is better
<lifeless> then lets ditch TestProgram entirely
<lifeless> so that we don't have two different paths.
<lifeless> ideally though, lets get a fixed TestProgram class in that file, which we can use appropriately, and submit a patch to python to make the stdlib one sufficient.
<james_w> ah, you're saying that TestProgram should be able to take a list of callables, rather than it being a current feature?
<lifeless> no
<lifeless> it currently takes a list of names
<lifeless> and does introspection
<lifeless> see the testr.conf for testrepository, for instance
<lifeless> (testrepository.tests.test_suite)
<lifeless> oh bleh
<lifeless> yes
<lifeless> I'm saying that if we need to change TestProgram to accept callables as well as names
<lifeless> or some such
<lifeless> then we should
<lifeless> or if we need to separate the concerns more
<lifeless> then we should do that
<lifeless> james_w: to put it most broadly:
<lifeless>  - subunit.run should be a trivial change to testtools.run
<lifeless>  - testtools.run should be a trivial wrapper for python's TestProgram
<lifeless> so lets make things better up the stack, and where we have to wait for patches to be accepted / propogate to old versions etc, we should have a subclass that implements what our patch does, with a 'XXX: delete when python2.7 is the oldest version we support', or similar.
<james_w> right
<james_w> I don't see TestProgram taking a list of callables right now
<lifeless> agreed
<lifeless> it does take a list *of the names of callables*
<james_w> right
<james_w> but serialising the discovered tests back to that seems wrong
<lifeless> so here's the review - please change subunit to use testtools more, it hasn't needed to for run as it was sufficient in the stdlib
<lifeless> and do the discovery work in testtools
<lifeless> and in testtools; either:
<lifeless>  - subclass TestProgram and make it more suitable
<lifeless>  - use a thunk to pass to TestProgram
<lifeless> james_w: it wouldn't be serialising
<lifeless> james_w: it would just call indirect the call to discover; I don't have a preference though
<james_w> should we push --discover in to TestProgram?
<lifeless> ultimately, yes. In fact 2.7 may do that already
<lifeless> so it may be a 'copy from python' case
<lifeless> as far as licencing goes
<lifeless> testtools is license compatible with python, deliberately.
<lifeless> so is subunit.
<lifeless> just need to update the list of external copyright holders in the docs.
<james_w> it doesn't yet, I was just checking that
<james_w> oh, hang on
<lifeless> I'm sure 2.7 supports discovery in some fashion
<james_w> it does
<lifeless> COPYING has the external copyright refs
<james_w> but not --discover
<james_w> it would be "python -m testtools.run discover"
<lifeless> thats ... interesting
<lifeless> uhm
<lifeless> I don't have a strong opinion here, if it works +1. If its maintainable +1. If its the same as python has ended up upstream thats nice; if you think its nicer to be different, thats ok too.
<lifeless> Just, where we are different, put patches forwardds.
<lifeless> if you think we should try it differently, and decide later what is nicest, thats fine too - we can put a patch in once we are convinced one way or the other.
<lifeless> back shortly, popping down to the bank.
#bzr 2010-06-08
<james_w> lifeless: is https://code.edge.launchpad.net/~james-w/testtools/discover/+merge/26994 something like what you had in mind?
<igc> morning
<lifeless> moin moin
<mgz> lifeless: on the topic of testtools.run from earlier,
<mgz> is there any good reason why it can't just be `python -m testtools`
<poolie> hi mgz
<mgz> and import the stuff from testtools.run in __name__ == '__main__' in __init__.py
<mgz> hey poolie.
<lifeless> mgz: no good reason either way
<lifeless> mgz: I will say, I somewhat prefer testtools.run
<lifeless> grabbing all the possible contexts as the default for testtools seems... crude
<poolie> hi lifeless
<lifeless> mgz: is it functional/aesthetics/other ?
<lifeless> hi poolie
<mgz> moving it is an easy way to fix 501174
<mgz> *bug 501174
<ubot5> Launchpad bug 501174 in testtools "Suggest alternative to python -m testtools.run for Python 2.4 (affected: 1, heat: 6)" [Critical,Triaged] https://launchpad.net/bugs/501174
<mgz> the actual code can still be in run
<mgz> I just want to -m the package root.
<lifeless> oh
<lifeless> mgz: yes, I get what you want :)
<lifeless> and its a functional difference for you
<poolie> ah, makes sense to me
<lifeless> mgz: sure, to make it work on 2.4 the little ugliness is ok
<lifeless> mgz: uhm, what do you think of
<lifeless> python -m testtools run <args>
<lifeless> and
<lifeless> python -m testtools.run <args>
<lifeless> both working
<mgz> sounds fine to me, should be easy to arg wrangle.
<mgz> especially as the james_w branch is making the __main__ code the ideal one line
<lifeless> I'd be happiest with that
<mgz> ...two lines. would fit on one though :)
<lifeless> because that way when 2.4 finally keels over
<lifeless> we can do other stuff
<lifeless> and if we have other front ends to add, they aren't squashed out
<james_w> 2.4 can't do -m something.dotted?
<mgz> nope, and I was confused too when I tried it.
<mgz> it's not something other packages I've wanted to use have gone for, no idea about it till I was trying testtools
<lifeless> right
<lifeless> james_w: yes, bug in 2.4, it assumed top level module.
<mgz> hm, might just try that now see what it looks like
<mgz> urk, that might not be a fix, seems to only want <module>.py not <module>/__init__.py
<lifeless> ah
<mgz> will just have to note in the documentation I guess.
<lifeless> so really not supporting modules :)
<mgz> poolie: ericmoritz was talking about calling Feature.available() because he wanted to skip if a feature *was* present
<mgz> but that wasn't the right test anyway.
<mgz> ah, whoops.
<poolie> igc1, hi there?
<mgz> guess I should repeat that, though not very important
<mgz> poolie: ericmoritz was talking about calling Feature.available() because he wanted to skip if a feature *was* present
<mgz> but that wasn't the right test anyway.
<poolie> oh ok
<poolie> hm, perhaps we should define an inverse feature then
<poolie> but that would be ok
<Stavros> hello
<Stavros> i had revision 20 on repo A, worked on repo B up to revision 40, bound B to repo A and all my revisions past 20 are gone
<Stavros> how can i get them back?
<Stavros> hmm, they are on B
<Stavros> that's odd
<lifeless> spiv: poolie: I think, on reflection, that any inheritance from Branch/Repository etc in remote.py is actually harmful, not beneficial
<spiv> lifeless: hmm
<spiv> lifeless: one of those two don't inherit
<lifeless> yes
<spiv> lifeless: and it's increasingly causing problems too
<lifeless> and we've been muttering that it should
<lifeless> I'm thinking it shouldn't more and more as I address this loom bug
<spiv> So inheriting in remote.py: not great.  Not inheriting: also not great.
<spiv> I wonder what the solution is.
<lifeless> consider sprout
<lifeless> what we want is:
<lifeless>  - no VFS for the default case
<lifeless>  - VFS if the smart server can't do what the branch needs
<lifeless>  - ideally smart in all cases
<lifeless> sprout is currently a method on e.g. Branch
<lifeless> we define sprout on RemoteRepository
<lifeless> not on Branch
<lifeless> and because of that Branch.sprout doesn't copy loom data across
<lifeless> I discussed a structured approach with poolie
<lifeless> but I'm not entirely happy with how it felt
<spiv> I think we haven't got sprout right in terms of which objects are responsible for the various parts of it.
<spiv> And the trouble with Remote + loom is a symptom of that.
<lifeless> it might be better with an Inter
<lifeless> and be on the format object
<lifeless> so it could do self._format._ensure_real()
<lifeless> self._format.sprout(...) and that lookup on the ...
<lifeless> anyhow, I think I'm going to:
<lifeless> sorry, sec
<poolie> lifeless, i think those base classes should become abstract
<poolie> many of them iirc have a lot of historical stuff near the top of the class hierarchy
<lifeless> poolie: I agree but I think that that is perhaps orthogonal
<lifeless> and that we should look for reuse in the Remote* hierachy through composition or something
<lifeless> thoughts on moving sprout from Branch to BranchFormat ?
<lifeless> its only use of self is self.copy_content_into
<lifeless> which the format could happily call
<lifeless> and we have [at least for now
<lifeless> ] established free access to Format objects for bzrdir components
<spiv> lifeless: reuse through composition sounds like a very plausible idea to me
<poolie> let's say complementary
<poolie> i think if you need to make them composable perhaps you need to move them out of the base class
<poolie> anyhow, hooray for cleaning it up
<lifeless> well I don't know how much cleaner it will be
<lifeless> did either of you have thoughts on the proposed move of sprout ?
<poolie> ah
<poolie> to the BranchFormat base class?
<lifeless> from Branch to BranchFormat
<lifeless> where differences exist
<lifeless> I propose to put it on appropriate BranchFormat subclasses
<lifeless> and on RemoteBranchFormat, we can then delegate to the actual Format
<poolie> sorry for the lag
<poolie> so you'll call effectively source_branch.format.sprout(to_transport)?
<lifeless> yes
<lifeless> for compat
<lifeless> we can leave Branch.sprout in place, deprecated
<poolie> and why is this better?
<lifeless> and it would call that as self._format.sprout(self, to_transport)
<lifeless> because we know the format of remote branches even if we haven't done _ensure_real on the Branch
<lifeless> so we can run the right code for looms without triggering VFS for regular branches
<poolie> hm
<poolie> i kind of see the problem you mean
<poolie> i think the public api that makes sense is probably branch.sprout(to_transport)
<poolie> i don't see why the caller would want to work in terms of the format
<spiv> In short: sprouting needs to take the format into account, and making the format responsible for sprouting takes care of that?
<lifeless> uhm
<poolie> now behind the scenes there are some issues about perhaps not yet knowing the remote format
<lifeless> so sprout as currently defined sprouts to a to_bzrdir
<lifeless> which is, I think ok
<poolie> ok
<lifeless> it needs to:\
<lifeless>  - make a new Branch in the bzrdir, which is a little complex.
<lifeless>    - it might be the same as the source format
<lifeless>     - or there might be some magic kick in to ensure it supports something that the default doesn't
<lifeless>  - it needs to copy the metadata from the source branch across
<lifeless> if you look at branch.py, at sprout
<lifeless> you can see that its ~15 lines
<lifeless> only one of which calls self.*
<lifeless> thats not a very strong argument, but its data
<lifeless> secondly, ideally, the copying of metadata would be a multimethod
<lifeless> on source,target
<poolie> right
<lifeless> and we can for such source, targets either use the Branch objects or the BranchFormat objects
<lifeless> now, BranchFormats are the unique things on disk
<lifeless> we guarantee that there are unique network strings for any given format, we don't guarantee that for Branch subclasses
<lifeless> its possible to use the same Branch class, parameterised, to handle two different Formats
<lifeless> I don't know if we use that, but that was part of the goals in the early design
<lifeless> so perhaps it wouldn't work now and we should discount it
<poolie> as i've said before there seems imperfect separation between formats and branch classes
<poolie> ah
<poolie> one could have a branch class that delegates absolutely everything to its format and could be used with every format
<poolie> i'm not sure why that would be useful though
<lifeless> that would be an extreme
<lifeless> Formats are factoried for Branch objects
<lifeless> so a BranchFormat can *parameterise* a Branch with appropriate delegated objects
<lifeless> on construction
<poolie> conversely i suppose we could have a branchformat that actually knows nothing about the format other than its name and what Branch class implements it
<poolie> right
<lifeless> right, thats the other extreme
<poolie> i don't feel there is a clear principled statement of where we go between those extremes
<lifeless> now, I guess I'm saying that right now, sprout feels more like an interaction between the formats
<poolie> and it's not consistent between the two of them
<lifeless> poolie: to me, disk management code should go in formats (or in objects the formats supply), and model code should go elsewhere
* 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: spiv | bzr 2.1.1 is out | bzr 2.1.2 is having binaries built for it
<poolie> (changed pilot->spiv)
<lifeless> spiv: wearing the pilots-get-interrupted hat, perhaps you could do the followup on the release
<lifeless> the execution-of-announcements etc, if the binaries are all copacetic
<lifeless> [the topic change reminded me]
<poolie> basically agree about that, though probably i'd like it to be objects that are plugged into the branch
<poolie> ah
<poolie> so i still think in terms of the public api, the user has a "branch _this_ to _here_"
<lifeless> poolie: 'it'? 'like it to be'
<poolie> " disk management code should go in formats (or in objects the formats supply)"
<lifeless> poolie: ok, so 'disk management code should be in objects that are plugged into the branch' ?
<lifeless> poolie: you have an implied 'and not the formats' there, right ?
<poolie> i think doing code that amounts to self.format.get_something(self.transport) is a bit weird
<poolie> where self is a branch
<lifeless> I think thats true
<spiv> poolie: thanks
<poolie> however doing at startup, self.tag_manager = self.format.get_tag_manager(self.transport) feels a bit less weird
<lifeless> If delegating like that, i'd write it as self.format.get_something(self)
<poolie> perhaps you could propose some text suitable for the architecture overview that describes what you think the split should be between branch/repo/wt etc and their formats
<lifeless> poolie: separate objects for separate concerns is good too - tag manager is a great example of splitting that out
<lifeless> I sure can
<poolie> mm
<lifeless> I want to get looms working first
<lifeless> but I'll put a doc refresh right under that on the stack
<poolie> for example is all the knowledge about a disk format going to be in the format, or in a class that the format knows about and provides to the branch, or is it going to be in parallel hierarchies, etc
<poolie> ok
<poolie> so let's talk for a bit about fixtures?
<poolie> we might propose a merge into testtools that adds fixtures such that
<poolie> the test scope cleans up the fixture
<poolie> people are encouraged to put reusable setup into a fixture class, not into setUp() or the test_()
<lifeless> http://pastebin.com/Nxkpz8Tp
<lifeless> this is an in progress patch I have
<lifeless> which uses a fixture concept heavil
<lifeless> y
<spiv> lifeless: Ok, I'll take a look at release followup, although I doubt if I'll get to that today.
<lifeless> with a focus on composition
<poolie> heh
<poolie> i'm coming to really dislike Command pattern in python
<poolie> i wouldn't veto this just because of that
<lifeless> poolie: I'd love to see a small patch for testtools to aid with fixture use and definition, though I think its really very small and likely to bikeshed until we have some wider experience with it
<lifeless> poolie: I don't see this as Command
<lifeless> poolie: I see it as Composite, if you want to name it
<poolie> MirrorProposed, i mean
<lifeless> oh
<lifeless> well thats me following suit on the lp plugin style
<poolie> it's 90% overhead compared to just having a function
<poolie> and it seems to harm refactoring rather than helping it
<lifeless> other bits of the lp plugin do this, and I wanted to fit with the style in that area
<poolie> ok
<poolie> but "if not now, when?"
<poolie> i'm just mentioning it because i see it now
<lifeless> when its fully automatically testable ;)
<lifeless> fair enough
<poolie> set a good example rather than following a bad one :)
<lifeless> I'm not enamoured of it either :>
<poolie> i'm glad we agree :)
<poolie> igc liked the netflix slides too
<lifeless> cool
<lifeless> so, I'd love it if you had a think about what I do with fixtures in that patch
<lifeless> its not perfect, but I think it communicates where my thinking is at
<poolie> hm
<poolie> why is manyfixtures useful?
<lifeless> and thats the sort of thing I'd want to encourage with a testtools patch, wearing my testtools patch reviewer hat
<poolie> just faster than calling useFixture repeatedly?
<poolie> does testtools have a list?
<lifeless> testing-in-python
<lifeless> which is perhaps not appropriate
<lifeless> jml: ^ we should revisit that
<lifeless> poolie: I don't know (multifixtures) it seemed like a good idea at the time; because many fixtures might want to group a few bits together.
<poolie> i'd like to get my thoughts a bit more straight before posting there perhaps
<lifeless> poolie: I'm sure its not right, I'm also not sure its wrong.
<lifeless> back to sprout
<lifeless> I feel a little hamstrung
<lifeless> should
<lifeless>  - move it to BranchFormat
<lifeless>  - just accept the VFS overhead of doing it in-place
<poolie> this is because you want to have the same RemoteBranch but it will have a different BranchFormat if the remote thing is actually a loom?
<lifeless> I don't want to move it to BF and leave a forwarding method, because if the *contract* is on Branch, RemoteBranch can't safely forward unconditionally.
<lifeless> yes
<poolie> why not?
<poolie> i mean why can't it safely forward unconditionally?
<lifeless> because SvnBranch.sprout might not forward\
<lifeless> so RemoteBranch.sprout, with the real branch being an SvnBranch, wouldn't do the right thing anymore
<poolie> sorry, got to go, back in about 60m
<lifeless> ok I'm going to go drop my PC for repair
<lifeless> should be ~same
<lifeless> ciao
<poolie> igc, re test fixtures
<poolie> * "[Launchpad-dev] New feature in Launchpad TestCase base class"
<poolie> * https://code.launchpad.net/~mbp/bzr/testsubjects/+merge/24188
<poolie> * https://code.launchpad.net/~mbp/bzr/fixtures/+merge/25337
<willmarshall> BZR first-time user question!
<spiv> jelmer: you set a merge proposal to Queued.  PQM isn't using the queue in LP atm, you need to use the email method.
<poolie> http://www.mail-archive.com/launchpad-dev@lists.launchpad.net/msg03226.html
<poolie> spiv it's an easy mistake to make because feed-pqm still lets you queue them
<willmarshall> In git, if I have changes I want to store but don't want to commit to my main branch - I can do git branch mynew branch, work in that branch, then commit that branch to my git server and do a merge later
<poolie> we should disable it in the client
<willmarshall> How would I do the same thing in bzr - spawn a new branch, push that branch to the bzr server
<spiv> poolie: right
<poolie> willmarshall:
<poolie> bzr branch . ../otherthing
<poolie> cd ../otherthing
<poolie> bzr merge --uncommitted ../firstthing
<willmarshall> poolie: Yah - but that's just local branches on my dev box
<poolie> or alternatively if you just want to store it temporarily and not commit it, 'bzr shelve'
<willmarshall> I really need to push this branch to the bzr server so others can also work on it
<poolie> willmarshall, well, then commit in otherthing and push it to the server
<poolie> you need to push them separately
<willmarshall> without pushing it to the branch we're deploying from, cos it breaks stuff
<poolie> or as a third alternative use bzr-colo which is more like git colocated branches
<willmarshall> poolie:
<poolie> push it somewhere different
<willmarshall> Ah! So bzr doesn't quite work like git, and I am confused?
<poolie> it's not quite like git; i'm not sure if you're confused :-)
<willmarshall> The manual for bzr seems to be telling me that if I do bzr branch myrepo ./somedir
<willmarshall> And then work on that branch, commit and push
<willmarshall> My changes won't be in a new branch on the server
<poolie> willmarshall, they'll be in a separate branch on the server if you push them to a separate branch
<willmarshall> unlike in git, where branches have names and you can push to different branches in the same place
<willmarshall> Ok
<poolie> right, normally in bzr each directory has only one branch
<willmarshall> How do I spawn that branch on the server?
<poolie> unless you use bzr-coro
<poolie> *bzr-colo
<willmarshall> Oh! So this is is more svn-like?
<poolie> a bit, but it's not exactly like svn either
<willmarshall> Ok
<willmarshall> Gotcha
<willmarshall> bzr-colo sounds like what I need
<poolie> normally if you have bzr+ssh://server/repo/trunk
<poolie> then you can just do "bzr push bzr+ssh://server/repo/otherthing"
<lifeless> poolie: ah, you're back
<lifeless> poolie: so, I think I'm just going to move it around and see how it feels
<poolie> by all means
<spiv> lifeless: +1
<poolie> i really think that document would help
<lifeless> poolie: I think it will too
<poolie> it may help you and it will almost certainly help with review and with making things more consistent in future
<poolie> we don't want people moving different aspects at random
<lifeless> poolie: I'll be thinking about it all the time I'm moving stuff
<lifeless> oh
<willmarshall> poolie! Awesome. That worked
<lifeless> and my games machine - cpu heatsink was /way/ loose
<poolie> huh, funny coincidence
<willmarshall> Thank you very much
<poolie> np will
<lifeless> attached properly and its apparently fine now
<poolie> lifeless, is it scorched?
<lifeless> poolie: appears not; thermal protection in i7 is pretty good I'm told
<poolie> great
<poolie> how did they get it to reattach properly? remove it and re-add thermal pad?
<lifeless> nope
<spiv> Hammer? ;)
<lifeless> just twisted the thumbscrews, pushed firmly till they went clink
<lifeless> I'd been afraid to really push hard here, and not sure of the mechanics inside the plastic heads
<lifeless> apparently its like plaster screws
<lifeless> with a inner than locks open, and the original install [probably] never got it quite open enough to lock in place
<lifeless> back in .au I had been seeing thermal warnings from time to time, just figured it was linux slackness
<lifeless> but now, no warnings at all
<poolie> likewise
<poolie> how strange
<poolie> this makes me wonder if my machine could be fixed by just re-seating it, but perhaps at this point it really is scorched
<lifeless> what cpu was/is it ?
<poolie> E6600 Core2
<lifeless> so the question would be if intel's thermal protection changed much from there to i7
<lifeless> well worth trying, I'd say
<poolie> i might call and ask then
<Bigcheese> Is there really no solution to the memory problem when branching large subversion repos?
<Bigcheese> I need to branch from llvm, which has 105k revs. I'm already on a 64bit machine.
<lifeless> bac: have you tried doing batches, like - branch -r 5000 source target; cd target; bzr pull -r 10000; bzr pull -r 20000 etc ?
<lifeless> bah
<lifeless> Bigcheese: ^
<lifeless> sorry bac
<Bigcheese> heh
<Bigcheese> That's what I'm doing now, and it works, it's just going to take for ever with how small I have to increment.
<lifeless> what size are you incrementing in ?
<Bigcheese> Even one revision uses all 2 gigs of ram...
<Bigcheese> 100 right now.
<lifeless> thats surprising
<lifeless> are you perhaps using the root of the svn repo, rather than one specific branch?
<Bigcheese> I'm checking out trunk.
<Bigcheese> So no, just one branch.
<lifeless> thats very odd
<Bigcheese> Well, 1000 seems to work.
<lifeless> could you file a bug, its not meant to use that much memory :)
<Bigcheese> There's already one filed :P And it's talked about everywhere on the internet :P.
<lifeless> uhm
<lifeless> memory issues are a hydra
<lifeless> I find assuming that a previous bug 'x used lots of memory' is rarely a good indicator.
<Bigcheese> Searching the bug DB I've found at least 5 of the exact same thing. One even mentions you :P.
<lifeless> thats likely
<lifeless> we've had many causes of too much memory
<lifeless> some are large files
<lifeless> some are cache misuse
<lifeless> some are too many strings
<lifeless> to answer the question about whether there is a fix, we need to figure out what particular 'uses lots of memory' bug you have
<lifeless> so - for starters, what bzr version and bzr-svn versions do you have?
<Bigcheese> how do I check the bzr-svn version?
<lifeless> bzr plugins
<Bigcheese> http://codepad.org/1ToCN8jN
<lifeless> bzr 2.1.2 reduces memory consumption for some operations
<lifeless> might be worth trying
<Bigcheese> Is that only availible via source?
<lifeless> what platform?
<Bigcheese> Windows 7 x64
<lifeless> I can't see a 2.1.2 binary on https://edge.launchpad.net/bzr/+download yet
<lifeless> so yes, looks like source only
<lifeless> spiv: ^ btw may be a fast task to do the release - just send email :P
<Bigcheese> Thanks, I may try that if I this breaks again.
<Bigcheese> It's finally working 10k at a time,
<Bigcheese> So that's not too bad.
<spiv> lifeless: might be fast, but we're done for the day.  Will have to look tomorrow.
<spiv> lifeless: thanks for the idea
<lifeless> spiv: sleep well
<parthm> mgz: ping
<bouncingzip> indeed I did apparently.
<bouncingzip> do I bother looking up how to ghost myself on this network...
<mgz> parthm: hi
<parthm> mgz: thanks for the patches :)
<mgz> it's your own fault for copying all those loops, 's like waving a red flag to a pedant like me :)
<mgz> I'll see if I can get to doing unicode support at some point too, though there aren't any great options on that
<parthm> mgz: yes. :) performat_output looks good to me. should are apply it or are you planning to change something else.
<mgz> if it doesn't regress anything for you, land it
<parthm> mgz: ok. i cool. i will try it out.
<mgz> I'd be interested in if it's done anything bad to the profile in the cases I mentioned though
<mgz> tried to keep stuff doing what it was doing before, but did change a few things
<parthm> mgz: yes. i will try that. you patch is well timed, we get bug #590589 fixed as bonus :)
<ubot5> Launchpad bug 590589 in bzr-grep "UnicodeDecode error with -F -i (affected: 1, heat: 8)" [High,Confirmed] https://launchpad.net/bugs/590589
<mgz> was trying not to make anything slower in that branch so the follow-on speed up was still a win.
<parthm> mgz: UnicodeDecodeError for 'bzr grep ff' on mysql repo http://pastebin.com/JGfwXbk5
<mgz> doh!
<parthm> mgz: maybe line.decode(file_encoding, 'replace') can fix it? i can do that here.
<mgz> did I forget the "replace" on one of the lines?
<mgz> you're ahead of me.
<mgz> I... forgot it on all of them?
<mgz> too much moving things around, the (four) places I added that 's not really correct, but it's the simplest for the moment
<parthm> mgz: np. works fine now. updated on the four locations.
<mgz> guess I need to try harder to make a test that'll consistently fail on that as well
<GaryvdM> Hi all.
<parthm> mgz: at least we have some unicode tests now :) ... i should have added them in the first place. thanks for putting them in.
<parthm> GaryvdM: hi
<mgz> morning gary.
<GaryvdM> I have a corrupted dirstate file, an the branch has uncommited changes.
<GaryvdM> Bug #450047
<ubot5> Launchpad bug 450047 in Bazaar "AssertionError: get_next() called when there are no chars left in dirstate (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/450047
<GaryvdM> Any recomendations on how to recover.
<parthm> mgz: tested on emacs and mysql. works nicely. -Fi bug is also fixed. Yay!
<mgz> no smart ideas here gary. branch from somewhere else and copy over the working tree?
<GaryvdM> Ok - I mv .bzr/checkout .bzr/checkout.bck, and then did a checkout, and the files with changes show up as conflicts.
<mgz> resolve --take-this then? (or -other which ever the right way round is)
<GaryvdM> This is on  a server. Only have bzr 2.1 :-(
<mgz> hm. annoying.
<parthm> mgz: for the fast-path patch there are two conflicts (same code) http://pastebin.com/swn9BN7Y .. should i just change that as mentioned in the paste?
<mgz> yup, that's the right resolution
<parthm> mgz: ok. cool. i am thinking of making a 0.4 release after this. -Fi seems like a serious enough bug. what do you think?
<GaryvdM> Ok - emergency over. Thanks mgz.
<mgz> moving the decode onto the line above to make the merge simpler was what made me forget the 'replace'
<mgz> parthm: could do, but no rush, only do it if you've got the time anyway
<mgz> I'm not that confident of all my changes, but getting them out is a pretty sure way of shaking out ugs
<mgz> +b
<parthm> mgz: shouldn't take long to me the release. and with the -Fi issue fixed, its definitely better than 0.3 :)
<parthm> mgz: fast-path is also merged. thanks.
<mgz> there are some line ending annoyances still to wrangle over there
<mgz> essentially, if people are stupid enough to use mixed, or mac, line endings, strange things may happen to them
<mgz> I reduced the change a bit to make it safe for landing though
<parthm> mgz: ah. ok. ... so do you think i should wait? anyway, the changes are on lp:bzr-grep so if someone want to use the latest thats always possible.
<parthm> we could do a 0.4.0 in a few days it you want to try something.
<mgz> no, but I think you might have to start wondering about what someone wanting the line numbers containing "a" in a file like "\r\r\na\n\r\r\na" should get
<mgz> str.splitlines does (\r\n \n \r) -> \n and text mode does (\r\n \n) -> \n
<mgz> but bzr doesn't help you out at all (in a default setup at any rate)
<mgz> and the regexp engine doesn't like unexpected \r
<parthm> mgz: yes. i suppose i will file a bug for this an explore it for a later release.
<parthm> mgz: bug #591147
<ubot5> Launchpad bug 591147 in bzr-grep "line numbers may not be correct for mixed line endings (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/591147
<mgz> it's a pain, as just using \n is and should be the right thing
<parthm> mgz: Yup. i suppose majority of software is about compatibility issues :)
<mgz> anyway, away for me.
<parthm> mgz: bye
<ronny> hi
<ronny> how can i disable bzr's lazy importer?
<ronny> bummer, its not possible
<RayChandlerIII> Does anyone know of a general guide on the idea of feature branching?
<parthm> RayChandlerIII: do you mean in context of setting up bzr repo structure?
<RayChandlerIII> parthm: Yes. I've setup a repo however I am having a hard time adding files or pulling revisions, or checking anything out. I am used to SVN and have have decided to switch to bazaar after reading your "why switch" guide. ;)
<RayChandlerIII> but I am not familiar with feature branching
<RayChandlerIII> there is also no wikipedia article on the topic and google turn up a bunch of stuff on HG
<parthm> RayChandlerIII: in bzr each branch is its own directory. you can set up a shared repo using 'bzr init-repo foo-repo'. inside dir foo-repo, you can have trunk and other branches.
<parthm> this way all branches with share history in the repo (less disk space used).
<RayChandlerIII> so each branch can be its own repository?
<parthm> RayChandlerIII: You have two options, you can create a branch using 'bzr init foo'. in this case branch and repo are the same (foo).
<parthm> or if you have a large history, you can 'bzr init-repo foo-repo ; cd foo-repo; bzr init trunk; cd trunk ; <hack on trunk> ; cd .. ; bzr branch trunk fix-123; cd fix-123 ; <hack on fix>'
<parthm> in the latter case all history is in 'foo-repo'.
<parthm> RayChandlerIII: http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/shared_repository_layouts.html
<parthm> RayChandlerIII: if you are starting a project from scratch 'bzr init' is simpler.
<RayChandlerIII> And this would use a distributed model?
<RayChandlerIII> <-- Is new at this.
<parthm> RayChandlerIII: bzr supports multiple workflows.
<parthm> Yes, bzr is distributed, so there is no "central" repo technically ... its only policy.
<luks> RayChandlerIII: you should not worry much about the layout of branches/repositories when you are starting
<luks> you can switch between them very easily
<parthm> RayChandlerIII: Yes, what luks said. You have the option of changing/adapting your workflow later.
<RayChandlerIII> So why can I not add files to the repository or check out a working directory?
<RayChandlerIII> I have a reposistory with a trunk.
<luks> you are working with branches
<luks> forget repositories for now
<RayChandlerIII> ok
<RayChandlerIII> forgotten
<RayChandlerIII> hmm
<RayChandlerIII> still not clicking
<RayChandlerIII> ok lets try this...
<luks> could you explain what exact problems are you having?
<RayChandlerIII> luks: have you worked with subversion>
<luks> yes
<parthm> RayChandlerIII: http://doc.bazaar.canonical.com/bzr.2.1/en/tutorials/tutorial.html covers the basic workflow in case you haven't looked at it.
<RayChandlerIII> parthm: will check it out. Thanks.
<RayChandlerIII> luks: In subversion if I start a new project I create a repo then check it out to a working directory
<RayChandlerIII> I then modify that working directory
<RayChandlerIII> merge changes from the repo to my local machine
<RayChandlerIII> then commit the changes
<RayChandlerIII> Compare what I just sayed to how you do it in Bazaar
<RayChandlerIII> better question.
<luks> the best answer to that is to read the tutorial
<luks> there are basics you will need to know
<RayChandlerIII> luks: the one that parthm linked to?
<luks> yes
<luks> the basic idea is that there is no difference between a repository no a server and your local machine
<luks> once you get how that works, it will be easy to do anything more advanced
<RayChandlerIII> Ok. Thank you for the help and your time. Let me take a look at the tutorial
<RayChandlerIII> Ok...
<RayChandlerIII> I think I understand it now. ;)
<parthm> RayChandlerIII: cool :)
<RayChandlerIII> brb
<al-maisan> Hello there! Does somebody recall the name of the tool that allows one to filter a diff/patch i.e. to exclude changes to particular files?
<Kinnison> Presumably you're referring to filterdiff(1)
<Stavros> hello
<al-maisan> Kinnison: thanks a million! That was the tool I had in mind!
<Stavros> when i switch to a colocated branch, will my uncommitted changes be shelved in the workspace automatically, or do i have to commit first?
<bilalakhtar> Hi there, people. My bzr is progressing very slowly during Finding revisions: Inserting stream. How many steps are after this? Is this the last step in branching a branch hosted on lp?
<GaryvdM> Hi all
 * GaryvdM was looking for jam
<maco> someone has a branch on lp, and i merged their branch into trunk and push that to lp... and it doesnt show them in the revisions thing. did i do something wrong?
<GaryvdM> maco: Launchpad may take a few minutes to reflect changes to branches
<maco> GaryvdM: the new revisions are there, im just wondering if its supposed to show the name of the person who did the merge or if there's a way to have the revision from the branch the merge came from be what shows
<GaryvdM> maco: code.launchpad.net only shows the mainline, but if you drill into the merged revisions with bazaar.launchpad.net (or with something like bzr qlog), you will see the original committer.
<maco> GaryvdM: oh. ok
<maco> GaryvdM: thanks
<Lo-lan-do> Hi all.  What to do when I get "error: Error -3 while decompressing data: incorrect data check" errors?
<Lo-lan-do> (bzr 2.1.2 on Debian sid)
<jelmer> hi Lo-lan-do
<Lo-lan-do> Hi jelmer :-)
<jelmer> Lo-lan-do: no idea, perhaps jam will have an idea when he shows up
<jelmer> Lo-lan-do: btw, did you see that we've made some progress on roundtripping support?
<Lo-lan-do> I hope so, because I can't commit to the repository now :-/
<Lo-lan-do> I've seen some commits on bzr-git, yes, which gave me hope :-)
<jelmer> the performance is still pretty pathetic for 'bzr git-serve', but it does work with the roundtripping code
<jelmer> Lo-lan-do: when we get a new cache format for bzr-git in place that is based on bazaar pack files it should be better
<Lo-lan-do> Great :-)
<effie_jayx> hey guys, with regards revision numbers after a merge
<effie_jayx> lets say I have some old code with rev nÂº 128 and I need to merge some of that stuff into 150
<effie_jayx> I merge changes to 128 but that makes rev nÂº 129
<nailuj24> if you merge 150 into 128, it'll be 129. if you do it the other way round, it'll be 151 (as far as i know)
<effie_jayx> I am sorry If I come out as a bit of a noob but truth is I come from using mercurial with a bunch of abusers that do not handle merges as they should :P
<effie_jayx> nailuj24: would it make sense to pull from another branch to get revisions to 151 and then resolve conflicts
<effie_jayx> ?
<nailuj24> what i'd do is to go into 150, and pull the 128. then you'll end up with 151 i think
<effie_jayx> nailuj24:  shall try that
<effie_jayx> thanks
<Lo-lan-do> If you pull, then you get the same version number as what you pull.
<effie_jayx> Lo-lan-do: good to know, not what I need
<nailuj24> oh, didn't know that
<Lo-lan-do> But anyway, pulling won't work in your case, since you have local changes not present in the remote branch.
<jelmer> abentley: did you just tag the nested-trees-feature bug with udd?
<abentley> jelmer, yes.
<rowinggolfer> My project is 714 revisions in, but I intend I am radically altering the folder hierarchy..  is there any reason why starting a fresh tree is a bad idea?
<Lo-lan-do> rowinggolfer: Apart from losing history?
<rowinggolfer> Lo-lan-do, the changes are so dramatic that bzr diff shows nada...
 * Lo-lan-do shrugs
<Lo-lan-do> bzr annotate on files might still be useful later on, but if you don't care, that's your call :-)
<rowinggolfer> Lo-lan-do, thanks for your input... I will keep the history
<rowinggolfer> only downside is bigger branches for folks I guess
<dan> hi
<dan> can someone link me to some documentation on how to get started with bzr?
<rowinggolfer> http://doc.bazaar.canonical.com/latest/en/mini-tutorial/
<rowinggolfer> dan ^^
<dan> ta!
<lifeless> moin
<Lo-lan-do> G'day
<jelmer> lifeless: ping
<jelmer> I mean
<jelmer> 'morning lifeless
<jelmer> lifeless: Is there an easy way to see what tests failed from the bzr pqm output?
<lifeless> jelmer: grep for error: and fail:
<lifeless> jelmer: there is a pending fix to pqm waiting on losa deployment to make it better
<jelmer> lifeless: ok
<jelmer> lifeless: Yeah, it was easier to find earlier - glad to hear it's a known issue.
<jelmer> lifeless: unfortunately the error message
<jelmer> is:
<jelmer> _StringException: lost connection during success report of test 'bzrlib.tests.per_branch.test_last_revision_info.TestLastRevisionInfo.test_non_empty_branch(BzrBranchFormat4)'
<jelmer> and the error doesn't fail locally
<lifeless> newz2000: so, that means one of two things
<lifeless> either the output was on stderr (should be at the top of the log)
<lifeless> or it was mangled so that the end of the test couldn't be read :(
<lifeless> I'll see if spm has time to do the upgrade when he surfaces
<jelmer> lifeless: thanks
<lifeless> jelmer: try with no plugins perhaps
<jelmer> lifeless: I can't reproduce the error myself, but it happens in bzr's pqm
<lifeless> yes, I'm suggesting trying with no plugins as a start
<lifeless> in case a plugin is fixing it
<lifeless> it's unlikely to be that specific test
<lifeless> progress bars break subunit regularly
#bzr 2010-06-09
<igc> morning
<lifeless> hi igc
<lifeless> losa ping
<spm> morning igc
<spm> hey lifeless, sup?
<lifeless> pqm
<lifeless> I rt'd a request to do an upgrade
<lifeless> a weekortwo back
<lifeless> its affecting developer troubleshooting
<lifeless> doyouhavetimetodoittoday?
<spm> if it's sufficiently high priority - and the world doesn't break again - sure?
<spm> what's the rt #?
<lifeless> I'm not sure :)
<lifeless> its somewhere in the cauldron
<spm> heh, see if I can find it. sec.
<spm> deploy PQM trunk rev 236 please - in coordination with Robert ? tho who this robert dude is, dunno. never heard of him.
<lifeless> see
<lifeless> thats the problem with young folk these days
<lifeless> no short term memory
<spm> old folk man, *old* :-)
<lifeless> spm: darn, I *forgot* that bit
<spm> ahh. i see what's happened, looks like francis set the wrong priority button - tho it's new to me that RT has > 1 priority setting
<spiv> lifeless: I just had that error too
<poolie> hi there
<spm> hey poolie
<poolie> lifeless, i filed https://bugs.edge.launchpad.net/pqm/+bug/591507 for the pqm 'lost connection' problem
<ubot5> Launchpad bug 591507 in PQM "bzr tests fail with "lost connection" (affected: 1, heat: 6)" [Undecided,New]
<lifeless> thanks
<poolie> since three people have hit this in recent days, at least, and since the subunit output is not actually valid, i'm inclined to disable it until it's more debugged
<lifeless> poolie: well, we haven't deployed the candidate fix
<lifeless> poolie: which spm and I are doing right now
<spm> indeedily
<lifeless> poolie: so perhaps we should try to fix it first :)
<poolie> ok, let's at least try that
<spm> novel :-)
<poolie> ah
<poolie> surely this is not going to make the streams actually valid though?
<poolie> or does it change them into attachments?
<lifeless> poolie: changes them to attachments
<poolie> oh great
<lifeless> poolie: it should be a step in the right direction. Will more steps be needed? Probably.
<lifeless> poolie: its been not deployed because of a priority confusion, apparently. '11:43 < spm> ahh. i see what's happened, looks like francis set the wrong priority button - tho it's new to me that RT has > 1 priority setting
<spm> lifeless: pqm disabled in crontab
<lifeless> '
<lifeless> spm: ok, so grab the revno
<lifeless> spm: as we don't have staging yet, this will be 'test by doing'
<lifeless> spm: bzr revision-info is the output to save
<lifeless> spm: then pull in trunk
<spm> simiar to you guys with bugs, we schedule our work based on priorities. by default stuff comes in and stays at zero; so tickets that are 'more important' need to be more apprioriately set. a LOT of our requests are wishlisty, so tend to be in the "I need a break, something easy" bucket.
<lifeless> spm: yeah, I'm not critical; explaining to poolie, because figuring out why something important went stale helps us prevent it.
<spm> lifeless: so current is revno 232
<spm> nod
<lifeless> spm: right, so the new commits are all simple:
<lifeless>   Record unfixed typeerror note.
<lifeless>   Make test suite run with bzr 2.2: set an explicit test usercode.
<lifeless>   Merge and tweak Aaron's errors-as-attachments code.
<spm> 232 robertc@robertcollins.net-20100422043204-70jn37kx2whdm8fr <-- rev info
<lifeless>   More tweaks to email attachment support.
<poolie> spm, i don't understand how you can schedule your work based on priorities but also "it's new to me that RT has > 1 priority setting"
<lifeless> spm: please pull in trunk
<poolie> or do you mean there's more than one priority-type variable?
<lifeless> poolie: multiple fields, I think.
<spm> poolie: more than 1 priority type variablee. 'priority' and 'final priority'
<lifeless> rt is... not the simplest
<spm> francis had set the latter; the former is what we use
<spm> lifeless: that is a major understatement :-)
<spm> Now on revision 236.
<lifeless> great, spin it up, I have a broken branch to send to it
<poolie> 'final justice' <http://bit.ly/acROW7>
<spm> bzr only re-enabled in the crontab; I gather we don't need a UI restart?
<lifeless> spm: UI is unaffected
<poolie> you're going to tell francis about that right?
<lifeless> poolie: #launchpad-code
<lifeless> he's usually around again for a bit soon, if he disappears off IRC without acking, I'll email
<spm> I think it was an accident tbh; normally he does set priority.
<spm> just hit the wrong field by mistake
<lifeless> can we hide that field ?
<spm> I have no idea. see "[09:51:48] <lifeless> rt is... not the simplest" :-D
<lifeless> lol
<lifeless> ok so the current branch has a failing test
<lifeless> everything going well it will a) fail to land, b) give me a useful email attachment in gmail.
<lifeless> I shall report in about an hour, I suspect.
<spm> np; should I be re-enabling pqm for U1 etc? ie they're safe here?
<spiv> lifeless: you should have tweaked the Makefile to do -f that_test  :P
<lifeless> spiv: no
<lifeless> spiv: its deliberately in the middle, want to be sure that under normal circumstances we get sensible stuff out
<lifeless> spiv: and that would raise the risk of getting it wrong
<lifeless> spm: unknown.
<spm> lifeless: fair enough; in that case, i'll stick with disabled for the time being.
<lifeless> spm: if its faulty, the most likely failure mode is errors going to cronmail
<lifeless> spm: its unlikely to let things through inappropriately
<spm> coolio, given the U1 guys don't seem busy on pushing code in; going into holding shouldn't hurt.
<lifeless> spm: can I ask a favour ?
<lifeless> spm: file a bug/rt ticket as appropriate, for your team, to delete the unused button; its caused friction here, and IIRC rt is meant to be very customised
<spm> lifeless: I can do that. I have no idea how easy that is tho; or the likyhood of it being done anytime soon.
<poolie> lifeless, do you know what 'unknown content code' in roland mas's problem report is likely to mean?
<poolie> to mean, the earlier gzip errors probably indicate a file-level problem
<poolie> which may ultimately be attributable to us for example not defending enough against a sudden machine crash
<lifeless> ok
<lifeless> the gzip errors indicate a group couldn't be decompressed
<lifeless> -> bit (or more) error in disk content
<lifeless> and either out-of-order disk operations(man I wish we had user space barriers), or entropy/cosmic ray
<lifeless> the invalid content code suggests a multibit error in gzip content not detected by the [weak] crc on the compressed block
<lifeless> and thus garbage coming out of gzip
<poolie> right
<lifeless> so two symptoms, one problem
<lifeless> we can verify the packs
<lifeless> md5sum them
<lifeless> and see if they match
<lifeless> I've mailed a reply to that
<poolie> that was what i suggested too
<poolie> thanks
<poolie> we could talk about the fixture stuff
<lifeless> sure
<lifeless> I was going to pop out and do lunchtimey shores
<poolie> but perhaps when i get home
<lifeless> s/shores/chores/
<poolie> we're going to look at some ui stuff with ian for a few hours
<lifeless> well, if you have speaks & a mic we could do a group call
<lifeless> I'm happy any which way
<poolie> the document is probably a bit rambly but the process was good
<lifeless> ok, -> local stuff
<lifeless> SMS if things blow up and I need to rush home
<lifeless> spm: ok, bzr causing funnies I think; tweaking the patch to deal
<spm> kk
<lifeless>  File "/home/pqm/pqm/pqm/core.py", line 194, in send_mail_reply
<lifeless>    message = Message()
<lifeless> TypeError: 'LazyImporter' object is not callable
<lifeless> went to cron
<lifeless> spm: please pull rev 237
<lifeless> spm: tell me when you have, I'll retest
<spm> lifeless: done, go for it.
<lifeless> spm: ok wow, rabbit hole goes deeper
<lifeless> Message, in email, is not what it should be
<lifeless> spm: I need some interactive testing please
<spm> oh?
<spm> sure. gimme 5? just sorting some space issues on lardibartfast
<lifeless> sure sure
<lifeless> utter bollocks
<lifeless> excuse the vernacular
<lifeless> spm: I've just done a push --overwrite; please pull --overwrite, and we'll try again.
<spm> sure
<lifeless> uhm, pushed ...
<lifeless> now
<spm> ow on revision 237. ?
<lifeless> yeah
<lifeless> log -r -1 should say 'import from the right place'
<spm> hrm. maybenot. we were there before. try again?
<spm> with a capital I and a Message in tehre as well, yarp
<lifeless> ok
<lifeless> can yuou aslo
<lifeless> also
<lifeless> do
<lifeless> "python -c 'from email.message import Message'"
<spm> pqm@balleny:~/pqm$ python -c 'from email.message import Message'
<spm> pqm@balleny:~/pqm$ echo $?
<spm> 0
<spm> looks good to me
<lifeless> thanks
<lifeless> boombs away
<spm> np
<lifeless> spm: pull again please
<spm> lifeless: rev 238
<lifeless> thanks
<spm> lifeless: how's it going? have a u1 item in the queue - are we safe to let it play?
<lifeless> spm: yes, its giving attachments now
<lifeless> we can iterate safely from here
<lifeless> please enable it all
<spm> oki, re-opening pqm
<lifeless> or bugger
<lifeless> its rather smaller than expected
<spm> ?
<spm> problem?
<lifeless> if their merge fails they won't get much diagnostics right now
<lifeless> but enable it
<lifeless> it isn't going to crash now
<spm> oki, it's enabled.
<lifeless> right, the attachment isn't
<lifeless> I need to dig deeper into the email api
<lifeless> I shall do that around dinner
<spm> kk
<spm> updating the RT as to where we're at
<lifeless> spm: when are you disappearing tonight? 15 minutes?
<spm> 75.
<lifeless> this looks wrong: Content-type: multipart/mixed
<lifeless> Content_type: text/plain
<spm> 6pm local.
<lifeless> bloody broken API's
<lifeless> spm: can you do python -c 'from email.mime.multipart import MIMEMultipart'
<lifeless> please
<spm> works fine
<lifeless> oh man
<lifeless> it wants headers spelt in lower case
<lifeless> no, thats not it.
<lifeless> gmm
<lifeless> who writes a dict interface that doesn't replace keys
<lifeless> So very not pythonic
 * lifeless sobs
<mgz> did you work out the email.Message vs. email.message thing from earlier?
<lifeless> mgz: yes
<mgz> you need both.
<lifeless> mgz: email/__init__ contains a bad lazy_import implementation
<lifeless> mgz: no, can just grab from email.message.Message
<lifeless> Message appears ripe for user bugs in so many ways
<lifeless> headers aren't normalised
<mgz> this needs to run on python 2.4 right?
<lifeless> mgz: no
<mgz> ah, okay, ignore me then.
<lifeless> mgz: it needs to run outside the chroot on balleny
<Tibi> hi
<mgz> mime isn't fun.
<lifeless> mgz: email.* isn't fun; mime itself is pretty well established ;)
<lifeless> mgz: check out message.Message.get_param for an eye watering docstring
<mgz> see, I'd blame some of that on mime/rfc 2231 making things overly painful
<lifeless> if the email module was close to rfc2231 compliant, I'd agree
<lifeless> :)
<lifeless> spiv: can you tell poolie, if he doesn't see me first, that I'm 'bloody fixing bloody pqm'.
<lifeless> losa ping
<mthaddon> lifeless: hi
<lifeless> mthaddon: hi, need to rollback the PQM change from earlier today; take 1 minute
<mthaddon> ok
<lifeless> mthaddon: on balleny in the pqm dir, bzr pull -r 232 . --overwrite
<lifeless> bzr revision-info should then report 232, and bzr st no changes
<lifeless> turns out the email API is really tricky to get right and I'm doing more extended QA locally before we do the upgrade again
<mthaddon> lifeless: https://pastebin.canonical.com/33182/ - I think we're good
<lifeless> mthaddon: we should be, thanks. I'll send a test through to make sure its back to its ugly old self
<mthaddon> k
<parthm> there is a bzr grep bug #591233 ... does bzrlib.option provide a way of having an option that allows '-' as start of argument? e.g. '-e "-blah"'
<ubot5> Launchpad bug 591233 in bzr-grep "support -e to specify pattern (affected: 1, heat: 6)" [Wishlist,Confirmed] https://launchpad.net/bugs/591233
<lifeless> parthm: no
<lifeless> parthm: or rather, I'm pretty sure it doesn't.
<parthm> lifeless: ok. thanks. i will look into it to see if there is an easy way to do it.
<lifeless> it will parse it as option 'b' with param 'lah' and no parameters given to 'e'
<parthm> lifeless: yes. thats what i got when i tried it.
<lifeless> Thats what I'd expect to happen; I don't think this is really a bug is it? just escape the - - -e "\\-blah"
<parthm> lifeless: yes. thats the workaround i suggested in the bug. but posix grep supports -e ... so i suppose people used to posix grep would try that first.
<lifeless> ok
<parthm> so its not critical, but nice to have.
<lifeless> so, if you find a way to add this to bzr core
<lifeless> I'd like to suggest that it be made obvious in two places
<lifeless> the docstrings for any objects that will sometimes-handle-leading-dash-and-sometimes-not
<lifeless> and the help for commands that use such options - automatically in the this second case
<parthm> argh. seems to be some problem with my network today. i keep dropping off.
<parthm> lifeless: i will see if there is a good way to support this. maybe a new option type. will file a wishlist against bzr for now.
<lifeless> 21:51 < parthm> so its not critical, but nice to have.
<lifeless> 21:51 < lifeless> so, if you find a way to add this to bzr core
<lifeless> 21:51 < lifeless> I'd like to suggest that it be made obvious in two places
<lifeless> 21:51 -!- parthm [~chatzilla@122.167.117.28] has quit [Read error: Connection reset by peer]
<lifeless> 21:51 < lifeless> the docstrings for any objects that will sometimes-handle-leading-dash-and-sometimes-not
<lifeless> 21:52 < lifeless> and the help for commands that use such options - automatically in the this second case
<lifeless> 21:52 -!- parthm [~chatzilla@122.167.117.28] has joined #bzr
<parthm> lifeless: makes sense. bug #591657
<ubot5> Launchpad bug 591657 in Bazaar "bzrlib.option should allow an option that allows argument starting with dash (-) (affected: 1, heat: 6)" [Wishlist,Confirmed] https://launchpad.net/bugs/591657
<lifeless> mthaddon: can you please tell me what python -V shows on balleny, outside the chroot ?
<mthaddon> Python 2.5.2
<lifeless> thanks
<lifeless> gnight y'all
<bilalakhtar> People, please help. bzr is stuck on Fetching revisions:Inserting missing keys: . Is this fine?
<bilalakhtar> ok, its fine. got it
<alf__> Hi all! When packaging using bzr builddeb is the versioned directory (upstream+debian) supposed to have debian/patches applied or not?
<james_w> if it is dpkg-source v3 (quilt)
<alf__> james_w: So, if I understand correctly, if it is v3 (quilt) it should have the changes applied *and* also have .pc/ versioned
<alf__> james_w: and that is what I should push to launchpad?
<james_w> yeah
<james_w> it's not ideal, but it's the best we have for now
<alf__> james_w: great, thanks
<servilio> hi! I have a branch with a couple of commits I'd like to remove is there a way to do this without using uncommit? or is there a plugin that automates this?
<maxb> servilio: Uh..... this is what uncommit is for.#
<servilio> maxb: yes, but there are ~20 commits before the ones I need to take out
<maxb> In that case you should just undo the effect of those commits on the tree (by doing a reverse-merge), and commit that
<servilio> maxb: I changed the history of the parent after that branch was made
<maxb> That sounds hideous
<servilio> yes, it is
<maxb> Well don't do that then :-)
<servilio> but it was a merge gone wrong I needed to take out ASAP
<servilio> I am looking into cherry-picking now
<servilio> looks like that will be the solution
<servilio> new branch, cherry-pick merge, push to the parent :D
<taxilian> can anyone tell me if there is a good equivilent to webdav publishing like svn or mercurial can do with bzr?  I'm using bzr+ssh, but that requires creating a user account on the central repo machine for each user, which I'd prefer not to do
<taxilian> or if there is a way I haven't found yet to run bzr over webdav...
<servilio> taxilian: have taken a look at bzr-webdav?
<taxilian> looked at a bit, but looks like it isn't stable
<taxilian> maybe it's just been too long since I looked
<servilio> haven't tried it myself, a co-worker did and it worked fine
<taxilian> so it looks like it requires installing a plugin on each dev machine?
<taxilian> what is the "recommended" way to publish a bzr repo?  sftp?
<servilio> yes
<servilio> yes was regarding the installation of the plugin in each dev system
<servilio> regarding the "recommended" way, can't tell you sincerely, just a user here
<servilio> I use bzr+ssh currently
<taxilian> yeah; that's what I don't get about bzr.  I like bzr; I've been using it for awhile
<taxilian> but bzr+ssh is not ideal for a real solid source control system
<servilio> define "real solid" :D
<servilio> meaning, state your requirements ;)
<taxilian> we used to use that with cvs, and that's one of the main things that everyone I've worked about liked about svn over cvs; it worked over http instead of needing ssh
<taxilian> flexible permissions on various projects
<taxilian> easy to add and manage users
<taxilian> with ssh, you have to deal with system users
<taxilian> and unix groups aren't real ideal for managing access control
<servilio> I have been looking at a solution for access control for ssh access that wouldn't need system account, but would use ssh keys
<servilio> but haven't found any so far
<taxilian> well, you can use ldap, but that's a pain
<servilio> there is http://pypi.python.org/pypi/ClueBzrServer/
<servilio> yes, a bit of a complicating solution LDAP is
<servilio> and yesterday I found nappingcat http://pypi.python.org/pypi/nappingcat/
<servilio> but haven't had time to take a look at it
<taxilian> hmm.  does look like cluebzrserver supports pushing; very interesting
<taxilian> not much information about nappiungcat
<lifeless> moin
<mtaylor> lifeless: moin
<mtaylor> lifeless: hey - quick question for you
<netshine> ;-(
<netshine> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<netshine> there any known problems right now?
<lifeless> netshine: known problems with?
<netshine> wish launchpad or bazaar ;-0
<lifeless> that error usually indicates an ssh configuration issue
<lifeless> do you have your ssh key setup correctly?
<netshine> i think so...
<netshine> i just updated my pgp key to be sure..
<netshine> :-0
<netshine> wait, ssh key?
<netshine> not pgp? about what you talking about :-0
<lifeless> ssh
<lifeless> I have to pop out for a bit
<netshine> :-?
<lifeless> if this is your first time using bzr with launchpad, you might try asking on #launchpad
<lifeless> bye for now.
<netshine> :-0
<netshine> lifeless, thanks: D
#bzr 2010-06-10
<lifeless> jam: nice
<lifeless> otfl
<lifeless> meh
<spm> lifeless: where are we at with the pqm shiny? can I mark that RT as complete? Or we're still testing?
<lifeless> we rolled back last night
<lifeless> I'm stabbing with a BIG KNIFE
<lifeless> unfuckingbelievable where this was at
<spm> wow, that bad eh?
<lifeless> yes
<lifeless> stdout and stderr are different fd's *for a reason*
<spm> oh my. :-)
<dmuir> Can anybody give me a hand with fixing history?
<maxb> dmuir: elaborate :-)
<dmuir> Basically, I have several revisions where files were deleted/added instead of moved, and I'd like to fix that.
<dmuir> Is there some way I can create a branch up to the offending revision, fix it, then play back the other changes on top?
<maxb> fix, from the point of view of making the actual old revisions look different, or fix, from the point of view of just stopping it causing a problem with future merging?
<dmuir> would be nice to fix so the old revision looks different, but primarily because it causes problems with merging.
<dmuir> Whichever is easiest :-)
<maxb> rewriting history is awkward. sorting future merging is easier
<dmuir> ok
<dmuir> say the offending revno is 20
<dmuir> bzr branch -r 19 trunk fix_moves
<dmuir> cd fix_moves
<dmuir> do I then do:
<dmuir> bzr merge -c 20 ../trunk
<dmuir> ?
<dmuir> and then fix the problems? Or is there a better way?
<dmuir> the problem with the above is merging back into trunk is a pain with fixing all the conflicts...
 * maxb ponders
<maxb> I've only ever fixed this sort of thing by carefully rearranging things *while* in the middle of doing a merge that generated contents conflicts
<dmuir> ah, ok. Yeah, a bunch of these are old revisions that are now causing problems...
<dmuir> and the conflicts are really hard to figure out...
<zearin> Hello?  Anyone not AFK here?  I sheepishly approach, with a n00b question 0:-)
<dmuir> zearing: ask away
<dmuir> err, sorry, zearin
<zearin> lol np
<zearin> K, soâ¦2 computers.  House WiFi.  I have a Bzr branch on my desktop I want to access on my laptop.  I am embarrassed to admit that I found this to be waaaaay harder than I expected :D
<dmuir> OS?
<zearin> Both computers are Macs on OSX 10.6, latest version of Bazaar, and I have discovered the joy of Bazaar Explorer
<dmuir> hmm... can you set up a shared folder?
<zearin> Oh yeah, I do sharing all the time
<maxb> Does OS X run a ssh server by default?
<maxb> If so, that'll be a good way to do it
<zearin> I'm just clumsy and novice when it comes to networking and URLs that aren't Web-ish
<zearin> I have successfully SSHed into my Desktop from this machine, but I want to be able to do it in Bazaar Explorer
<maxb> bzr+ssh://othermachine/path/to/branch :-)
<zearin> (Also, I think I want to make it a "bound" branch so both stay in syncâ¦that is correct, right?)
<zearin> oh! :)
<zearin> No username@machine/path/etc/etc ?
<zearin> (with the protocol prefix I forgot to type?)
<zearin> (gonna try it out right nowâ¦)
<maxb> You can stick a username@ in before the machine name if your username is different on one end of the connection to the other
<zearin> no, same username.
<maxb> no need, then
<maxb> 'bound' means 'when I commit, make sure it happens both remotely and locally'
<zearin> AndâI feel stupid asking as I'm pretty sure the answer is "yes", butâthis is a URL, so I should choose "Open URL" instead of "Open" in Bazaar Explorer right?
<maxb> uh, possibly. I'm a command-line person
<maxb> no idea :-)
<zearin> :)
<zearin> I have full respect and reverence for the CLI
<zearin> But I have a visual brain and I forget commands repeatedly unless I can see them as a button :)
<zearin> Hehe
<zearin> Thanksâ¦gonna give this a shot, but I wanna say this was great supportâyou guys (and gals?) rock!
<dmuir> maxb: I've got another problem too... I have some cases where some stuff was added to both a trunk and staging branch, independently. When I try to merge between the two, conflicts galore... any "quick" way to solve?
<maxb> um. not 'quick'
<dmuir> bummer :-)
<maxb> The only way I know is to actually merge, get the conflicts, and then make sure you sort them out the right way such that you never need to do it again
<zearin> Gah.  No luck with bzr+ssh: "Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist." :(
<zearin> Guess I'm off to launchpad :)
<dmuir> zearin: That'll work too... the other alternative would be to set up a share, and put the branch there. You should then be able to access it via the file system.
<zearin> under /Volumes/ ?
<spiv> zearin: there's probably an error from SSH just before that line that may be relevant
<zearin> I tried the SSH in the OSX Terminal and it worked fine
<dmuir> maybe  a password issue?
<zearin> well correctionâ¦I tried a plain SSH to my other machine in the Terminal, and it worked fine
<zearin> I didn't test the bzr+ssh on the CLI
<dmuir> maxb: what's the "right way"TM to merge so I never need to to do it again? :-)
<dmuir> zearin: I've found that by using ssh keys, you're much less likely to have issues when using bzr+ssh.
<zearin> Hm okayâ¦again, this is something I have fiddled with.  Barely.  But I don't really know what I'm doing with keys.  I have a GUI app to help me manage them (don't laugh! :P)
<dmuir> last time I tried using bzr over a protocol requiring authentication, it would crap out if asked for a password.
<zearin> that seems to be what is happening
<zearin> I tried it in terminal and after I gave the password it died
<lifeless> bzr doesn't have the ability to do ssh passwords - ssh grabs the terminal entirely itself.
<lifeless> so if you're using ssh (and lp: ends up using ssh), you have to use an agent that can prompt you, or hold the keys open for you
<zearin> define "grabs the terminal entirely" ?
<zearin> okay
<dmuir> zearin: tutorial for setting up ssh keys: http://wiki.dreamhost.com/Ssh#Passwordless_Login
<zearin> I have one already set up
<zearin> I set it up for LP
<zearin> I just don't know how to use it otherwise :)
<spiv> zearin: my point is that the "Connection close: Unexpected end of message..." error is usually not the whole error.  There's often some more output just before that that indicates why the connection failed.
<zearin> Okay spiv â¦Â onesec
<zearin> Tonys-MacBook:~ tony$ bzr branch bzr+ssh://Tonys-iMac.local/Developer/Projects/org.lyris
<zearin> Unable to load plugin 'rebase'. It requested API version (2, 1, 0) of module <module 'bzrlib' from '/Library/Python/2.6/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (2, 2, 0), and the maximum is (2, 2, 0)
<zearin> Password:
<zearin> bash: bzr: command not found
<zearin> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<zearin> That "rebase" error always occurs
<zearin> But I've never used the rebase command, and other operations seem unaffected, so I ignore it.  It can't be connected to the SSH issue, can it?
<lifeless> zearin: 'command not found' - you don't have bzr installed on your server.
<zearin> I do, though
<dmuir> zearin: iYou need to add the same key you added to LP to your other mac, and you'll be able to log in to it without a password.
<zearin> OOooh
<zearin> both the identity & identity_rsa ?
<lifeless> zearin: is it in your path ?
<spiv> zearin: try "ssh Tonys-iMac.local bzr help", I think you'll see that fail too
<lifeless> zearin: do this: "ssh Tonys-iMac.local bzr help"
<lifeless> spiv: \o/
<zearin> it did fail.  WTF?  I know I have bzr on my Desktop because I've already used it there!
<dmuir> Yes, when you log in directly, but it might not be on the path for ssh.
<zearin> Well I also tried bzr+ssh://Tonys-iMac.local/~/rest/of/path , which according to the Documentation should unambiguously start me at the home dir
<zearin> with same results.  :(
<dmuir> zearin: When you connect via ssh, it typically uses a different profile.
<zearin> okay, so I just did this:
<zearin> Tonys-MacBook:~ tony$ ssh Tonys-iMac.local
<zearin> Password:
<zearin> Last login: Wed Jun  9 22:11:37 2010 from tonys-macbook.local
<zearin> -bash: /Users/tony/.bashrc: No such file or directory
<zearin> Tonys-iMac:~ tony$ bzr
<zearin> Bazaar 2.1.2 -- a free distributed version-control tool
<zearin> http://bazaar-vcs.org/
<zearin> â¦
<zearin> â¦
<zearin> â¦
<zearin> I am so beyond confused.  :(
<lifeless> you're setting the path to bzr in your bash_profile, not your bashrc, or vice verca
<lifeless> I can never remember which is which :)
<zearin> Neither can any of Google's search results :)
<lifeless> or you may have it beyond an interactive-only guard in bashrc
<lifeless> or something like that
<zearin> Tonys-iMac:~ tony$ which bzr
<zearin>  /usr/local/bin/bzr
<spiv> lifeless: I'm not sure that execing a command via ssh will run your bashrc (or whatever your shell of choice is) at all?
<zearin> I'm not sure what you meanâ¦ :(
<zearin> Tonys-iMac:~ tony$ cat .bash_profile
<zearin> . ~/.bashrc
<zearin> #	Setting PATH for MacPython 2.6
<zearin> #	The orginal version is saved in .bash_profile.pysave
<zearin> PATH="/Library/Frameworks/Python.framework/Versions/2.6/bin:${PATH}"
<zearin> export PATH
<zearin> #	Aliases
<zearin> #
<zearin> #	@TODO - use "-G" and customize color outputs
<zearin> alias ls="ls -aehAF"
<zearin> Does that help?
<dmuir> .bashrc is used for non-login shells
<spiv> zearin: (please use a pastebin)
<zearin> How do I use a pastebin?
<lifeless> spiv: zearin put the PATH version in .bashrc
<lifeless> bah
<lifeless> zearin: ^
<lifeless> spm: ready for some monkey love?
<zearin> â¦
<spm> lifeless: perhaps not literally
<zearin> *innocent look*
<lifeless> spm - please pull lp:~lifeless/pqm/attachments into pqm, after grabbing the current revision-info
<zearin> I prefer my girlfriend :)  She's much nicer than a monkey
<spm> hookay
<dmuir> ok... this is getting weird... back to work...
<spiv> zearin: you need to set PATH in your .bashrc
<zearin> Okay
<zearin> Can I be lazy and justâ¦cp .bash_profile .bashrc?
<lifeless> no
<zearin> Damn.
<lifeless> spiv: I wonder if thats the macosx installer's fault?
<spiv> lifeless: hmm, possibly
<zearin> :(*
<zearin> :*(
<spm> lifeless: 232 robertc@robertcollins.net-20100422043204-70jn37kx2whdm8fr
<spiv> lifeless: worth asking someone that knows, at least :)
<lifeless> spiv: will you file the bug, or should I?
<spm> lifeless: Now on revision 252. u1 and ls are disabled for now; bzr is not
<lifeless> spm: and do 'python -c "import bzrlib.tests"' just to check
<spiv> lifeless: please do, if you don't mind.
<spm> worked
<lifeless> spm: thanks
 * spm waves heyo to spiv-the-dad
<lifeless> zearin: how did you install bzr ?
<zearin> Mac installer.
<spiv> spm: hey :)
<zearin> lifeless: I installed it from the command line before, but I could never get Bazaar Explorer to install and work when I did that.  I tried installing all the dependencies from scratch and went through tons of grief in a long Launchpad troubleshooting dialogue.  Finally a new Mac installer came out, and I used it, and Bazaar Explorer worked.  I was ecstatic.  :)
<zearin> lifeless: Both machines are using bzr from the Mac Installer now.
<zearin> All I want is to sync two machines in my house.  :(  Why do I fail?
<lifeless> zearin: make the change spiv recommended
<zearin> tryingâ¦
<zearin> Gah
<zearin> I'm too clumsy at this stuff :(  And tired.  I gotta go sleep.
<zearin> But you were really supportive and I totally appreciate that!  lifeless, spiv, dmuir, anybody else I forgotâthanks.  I'll try again soon.  ;)
<zearin> Good night all, and may your commands complete execution flawlessly!
<dmuir> maxb: thanks for the help. I've been able to fix the conflicts and now merging works again :-)
<lifeless> spm: again please
<lifeless> dmuir: cool
<spm> lifeless: Now on revision 253.
<lifeless> spm: thanks
<spm> that was from lp:~lifeless/pqm/attachments again, to verify for you
<lifeless> yes
<poolie> hi lifeless
<poolie> can we talk about pqm some time?
<lifeless> poolie: sure
<lifeless> now is good
<poolie> me too
<poolie> hi lifeless, i'm back if you want to talk about fixtures
<lifeless> please ring me
<lifeless> poolie: ^
<m3ga> bzr 2.1.1 on lucid. if i do 'bzr merge /other/branch/' i get 'bzr: ERROR: Working tree has uncommitted changes (See bzr status).' but 'bzr status' says nothing. whats going on?
<spiv> m3ga: that's strange
<m3ga> hey spiv. yes, strange indeed
<spiv> m3ga: I suppose that might happen if you had aliased bzr status to actually do "bzr status ." and your cwd isn't the project root...
<m3ga> nope, thats not it
<spiv> Yeah, that did seem a bit far-fetched.
<m3ga> is just did 'bzr revert' and it removed a couple of files.
<spiv> Hmm, then 'bzr status' should have reported something before the revert.
<m3ga> i agree :-)
<m3ga> and now it thinks there is no common ancestor
<spiv> Or perhaps 'bzr --no-plugins --no-aliases status' should have ;)
<m3ga> thay may in fact not have a common ancestor.
<spiv> Yeah, that message is generally right :)
<m3ga> yep, no common ancestor
<m3ga> thanks spiv
<lifeless> spm: hi
<spm> lifeless: I'd thought you'd forgotten about me....
<lifeless> no
<spm> :-)
<lifeless> sadly python 2.x sucks
<lifeless> and something is upcasting things to unicode
<spm> switch to VisualBasic, make all our probvlems go away
<lifeless> so it only shows up in prod :(
<spm> excellent
<spm> spmdo?
<lifeless> sec
<lifeless> managed to reproduce locally
<lifeless> via the magic of paranoia
<spm> :-)
<spm> lifeless: just for the moment: http://www.youtube.com/watch?v=rpRiSb_Ir-s
<vila> hi all
<spm> hey vila
<lifeless> spm: spmdo, 254 incoming
<spm> lifeless: 254 from lp:~lifeless/pqm/attachments pulled in
<lifeless> spm: nice song
<spm> lifeless: you've not come across Garbage before? havea  few of their cd's. not too shabby.
<lifeless> oh, I have cd's :)
<lifeless> doesn't stop it being a nice song
<spm> heh
<lifeless> I got into garbage at uni
<lifeless> -not to be quoting thast-
<spm> struggling to remember who I was listening to at Uni. zztop, pink floyd, queen, icehouse for a local band - live at expo '88 - awesomeness; /me quickly checks his record (yes record) collection, gets embarrassed and stops describing right there.
<vila> spm: yeah, better stop there or you will look even older than me :) (There was a Status Quo appearance near Strasbourg a couple of weeks ago and that's how I learned that they weren't dead after all :)
<spm> vila: you'll be pleased to know we've been educated our 7yo with Status Quo, (and Slade etc) which he tends to sing very loudly. I only hope it's a few more years before he discovers the meaning of some of those lyrics... :-D
<vila> hehe
 * vila takes note to listen to the lyrics again now that his english has hopefully improved enough to understand ;)
<spm> 'the wanderer' is a classic that way
<spm> lifeless: how are we going with pqm? safe to open for U1 et al yet? or keep it wrapped?
<lifeless> waiting on spivs job
<lifeless> then my test one will go through
<lifeless> so - 1.3 hours prob
<lifeless> I'll liase with mthaddon
<vila> lifeless: what is up with pqm ?
 * lifeless needs to send mail
<lifeless> trying to fix the terrible output people were getting
<vila> for value of terrible including None ?
<lifeless> no
<lifeless> truncated subunit stuff
<lifeless> filtered, no cause of error show, stdout+stderr conflated
<spm> lifeless: oki, I'll make sure the R Tis updated with the deatils of where we're at
<lifeless> thanks
<vila> lifeless: oooh, the one poolie mentioned, great, I think babune encountered it from time to time but I thought it was due to something else, since it was sporadic I had no way to diagnose, so any fix there will be warmly welcome
<vila> lifeless: so you're fixing subunit or pqm ?
<mwhudson> vila: morning, how was your trip home?
<poolie> hi there spiv, vila, mwhudson, lifeless
<lifeless> vila: pqm
<spm> hey mwhudson
<poolie> lifeless,  do you know off hand a good incantation to run a unittest from the interpreter
<poolie> or more particularly from a doctest
<vila> mwhudson: I missed a train in Cambridge, got the next one (luckily 20 mins later), had on horrible trip between London and Paris due to 6 guys playing cards, drinking beer and laughing louder than you can imagine, but I arrived safely in the end :)
<mwhudson> vila: :/
<mwhudson> vila: arriving safe is the main point i guess
<poolie> and the worst thing... they work for us :/
<poolie> ;-)
<vila> mwhudson: I managed to fix two bugs related to BZR_PLUGINS_AT. Since I couldn't fight the guys, I throw my anger at the bugs :)
<vila> poolie: hehe, no way, we have some guys who drink but they manage to make *us* laugh instead :)
<mwhudson> s/some/one/
<mwhudson> :-)
<vila> mwhudson: well, protecting the innocent(s) requires some blurry references :)
<poolie> one guy who drinks? i think you need to pay more attention :)
<vila> there is drinking.... and then there is... drinking...
<lifeless> poolie: testscenarios has a doctest demo doing that
<lifeless> poolie: already fixed up to not chat to stdout/stderr
<poolie> ok thanks
<lifeless> you may recognize it still :)
<vila> I drink only water and I'm not responsible for what is added there by barmaids as long that it's less than say 20% of the total :)
<poolie> :)
<lifeless> I hate python2
<netshine> :-(
<netshine> i like java :+)
<netshine> btw lifeless, if i have changes in my files, and bzr know about that modified:
<netshine>   ChangeLog
<netshine>   src/cv_paintbrush_tool.c
<netshine> why he still dosnt want to update... has uncommitted changes (See bzr status). Use --no-strict to force the push.
<lifeless> netshine: newer bzr doesn't do that, it says '--strict to prevent'
<lifeless> netshine: but are you pushing, or updating ? they are different things
<netshine> thats ok fixed that. i was needed to mark the changes.
<mgz> I have clearly gone mad
<mgz> apparently left this branch in a completely broken state on the last commit
<mgz> syntax errors and everything
<mgz> this last bug is at least in codecs.open rather than my code
<bialix> hey mgz
<mgz> hey Alexander, just read the mail about a branch you want me to review
<vila> privet sacha, hi mgz
<mgz> vila has been practicing his russian? or is very interested in hedges.
<vila> mgz: can jython use ctypes ?
<fullermd> mgz: Either way, he's branching out    8-}
<vila> One more joke going over my head :-/
<vila> fullermd: _o/
<mgz> vila: not currently, but there is com.sun.jna
 * fullermd buys vila a very tall hat.
<vila> I hate hats (sounds funny :)
<mgz> http://www.hedging.co.uk/acatalog/pics_10273.html
<vila> mgz: hehe, so, bialix told me privet is the closest to hello indeed ;)
<bialix> what?
<bialix> why are hedges?
<mgz> I was just making a little joke, bialix :)
<bialix> ali g?
<bialix> I don't want a chicken
<bialix> bonjour vila
<bialix> :-P
<mgz> bialix: lp:~jspashett/bzr/587868_args_handling_cant_debug looks sensible to me, could do with some tests though
<bialix> yep, I think it's possible to write tests here by replacing sys.argv with some value and then back
<bialix> can you add such comment? I'm not sure is Jason will be able to write such tests though
<mgz> no problem.
<bialix> nice Bug 592083
<ubot5> Launchpad bug 592083 in Bazaar "UnicodeDecodeError in get_password if user name is unicode (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/592083
<bialix> there are several nasty bugs when user name is non ascii, or have a space inside.
<bialix> I know, but never got enough time to fix :-/
<mgz> yeah, the space inside one bugged me for agest
<mgz> but removing the default userid stuff last month was good enough for me
<bialix> it's not enough
<bialix> and that bug show
<jam> vila: are you still around?
<vila> jam: hellloooo jam, yes
<mgz> parthm... isn't in the channel...
<parthm> jam: ping
<jam> hi parthm
<parthm> jam: hi
<parthm> jam: i was looking into the "Will continue to try.." message. removing it totally seems good to me.
<parthm> jam: if the timeout is always 0 i can also remove the code for it. do you know if "poll" is bzrlib.lockdir.wait_lock is used or is that also always 0?
<jam> parthm: the timeout is not 0 locally
<jam> just for the smart server
<parthm> jam: ok. in that case i suppose i will just put the message in a conditional for time > 0
<parthm> s/time/timeout/
<parthm> jam: thanks for the clarification. i will update the mp for this.
<mgz> okay, let's finish this off, building py3k now.
<exarkun> mgz: did you port bzr to python 3?
<mgz> ha, no, need to finish getting it working on less exotic pythons first
<mgz> I need to check that my testtools change doesn't break py3k though.
<mgz> okay, this is going to be a problem
<mgz> looks like testtools has been written to be source-compatible with py3k
<mgz> don't see how I can easily maintain that and actually test things related to unicode
<mgz> wonder if they'd take a patch that ran 2to3 in setup.py instead
<mgz> though, does appear to be broken on py3k currently anyway
<mgz> okay, back to work
<mgz> why I hate DocTestMatches - what the hell is the mismatch here:
<mgz> http://paste.ubuntu.com/447885/
<mgz> okay, got it.
<mgz> py3k removes the word "integer" from the exception message raised by `1/0` which means there's one too many spaces between the dots
<TresEquis> anybody know how to get loggerhead to serve up robots.txt?
<TresEquis> spiders suck, but at least some of them play by the rules
<mgz> why should that be loggerhead's job? or are you using it without any kind of front end webserver?
<lifeless> morning
<mgz> morning lifeless
<TresEquis> mgz: it is running proxied behind apache
<mgz> so, get apache to serve up robots.txt then.
<TresEquis> but the "top level" for the domain is the loggerhead server
<mgz> Alias robots.txt /path/to/robots.txt # or something
<mgz> hm... my conf uses AliasMatch ^/robots.txt$ - but can't remember if I had a reason or was just being anal
<TresEquis> mgz: can you post the whole line?
<mgz> well, what I have to hand is:
<mgz> AliasMatch ^/robots.txt$ "C:/Program Files/Apache2/htdocs/robots.txt"
<mgz> I remember why I wrote it like that now, means paths like /robots.txt/extra/junk won't be translated
<TresEquis> hmm
<TresEquis> that doesn't seem to do it in my case
<mgz> what mechanism are you using to forward requests to the (I presume) seperate loggerhead server?
<TresEquis> mod_rewrite
<TresEquis> I have a working rewrite rule now
<mgz> ugh, could also be called mod_misuse
<TresEquis> mgz:  I've been using it to front Zope for more than a decade
<mgz> bet you could do exactly what you are already with shorter, more readable config and just straight mod_proxy
<TresEquis> nope
<mgz> for some reason people treat mod_rewrite as a front end to everything else
<TresEquis> I really do need to rewrite the URLs to get virtual hosting working
<mgz> anyway, glad it's working.
<TresEquis> it uses mod_proxy on the backend
<TresEquis> thanks
<TresEquis> I still think that loggerhead should be able to serve static files trivially
<lifeless> I think that might be nice
<TresEquis> lifeless: howdy!  you find a house yet?
<lifeless> http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=40+Rowse+Street,+Rangiora,+Canterbury,+New+Zealand&sll=-43.561088,172.721778&sspn=0.007961,0.017767&ie=UTF8&hq=&hnear=40+Rowse+St,+Rangiora+7400,+New+Zealand&ll=-43.316451,172.586439&spn=0.007993,0.017767&z=16&layer=c&cbll=-43.316371,172.586489&panoid=QOxqEX79iOaIyNEKwDze-A&cbp=12,283.41,,0,12.7
<lifeless> we've put an offer in on it
<TresEquis> cool
<TresEquis> good luck
<TresEquis> we lost a bidding war when I was looking 10 years ago
<lifeless> :(
<TresEquis> turned out the place would've sucked -- the one we got is better (and cheaper)
<lifeless> :)
<lifeless> they have accepted out offer
<lifeless> but we're doing due diligence stuff atm
<lifeless> so contract isn't unconditional yet
<TresEquis> ah, ok
<agrippa> I want to make the first revision the current revision.  How do I do that?
<lifeless> TresEquis: hey
<lifeless> mars: since TresEquis is here, lets talk zope.testing briefly
<lifeless> mars: you might like to read https://code.edge.launchpad.net/~gz/testtools/unicode_tracebacks_501166/+merge/26094
<TresEquis> lifeless: I'm still around
<mars> lifeless, well, that is interesting :)
<lifeless> TresEquis: I'm worried that I'm going to hold up actual fixes going into zope.testing for mars
<lifeless> when it seems to be that all the proposed patches improve things, there doesn't seem to be a benefit holding one hostage to a separate infrastructure issue
<lifeless> so I'm hoping to change your -1 that you put in the zope.testing utf8 traceback review ;)
<TresEquis> lifeless: new features that the Zope developers can't test shouldn't land
<TresEquis> and bugfixes that we can't test are iffy, too
<lifeless> TresEquis: they can test it, its just not convenient, AIUI.
<lifeless> TresEquis: or am I wrong?
<TresEquis> testing means that it can be run in buildbots, on multiple OSes, etc.
<lifeless> yes
<lifeless> and in the case in point it can be
<lifeless> its just not convenient - which there is a separate task going on to fix.
<TresEquis> If somebody who actually uses subunit can take point on it, then I think we can merge fixes
<TresEquis> frankly, the original feature should never have landed without reproducible tests
<lifeless> TresEquis: mars and sidnei both do - lp uses it for its c-i stuff, and landscape uses it for client tests
<TresEquis> that don't depend on having subunit installed in the OS default path
<lifeless> You had me totally convinced until that line; how something is installed is really irrelevant, isn't it ?
<TresEquis> so, if sidnei wants to merge the fix, and promise that it actually helps, I guess I'm -0 on that
<TresEquis> lifeless: it needs to be testable in isolation
<TresEquis> on *every* machine where *anybody* develops zope.testing
<TresEquis> which means one of the two solutions we talked about the other day
<mars> TresEquis, does the test suite pass right now when subunit isn't installed?  I see that there are doctests for the subunit support.
<lifeless> TresEquis: yes, thats orthogonal to virtualenv though: you have vm's, chroots, virtualenv, ec2 as different means to do isolated testing.
<TresEquis> mars: but nobody except you guys can keep from breaking the subunit support
<mars> true
<lifeless> TresEquis: I don't buy every machine, as soon as you have any OS specifici stuff, *some* tests have to become conditional.
<TresEquis> e.g., zope.testing's testrunner is now deprecated
<lifeless> TresEquis: I'm not saying 'dont improve the testing situation with subunit'
<TresEquis> lifeless: there is *nothing* actually OS-specific about htis
<TresEquis> just that subunit's Python support is tied at the hip (for now) to its C build
<lifeless> TresEquis: I'm saying 'don't hold actual fixes hostage to a different *improvement*'. If mars was reducing test coverage, I wouldn't be saying what I'm saying.
<lifeless> TresEquis: the risk you speak of already exists, and mars's patch doesn't make it worse - AIUI.
<TresEquis> right now, *everything* to do with subunit in zope.testing is bitrotted
<lifeless> TresEquis: which is impressive, as its what - 3 weeks old or something ? :)
<TresEquis> no, its a year old
<TresEquis> particularly because zope.testing.testrunner is itself deprecated in favor of zope.testrunner
<lifeless> wow, time flies.
<lifeless> I was sure jml's patch only landed a month or so back
<TresEquis> but none of the developers working to manage the split to zope.testrunner can test the subunit stuff without a major timesuck
<TresEquis> I did that merge
<TresEquis> but subunit support was around longer than that
<mars> TresEquis, ok, would getting subunit onto PyPI solve the problem?  Then we can make zope.testing properly depend on subunit for devs.
<TresEquis> mars: yes, that would help
<TresEquis> 'subunit-python' or 'python-subunit', that is
<TresEquis> I contributed a setup.py for that
<jml> TresEquis, I'm confused
<jml> TresEquis, I added subunit support to zope.testing this year
<TresEquis> Didn't sidnei add other subunit-related stuff last year some time?
<jml> TresEquis, there's some other stuff related to running tests in subprocesses
<jml> TresEquis, which has, sadly, nothing to do with subunit
<jml> TresEquis, although if it were implemented properly, it would probably use subunit :)
<lifeless> TresEquis: so what I think you are saying is "There is a testing and refactoring risk with subunit in zope.testing at the moment"
<TresEquis> yes
<lifeless> TresEquis: and "That risk must not be increased and should be decreased"
<TresEquis> in particular, we are actively refactoring zope.testing
<lifeless> TresEquis: and I agree with both of those.
<jml> the subunit stuff in zope.testing is very well tested, fwiw and was added just before the recent split-out of zope.testing.testrunner was proposed
<lifeless> TresEquis: however you also seem to be implying "the patch from mars increases the risk"
<lifeless> TresEquis: which seems entirely false to me, as it comes with tests.
<TresEquis> lifeless: I said earlier in this conversation that I could see mars' fixes landed by somebody like sidnei
<lifeless> ok cool.
<TresEquis> who can test them
<lifeless> then we're good. I will get to your subunit patch, I promise.
<lifeless> now we're not house hunting I should be able to catch up with my personal projects  :)
<TresEquis> but I'm unwilling to see *more* features added that can't be tested by anybody working on zope.testing
<mars> TresEquis, yes.  I didn't even realize the subunit tests were conditional when I added them.  My subunit unit test would break on those dev's workstations :(
<TresEquis> if subunit support in zope.testing were automated, for instance, then I or Lennart or somebody could help get them ported to zope.testrunner (without aforementioned timesuck)
<jml> sorry, I've joined late, but by "automated" you mean something more than the large number of doctests that are already present and run whenever subunit is installed?
<TresEquis> zope.testing's self-dependency (it needs itself to run its own tests) has been a major stumbling block on porting zope.* code to Py3k, for instance
<TresEquis> jml: they should run *always*
<TresEquis> or else the code will bitrot
<jml> TresEquis, what about the code in z.testrunner that only works if Python is compiled with certain options?
<TresEquis> which means that getting subunit-python into the buildout (or better, the virtualenv) is crucial
<TresEquis> hmm?
<TresEquis> those features are tested on buildbots
<jml> TresEquis, so, would it be good enough for me to set up a hudson instance (or I guess a buildbot) that runs the tests in an environment w/ subunit installed?
<TresEquis> those features are also used frequently by at least some of the folks who maintain zope.testing
<TresEquis> subunit isn't (yet, at least)
<TresEquis> except for sidnei, apparently
<jml> TresEquis, my outsider status aside, I do use subunit w/ zope.testing frequently and I do send patches
<TresEquis> jml: right
<TresEquis> it's just hard to do the refactoring of zope.testing / zope.testrunner without knowing whether we have broken the conditional tests
<jml> TresEquis, well, you'll have to test both paths anyway as long as it's an optional dependency
<TresEquis> my branch for subunit adds a distutils setup.py for the package, for instance:  lifeless is going to look into merging it
<jml> TresEquis, I guess you could hack up something that tweaks sys.modules or what-have-you
<TresEquis> jml: we have patterns for that:  e.g., the buildout has separate parts for separate Python versions, etc.
<jml> oh right.
<jml> buildout :)
<mars> jml, I think the idea was to make subunit a required dependency for developers, but optional for users
<TresEquis> jml: not everybody lives in a .deb monculture
<TresEquis> mars: rithe
<TresEquis> sorry, right
<TresEquis> and make it trivial to install
<TresEquis> I actually made a stab at doing a CMMI build *inside* the buildout
<TresEquis> but ran out of tuits
<jml> TresEquis, you should have read my blog post first :)
<TresEquis> subunit is just a little cranky to build
<jml> yep.
<TresEquis> the Python bits are straightforward, though
<TresEquis> at least for now
<TresEquis> lp:~tseaver/subunit/add_distutils_support
<TresEquis> creates an sdist which installs the library code and the tests cleanly
<TresEquis> sorry, s/tests/filters/
<jml> TresEquis, have you verified that this makes a usable egg for your purposes?
<mars> lifeless, does your testtools traceback branch obsolete my zope.testing traceback branch?
<lifeless> I don't think so
<mars> ok
<TresEquis> jml:  that was at the end of the tuit stack, too
<meoblast001> hi
<TresEquis> I did verify that it made an sdist installable in a virtualenv
<TresEquis> and that the filter scripts could run with '--help'
<mars> lifeless, actually, it looks like they are unrelated.  testtools can't handle utf-8 : neither could the zope.testing subunit output.  Same bug, different pieces of code.
<TresEquis> meaning that they could import subunit
<lifeless> mars: right
<lifeless> mars: the testtools fix that mgz is doing is rather deeper
<jml> TresEquis, cool.
<lifeless> mars: because pedants
<meoblast001> i have a friend who uses Windows who will be testing a project i'm working on.... he installed Python 2.6.5, Bazaar, and Bazaar Explorer, but he gets a cannot execute bzr error
<jml> TresEquis, I guess ideally I'd like to know it works before I merge it, particularly since setup.py's are quite hard to test automatically.
<lifeless> mars: and interestingly I've got a patch I'm looking at right now to address a similar cause in subunit itself
<mars> lifeless, yes, I thought about finding and fixing traceback inputs for all of 5 minutes before moving to a defensive code solution
<TresEquis> jml:  one trivial test is to run 'python setup.py --long-description', or whatever, and examine the output
<TresEquis> which at least guards against syntax errors
<mgz> lp:~mars/zope.testing/fix-subunit-utf8-traceback-reporting right?
<TresEquis> but the folks doing the release-to-PyPI are the ultimate watchdogs
<TresEquis> which works because they rely on setup.py to do that task
<lifeless> mars: yes
<lifeless> bah
<lifeless> toomanyms
<jml> TresEquis, I don't know who's going to do that :)
<lifeless> mgz: yes
<mars> mgz, yep.  We had a crash where the traceback coming into the code could be uft8, unicode or ASCII.  And it is in a testrunner, so for the tb contensts, anything goes!
<mgz> it's similar in that it adds handling for arbitrary bytestrings as tracebacks.
<lifeless> jml: I'm happy for any subunit committer, which includes you, to upload stuff to pypi - I'd like them all to have permissions.
<lifeless> in fact
<lifeless> I'd like a lp-group-to-pypi-project permission syncer
<lifeless> I can has automation please?
<jml> lifeless, LP has APIs. Don't know about PyPI
<mgz> the branch for testtools is more like changing your OutputFormatter.format_traceback code to always return unicode
<mgz> but both are trying to squish the same kind of problem.
<lifeless> jml: it has a web UI at lesat ;)
<TresEquis> jml: Stephan Richter has some script he uses to bless / blast users with perms for zope.* packages
<jml> lifeless, and james_w has beautifulsoup matchers. you should write the syncer now :)
<james_w> \o/
<james_w> did you see my bug about matchers and addDetail?
<jml> no, I didn't.
<TresEquis> PyPI speaks xmlrpc, I think:  http://wiki.python.org/moin/PyPiXmlRpc
<james_w> Mismatches should have a way to persuade assertThat to call addDetail with a bunch of Content if it fails due to them
<james_w> I want to stop the Mistmatch.describe() methods in soupmatchers stop printing the whole html, as that's a terrible idea, but I would love to provide it for looking at if desired
<jml> TresEquis, if I merge this patch into trunk but don't release, will that help / unblock you?
<lifeless> james_w: oh thats a great aidea
<lifeless> james_w: please do it
<lifeless> james_w: I suggest a query interface on Mismatch
<lifeless> james_w: get_details, or something
<james_w> I suggested an attribute, but that works fine
<lifeless> and then, assertThat can do 'for content in Mismatch.get_details: self.addDetail(unique_name, content)'
<lifeless> or roughly that
<james_w> bug 591327
<lifeless> adjust as you please
<ubot5> Launchpad bug 591327 in testtools "Please allow Mismatches to add detail to the result (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/591327
<lifeless> these abstractions are feeling really right
<james_w> yeah
<james_w> though of adding disposition to Content?
<james_w> thought
<lifeless> mm
<james_w> as in inline/attachment
<james_w> which could be interpreted by a runner as to whether to display by default?
<lifeless> I don't think it belongs there
<mgz> derailing the Matchers topic a bit, did anyone play my spot-the-difference from earlier? http://paste.ubuntu.com/447885/
<lifeless> content maps well to email, http, disk files
<lifeless> what to do and how to address it is a wrapper issue - IMO, I may well be wrong
<TresEquis> jml: we aren't really unblocked meaningfully until we can either install 'subunit-python' from PyPI (or another URL)
<TresEquis> or else build subunit inside the buildout
<TresEquis> I prefer the former at this point ;)
<jml> TresEquis, ok. that's good to know.
<TresEquis> if somebody made the sdist from that branch and put it up somewhere "permanent"
<james_w> plus there's my testtools merge request if someone wants to take a look?
<TresEquis> then we could point to that URL in the 'find-links' bit for the buildout
<jml> TresEquis, I'm a little reluctant to release subunit right now, mostly because it's too much of a context switch and I'm not 100% the setup.py does what we want. Also I have to leave for a flight in ~30mins
<james_w> (t-i-p IRC channel?)
<jml> james_w, yeah, let's
<TresEquis> and procede accordingly
<lifeless> james_w: that is #python-testing
<jml> TresEquis, but I'll try to get to it tomorrow or next week, and try prodding lifeless to get there first :)
<jml> mgz, nothing stands out
<TresEquis> jml: OK -- in the meanwhile, sidnei or gary_poster or somebody with subunit-fu can go ahead and do the merge of mars' branch
<jml> TresEquis, cool.
<mgz> indeed. only printing the actual line for the Mismatch would help, and putting the whole thing as an attachement as was being discussed
<jelmer> lifeless: so, bug 309682
<ubot5> Launchpad bug 309682 in Bazaar Subversion Plugin "tags are copied but their revisions may not be (affected: 0, heat: 9)" [Low,Triaged] https://launchpad.net/bugs/309682
<jelmer> james_w: ^
<jelmer> I'm wondering if the right approach is to fetch all revisions for which we have tags
<james_w> jelmer: I'd be happy with that
<james_w> jelmer: would it be any more expensive for bzr-svn?
<jelmer> james_w: not particularly
<jelmer> james_w: of course if there's a revision tagged that doesn't have any relation to the mainline it will mean fetching more data
<jelmer> but that doesn't seem unreasonable
<lifeless> jelmer: I think we should do that
#bzr 2010-06-11
<lifeless> argh
<lifeless> traceback.format_exception_only is broken
<lifeless> whats wrong with this (python 2.6):
<lifeless> 171  ->     if (isinstance(etype, BaseException) or
<lifeless> 172             isinstance(etype, types.InstanceType) or
<lifeless> 173             etype is None or type(etype) is str):
<lifeless> 174             return [_format_final_exc_line(etype, value)]
<lifeless> mgz: ^
<lifeless> ah, little early.
<lifeless> hmm, I need a teddy bear
<Meths> What's the error msg?
<lifeless> it doesn't crash-fail, it formats wrongly
<lifeless> looks like some remaining 'string exception' support that hasn't been cleaned up
<lifeless> I'm going to see about tackling it differently
<lifeless> ok, \o/
<lifeless> python3 would be so much nicer
<mgz> you say that lifeless
<mgz> I spent this afternoon looking at python 3, and have come to the conclusion it doesn't do unicode properly
<lifeless> mgz: that doesn't entirely suprise me
<lifeless> hey, can I get your opinion on two small patches
<lifeless> gimme a sec to pastebin em
<lifeless> http://pastebin.com/qrys3xgK
<lifeless> http://pastebin.com/M7AwUADN
<mgz> http://paste.ubuntu.com/447983/ <- I just want my repl :_:
<lifeless> mgz: ironpython3 ?
<mgz> no, straight up python 3, built from trunk by my own fair hand this afternoon
<mgz> I guess it's just no one has bothered testing it on a non-utf-8 terminal or something
<lifeless> is your console encoding set correctly ?
<mgz> yes, it's correctly set tp cp932
<lifeless> weird
<lifeless> so what do you think of those two patches
<mgz> sys.stdout is "strict" though, which added to them trying to be clever with repr = bad experience
<mgz> first one seems fine.
<lifeless> the subunit one is for [] tracebacks, which have no explicit encoding (but I am just going to treat as utf8 and retroactively define them thusly
<mgz> second one is building on wrong code.
<mgz> the current __str__ method there doesn't do what the person who added it thinks it does
 * lifeless provides context
<lifeless> PQM is failing to format and attach subunit summaries
<lifeless> even though the WEBUI is doing just fine
<lifeless> its failing because bzr's formatters upcast stuff to unicode in a couple of places [bad], and because testtools uses the iter_text code path for deserialising text/* objects
<lifeless> which become unicode
<lifeless> and then traceback.format_exception_only triggers an implicit conversion to __str__, and ye old ascii codec raises its head
<lifeless> so the subunit one permits iter_text to work
<mgz> where does subunit hook into testtools test results?
<lifeless> and the testtools lets it format properly in traceback.format_exception
<lifeless> subunit/details.py line 47
<lifeless> its weakly coupled - speaks the same object protocol, magic happens
<mgz> okay, in which case, I think you just need my traceback branch
<mgz> the problem with testtools currently is that exceptions go through traceback.format_exception *twice*
<mgz> once originally in the test result, and then again in _StringException form
<lifeless> ok
<mgz> I changed both of those to use unicode, so it's no longer cooercing to str
<lifeless> my testtools patch would seem in line with that change
<lifeless> neither right or wrong
<lifeless> mgz: I want your patch; is it finished?
<lifeless> win goto #debian-devel
<mgz> ^it's similar indeed, it's just spelled more specifically in the unicode traceback branch (because the possible variations are reduced)
<lifeless> ok
<lifeless> so as I'm going to be getting the syadmins to do a kindof backport of these two things
<strk> Bazaar (bzr) 2.1.1
<lifeless> I'm going to go with the little one, unless it will break your branch.
<strk> 4 lines diff
<strk> over sftp
<strk>   4272KB     3KB/s | Uploading data to master branch - Stage:Fetching revisio
<mgz> the main problem with yours is you're hardcoding certain things from the environment that won't always be correct
<lifeless> strk: sftp is the problem, its a database
<lifeless> strk: if this is savannah, bzr+ssh support is being worked on.
<strk> no 'packing' thing ?
<strk> long ago someone mentioned it was "packing" one of the problems
<mgz> for a backport to fix pqm, I presume this isn't a concern, it's only one machine
<lifeless> strk: autopacking is part of the database layer yes
<strk> I mean, is there anything I could do to improve the situation while over 'sftp' ?
<lifeless> strk: not really.
<strk> like disabling autopacking while on gprs ?
<mgz> <lifeless> mgz: I want your patch; is it finished? <- I have some brown paper bag things to push, then need to work out how to no re-break py3k support (which is currently broken, so may not matter much), then the moving around we discussed
<mgz> it's close, want to get it done before I go away for the weekend really
<lifeless> mgz: py3k is broken? worked for me in our hudson
<lifeless> mgz: I need to start that machine up again soon
<mgz> what method are you using to install it? both ways I tried had problems.
<mgz> I filed a bug and made a merge proposal at any rate
<lifeless> ah, import issue with the result refactoring
<mgz> and 2to3 had problems with the Queue import.
<lifeless> yeah, testtools is single-source not 2to3
<mgz> anyway, I have a big issue in that there seems to be no source-compatible way of spelling unicode literals
<mgz> so I'm not sure how to write the tests I need to do
<mgz> u"\u1234" -> ???
<mgz> the _u function is useless because it assumes latin-1
<mgz> everything else I think I can hack around though.
<mgz> (well, I can hack around that too, I just need to pick which ugly method I least dislike)
<lifeless> change _u to assume utf8 ?
<mgz> that breaks one of the current uses, so I assume it's the way it is for a reason, though it's not clear
<lifeless> point me at the use?
<mgz> testtools/tests/test_content.py:        self.assertEqual([_u("bytes\xea")], list(content.iter_text()))
<lifeless> I love the way 3.x is becoming harder and harder to be compatible with.
<lifeless> Its almost like upstream want -no- adopters
<mgz> yeah, a bunch of this stuff just doesn't seem thought through
<lifeless> mgz: recode that literal as utf8 ?
<mgz> can do.
<lifeless> mmm
<lifeless> actually
<lifeless> here's the algorithm:
<lifeless>  - find out what python3.x will do with a bare string
<mgz> the other option is something like... _unicode(r"\u1234") where I call .decode("unicode-escape") for Python 2
<lifeless>  - pick some bare string that will result in the same unicode object that that current one does, with a changed _u function
<lifeless>  - then change the _u function as you desire
<mgz> need to remember the r for that, but is easier to read than encoded utf-8
<lifeless> hah
<mgz> also filed a bug for the string exception thing as you requested, I can't actually see any downside to changing to a bare except clause
<lifeless> james_w: your patch from python3.x :)
<lifeless> whats 'print "foo"' in python3 ?
<lifeless> mgz: oh, base exception in all 2.x releases is broken broken broken in its unicode handling
<lifeless> mgz: theres a upstream bug about it
<lifeless> mgz: __unicode__ triggers ascii decoding, __str__ triggers ascii encoding, with all sorts of weird side conditions IIRC
<mgz> yup, got to be careful about what you put in builtin exceptions
<lifeless> mgz: ok, 3.1 support pushing up now
<mgz> cool, I'll merge trunk back in rather than fiddling with it more here
<jelmer> 3.1 support for testtools?
<lifeless> jelmer: yep
<jelmer> nice
<lifeless> we had 3.0
<lifeless> but 3.1 changed the rules for imports again
<mgz> pushing my fixes for idiocy, I'll then get py3k working
<mgz> lifeless: what do you think about moving testtools.utils.iterate_tests to testtools.testsuite.iterate_tests and renaming utils 'compat' or similar?
<mgz> it's mostly encoding stuff, but some other misc py3k things too
<lifeless> sure
<lifeless> uhm
<lifeless> please rename utils.py, and then add back a module which imports the old things and does the deprecationwarning dance if its imported at all
<mgz> well, iterate_tests is the only public function
<lifeless> yes
<mgz> I could just leave it there, and move everything else
<lifeless> whatever is easier
<lifeless> my concern is just that we will probably have folk wanting backports/SRU's
<lifeless> and the easier for them, the better - particularly when its low cost to us.
<poolie> hi there lifeless, mgz
<mgz> hey poolie
<mgz> okay, I'm now at... clean on 2.4, clean on IronPython, two failures on Jython due to a single space difference, and syntax error on py3k
<mgz> let's squish that last one
<poolie> lifeless, i don't want to spend all day on test frameworks
<lifeless> I can feel a but turning up ;)
<poolie> but i did realize last night that the current protocol means many fixtures
<poolie> heh
<poolie> many fixtures must override tearDown and then super-call
<poolie> similarly setUp
<poolie> and we just went through realizing this was error-prone in test cases themselves
<lifeless> agreed
<lifeless> this seems more an internal contract question, not the public composing contract though ?
<poolie> we could say that when you subclass Fixture, you should implement doTearDown for example
<poolie> separating out the template method
<poolie> alternatively we could just say that fixtures are ObjectWithCleanup
<lifeless> [template] I don't think that works very well in python for avoiding 'fail to upcall', because as soon as two classes in one MRO do it, it requires upcalling.
<lifeless> something like TestCase.addCleanup would be good, I think
<lifeless> I was thinking self.manageFixture(fixture_I_created)
<lifeless> to hook into setUp and tearDown in LIFO order
<lifeless> james_w: while you're looking at testtools.run, supporting bug 505386 would be most awesome
<ubot5> Launchpad bug 505386 in testtools "testtools.run should support selecting tests by id (affected: 2, heat: 8)" [Wishlist,Triaged] https://launchpad.net/bugs/505386
<spm> lifeless: heyo; where are we at with pqm this fine friday?
<lifeless> spm: nothing to do at the moment
<lifeless> spm: I am doing some metaphorical housecleaning
<lifeless> will have some new dep packages to build in CAT later
<spm> so... all finished? ie I can close the RT? or leave it pending for now?
<spm> ahhh
<lifeless> spm: turtles all the way down (python2 and unicode and str types is a freaking disasterous mess)
<spm> \o/
<mkanat> I thought it was mud all the way down. :-)
<lifeless> mkanat: its terrible every which way ;)
<mkanat> :-D
<lifeless> mkanat: hey glad you're here, we had some 500's on loggerhead today
<lifeless> mkanat: not server hangs though
<mkanat> lifeless: 500's? That's odd.
<lifeless> mkanat: hopefully Chex will have filed a bug
<lifeless> mkanat: yes
<lifeless> mkanat: a restart didnae halp
<mkanat> Dang.
<lifeless> which suggests incomplete handling of a bzr core exception, to me.
<lifeless> something we should show rather than go boom on.
<lifeless> so conceptually shallow
<lifeless> mars: what was the branch again ^
<poolie> lifeless, i wonder if we should say that the person setting things up is responsible for starting them, if that's needed
<poolie> probably it's not needed in most cases
<poolie> anyhow it's not complicated to do so
<poolie> then just use addCleanup to shut them down, and fixtures that themselves create fixtures are responsible for getting them shut down
<lifeless> poolie: I think the start/stop are paired, separate from instantiation, and the responsibility of the instantiator
<lifeless> poolie: so convenience support for that would be nice.
<lifeless> mars: bug 592262, if you want to chat in realtime, I'm here
<ubot5> Launchpad bug 592262 in testtools "testtools breaks if a string exception is raised (affected: 1, heat: 6)" [Wishlist,Incomplete] https://launchpad.net/bugs/592262
<lifeless> ba
<lifeless> bah - mars sorry!
<lifeless> mgz: ^
<lifeless> too many m's
<mgz> so, I don't see any risk in just doing:
<mgz> -    except Exception:
<mgz> +    except:
<lifeless> mgz: KeyboardInterrupt and SystemExit
<mgz> but I've not looked at py3k properly till today and it's still... suprising me
<mgz> KeyboardInterrupt is being explicitly caught above anyway
<lifeless> ah
<spiv> And string exceptions ;)
<mgz> if we worry about SystemExit/GeneratorThingy, can just add them up there too
<lifeless> mgz: I think my main hesitation is that there's no good reason to care :)
<mgz> (caught and re-raised)
<lifeless> mgz: [that I know of]
<mgz> well, people sometimes forget their classnames, and unittest Does The Right Thing
<mgz> it's not a big issue, I just wrote a test for it and it made the run fall over
<spiv> In addition to GeneratorExit, there's anything else that someone decides to base off BaseException rather than Exception in their own code.
<mgz> well, there's bags of code in the stdlib that gets the exception heirachy wronger than this
<mgz> catching the wrong stuff, letting to much through, etc etc
<spiv> So, if the goal is "not catch string exceptions"
<lifeless> mgz: heh. We don't need to lower ourselves to its level ;)
<spiv> Then why not explicitly "except BaseException:" ?
<mgz> current annoyance - how the hell am I meant to get a copy of stdout that won't blow up randomly for py3k
<mgz> BaseException doesn't exist in 2.4
<mgz> and no, the goal is catching string exceptions, in my opinion.
<spiv> Or "except BaseException: raise" "except Exception:..."
<lifeless> ok
<lifeless> so what do I care about here?
<lifeless> I care that:
<mgz> attribte lookup code and other core stuff can swallow SystemExit and so on
<lifeless>  - we do the right thing on as many pythons as possible.
<mgz> nothing does is right
<spiv> mgz: "try: BaseException; except NameError: BaseException = Exception".  Or even = () ;)
<lifeless>  - where we can't do it right on both 2.N and 2.N+(M>0), and can do it right on either of them, I'd rather 2.N lose out.
<lifeless>  - where we can't get it right no matter what, maintainable code in testtools should become a consideration
<lifeless> string exceptions in particular I had discounted because python itself, in the 2 series, has made them illegal.
<lifeless> but I have no intrinsic objection to supporting them.
<lifeless> I *suspect* the rabbit hole is kindof deep.
<mgz> doesn't seem all that bad to me.
<mgz> not compared to trying to actually make sure KeyboardInterrupt is always propogated
<lifeless> mgz: we do pretty good on KI at the moment I think
<mgz> sure it's just the platform that's the problem :D
<lifeless> mgz: so, the question spiv raised earlier is a good one. What about 'class MyBase(BaseException): pass'
<mgz> `getattr(a, "b", None) is not None` only gets you so far
<lifeless> mgz: indeed, thats buggy :)
<lifeless> sentinel = object(); getattr(a, "b", sentinel) is not sentinel
<mgz> ^if not isinstance(e, (Exception, str)): raise
<lifeless> mgz: ok, so
<mgz> where we get e from sys.exc_info for py3k source happiness
<lifeless> except:
<lifeless>  exc_info = sys.exc_info()
<lifeless> etc
<mgz> right. three line diff.
<lifeless> mgz: ok, if you add a couple of tests for failure modes we've discussed and are avoiding here. Then +1
<mgz> what could possibly go wrong. ;)
<lifeless> mgz: ohhhh, we've seen a bit
<mgz> argh, this is a nightmare... I think I have to manually clone this wrapper just to get a working stdout
 * mgz curses people with unicode terminals and no imagination
<lifeless> :<
<lifeless> what should it do if it can't encode to your terminal - show the repr ?
<mgz> well, this is in the context of running a testsuite
<mgz> it has a failure on some test, that happens to involve some non-english text
<mgz> py3k would currently throw a UnicodeError when trying to print the result
<mgz> this seems the least helpful option to me
<lifeless> \o/
<mgz> unfortunately, it also seems to provide no way of actually *doing* anything with the multi-layered nightmare of wrappers, either
<lifeless> but thats ok
<lifeless> at least bytes are a different type now
<lifeless> :P
<mgz> okay...
<mgz> return stream.__class__(stream.buffer, stream.encoding, "replace", stream.newlines, stream.line_buffering)
<mgz> and I actually get complete output.
<mgz> horrible hack, but I'll survive
<lifeless> oh my
<lifeless> mgz: I could send you a CD of Ubuntu, if you like.
<mgz> I could run this on another box, but the code still needs to be able to print test results to a non-unicode target
<lifeless> mgz: I was teasing :)
<mgz> I would play along, but py3k is keeping me up past my bed time...
<lifeless> mgz: http://pastebin.com/bPhtYmkg
<lifeless> mgz: could you give that a very quick eyeball
<lifeless> I've added a comment since you saw it last
<mgz> ack, yes, that self._exc_info_to_string you've added the comment by will be an issue
<lifeless> yeah
<lifeless> I thought it would be :)
 * lifeless upgrades it to XXX
<lifeless> spm: I has updated rt
<lifeless> spm: please advise if I can assist with the CAT stuff
<spm> lifeless: yarp; just read same. ta.
<spm> possibly - should be ok from here.
<mgz> currently I'm doing .encode("ascii", "replace") in _StringException.__str__ so even people with fancy utf-8 terminals will see errors when everyone else does ;)
<lifeless> mgz: evil!
<lifeless> self.pop()
<lifeless> looms, right
<lifeless> I feel the need for wotw
<mgz> okay, is my py3k just broken, or is something really stupid going on:
<mgz> >>> open(os.devnull, "w", encoding="ascii").write("it's a repr %r" % "\u1234")
<mgz> Traceback (most recent call last):
<mgz>   File "<stdin>", line 1, in <module>
<mgz> UnicodeEncodeError: 'ascii' codec can't encode character '\u1234' in position 13: ordinal not in range(128)
<mkanat> mgz: That sounds right.
<mkanat> mgz: ascii can't encode Unicode character 1234.
<mgz> I see no reason that trying to write a repr to file should be attempting to encode the *escaped* string
<mgz> I'm not writing \u1234, I'm writing \\u1234
<mgz> as it were.
<mkanat> mgz: Did you mean r"\u1234"?
<lifeless> what does "%r" % "\u1234" do ?
<mgz> that, I'd hope.
<lifeless> mkanat: he's simulating the code path of a test error report
<mkanat> mgz: I think %r of a string is the string.
<mgz> then what's %s?
<mkanat> mgz: Also a string.
<lifeless> >>> "%r" % "\u1234"
<lifeless> "'á´'"
<lifeless> >>> type("%r" % "\u1234")
<lifeless> <class 'str'>
<mgz> okay, so these days, repr is useless.
<mkanat> mgz: But %r takes any data type.
<lifeless> >>> len("%r" % "\u1234")
<lifeless> 3
<lifeless> >>> len("\u1234")
<lifeless> 1
<lifeless> mkanat: its not the string itself
<mkanat> lifeless: Sure, it's the string in quotes. :-)
<mgz> it just... adds quotes
<lifeless> it is, helpfully, '-thestring-'
<lifeless> mgz: yes, :)
<mgz> so, I need encode ascii and backslashreplace instead I guess
<lifeless> so repr is unicode these days
<mkanat> mgz: Is there not a way to make encode="ascii" be more lax?
<lifeless> mkanat: terrible for debugging
<mgz> not and actually have the test still be meaningful
 * mkanat nods.
<lifeless> mkanat: we want a codec that shows how to get back a unicode string from an ascii editor
<mkanat> lifeless: Ah.
<lifeless> mkanat: which repr in python 2.1 was
<lifeless> mgz: unless I've got something wrong ?
<lifeless> s/1/x/
<mgz> nope, that's it.
<mgz> I'm testing string roundtripping in testtools, this means I need to be knowing exactly where I am at all stages... which py3k source compat is confusing somewhat
<mgz> get this string into this file in this encoding escaped thusly, test than running said file gets sensible unicode output
<thumper> how do you 'close' a branch?
<spiv> chmod -R a-r?  Or is there something more you want than "no-one has permission to change this"?
<rockstar> spiv, I think thumper wants something like open().close(), but for branches.
<spiv> Oh, ok.
<spiv> There's no explicit close in the API.  The closest we have is "release all references to that object".
<spiv> What's this for?  If it's to do with tests and connections vila is working on something in that area.
<rockstar> thumper, ^^
<lifeless> indeed, Branches have the same lifetime as any python object.
<lifeless> 'del' should do
<lifeless> a 'closed Branch' does not make any sense, it would be an invalid state for the object to be in.
<lifeless> jam: I'm going to feel all guilty now.
<jam> lifeless: don't, I'm capped on everything but goo
<jam> it's actually a bit boring
<lifeless> jam: yeah, I saw when you zerged me :)
<jam> please steal some stuff so i feel worthwhile again :)
<lifeless> ok, well the weekend is approach
<lifeless> I'll see what I can do
<BlindWolf8> Hello. Anyone here?
<spiv> Yes.
<BlindWolf8> Hi spiv.
<BlindWolf8> I have a question about Bazaar setup. Are you able to help me?
<spiv> Maybe :)
<spiv> Ask the question and we'll find out!
<BlindWolf8> Haha... I have Bazaar v2.2b3 installed on my server
<BlindWolf8> right from source
<BlindWolf8> I am on a Windows box and I installed bzr on a Linux box
<BlindWolf8> I downloaded Bazaar on my Widnows box and went to create a new shared repo remotely on the Linux box through Bazaar explorer
<BlindWolf8> I get Permission errors (error 13)
<BlindWolf8> The user that I logged in as should have permission for everything. I am not sure what it's trying to do.
<spiv> Hmm.
<spiv> Creating a shared repo just tries to create a few directories and files, and does some renames of files along the way.
<BlindWolf8> Could it be the group the user is in?
<spiv> There should be a traceback in bzr's log file, if you run "bzr --version" it should tell you where to find it.  If you can pastebin that it might provide a clue.
<BlindWolf8> OK, hold on one moment...
<BlindWolf8> there's a .bzr.log will that help?
<spiv> Yes, that's the file.
<lifeless> also look in the .bzr.log on the server :)
<lifeless> depending on versions and so forth, some of the code runs on the server side
<spiv> How are you accessing the shared repo remotely?  Via a bzr+ssh URL, or a SMB share, or..?
<BlindWolf8> bzr+ssh
<BlindWolf8> using a public/private key, which works
<BlindWolf8> yeah, I meant the .bzr log on the server
<BlindWolf8> so, whihc log do you want?
<BlindWolf8> The exact error I get in Bazaar Explorer is: bzr: ERROR: Permission denied: ".": : [Errno 13] Permission denied: '/.bzr'
<BlindWolf8> Hello?
<BlindWolf8> Hi Adys
<BlindWolf8> Hello all.
<spiv> BlindWolf8: the bzr log from the client to start with, I think, but the remote one might be interesting too
<spiv> BlindWolf8: that error does sound likely to be a simple permissions problem, though
<vila> hi all
<spm> hey vila
<vila> thumper, spiv: In a forthcoming submission I implemented a transport.disconnect() method that close the socket for transports that have one
<vila> thumper, spiv: That means that the transport objects as still usable since they will reconnect on demand while also providing a way to collect the unused sockets when needed
<spiv> vila: and the hooks we discussed?
<vila> spm, spiv: Could we configure the news_merge plugin on the pqm host ? I got two submissions failing yesterday because of that
<BlindWolf8> OK, I'm back.
<vila> spiv: I've still to implement them and they still sound like the best idea so I will :)
<spm> vila: I guess, not sure what you need/where tho?
<BlindWolf8> spiv: Where are the logs on the client side?
<spiv> I think lifeless may have filed a RT about enabling news_merge on the PQM host, not sure.
<vila> spm: Either in branch.conf or locations.conf in the appropriate section, we need: news_merge_files = NEWS
<spiv> BlindWolf8: open a command prompt and run "bzr --version" and it should tell you.
<BlindWolf8> spiv: got it!
<BlindWolf8> spiv: Here's the client log: http://pastebin.com/CBmzHwZd
<spm> spiv: vila: if he has, it's not got 'news_merge' anywhere in it.
<vila> spm: 'he' == lifeless ?
<spm> yup
<spiv> spm: ok, good to know.  Thanks for looking :)
<spm> tho, specifically, anyone; the search was pretty open. :-)
<vila> spm: It could be that he asked for a bzr upgrade so the plugin was available but didn't mention the .conf stuff
<spm> we have been faffing around with pqm upgrades the past few days; so possibly in there somehow
<spiv> Yes, I think the only pre-req is that PQM is using bzr 2.1 or newer to do the merges.
<spiv> If that's done, then probably turning on news_merge is a good idea.
<BlindWolf8> spiv: If this helps: client: 2.1.1, server: 2.2b3
<spm> spiv: Bazaar (bzr) 2.0.4, so no. :-)
<BlindWolf8> spiv: huh?
<spiv> BlindWolf8: was talking to spm, sorry!
<spm> spiv: hrm. interesting. might actually be running 1.17. we're not using the system bzr for bzr itself; have a local copy
 * spm has visions of shaving yaks in the near future
<BlindWolf8> spiv: haha, no problem
<lifeless> woo
<lifeless> Ran 2 tests in 0.578s
<lifeless> OK
<lifeless> bzrlib.plugins.loom.tests.test_branch.TestLoom.test_sprout_remote_loom is leaking threads among 1 leaking tests.
<BlindWolf8> spiv: Thanks again for any help you can provide...I've come this far...so close!
<vila> lifeless: using an http or sftp server ?
<lifeless> vila: bzr+ssh
<lifeless> vila: I must be tired, I didn't answer 'False' :)
<spiv> BlindWolf8: so, this seems likely to be a fairly normal permissions problem: that error seems likely to be due to "mkdir .bzr" in failing
<vila> lifeless: yeah, so one leaked thread for each connection, we need one of the hook spiv mentioned above to catch them
<BlindWolf8> spiv: Odd. I can ssh in and make the dir myself no problem.
<vila> lifeless:  :)
<spiv> BlindWolf8: hmm, odd indeed!
<BlindWolf8> spiv: my exact commend, for reference is bzr+ssh://user@site.com:port
<vila> lifeless: i.e. the smart server starts a daemonic thread for each client connection, a hook there will allow the tests to shut them down
<spiv> For some value of "exact", I'm sure ;)
<BlindWolf8> spiv: LOL
<spiv> If there is a traceback in the server's .bzr.log that would be interesting too.
<BlindWolf8> spiv: there's not. The only thing I notice is that there's two return code...btoh are 0s
<BlindWolf8> spiv: I can pastebin it tho if needed for ref.
<spiv> Did the server manage to create any directories?
<BlindWolf8> spiv: no
<spiv> No I don't need to see the server log then, that's ok, that's what I'd expect.
<BlindWolf8> spiv: oh wait, whoa...
<lifeless> vila: oh, I wasn't talking about the leak
<lifeless> vila: I was talking about the remote loom branch working
<spiv> lifeless: hooray for loom working!
<BlindWolf8> spiv: looking at the server log, looks like there was a traceback at one point
<vila> lifeless: hurrah !!!
<spiv> BlindWolf8: to do with permission denied?
<lifeless> spiv: please comment on http://pastebin.com/e4fs3zey
<vila> lifeless: I had to copy the last-loom file manually this week
<lifeless> vila: the shutdown-of-the-server thing - no hook needed, surely. We already call tearDown on the server, that can DTRT, can't it ?
<vila> lifeless: Well, we *can* collect the threads/sockets for all cases but we really need it for the tests
<BlindWolf8> spiv: here's the log from the server: http://pastebin.com/UPez6RS7
<spiv> lifeless: Hmm, _ensure_real for sprout?  Isn't that going to regress some HPSS call count ratchets?
<lifeless> spiv: thats on Format
<spiv> lifeless: oh right
<lifeless> spiv: :!./bzr selftest --no-plugins branch.*acceptance --strict
<lifeless> bzr selftest: /home/robertc/source/baz/pending/working/bzr
<lifeless>    /home/robertc/source/baz/pending/working/bzrlib
<lifeless>    bzr-2.2b3 python-2.6.5 Linux-2.6.32-22-generic-x86_64-with-Ubuntu-10.04-lucid
<lifeless>                                                                                                                                                                                                                                               
<lifeless> ----------------------------------------------------------------------
<lifeless> Ran 3 tests in 6.135s
<spiv> BlindWolf8: yeah, that's nothing interesting (at some point you ran "bzr whoami" and it logged some stuff about the whoami info not being set yet)
<BlindWolf8> spiv: before that though
<lifeless> vila: Clean shutdown matters for real servers too - we need to interrupt long running threads somewhat cleanly or we can cause bad http results and so forth (think 1.0 envelopes)
<BlindWolf8> spiv: I did notice a traceback
<lifeless> vila: I still don't understand why a hook is needed
<lifeless> vila: and I'm really concerned that its just confusing overhead we don't need
<spiv> BlindWolf8: I'm not sure what you're talking about?
<BlindWolf8> lemme see...
<lifeless> vila: why won't 'tearDown the server kills its threads' do the right thing ?
<lifeless> vila: -and- why does a hook do better ?
<BlindWolf8> spiv: ah eyah, misread...it was the whoami
<spiv> BlindWolf8: I'd be interested to see if you can make that directory using a sftp://... URL instead of bzr+ssh://...
<BlindWolf8> spiv: so, what would you recommend?
<lifeless> spiv: any other comment than that ?
<vila> lifeless: that's what I've currently implemented for SmartTCPServer_for_testing
<BlindWolf8> spiv: Would it have to do with my version being beta on the server?
<vila> lifeless: spiv mentioned the hook as being useful in the general case too
<spiv> lifeless: it's not just about threads, it's about FDs
<lifeless> vila: qualify that please :) - what is the that that you speak of
<BlindWolf8> spiv: OK, I'll try it out
<vila> lifeless: collecting the threads
<spiv> lifeless: you can prod the test server to shutdown its threads and close its fds
<BlindWolf8> spiv: SFTP Test: FAIL
<lifeless> spiv: right; and we can use the paste glue to raise exceptions in the threads to close their fds immediately etc
<spiv> lifeless: but what about the client side?  The transport objects won't necessarily notice their connection has had the other side close and thus close their fds too.
<vila> lifeless: I haven't implemented killing threads yet as I'm unclear about adding a ctypes dependency here, and even more if it's needed outside the tests
<vila> spiv: client side is a different problem *anyway*
<spiv> vila: ?  I thought we were discussing transport.disconnect?
<vila> spiv: no, we're talking about connections received by the smart server
<spiv> BlindWolf8: but you can ssh to that server as the same user and make that directory (or even "bzr init-repo")?
<lifeless> spiv: client side sockets only matter for zope.testing AFAICT
<lifeless> spiv: and for them, 'del my_branch' should be entirely sufficient.
<lifeless> spiv: in fact, the test attribute cleanup we already do should remove all references; it may be we have cycles to take care of.
<BlindWolf8> spiv: I can ssh in and make the dir and run "bzr init". Have not tried "bzr init-repo"
<BlindWolf8> spic the directory that I'm using has nothing in it. DOes that matter?
<lifeless> spiv: While I dislike transport.disconnect intensely, I'm resigned to it coming in, but I don't see that thats a hook situation - and a dict of things such a hook would call seems terrible.
<BlindWolf8> spiv: the directory that I'm using has nothing in it. Does that matter?
<spiv> BlindWolf8: no, that doesn't matter
<spiv> BlindWolf8: I'm not sure what the problem is :(
<lifeless> BlindWolf8: whats the URL you're using ?
<lifeless> BlindWolf8: if it is really ' bzr+ssh://user@site.com:port'
<lifeless> BlindWolf8: then you're trying to create a repo in the root of the server
<spiv> BlindWolf8: there should be no difference in access between "ssh user@host mkdir foo" and "ssh user@host" followed by typing "mkdir foo" at the prompt
<lifeless> BlindWolf8: which only 'root' can do
<BlindWolf8> lifeless: the repo isn't public
<lifeless> BlindWolf8: sure, I get that you would want to obfuscate the url.
<lifeless> BlindWolf8: I'm saying that if you don't include a *path* after the port, its making it in /
<lifeless> BlindWolf8: which, unless you're root, really isn't going to work.
<spiv> lifeless has a good point, bzr+ssh (and sftp) URLs in bzr are relative to the root of the filesystem, not the home directory.
<BlindWolf8> lifeless: hmmmm...
<lifeless> a much more usual path would be e.g. /srv/myrepo, e.g. bzr+ssh://user@site.com:port/srv/myrepo
<spiv> lifeless: well spotted!
<lifeless> and you'd mkdir /srv/myrepo on the server as root first, and chown it to your group/user as appropriate.
<lifeless> spiv: :)
<BlindWolf8> lifeless: that's really odd...I would think that bzr would default to the user's home dir
<lifeless> spiv: really, I just want to get you to tell me about my patch in more detail, can't have you spinning on helping a user ;)
<BlindWolf8> lifeless: as I made a special user with a specific home directory for security reasons
<lifeless> BlindWolf8: we use /~/ to mean 'the users home directory'
<spiv> BlindWolf8: but then how would you give a URL to somewhere not in the home directory?
<lifeless> BlindWolf8: as long as you have a new bzr on both ends that will work fine
<BlindWolf8> lifeless: sorry for bugging you guys :P
<lifeless> BlindWolf8: hey, no problem at all.
<spiv> lifeless: he has 2.2b3 on the server, so /~/ should be fine
<lifeless> BlindWolf8: it was confusing you, and we're here to help :)
<BlindWolf8> lifeless: lemme try it out guys
<spiv> BlindWolf8: Thanks for your patience!
<spiv> We should make this less confusing somehow, although I'm not immediately sure how.
<BlindWolf8> lifeless: I guess that's what I get for assuming that bzr would see the user taht logged in and go "Oh, OK, I'll make it in their home dir"
<spiv> Some sort of verbose logging flag for the server, I guess.
<lifeless> BlindWolf8: indeed, bzr is more like wget than scp
<spiv> BlindWolf8: you can configure the SSH server to do that if you want in the authorized_keys file
<spiv> BlindWolf8: http://doc.bazaar.canonical.com/development/en/admin-guide/security.html#using-ssh
<BlindWolf8> Thanks guys
<BlindWolf8> OK, here's what happened...
<BlindWolf8> Did the command, then the it said it created it. I was like :) but I clicked Close.
<spiv> lifeless: so regarding your patch
<lifeless> I want a 'deprecated_method_blows_up' switch
<BlindWolf8> error'd out complaining about it not being a repo, and I was like :(, but I did Open URL and it looks like it's all good
<spiv> lifeless: python -Werror, or something
<lifeless> spiv: switched the readlock/deprecated lines, works better
<BlindWolf8> Thanks again guys. I think I got it from here.
<BlindWolf8> You guys won't be forgotten
<lifeless> great. Do ask again if you have further issues ;)
<spiv> lifeless: the code change looks ok after a quick look.  Moving this stuff to format does still feel a bit weird but the result doesn't seem worse structurally.
<BlindWolf8> You two will get credit on our game :P
<lifeless> \o/
<BlindWolf8> hahah
<BlindWolf8> l8r guys
<spiv> lifeless: try/finally blocks make me a bit sad, but I realise bzrlib.cleanup isn't as convenient :/
<spiv> lifeless: I haven't read the docs yet
<spiv> lifeless: and that's my comments so far!
<lifeless> so, I haven't done the 'migrate callers across' yet
<lifeless> it may look worse after that
<lifeless> the try:finally stuff - I was going to ask about the best way to do it now
<lifeless> however, I realised I only have one write lock in each code path, and it was previously @decorated anyhow
<lifeless> spiv: what might be nice is an @ decorator to cleanup
<lifeless> @cleanup('source', 'read_lock')
<spiv> Hmm, that might be a touch evil.
<lifeless> spiv: meaning 'call source.read_lock and add the result's unlock to a cleanup object just for this'
<lifeless> spiv: I wants sugah
<spiv> You'd need to burrow uncomfortably deeply in the code object to find which argument is called source
<lifeless> spiv: SUGAH
<spiv> If you required that the relevant arg is a kwarg it wouldn't be so bad.
<lifeless> yeah
<lifeless> is it 3.2 that has kwawrgonly stuf?
<spiv> Sugar is nice, but sugar that has to do complex things at import time and possibly rely on details that aren't guaranteed outside of CPython...
<spiv> 3.something, at least.
<spiv> The exact value of ".something" is a bit academic as far as bzr is concerned :)
<lifeless> anyhow
<lifeless> I'll polish this a bit
<lifeless> but I like the following bits:
<lifeless>  - no VFS for bzr branches
<lifeless>  - no runtime introspection to decide which are bzr and which aren't
<lifeless>  - heads in a direction where we could do a multimethod without the somewhat ugly Remote* magic we had to do for similar stuff in Repository.
<spiv> It would be less pretty, but @cleanup(0, 'read_lock') [where 0 is which positional argument to cleanup] wouldn't be unreasonably ugly to implement.
<spiv> Yeah.
<spiv> The part where it allows looms to DTRT with minimal fuss is a good sign that this is good.
<lifeless> this is the loom patch so far
<lifeless> http://pastebin.com/JnspcZMf
<spiv> lifeless: so, with the PQM issues
<lifeless> should be the entire thing
<lifeless> the key bit is
<lifeless>             # If we're copying from a proxied Loom - a RemoteBranch, unwrap it.
<lifeless>             if not isinstance(source, LoomSupport):
<lifeless>                 source._ensure_real()
<lifeless>                 source = source._real_branch
<lifeless> which is a little not-right
<lifeless> alternatively we could make RemoteBranch more pass-through
<spiv> lifeless: I have a submission that is failing without any useful hints in the reply from PQM.  If I turn off subunit in the makefile for that submission will that help me?
<lifeless> spiv: yes
<lifeless> spiv: [probably, maybe not]
<spiv> Ok, good.
<spiv> Yeah, that's a bit of a hack, but at least it'll make things work now, and we can make it elegant later.
<lifeless> its not as gross as it could have been :)
<spiv> :)
<BlindWolf8> Hello?
<parthm> BlindWolf8: hi
<spiv> Hello again
<spiv> parthm: oh hey
<parthm> spiv: hi :)
<vila> parthm: \o_
<spiv> parthm: I wanted to thank you for answering that active directory question on Launchpad
<spiv> parthm: so... thanks! :)
<parthm> vila: _o/
<parthm> spiv: np. i don't know much about active directory ... but some errors were general enough :)
<vila> parthm: I second spiv thanks :)
<BlindWolf8> spic: I just have one more quick question about bzr_ssh_path_limiter: Can I just pop that script anywhere?
<BlindWolf8> spiv: I just have one more quick question about bzr_ssh_path_limiter: Can I just pop that script anywhere?
<spiv> BlindWolf8: yeah, pretty much, although if it's not on PATH you'll have to give the full path to it in authorized_keys I think
<BlindWolf8> spiv: Right. Anything else I should know about the files that got unzipped from the original bzr source?
<BlindWolf8> spiv: I'm assuming they're safe to delete since I installed bzr and bzrtools?
<spiv> Sure, it's safe to delete the stuff you unzipped.  If you are interested in the contents of the doc/ or contrib/ or whatever directories again you can always unzip again.
<BlindWolf8> spiv: OK, great!
<BlindWolf8> spiv: You guys have made my night!
<spiv> BlindWolf8: :)
<parthm> i see a bunch of gc warning for '--no-plugins selftest test_lock' on trunk. is this expected? http://pastebin.com/Qj8tJ6kg
<BlindWolf8> spiv: Bye once again spiv. Everything seems to be working perfectly now! :)
<spiv> BlindWolf8: great!
<spiv> parthm: not sure if it's expected precisely, but it certainly would be good to fix
<parthm> spiv: ok. i will file a report for now so its not lost.
<spiv> parthm: looks like a one-line fix
<parthm> spiv: oh. where should i look?
<parthm> spiv: ah. line 55 ... let me check.
<spiv> parthm: yeah, it's a one-liner, I'll just submit that to PQM right now, it's trivial (and IIRC my fault!)
<parthm> spiv: ok. sure. just for my info. what is the fix?
<spiv> parthm: self.addCleanup(branch.unlock) immediately after branch.lock_read()
<spiv> The warning is about an object that was locked being garbage collected, i.e. something forgot to unlock it
<parthm> spiv: ahh. ok. thanks.
<spiv> In this case, the "something" is the test itself which does the lock_read but never unlocks.
<parthm> spiv: cool.
<lifeless> spiv: parthm: a nice way is
<lifeless> self.addCleanup(branch.lock_read().unlock)
<lifeless> that idiom makes missing unlocks more obvious
<spiv> lifeless: Hmm, I actually don't like that so much
<spiv> It emphasises the cleanup rather than the locking.
<spiv> Which seems backwards to me
<lifeless> spiv: branch.lock_read(register_with=self.addCleanup) ?
<spiv> I'd almost rather have self.lock_read(branch) helpers.
<lifeless> spiv: helpers like that would be ok too; that said I don't think it particularly emphasises anything other than 'if you lock you should unlock'
<spiv> Hmm, it's wordy and I'm not sure if pushing that into the lock_read contract is wise, but otherwise yes I'd prefer that.
<lifeless> spiv: I found bugs when I introduced the idiom to builtins.py
<lifeless> spiv: (in plugins)
<spiv> I definitely agree with the overall direction of pushing it to be a single step
<lifeless> spiv: I think its worth having an idiom like this - even if you spell it differently - to make ... right
<lifeless> spiv: if you feel strongly that it should be different, 2.2 would be the time to change it :)
<spiv> True!
<spiv> But not 6pm on a Friday :)
<lifeless> indeed ;)
<spiv> I'll make a note to look at this on Monday
<lifeless> personally
<spiv> Would you like me to mail the list about it, or just propose a patch to add lock_read/lock_write helpers to TestCase and Command?
<lifeless> I think the loose coupling of returning a cleanupable is better than locks knowing they need to do something with a cleanup
<lifeless> spiv: I'm entirely happy with what we have; I won't block other changes, but I don't see them as being better.
<lifeless> Just, at best, different.
<spiv> I'm not totally sold on the tastefulness of such a patch, which is why I hadn't yet done so, but I'm not finding the new idiom very loveable either.
<lifeless> spiv: ok
<lifeless> spiv: then it sounds like brainstorming to find another way to spell 'these things are connected' is appropriate.
<spiv> *nod*
<spiv> My current thinking is: I think the returning a callable is a sound design, but lock_read and lock_write in TestCase and Command are overwhelmingly our common case so let's make that stupidly easy to do right.
<spiv> Anyway, thanks for the quick teddy bear.  I'll followup on Monday.
<lifeless> sounds good
<mobby> Hi, I've just tried to add the bazaar beta PPA repository but I can't seem to access the signing key. I've tried through the terminal and through the web browser. Any ideas?
<mobby> Clicking the link on the launchpad site doesn't load and the terminal times out after a while
<mobby> I've tried clicking on the links for the stable and the nightlies as well and they do the same thing
<parthm> a 300sec timeout for local lock contention ("Will continue to try...") seems quite long. Does this need to be high? Maybe this should be reduced?
<parthm> mobby: seems to work for me. this is the url i got http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0xD702BF6B8C6C1EFD
<mobby> hmm strange, I'm in work so it might be our proxy settings. I'll try something else.
<mobby> yeah it was our proxy. Apologies, should have tried that first. Thanks for the help.
<cbz> what does 'conflicting tags' mean?
<Mez> Can I force bzr to pick up the "whoami" info from an environment variable?
<jelmer> Mez: hey
<jelmer> Mez: I think it honors $EMAIL
<Mez> jelmer: hey :)
<Mez> As these feckers here generally all log in as the same user, I want to try and set the whoami on their ssh key
<jelmer> :-)
<jpds> #export BZR_EMAIL="$NAME <$EMAIL>"       # Override email for Bazaar.
<Mez> jp~.
<Mez> jpds: except - If you've set it in bzr.conf - it doesn't override - and also - "export" would make it the same for anyone who logged in - surelt... so X logs in and then Y logs in - X's commits show as coming from Y
<Mez> so I've set it based on the SSH key used to login
<jpds> Mez: Yep, that's what I have in my shell conf.
<Mez> jp~.environment="EMAIL=Martin Meredith <martin.meredith@mobilefun.co.uk>" ssh-rsa AAAAB3NzaC1yc2 <-- etc etc
<Mez> o_o
<Mez> environment="EMAIL=Martin Meredith <martin.meredith@mobilefun.co.uk>" ssh-rsa AAAAB3NzaC1yc2 <-- etc etc
<Mez> in authorized_keys
<ciss_> hi
<n3l> Quick question... just install bzr on mac os x.  Where is the gui app installed to?  Not found in applications.
<n3l> Nevermind... bzr explorer : this isn't noted in bzr -h : https://answers.launchpad.net/bzr/+question/99420
<ciss_> what is your preferred strategy to set up ignored files: do you explicity exlcude files and directories, or do you exclude everything and then explicitely add files?
<parthm> ciss_: you can add patterns for files to be ignored to .bzrignore (see 'bzr help ignore')
<ciss_> parthm, i'm aware of that. i was just curious if you prefer white-listing or black-listing files
<ciss_> it's a workflow related question
<parthm> ciss_: i tend to add files i need to ignore at the pop up as unknown in 'bzr st'. so black-list.
<krisives-gearbox> Does anyone know how nested branches in BZR 2 are handled?
<jelmer> krisives-gearbox: there is no support in the core for nested branches
<jelmer> krisives-gearbox: there are some plugins that provide some degree of support
<krisives-gearbox> jelmer: That's what I see on the documentation, but I don't know what BZR will do when it encounters nested .bzr directories
<krisives-gearbox> it appears to not touch to sub branch
<jelmer> krisives-gearbox: afaik it will ignore them, not sure what happens if you try to 'bzr add' a nested branch
<krisives-gearbox> I tried bzr add from inside the nested branch and out and I can't seem to get files in the sub directory/branch to get added to the outer branch
<krisives-gearbox> I'm not trying to do "true nested trees", I don't care if things propigate, I just want it to version those files
<jelmer> I don't think there is a way to version those files in the outer rather than the inner branch
<jelmer> not unless you move the .bzr directory of the inner branch out of the way somehow
<krisives-gearbox> Yeah, which isn't worth getting into lol
<krisives-gearbox> Have you ever used Stacked Branches?
<jelmer> krisives-gearbox: yep
<krisives-gearbox> I'm using Bazaar to version web software for a company that has created 3 versions of software that share many common similarities
<krisives-gearbox> A and B are the same, so B can be a branch of A because their changes can be shared easily
<krisives-gearbox> C is the problem, because we want to be able to make changes to C and push them to A (which will ultimately go to B)
<jelmer> krisives-gearbox: stacked branches are just a storage optimization, they won't help you in this regard
<krisives-gearbox> I see, have you used ConfigManager?
<krisives-gearbox> I basically need to make a frankenstein branch
<krisives-gearbox> Take this, that, this, etc. and throw it all together into a new one
<jelmer> no, I don't have experience with config-manager
<ericmoritz\0> I mean
<krisives-gearbox> Does anyone know how I can specify a FTP that has @ in it's username?
<krisives-gearbox> Like foo@bar on baz.com
<krisives-gearbox> (bar and baz are the same though)
<krisives-gearbox> foo@baz.com doesnt work because foo isn't foo@bar
<fullermd> URL-encode it.
<krisives-gearbox> I'll give that a shot
<krisives-gearbox> fullermd: Thx, where do I send the remaining amount on my gift card ?
<krisives-gearbox> :)
<fullermd> Sorry, I only accept Krugerrand and first-born.
<krisives-gearbox> Damn, and I skipped right to second-born, so I can't compensate you there
<fullermd> Well, maybe you can fill in the first-born later.  I'll waive interest charges for a year.
<krisives-gearbox> Well, I do have a few spare dollars on the gift card, you're welcome to it
<krisives-gearbox> BZR folks need more love
<krisives-gearbox> I'm willing to fund git away from usage
<krisives-gearbox> Just so I don't have to remember SHA1 hashes
<krisives-gearbox> either way, thanks for the help :)
<fullermd> np   :)
<krisives-gearbox> are you a bzr dev fullermd?
<fullermd> Oh, no.  I just sit around and harass them.
<krisives-gearbox> great minds think alike
<krisives-gearbox> I made a script to doctor up merging .moved directories to contain the old unversioned contents with the new versioned contents overriding it, I wonder what chance I have of getting that included as a --cleanup-moved-dirs ?
<krisives-gearbox> and if I did, how long until that version could trickle down to my users
<ciss_> hi, i could use a little help on an ignore rule: i have a folder structure "./folderA/folderB/folderC/fileA". i added an ignore rule "folderA/folderB" expecting everything below to be ignored as well. still bazaar wants to add fileA
<ciss_> do i really have to use "folderA/folderB" and "folderA/folderB/**/*" each time i want a folder and its contents to be ignored?
<fullermd> Is folderC versioned?
<ciss_> oh. yes, it is.
 * fullermd nods.
<fullermd> That'll break the ignore chain then.
<ciss_> thanks a lot, knowing this should end all my troubles with .bzrignore :)
<ciss_> is it possible to commit only removed files, but keep modified ones for a later commit?
<TresEquis> ciss_: you can name the specific files as arguments to 'bzr commit'
<TresEquis> e.g. '$ bzr commit -m "Should have ignored." folderA/folderB/folderC/fileA'
<ciss_> sorry to ask: (how) can i use a text file as source for the file listing? it's a rather long list.
<fullermd> No way with bzr itself.  You could 'bzr ci `cat foo`' or 'cat foo | xargs bzr ci' or the like, assuming it'll fit on the command line and not get in trouble with special chars.
<fullermd> Or you could go the other way around, and shelve the other changes, commit, and unshelve.  That might be easier if the 'other' changes are a small list.
<fullermd> ci also has an --exclude you could use to name the things not to commit.
<ciss_> thanks
<hazmat> is there anything like a more permanent shelf
<hazmat> like i can unshelve some changes, but still keep the patch/content shelved
<radoe> hazmat: bzr unshelve --keep?
<hazmat> radoe, perfect, thanks
<maxb> bzr-svn is so amazing, but it's somewhat crippled when your project is one of many in a repository with half a million revisions :-(
<jelmer> maxb: have you tried disabling the cache?
<maxb> jelmer: It improved matters considerably for read only operations
<maxb> However, when I tried to push back, I got bit by 'determining revprop revisions'
<jelmer> maxb: do client and server both run svn >= 1.5 ?
<maxb> yes, they do
<jelmer> maxb: can you get me a traceback of that?
<jelmer> (Ctrl+\ then running bt)
<maxb> jelmer: oh, sorry. of what? pushing?
<jelmer> yeah
<jelmer> of the step taht is takin too long
<maxb> I will, but not for a while - I'm in the middle of actually building the cache and I don't really want to interrupt it
<maxb> only another 240 thousand revisions :-/
<jelmer> heh
<jelmer> maxb: please file a bug with the traceback
<maxb> will do
#bzr 2010-06-12
<Demosthenes> i need the ability to store keywords inline in my files like RCS did (ie: $Id$), and i'm looking at the bzr-keywords addon... has there been an "official" solution i should be aware of?
<Demosthenes> plus the repo's a year out of date ;]
<mlh> Demosthenes: filters
<Demosthenes> mlh: the reference i pulled on that isn't quite complete. know any working examples? i'm at 2.0.3
<fullermd> keywords IS built on the filter layer.
<mlh> oh, there you go
 * mlh gets his coat
<mlh> I was always advise people to very carefully consider whether they actually need them, anyway
<Demosthenes> its a typical issue where i need version number or branch id in something visible to the end user.
<BlindWolf8> Hello?
<BlindWolf8> Hello?
<BlindWolf8> Hello?
<dcoles> Interesting. When trying to use the https transport with a mercurial Google Code repository bazaar gives up at the first 405
<dcoles> Though with http it seems quite happy to slowly fall back until it finds the right VCS transport
<dcoles> Should the hg plugin handle https?
<maxb> Is there a way bzr-svn could have messed up branch metadata such that bzr makes some *stupid* choices when merging?
<maxb> such as reverting changes on the merged-into branch for no good reason
<maxb> copying the base/left/right versions of the affected file into new bzr branches and trying the merge there produces a better merge
<jelmer> maxb: I doubt that's a bzr-svn issue.
<jelmer> dcoles: yeah, it should handle https but there are some known issues with https not specific to the hg plugin
<dcoles> jelmer: Ah. Thought that might be the case.
<maxb> jelmer: even though the merge is different if I recreate the relative ancestry the files would have had if the project had been in bzr all along, and the merge is better then?
<maxb> s/files/versions of the file/
<dcoles> jelmer: I'm just trying to look at that Google Go hg import bug
<jelmer> dcoles: one thing that might work is to uninstall pycurl
<dcoles> jelmer: For the moment using http should be fine - not need to push yet
<dcoles> Just trying to work out why bzr-hg generates an inventory delta that seems to be missing one of the parent directories
<jelmer> dcoles: just a word of warning; bzr-hg is still very much alpha code
<dcoles> Ah. Ok. I'll keep that in mind :)
<maxb> Is there a command to dump an inventory for debugging?
<maxb> like bzr inventory --show-ids but more so
<jelmer> maxb: Not aware of one, please let me know if you find one :-)
<jelmer> dcoles: patches welcome :-)
<dcoles> Heh. I'm trying :D
<dcoles> People just keep insisting on using things OTHER than bazaar.
<dcoles> ... or checking in files to SVN with paths like "connectors/perl/temp/\"...
<jelmer> yeah, that one seems to be becoming more and more of an issue
<dcoles> I see that there's already a bug for having '\' in a path.
<jelmer> there isn't anything in bzr that inherently prevents us from using it
<dcoles> Mainly to be safe on Windows correct?
<jelmer> we've just been on the side of caution since it's impossible to check out those paths on windows
<jelmer> yeah
<jelmer> we know how we'd like to fix this:
<jelmer> allow backslashes but refuse to check out paths with backslashes on windows
<jelmer> when adding files with backslashes we'll warn the user
<dcoles> That seems like the right idea. Much like when people check in files with filenames that differ only by case
<jelmer> dcoles: right, that's another good example where we should allow files to be added (we already do atm) but need to warn the user.
<dcoles> If I'm looking at migrating a repository, would the best thing be to "fix" svn's history and then import? Or is it safe to remap the filename at import time?
<jelmer> dcoles: remapping the filename at import time isn't really possible, unless you use a custom version of bzr-svn and are never going to use the original svn repo again after you've migrated.
<dcoles> jelmer: Hmm. I figured that might be the end result. Alright. Cleaning up history seems to be the go.
<lool> Hi folks
<dwt> Hi there, I'm trying to use bzr-svn with bzr 2.2b3 but it keeps failing with an error like this: Unable to load plugin 'svn'. It requested API version (2, 1, 0)....
<dwt> is there a newer version of the bzr-svn plugin available somewhere?
<dwt> I'm currently using http://people.samba.org/bzr/jelmer/bzr-svn/1.0/
<dwt> (from launchpad that looked like the most recent branch)
<dwt> jelmer: maybe you could give me a hint? (If it's daylight where you liveâ¦ :)
<dwt> Should I be doing 'bzr branch lp:bzr-svn' - and what difference would that make?
<dwt> Oddly, enough that seems to have fixed my problem - even though I'm on the same revision now as before. Â¿Â¿Â¿
<dwt> well, thanks for the patience I guess.
<dwt> adios!
<marioxcc> hi all
<marioxcc> Â¿what benefits do Bazaar offers over GIT?
<C-S> marioxcc: it has a very clean interface and above all: it has plugins
<marioxcc> C-S: but what about the basic
<marioxcc> branches, files, merges, and so
<marioxcc> what are the differences?
<C-S> marioxcc: to be honest, I can't tell you very much about the internal differences, however:
<C-S> marioxcc: branching is a bit more traditional in bzr, i.e. you have a folder per branch
<marioxcc> C-S: ok
<marioxcc> thanks
<C-S> marioxcc: I would just give it a chance. I personally switched from git to bzr a few month ago.
<C-S> marioxcc: and I am really happy
<C-S> marioxcc: but the differences are not that big in the end. These are all great VCSs
<marioxcc> C-S: I like the model of GIT of commits as a directed graph and branches as references to commits
<marioxcc> i can't figure out why did emacs now use bazaar
<marioxcc> maybe BZR have a awesome feature than git don't
<marioxcc> that is why i'm asking
<C-S> marioxcc: well there are nice advantages. launchpad.net is great for example.
<C-S> marioxcc: I think, its interface and documentation is just much more consistent.
<C-S> marioxcc: but I am not sure why they switched. I did because git became buggy...
<C-S> marioxcc: and git has a severe drawback in design with renaming.
<C-S> marioxcc: it seems to guess the file names and there are quite a few examples where it guesses wrong.
<marioxcc> actually some we consider the "renaming" thing a feature :)
<C-S> marioxcc: in bzr you can also add empty directories. something not possible in git.
<marioxcc> yeah
<marioxcc> about launchpad, i don't like it
<marioxcc> it promotes the void open source
<marioxcc> instead of free softwre :(
<marioxcc> i always use and contribute to GNU Savannah, when i can :)
<C-S> marioxcc: I don't understand you.
<marioxcc> oh :S
<marioxcc> sorry
<marioxcc> i mean
<marioxcc> launchpad is about open source software
<C-S> marioxcc: right
<marioxcc> savannah is about free software
<C-S> marioxcc: what's the difference?
<marioxcc> free software talks about freedom and ehtical values
<marioxcc> open source don't
<C-S> marioxcc: is there free closed source software supported? I don't like that.
<marioxcc> Â¿?
<marioxcc> the "free" in free software means freedom, not free beer
<marioxcc> we the GNU supporters look for freedom, not zero price
<C-S> marioxcc: I know, that's why I use a truly free software: BSD
<C-S> marioxcc: I see
<marioxcc> BSD-style licenses allow propietary derivates :(
<C-S> marioxcc: right, that is true freedom: "do what you want but cite me"
<C-S> marioxcc: it does not force another person to continue the same way
<C-S> marioxcc: anyway, that becomes off topic now :-)
<marioxcc> yeah
#bzr 2010-06-13
<glyph> is bzr-svn supposed to support the svn:mergeinfo to retrieve merge parents?
<glyph> I have a branch (which, happily, is in a public, open-source project) which has lots of merges from trunk, with appropriate mergeinfo properties on them
<glyph> 'svn merge --reintegrate branch .' in an SVN working copy works great
<glyph> 'bzr merge ../branch' in a bzr checkout of trunk gives me tons and tons of conflicts
<spiv> glyph: https://launchpad.net/bugs/131323 perhaps?  It seems that it's half fixed.
<ubot5> Launchpad bug 131323 in Bazaar Subversion Plugin "Support svn:mergeinfo (affected: 0, heat: 0)" [Medium,Fix released]
<spiv> i.e. bzr-svn will update that property, but doesn't use it itself yet.
<glyph> spiv: Aah.  "Fix released" is a misleading state for that bug, given its description.
<glyph> I had already found it, and my understanding was that I was discovering a bug in the integration, not that the integration didn't exist.
<spiv> glyph: yes, the NEWS file at least doesn't claim it's fully fixed
<spiv> glyph: probably just a momentary lapse of attention
 * spiv reopens
<glyph> spiv: Thanks
<glyph> although this is a little disappointing, I have a long plane-trip ahead of me and I was hoping to experiment with different merge strategies
<lifeless> mornink
<thumper> lifeless: morning
<lifeless> thumper: hello!
<Pilky> lifeless, thumper: who would be the best person to talk to about bzr explorer (especially on the Mac)
<lifeless> Pilky: uhm, Ian was handing over maintenance of that
<lifeless> I think bialix probably
<Pilky> thanks
<lifeless> who is in Russia, so a bit late right now :)
<Pilky> yeah
<Pilky> I'll try tomorrow at a more sane hour
<lifeless> you could mail the list :)
<Pilky> just want to talk with him about how explorer works and how to try and make it feel more OS X native
<lifeless> well its qt
<lifeless> so is there a qt quartz theme perhaps?
<Pilky> well, I think that qt wraps around cocoa a bit
<Pilky> but it's a bit less about appearance and more about placement
<Pilky> like there is a series of tabs at the bottom, which really should be at the top in a Mac app
<Pilky> I'll try messaging him tomorrow and try the list if he isn't on
<Pilky> thanks again :)
#bzr 2011-06-06
<workthrick> jelmer: thanks for your help, I'll come with more substantial questions tomorrow or thereabouts
<jelmer> workthrick: sure
 * workthrick reboots
<poolie> hi all
<jelmer> 'morning poolie
<poolie> hi jelmer
<spiv> Good morning
<wgrant> spiv, poolie: We had some odd branch corruption on the db-devel builder on Friday.
<wgrant> http://people.canonical.com/~wgrant/launchpad/pygettextpo.tar.gz is the branch. An upgrade to 2a works, then pulling lp:~launchpad-pqm/pygettextpo/trunk crashes with BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys: [StaticTuple('sha1:d34f39faee56e120a83e7cec4fe01c4fd5fd32f6',)]
<wgrant> A fresh checkout works fine.
<wgrant> Still broken on a daily 2.4 build.
<spiv> wgrant: hmm
<wgrant> Yes.
<spiv> I don't think we've had a report of that error from a fresh upgrade before.
<wgrant> check/reconcile are happy.
<wgrant> So perhaps the remote branch is bad or something...
<spiv> Oh, it's probably not upgrade then, problem an issue in the remote
<wgrant> Only just saw that they're happy now.
<wgrant> But the remote branch hasn't changed in a year...
<spiv> *or* if the remote is fine in isolation too (passes check), then you've possibly got a example that pinpoints a bug in fetch.
<spiv> Oh, if the remote is that old, possibly it has the non-canonical-chks issue
<spiv> wgrant: try 'bzr check-chk' from the lp:bzr-repodebug plugin on the remote
<wgrant> Hmmmmmm.
<wgrant> bzr was upgraded in devel recently.
<wgrant> But one revision after what's in db-devel at the moment.
<wgrant> Rather suspicious timing.
<spiv> wgrant: ah, yes, check-chk finds *many* issues in lp:~launchpad-pqm/pygettextpo/trunk
<wgrant> I don't see how the db-devel slave would be using the devel bzr, though...
<wgrant> spiv: How do we fix that?
<spiv> bzr reconcile --canonicalize-chks
<spiv> (it's a hidden option, it's specifically for repairing damage from bug 522637)
<ubot5> Launchpad bug 522637 in Bazaar 2.0 "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys" [High,Fix released] https://launchpad.net/bugs/522637
<wgrant> Time for some PQM fun, I guess...
<wgrant> Thanks.
<spiv> And must be run on the actual damaged repo, not just done elsewhere and pulled, due to the nature of the problem.
<wgrant> Yep.
<spiv> It's pretty impressive, actually.
<spiv> I'm not sure I've seen a branch with so many non-canonical-form CHK maps before!
<spiv> wgrant: thanks for reminding me of that issue!
<spiv> wgrant: I just realised it accounts for some package import failures :)
<wgrant> spiv: Ah!
<poolie> hi spiv, wgrant
<spiv> Hmm.
<spiv> Non-canonical CHKs were *part* of what was breaking libffi
<spiv> But there's still something funky going on.
* poolie changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | UDD failure ratchet: 481
<poolie> lifeless: in https://code.launchpad.net/~mbp/bzr/220464-stale-locks/+merge/62582 what do you mean by something stronger?
<lifeless> poolie: well, you mentioned putting a machine identifying hash in or something
<poolie> mm
<poolie> it could go in /home
<poolie> a lot of the problem cases have shared disks so that may not help
<shadeslayer> https://code.launchpad.net/~neon/+recipe/project-neon-calligra << bzr runs out of memory on that recipe, could someone look at it? IIRC this bug was fixed a couple of months ago right?
<spiv> shadeslayer: well, bzr memory usage has typically been improving with every major release
<shadeslayer> spiv: i agree, but that branch is like 97 MB's in xz format :)
<spiv> Whether that means your particular out of memory case has been fixed I couldn't immediately say.
<shadeslayer> any ideas when it'll be able to build that particular size?
<spiv> Depends on what the problem is, and what version of bzr (and maybe bzr-builder) the buildslave is running.
<shadeslayer> i guess, whatever launchpad uses
<spiv> It *might* be as simple as getting bzr upgraded there.
<spiv> Well, I say Ã¢Ã¢Ã¢"simple" but I'm sure wgrant will correct me...
<shadeslayer> well .. the source code import uses git->bzr conversion, but i have no idea what the bzr branch format is ... will look into it later this evening then
<spiv> I don't mean upgrading the repo/branch format being used
<spiv> Those are already current
<spiv> I mean the version of the 'bzr' program being used.
<shadeslayer> ah
<poolie> i think jelmer and others  have a project underway to upgrade bzr
<poolie> i don't think it's all done yet
<poolie> according to https://code.launchpad.net/ lp is still using bzr 2.2.3
<fullermd> Headers: {'Software version': '2.2.3dev'}
<spiv> I don't think the PPA builders are necessarily using the same version of bzr as the rest of Launchpad.  I might be wrong.
<wgrant> poolie, spiv, shadeslayer: The bzr upgrade has landed, and I'm QAing it now. Will be deployed in a couple of days.
<wgrant> But spiv is right.
<wgrant> The buildds don't use the same version.
<wgrant> They use packages.
<wgrant> I may converse with lamont.
<lifeless> poolie: re: locks - I want to avoid us trashing repositories in the lp deployed configuration which will be N hosts, one cluster FS for storage
<poolie> i want that too :)
<poolie> having multiple hosts, one filesystem should be safe
<poolie> s//should actually be safe in the patch as proposed
<poolie> i'm going to check the server side behaviour though
<spiv> shadeslayer: and fwiw that branch is much larger than your xz'd 97MB.  'du -hs .bzr' says 509M.
<maxb> spiv: Hi. Do you think I should file a bug for "Please upgrade bzr-builddeb on jubany", or is it not worth the process?
<maxb> We should be in the clear to redo the sysvinit import as soon as current trunk of builddeb & udd are deployed, which would be nice, as it's a user request
<spiv> Hmm, a lot of changes since r494
<maxb> oh yes :-)
<spiv> It sounds like a good idea, and I think I'd be happy to just do it, but not at 5pm :)
<spiv> So probably worth filing a bug
<maxb> rihgt
 * maxb is intrigued by the cpuarrayd failur
<maxb> Somehow the importer has decided to import a package name which does not exist
<spiv> maxb: yeah, I was wondering about that one too
<poolie> hello vila
<vila> poolie: hey !
<poolie> hi
<poolie> :)
<poolie> i like your mails-
<poolie> i might need subtitles though :)
<vila> http://www.youtube.com/watch?v=CN666q3ptAU
<vila> :)
<vila> poolie: corrections welcome nevertheless ;)
<poolie> vila so actually more seriously i don't know what spam you're talking about
<poolie> did people object to the previous message/
<vila> hmm, right, so what's the saying about explaining jokes ? ;)
<vila> this was just a way to roll the drums about the policy change, people should know that there is something going on with reviews and subscriptions by now
<vila> I probably viewed too much monty python lately: http://www.imdb.com/title/tt0071853/crazycredits
<poolie> i like the humour
<poolie> i think perhaps a subtitle saying what's actually happening would help
<vila> right, the link to maxb message was supposed to give the serious info
<poolie> well, just something to think about
<poolie> vila, whoa, you sent through my stale lock branch?
<poolie> i was just drafting a reply to robert
<vila> mgz approved it...
<vila> :-/
<poolie> i think it's probably ok but i was going to look at it again
<vila> did I miss a reply from Robert ?
<poolie> i do appreciate you trying to flush the queue
<poolie> he asked if it's safe wrt server side operations
<vila> May be I over interpreted but I read mgz's last comment as: that's fine as it is, we can do a further proposal
<vila> poolie: oh right, but this won't be deployed on lp then ?
<poolie> why not?
<vila> meh, if you think you need a further proposal, this don't *have* to be deployed on lp
<vila> if you're ok, I don't have objections myself
<poolie> well
<poolie> on the whole we should probably land it and perhaps do follow up
<poolie> i wouldn't mind brainstorming other things we could check, with you
<poolie> what do you think we should do about matching up the host names?
<poolie> i'm tempted to also ask a losa to kill the pqm job until we're agreed on how to do it
<vila> how about a grace period before stealing the lock ?
<vila> The issues you and Robert raised still exist with break-lock no ?
<poolie> ok, i replied
<poolie> a grace period could be another option
<vila> I can't think of a good way to make the host name check stronger that can't be defeated either so I'm not sure about that
<poolie> ok, good night!
<vila> g'night !
<vila> poolie: pqm failure anyway, so no worries
<jelmer> g'night poolie
<lifeless> vila: poolie: re: landing and iterating; If landing something that makes server deployment risky, how would we identify that this blocks a release/deploy to lp ?
<lifeless> not saying you should or shouldn't, just wondering what the process to avoid mistakes further down the line is
<vila> lifeless: add more tests ? ;) Anyway, there was a pqm failure for this proposal so it didn't land
<bigjools> hi all, I'm doing a "bzr shelve --all" and getting this error, what can I do to fix it?
<bigjools> bzr: ERROR: Could not acquire lock "/home/ed/canonical/lp-branches/copies-must-use-queue-bug-789502/.bzr/checkout/dirstate": [Errno 11] Resource temporarily unavailable
<jelmer> bigjools: there's no other bzr instance trying to access that branch at the same time?
<bigjools> jelmer: I hope not, I've not touched bzr since I booted the box, that's the first thing I typed
<bigjools> ah, there's a bzr grep running ...
<bigjools> jelmer: that was it :/
<bigjools> I didn't think it'd do an exclusive lock
<bigjools> thanks
<jelmer> not one of our best error messages..
<bigjools> no :)
<quicksilver> does anyone use reviewboard with bzr? or alternatively, have suggestions on tools in this area? That is, support for code review workflows
<ScottK> quicksilver: I've used it.
<quicksilver> ScottK: works well?
<ScottK> You need a patch and then it works.
<ScottK> Let me see if I can find it.
<quicksilver> the bzr-diff-revid stuff?
<ScottK> Yes.
<quicksilver> found that already in my initial researches.
<quicksilver> trying to find a bit of automation for a good merge-request/code-review workflow.
<ScottK> There's also a patch to rbtools we needed.
<ScottK> I think that may just be because we were on an older version.
<quicksilver> I really want something which can work on the output of "bzr merge --preview"
<quicksilver> that is, the diff between unmerged branches.
<quicksilver> most code review tools seem to want to work on diffs between versions of a particular branch
<ScottK> I don't think I've used it that way.
 * quicksilver nods
<quicksilver> maybe my workflow is odd
<quicksilver> but I like to review changes before we pull them into mainline.
<spiv> quicksilver: that's not odd at all; it's how Launchpad's code review workflow works for example.
<quicksilver> spiv: hmm maybe running an internal launchpad instance is a better idea then?
 * quicksilver tries to google info about lp code review
<spiv> quicksilver: but I guess the thing is if you have a branch that's simply a bunch of revisions on top of the target branch (i.e. no merges from the target onto the branch-for-review part way through its new commits) then diff-between-versions-of-branch is the same.
<quicksilver> right. but we always have those (merges from target onto branch-for-review)
<quicksilver> apart from anything else it's the branch-developers obligation to keep testing against latest mainline and ensure there are no conflicts
<quicksilver> so there should be regular merges in that direction.
 * spiv nods
<quicksilver> spiv: seems lp code review gives you a workflow and an interface to browse merge candidates, btu doesn't actually support the process of annotating the diffs?
<spiv> It gives you a place to add comments about the whole diff, but no way to directly annotate a part of the diff with a particular comment, no.
 * quicksilver nods
<quicksilver> currently I review the entire output of bzr merge --preview in emacs, make notes and then discuss those notes with the developer.
<spiv> (I think there was some discussion recently about maybe adding something like that)
<quicksilver> it works OK but I was wondering if I could automate some of those parts
<quicksilver> and having it on the intranet lets the rest of the team get some idea what's going on
<quicksilver> which is nice.
<spiv> My usual way to do reviews with Launchpad is I get the email sayingg
<spiv> "review this, here's the diff" and I reply to that email, quoting the bits of the diff I'm commenting on and following them with my remarks.
<spiv> s/to do/I do/
 * quicksilver nods
<spiv> I don't mean to suggest my preferences are universal :)
<spiv> Part of the difficulty of directly annotating LP's diffs is that they are updated automatically as the branch changes
<spiv> So the comments on a review may be interleaved with "New revision: Add more comments, fix typo." etc
<quicksilver> spiv: reviewboard (which ScottK and I were just discussing) claims to understand about different versions of diff.
<quicksilver> I'm not sure what it looks like in practice.
<spiv> I'm not either, I haven't taken a close look at reviewboard recently at all.
<ScottK> I think you'll have to try it to know if it fits your workflow.
 * quicksilver nods
<niemeyer> Greetings!
<niemeyer> I faced an issue with bzr over the weekend that prevented importing some code on it.  Wondering if someone already had a look at something similar:
<niemeyer> bzr: ERROR: An inconsistent delta was supplied involving '<unknown>', 'hg:usr_sgri'
<niemeyer> reason: Parent is not present in resulting inventory.
<niemeyer> This was a simple non-fancy import of about 8600 revisions, just one commit after the other
<niemeyer> This seems to be the same bug as this one:
<niemeyer> https://bugs.launchpad.net/bzr-hg/+bug/513368
<ubot5> Ubuntu bug 513368 in Bazaar Hg Plugin "inconsistent delta during fetch" [Medium,Triaged]
<niemeyer> What surprised me is that I'm hitting the bug just with plain command line interaction
<maxb> niemeyer: It's not that surprising, bzr-hg is somewhat less developed that other bzr foreign plugins
<niemeyer> maxb: I'm not using bzr-hg
<niemeyer> maxb: bzr is crashing all by itself
<niemeyer> maxb: I go 8600 revisions doing "bzr add; bzr remove; bzr commit"
<niemeyer> and the resulting repository has this bug
<maxb> The string 'hg:usr_sgri' from your error message is *highly* suggestive of bzr-hg being involved
<niemeyer> maxb: Ouch.. maybe the plugin is kicking in just because there's an .hg directory?
<maxb> Entirely possible
<niemeyer> Ugh
<niemeyer> Ok, that'd explain a lot
<niemeyer> maxb: ...and I had it installed. I'll try to reproduce the bug without it, but it looks like you're right. That was very helpful, thanks!
<niemeyer> maxb: OMG.. not only it works, but it's also several orders of magnitude faster
 * niemeyer hugs maxb
<maxb> :-)
<maxb> Did you try using bzr-hg to import the branch first?
<maxb> It would be somewhat simpler than an add/commit loop
<gour> reddit story about bzr - http://www.reddit.com/r/programming/comments/hseul/do_you_like_bzr_were_working_on_the_github_for/
<asabil> mergebox sounds like something that would probably help increasing bzr adoption
<niemeyer> maxb: Heh
<niemeyer> maxb: I'm sure it's simpler when it works
<niemeyer> maxb: This bug is around for more than a year
<shadeslayer> wgrant: thanks!
<shadeslayer> spiv: alright, i
<shadeslayer> +i'll test it out when its rolled out
<shadeslayer> wgrant: is the new bzr out on production servers?
<poolie> hi maxb, all
<maxb> hello
<jelmer> hi poolie, maxb
<poolie> hey there
<wizonesolutions> Anyone know if Bazaar has something similar to git-submodule?
<lifeless> there is a plugin
#bzr 2011-06-07
<quotemstr> If I have a branch that's diverged from upstream, how do I discard my changes and revert so I can use 'pull' again (instead of merge)?
<spiv> quotemstr: pull --overwrite
<quotemstr> spiv: Thanks.
<poolie> and then 'bzr revert'
<poolie> hi spiv
<spiv> Hi poolie.
<spiv> poolie: I'm currently digging into the libffi package import failure: initially it was the old stacked repo problem, but having repaired the stacked repositories (to have the parent inventories) some fetches still fail
<poolie> ok, that's good
<poolie> i'm working on getting X going on my laptop
<poolie> well, on my laptop with an external screen
<poolie> and i will push on 220464
<spiv> poolie: I *think* there may be an issue when a revision in a stacked repo has the same inventory and thus same CHK maps as one of revisions immediately over the stacking boundary
<poolie> would be interested in your thoughts on the mp actually, if you didn't comment already
<poolie> not the diff, just the conceptual thing of when we should consider it safe to break
<poolie> hm, interesting
<spiv> And relatedly I'm finding there's no good in-tree documentation of the stacking invariants, and so perhaps unsurprisingly even if the code is correct here it's a bit unconvincing.
<poolie> that would be good to add
<poolie> hm
<poolie> i don't think we have properly closed things up about adding developer documentation
<spiv> Because it just does a bunch of stuff to determine what records are interesting and uninteresting, without explaining/justifying why.
<poolie> for instance, how much we should insist on it being done in the mp
<poolie> right
<spiv> Yeah, I don't think so either, but I don't have any great ideas to fix that.  I am actually in the middle of drafting an addition about stacking to doc/developers/fetch.txt
<spiv> But more out of a lack of better ideas about where to write it down in-tree than because I feel it'll actually acheive much :/
<poolie> anyhow, i short, i think updating them would be very good
<poolie> jorge gave a talk at UDS encouraging people to delete bad data from the Ubuntu wiki
<poolie> i liked it
<poolie> in fact he challenged people to delete 5 bad things from the internet each
<spiv> Heh.
<spiv> A productive variation on "someone is wrong on the internet" :)
<spiv> poolie: so regarding the stale locks breaker
<spiv> poolie: my first impression is "isn't your patch ok then?"
<poolie> :)
<poolie> on the whole it is
<poolie> i think.
<poolie> rebooting to try a new kernel
<spiv> As all the scenarios people are actually concerned about (as opposed to pathological hypotheticals) seem likely to work ok.
<poolie> i think so
<spiv> Hmm
<poolie> the hypotheticals like having two machines with the same name and the same disk are not... ridiculously contrived
<spiv> True, especially with default hostnames.
<poolie> but perhaps not that likely to happen
<spiv> But people do tend to customise hostnames almost always?
<spiv> If there were a portable way to get machine- (or boot-) specific unique info to add in, then great, but there isn't that I know of, so that's a can of worms.
<spiv> I don't really like the idea of being in the business of finding out MAC addresses or whatever.
<spiv> If only "time at boot" was a portably available feature ;)
<spiv> poolie: so I guess my thought is "if there's a config option to disable it and/or make it more conservative" then I'm totally comfortable
<spiv> We have to balance this against the risk that users today don't understand how locks interact with smart servers
<poolie> right
<spiv> So the answer they give to break-lock (which bzr does suggest they run) is probably going to be wrong at least as often as your heuristic!
<poolie> exactly
<poolie> ok, thanks for that
<poolie> i'll just have a look at the pqm failure then
<spiv> Ok, time to go grab a pie, bbiab.
<poolie> :) enjoy
<spiv> poolie: https://code.launchpad.net/~spiv/bzr/doc-stacking-constraints/+merge/63640
<poolie> thanks!
<poolie> unicode's elipsis character is not really all that well typeset
<spiv> Dear unity: please unhide all the windows that were on workspace 3
<poolie> at least in monospace
<poolie> ok, replied
<poolie> and rebooting again
<vila> hi bazaaristas !
<jam> morning all
<vila> jam: hey !
<spiv> Good afternoon vila, jam
<jam> hey poolie, sorry I missed you yesterday
<spiv> jam: would you mind taking a look at https://code.launchpad.net/~spiv/bzr/doc-stacking-constraints/+merge/63640?
<jam> spiv: certainly
<jam> another way to describe the short rule
<jam> "a repository must be able to generate a valid stream for revisions it claims are present, without having access to a backing repository"
<jam> I'm not sure what is clearer
<jam> I agree with vila that the short rule should be at the beginning of the document.
<spiv> Given a sufficiently clear definition of "valid stream", of course :)
<jam> spiv: your opening statement is actually slightly wrong
<jam> the actual requirement
<spiv> Excellent!
<jam> is that if someone has X, and we have Y descended from X
<jam> then they can get everything for Y that they need from us
<spiv> Ah yes.
<spiv> That is what I was trying to say, but you're right I didn't quite hit the mark.
<jam> the idea of "complete stream" is that we can generate everything needed for Y *without* the backing repo
<spiv> Right.
<poolie> hello jam, vila
<vila> _o/
<vila> Does anybody know the fullname of Geoff/xaav ?
<spiv> vila: see the committer in the bzr revisions
<spiv> Well, it's closer anyway :)
<vila> hmm, I was wondering if it was a nickname or his true fullname :-/
<vila> I'd settle with Geoff/xaav in the news entry, if he disagrees we can fix it later
<jam> spiv: do you want me to rewrite the text a bit, or are you working on it?
<spiv> jam: just done, and in fact sent to PQM
<spiv> jam: you're certainly welcome to polish that version even further if you think you can improve it :)
<jam> spiv: sure, I just didn't want to be editing something concurrently
<spiv> ...and that's 6pm, so probably a good point to wind up.
<spiv> jam: just briefly before I go
<spiv> jam: I think GC's stream source is maybe not quite right when there are inventories with identical contents in the "interesting" and "uninteresting" sets
<jam> spiv: it is possible
<jam> would take a bit of digging
<spiv> Actually, hmm, this is probably a discussion to have a touch more time for
<jam> I think I see your point (direct root inventories of the interesting set should be sent)
<spiv> Right
<spiv> As an example, the current state of lp:libffi/debian/experimental; try fetching that into an empty repo
<Merwin> Can someone tell what's the best way to know if a directory is a valid bzr repo ? Is there a command which return 0 or 1 ?
<spiv> (and then try making a standalone branch of it...)
<jam> Merwin: "bzr root" ?
<jam> not sure about the return code, though
<spiv> Anyway, I'll happily keep digging into that tomorrow
<Merwin> jam: Thanks
<spiv> The stacking invariant docs were written partly to make sure I had it clear in my head exactly what the requirements are.
<spiv> G'night folks
<vila> spiv: g'night
<strycore> Hi
<strycore> Is there any way to configure bzr so I can type bzr branch bzr+ssh://myserver/myproject instead of bzr+ssh://myserver/path/to/repo/myproject ?
<fullermd> You could look at the bookmarks plugin.
<fullermd> Or create a symlink in your homedir and use /~/myproject/
<bigjools> is there a way to uncommit a sub-commit inside a branch that I merge to my branch?
<fullermd> You can only uncommit off the top.
<bigjools> yeah, as I thought :(
<fullermd> Removing a rev in the middle somewhere means you need to create new revs for everything after it.
<bigjools> well it was at the top of the other branch I merged
<bigjools> then I did a bunch of conflict resolution, not realising, and now I have to re-do all that work :(
<fullermd> Do you really need to eliminate it from the history, or is it OK to just create a new commit reversing it?
<bigjools> I can't reverse it because my branch will eventually get merged back to the other one
<fullermd> Ah.  Yeah, then you're stuck with nothing to do but re-do the merge.
<bigjools> my day just gets better!
<maxb> bigjools: So, you just want to have merged one less revision than you actually did?
<bigjools> maxb: pretty much, yeah
<maxb> I'd probably do something like this
<maxb> 1. Uncommit the merge
<bigjools> I could uncommit + shelve each
<maxb> 2. Forget the pending merge tip
<maxb> 3. Shelve the tree changes
<maxb> 4. Rerun the merge minus the unwanted revision
<maxb> 5. "bzr revert ." - revert the tree, but keep the pending merge tip
<maxb> 6. Unshelve the tree from 3.
<maxb> 7. Manually or with the aid of patch get rid of tree changes from the unwanted revision
<maxb> 8. Commi!
<maxb> +t
 * vila nods
<vila> 9. Check that merge --preview <that branch with the unwanted revision> is what you expect
<bigjools> right, I'll bash that in, thanks for the help!
<vila> bigjools: you'll need bash-dwim for 7 :-/
<fullermd> Y'know, if you'd just integrate bash-dwim with the bug tracker on LP, it would save an awful lot of development effort.
<vila> That's what I meant... :)
<bigjools> I just snapped my fingers and it all worked like magic
 * vila sends black helicopters to capture fingers
<jam> jelmer: it looks like your add-by-delta patch broke the case-insensitive code for windows.
<jam> I'm not positive, but: http://babune.ladeuil.net:24842/job/selftest-windows/435/
<jam> that's what it looks like
<jam> vila: the "test_branch_local_remote" doesn't fail here, the other 2 do
<jelmer> jam: Ah, hmm. Thanks for letting me know, I'll have a look
<jelmer> unless you're already looking into it?
<vila> jam: fuzzy memory, but I think there are multiple tests failing with .pack files involved, some failures  may be transient ?
<jam> vila: I'll see if I can provoke it
<jam> I've also seen some things like that fail because it is a single CPU instance
<jam> because it changes how GIL contention works
<vila> jam: also, #437 doesn't have this failure, so transient++
<jam> vila: after 15 runs, no failures here
<jam> vila: one problem with rename failures, is we don't know if it failed because of the target, or the source.
<jam> I'm guessing source was still marked as open
<jam> "sftp" is very suspcious
<jam> because of non-deterministic closure
<jam> jelmer: also, I'd really like to work with you on barry's "is this branch up-to-date" command. Is it somewhere I can just poke at it myself?
<vila> jam: did you query babune for a big/huge log file ? (couple of minutes ago ?) I saw a weird spike on disk accessees
<vila> s/ee/e/
<jam> vila: nothing more than opening that url and the linked urls.
<jam> some are modestly sized
<vila> nah, just the tracebacks shouldn't explain that.... unless jenkins needs to load the whole log file to display them (and cache it then)
<spiv> strycore: yes, or perhaps more accurately you can configure your sshd to do that:
<spiv> strycore: http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/simple-setups.html#using-a-restricted-ssh-account-to-host-multiple-users-and-repositories http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/security.html#using-ssh
<strycore> thanks fullermd and spiv :)
<jelmer> jam: I was hoping to finish the bzr deployment to lp related fixes today; should we meet for some pair programming sometime this week?
<jam> jelmer: sure. I think the lp stuff is most important for now
<maxb> jubany Request: ./requeue_package.py python-unit python-werkzeug language-pack-az language-pack-gnome-uz # Transient failures
* maxb changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | UDD failure ratchet: 482
<maxb> (+1 for the mysterious cpuarrayd import, which isn't actually a problem since the package does not exist in Ubuntu or Debian)
<james_w> maxb, done
<maxb> thanks
<james_w> maxb, cpuarrayd never existed, or just no longer exists
<james_w> ?
<maxb> james_w: Launchpad now claims it never existed
<maxb> Though apparently it temporarily existed at some point
<maxb> Or perhaps someone did  requeue --force on a bogus name?
<jimi_hendrix> hello, i am using bazaar explorer to branch something, but i keep getting the following error: bzr: ERROR: Unsupported protocol for url
<james_w> maxb, yeah, that's certainly possible, I think there are a couple of odd package names in the db when I mistyped things
<maxb> jimi_hendrix: Well... what is the url?
<jimi_hendrix>  lp:~snova/+junk/lyx
<jimi_hendrix> maxb, ^
<maxb> hm
<maxb> Well, I don't see anything wrong there, so you'll need someone who has actually used bzr-explorer, which I have not
<jimi_hendrix> maxb, going from the command line works
<jimi_hendrix> dont know what was up
<vila> jimi_hendrix: unsupported protocol for 'lp:' strongly hints at plugin disabling
<jam> vila: if he is using bazaar explorer, he probably has plugins enabled, but maybe unselected "Launchpad" from being installed.
<vila> jam: but he said the command-line was working...
<jam> I missed that part. Definitely strange
 * gour notices that someone descended from the heaven here
<arnetheduck> hi, I'm getting 207 failures when running the selftest on win7 64-bit py2.7 - is that normal or should I report it somewhere?
<james_w> arnetheduck, http://babune.ladeuil.net:24842/view/Windows/job/selftest-windows/lastCompletedBuild/testReport/ only sees two failures currently
<james_w> arnetheduck, so I would say yes
<james_w> as a bug I mean
<arnetheduck> james_w, I'm testing a fairly recent lp:bzr with no compiled extensions - maybe that makes a difference?
<james_w> arnetheduck, I'm not sure
<james_w> the no compiled extensions thing may be involved
<poolie> hi all
<mgz> hey poolie.
<poolie> hi mgz
#bzr 2011-06-08
 * jelmer waves
<mwhudson> jelmer: hi
<mwhudson> jelmer: will the new bzr-hg improve memory behaviour at all for imports?
<jelmer> mwhudson: somewhat - fetching in batches will limit the memory usage somewhat
<mwhudson> jelmer: ok, so it'll be worth retrying the python import, for example?
<jelmer> mwhudson, but we're still keeping the entire bundle we receive from the mercurial server in memory at the moment
<mwhudson> ah
<jelmer> mwhudson, are there any particular ones for which memory usage is an issue at the moment?
<mwhudson> jelmer: dunno, i just saw a bug report update go by
<mwhudson> https://answers.launchpad.net/launchpad/+question/160305
<mwhudson> jelmer: you'll be surprised to learn that the OO.org import is reported as having issues
<jelmer> ah, openoffice
<mwhudson> but also python
<mwhudson> which is a bit less ridiculous i guess
<jelmer> I hope it'll be better with the rollout
<mgz> jelmer, for bug 788219 is what apport has duped it to what you were thinking of?
<ubot5> Launchpad bug 788219 in bzr (Ubuntu) "bzr crashed with IOError in get_password() (dup-of: 534326)" [Undecided,New] https://launchpad.net/bugs/788219
<ubot5> Launchpad bug 534326 in Bazaar GTK+ Frontends "bzr: ERROR: gnomekeyring.IOError:" [Medium,Fix released] https://launchpad.net/bugs/534326
<jelmer> mgz, no, those are definitely different issues
<mgz> because that's still a bzr-gtk bug and the guy doesn't have bzr-gtk installed
<jelmer> they're both caused by gnomekeyring, but one is when it's used through launchpadlib and one when it's used through bzr-gtk
<jelmer> they both have to handle IOError
<jelmer> mgz, unduped - thanks!
<mgz> can you find the launchpadlib bug? I didn't find it when I tried.
<mgz> I don't know what to do about bug 791839
<ubot5> Launchpad bug 791839 in bzr (Ubuntu) "bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte ..ordinal not in range " [Undecided,New] https://launchpad.net/bugs/791839
<mgz> as reported it's a dupe.
<poolie> jelmer: i think i've hit that too
<poolie> the ioerror
<mgz> I don't see what's wrong with Fabien's statement that etckeeper should use git.
<poolie> i'm also experiencing lplib corrupting the credentials it stores in the keyring, which is a separate unrelated bug
<mgz> bzr plain doesn't work on nix without LANG set and obeyed.
<poolie> probably it would be better to assume the filesystem is utf-8 if it's not set
<poolie> well, there are a couple of cases here
<poolie> - the filename is just not in any valid encoding, or it's inconsistent with other files in the same tree
<mgz> he's got random junk cert names.
<poolie> which is an inherently hard case for us
<mgz> even without the traceback from bzr we won't commit the file.
<poolie> the other
<poolie> is that the encoding is not set or not set properly
<poolie> which is pretty much what you say in https://bugs.launchpad.net/bzr/+bug/715547/comments/7
<ubot5> Ubuntu bug 715547 in Bazaar ""bzr add" crashed ERROR: exceptions.UnicodeDecodeError" [Medium,Confirmed]
<poolie> mgz: are you sure they're not utf-8?
<poolie> if they came from an ubuntu package and they're not utf8, that sounds a bit like a bug in that package
<mgz> they could be, but there's no reason to expect all programs writing to /etc to behave
<mgz> and having your backup randomly fall over in that case is... a hard behaviour to argue for
<poolie> so
<mgz> wereas falling over fast is generally the right thing for a manually curated source tree
<poolie> i think we should group/dupe the bugs into those two splits
<poolie> plus any others for accidental cases where we know the right encoding but just do the wrong thing
<poolie> what do you think?
<mgz> seems reasonable. we've had various symptom bugs for these problems in the past than have been fixed, regressed, and so on
<poolie> i think "assume utf-8" should be feasible to do and by my recollection of the bugs reported it will fix somewhere well over half of them
<poolie> like it seems like it will fix this case
<poolie> "i want to version names with just random byte strings" might be harder
<poolie> hm
<poolie> if people really want that they could set their fs encoding to say 8859-1, which will accept anything and send it to equally arbitrary utf-8
<mgz> that's true.
<poolie> i wonder how hard it is to persuade python to use an fsenc other than what it originally detected?
<poolie> do you want to reorganize them or shall i?
<mgz> changing it would be somewhat dodgy, comes from a global variable set during initialise that lots of things depend on
<poolie> we//
<mgz> ^go ahead, I think we shouldn't have too many open bugs for the same thing, maybe just want a new one for changing the default
<poolie> i think at least having a bug saying "we want this behaviour"
<mgz> yup.
<poolie> then we can see if it's too hacky to actually get it
<poolie> as a matter of (fairly) objective fact, the right fs name encoding is utf-8
<mgz> our uses probably, or at least should, all go through osutils anyway?
<poolie> either do, or can be made too
<poolie> s//to
<poolie> possibly we can get around it by always passing byte strings
<poolie> in the very worst case we can reimplement some os interfaces
<poolie> o/ spiv
<spiv> Hey poolie
<poolie> hi spiv
<poolie> spiv, still here?
<poolie> i'm trying to fix the lp-propose lazr.restfulclient bug
<poolie> for some reason python insists on loading the OS version of that library even though i have another one on my pythonpath...
<poolie> oh, maybe because it imports lazr.somethingelse
<spiv> Maybe the lazr.* packages have funky .pth files or something?
<poolie> !
<poolie> :qa
<poolie> heh
<poolie> /usr/lib/python2.6/dist-packages/lazr.restfulclient-0.9.20-nspkg.pth
<poolie> blah
<poolie> import sys,types,os; p = os.path.join(sys._getframe(1).f_locals['sitedir'], *('lazr',)); ie = os.path.exists(os.         path.join(p,'__init__.py')); m = not ie and sys.modules.setdefault('lazr',types.ModuleType('lazr')); mp = (m or          []) and m.__dict__.setdefault('__path__',[]); (p not in mp) and mp.append(p)
<poolie> all on one line
<fullermd> Hrm.  Should bzr really check URL's before filenames?
<poolie> fullermd: well, URLs are a strict superset of filenames
<fullermd> Not when they fail   :p
<poolie> by which i mean, any filename can be represented as aurl but not vice versa
<poolie> but, we can use sensible heuristics if it's bad
<fullermd> % bzr diff 2001:470:8:7f6
<fullermd> bzr: ERROR: Unsupported protocol for url "2001:470:8:7f6"
<poolie> right
<poolie> ./2001... should fix it
<jam> morning all
<fullermd> Yeah, it's trivial to workaround.  But annoying.
<vila> hey guys !
<fullermd> Checking the other way around...  well, I guess it would make your life really unpleasant if you had a file called 'lp:bzr' in your tree, but...
<poolie> fullermd: i guess we could say "if there's no such scheme, assume it's a file"
<poolie> that could work
<fullermd> File a bug?
<poolie> spiv: yes i think that's it: so just having this module installed looks ilke it will always be loaded?
<mgz> fullermd wants to break bazaar on alternative data streams in a new and interesting way?
<mgz> nice systems don't let people put colons in filenames :)
<fullermd> Well, I've for sure never advocated breaking things in old and boring ways.  I've got style, dangit.
<poolie> :)
<fullermd> I store important data in files called '%s', just to be sure they're not used in format strings.
<mgz> ehehe
<poolie> wow that's a precious snowflake
<poolie> i did not realize you could run arbitrary code from there
<fullermd> There are more things in heaven and on earth than are hacked apart in your philosophy   ;)
<vila> poolie: Regarding lp:~mbp/bzr/220464-stale-locks , is there some pending points you want to address or can it be landed ?
<poolie> >  Lines starting with import (followed by space or tab) are executed.
<poolie> vila, hi
<poolie> i haven't fixed the pqm failure yet
<vila> poolie: ISTM this is already landable and the proposal is already > 900 lines
<vila> ha, ok
<mgz> poolie, I've got one more change in my copy of the branch, I didn't remove the win32 test skip
<mgz> what was the pqm failure? it didn't get pasted to the mp
<spiv> poolie: yes, it's a great way to do cool/surprising things :/
<mgz> pth files are evil.
<vila> poolie: also, AIUI, this is now restricted to the same user so you may want to update the news entry
<poolie> good point
<mgz> okay, pushed, lp:~gz/bzr/220464-stale-locks
<spiv> Presumably there's a convention for co-operating nicely with namespace packages like that for when you're developing your own version of a module in that namespace, but I'm not sure what it is.
<poolie> hthanks
<vila> poolie: python2.6 ? Aren't you running natty ?
<poolie> i am, but that was from a clean maverick chroot
<poolie> to see if it's something strange on my main system
<poolie> the same problem occurs there
<vila> ha ok
<poolie> ok i'll leave this and finish 220464
<jam> poolie: where do you think you're at with the stale lock thing
<jam> I feel like we've discussed it to exhaustion, without actually reaching consensus
<vila> jam: really ? Did you read the last version on the proposal on lp ?
<jam> vila: did you read the discussions between robert, martin and myself?
<vila> yes
<mgz> apart from esoteric things about people using funny network share setups with computers all named the same thing the issues look resolved to me
<vila> if there are still controversial points on these cases then I think tests are better than discussion to break the ties
<jam> mgz: except it doesn't seem all that esoteric ime. Specifically if you install ubuntu from live install, it always calls the machine "ubuntu"
<mgz> but would you really mount a filesystem on another such system remotely?
<jam> mgz: sftp://
<vila> sftp://ubuntu ?
<jam> vila: sftp://bazaar.launchpad.net/my/project/branch
<jam> poolie's proposal breaks *remote* locks that look like they were held by the local machine
<jam> which has some nice bits
<jam> like "bzr push sftp://... ^C bzr push" will work
<jam> rather than warning you about the stale lock from the previous push
<vila> right, my point is that writing tests for that will make the actual and intended behaviors clearer
<jam> mgz: it has some problematic bits that if your machine is configured oddly, you can overwrite critical data.
<jam> I'm trying to weigh the balance in my head
<jam> since as poolie points out, breaking locks by hand can be just as risky
<vila> and since the proposal is already 945 lines long it should either be landed or split or all discussions become more complex and progress harder
<vila> AIUI the only case where we can override/lose data is for the repo lock
<vila> in this case, the .pack ..ix files should still exist and we can think about ways to recover them but this is out of scope for this proposal
<vila> also, this lock is short-lived to just pausing a bit may be enough to detect a stale lock, but I'd rather look at this kind of change in a smaller proposal
<vila> s/to just/so just/
<jam> vila: we lose data from .conf overrwrites and a branch lock
<jam> we lose master bound branch integrity from branch locks
<jam> we lose a few other things.
<jam> nothing I would say is "super critical", but it *is* data loss
<jam> (my bound branch commit can succeed, and in the end master doesn't point at my revision.)
<jam> vila: so the *critical* case is repo locking, but there are minor cases elsewhere
<vila> then back to tests, if these scenarios are worrying enough, they should be covered no ?
<jam> I'm pretty sure I'm falling on, "this is a net gain so we should land it", but I don't feel it is cut-and-dry
<jam> vila: we can add tests for concurrency issues. However, we have to decide if we care if they fail
<jam> vila: the current proposal will fail under esoteric conditions
<jam> is that ok?
<jam> I certainly can write a test that proves it.
<jam> But does that actually help us.
<vila> Yes it does, it means a better ground for addressing it
<vila> It kills the FUD :)
<jam> vila: except the discussion is tending towards "that failure mode is ok"
<jam> which means, we don't actually need the test
<jam> and actually, we don't *want* the test, because it would fail
<jam> vila: we know from the code and its behavior how it can fail. we are asking "is a this rare enough event that we don't need to worry about it"
<jam> no FUD
<jam> just an open question
<jam> we don't have to always be perfect, and we have to determine the tradeoffs
<vila> I'm not saying you're propagating FUD, I'm saying you're a FUD victim here. To rescue you we should address your fear :)
<vila> or doubts
<jam> vila: I can't test how often in-the-wild the esoteric conditions are met
<jam> which is the fear
<jam> I don't care about the test
<jam> I need to know real-world-how-likely-is-this-to-fail
<jam> I'm thinking it is low enough to go ahead.
<jam> I *know* it fails in a particular way, I *don't* know how likely that way is.
<jam> We've had other cases where we made the tradeoff
<jam> and people got bit by it.
<jam> Like the "inventories during repack"
<jam> I knew it was broken, but that "bzr pack" fixed it.
<jam> People have hit it, and we decided that wasn't enough, so we spent more time to work on it.
<vila> But isn't adding the user in the check enough to reduce the esoterism here ?
<jam> vila: maybe, but the most likely cases for actually running into this is probably stuff like cron scripts
<jam> I'm unlikely to race with myself
<jam> we ran into a lot of bugs from the twisted guys, where they had multiple bots pulling into the same repository.
<poolie> hi jam
<jam> hi poolie
<jam> poolie: so I think what I'm leaning towards is: land it, but file a couple bugs about known failure cases.
<jam> To give us points to track if it happens in the wild.
<jam> And especially a way to document known workarounds, etc.
<poolie> i think so too
<poolie> mm, except i'm against filing vague bugs
<poolie> but if we say "will hit trouble if you have two machines with the same hostname"
<poolie> you guys ready for a call in a `5m?
<poolie> 15*
<lifeless> jamesh: poolie: FWIW, I would lean towards being conservative; our user base is large enough now that 'minor risk' tends towards 'will happen', I think.
<lifeless> s/jamesh/jam/
<poolie> mm
<lifeless> but, I say this from the peanut gallery; the call is yours.
<poolie> perhaps we should downgrade it to just warning, and leave it up to the user to decide if they think it's probabyl dead?
<poolie> this may be a cop out
<poolie> if they get it wrong anyhow
<lifeless> thats what vim does, and it has a somewhat simpler problem to solve I tihnk
<poolie> why simpler?
<lifeless> no smart server
<lifeless> just filesystem
<lifeless> perhaps its equivalent
<lifeless> I wasn't claiming radically simpler problem
<jam> lifeless: well, their lock is also a WAL, which allows them to "incorporate changes" which we don't provide
<vila> jelmer: time to reboot :)
<poolie> WAL?
<poolie> write ahead log?
<jam> right
<jam> I don't know that it is strictly that
<jam> but you can say "apply changes from the .swp file"
<jam> before you delete it
<poolie> really, "apply", not just loading the whole thing?
<jam> poolie: I don't know the specifics. But I think the idea is that if the text file is really big, Vim doesn't write out the changes to the file all the time. But keeps a small "these are the edits" in the .swp file. I just know that one of the options on load is "delete" and another is "recover"
<poolie> spiv, hi?
<poolie> i think 'recover' is just 'load it' not 'merge the changes'
<poolie> imbw
<jelmer> Riddell: bug 746822
<ubot5> Launchpad bug 746822 in Launchpad itself "fails to build recipe with "bzr: out of memory"" [High,Triaged] https://launchpad.net/bugs/746822
<apw> anyone know what this might mean, when trying to bzr merge-package:
<apw> NoSuchRevision: CHKInventoryRepository('file:///home/apw/local/bzr/tmpFFe1XH/upstream/.bzr/repository/') has no revision ('james.westby@ubuntu.com-20100820023033-dousm0xjfuraxtd7',)
<jelmer> apw: merge-package apparently can't find a particular revision but it has a reference to it
<jelmer> apw: it sounds like it might be a bug in bzr-builddeb or a broken repository
<apw> jelmer, i can bzr checkout the url ok, just not merge it
<jelmer> apw: does regular merge work?
<jelmer> Riddell: bug 746822 seems to be the same issue as the recipe build running out of memory you mentioned
<ubot5> Launchpad bug 746822 in Launchpad itself "fails to build recipe with "bzr: out of memory"" [High,Triaged] https://launchpad.net/bugs/746822
<Riddell> jelmer: yep, not much extra information on it though
<apw> jelmer, yet it would be mergable directly
<jelmer> vila: does 2.3.3 really address just a single bug (failUnless & co cause PendingDeprecationWarning) ?
<poolie> if so, that does not seem worth SRUing
<poolie> it's true natty has 2.7 and people might run the tests there, but, it's not crucial
<jelmer> fwiw: 2.3.2 hasn't been SRU yet either and has more bugs (12)
<jelmer> though I'm surprised that we did a release just for the deprecation warning thing
<poolie> ah, that makes more sense
<poolie> i think it just squeaked in between 2.3.2 being tagged, and being discarded
<poolie> it was cancelled during the release process for some reason that i forget at the moment
<jelmer> ah, 2.3.2 was *that* release
<jelmer> poolie: thanks
<poolie> wasn't it?
<poolie> ah the release page says
<poolie> > This release broke the test suite under python-2.7 and the corresponding tarball has never been released.
<vila> yup
<poolie> so my fix makes it releasable
<vila> yup and allowed the test suite to run which is part of the SRU AIUI
<vila> well, at least for recent series
<poolie> mm
<poolie> but would it run against 2.7 on natty?
<poolie> yes, it would, since 2.7 is the default
<poolie> well that's all good then
<vila> right, 2.3.2 was worth a SRU but couldn't released so I cut 2.3.3 since fixing the tag issue was not practical
<vila> s/released/be released/
<poolie> ok
<poolie> so the figurehead should be something from 2.3.2 probably
<maxb> 2.3.2 nominally doesn't exist, right?
<poolie> right, see above
<poolie> and good morning
<jelmer> poolie: what was the ecryptfs bug?
<poolie> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/793367
<ubot5> Ubuntu bug 793367 in linux (Ubuntu) "ecryptfs corruption during make -j" [Undecided,Fix committed]
<poolie> i sent a mail
<poolie> ok that's enough for now
<jelmer> poolie: thanks
<fritz[]> hi
<fritz[]> I'm trying to help with this bug
<fritz[]> https://bugs.launchpad.net/bzr/+bug/680529
<ubot5> Ubuntu bug 680529 in Bazaar ""Lock was renamed into place, but now is missing"" [High,Confirmed]
<fritz[]> can someone instruct me where to put sleep?
<jelmer> hi fritz[]
<fritz[]> hi
<poolie> jelmer: that's great, thanks
<poolie> fritz[]: basically in lockdir.py, just look for the 'lock was renamed into place' mesasge
<poolie> put that in a 'for i in range(5):', try the check, and if it fails, sleep(3)
<fritz[]> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/view/head:/bzrlib/lockdir.py
<fritz[]> from line
<fritz[]> 251
<fritz[]> to
<fritz[]> 262
<fritz[]> put that in for loop?
<poolie> i would say only up to line 255
<poolie> then, if it doesn't find it
<poolie> obviously you don't want to raise straight away, but only if the data is not found on any attempt
<poolie> thanks very much for taclking this!
<poolie> it seems to bite many people but it's hard to reproduce-
<fritz[]> sure, no problem
<fritz[]> I'll just take maseratti :)
<jam> jelmer: so with bzr.dev "time bzr branch --stacked -Dmemory ...kde-workspace" only peaks at 150MB
<jam> and takes 2.4min here
<jam> that is http:// explicitly
<jelmer> jam: which bzr version is that?
<jam> bzr.dev
<jam> I'm checking an older version next
<jam> do you know what is on the builders?
<jelmer> I think the builders are running 2.2-something
<jelmer> let me check
<jam> jelmer: using bzr-2.2.2, I get 2m32s, and 188MB peak memory for the same kde-workspace
<jam> not all that different
<jam> note, those numbers might ~double if they are using 64-bit systems
<jam> though why you would run a 64-bit system with only 1GB of ram seems a bit silly.
<jelmer> jam: virtual process size limit is set to 1 000 000 000 bytes
<jam> given that 64-bit programs are almost universally much bigger in mem because of the extra pointer sizes
<jelmer> I'm not sure why it uses RLIMIT_AS rather than something else
<jam> spiv: with bzrr-2.2.2, 'bzr branch --stacked lp:.../kde-workspace' took 220MB peak, and 5m4s. While http:// took 188MB and 2m30s.
<jam> so bzr+ssh vfs seems a bit weak
<spiv> jam: yes, probably because there's double-caching
<spiv> jam: e.g. RemoteRepository will keep a get_parent_map cache, then when it falls back to VFS the "real" repository object will probably fetch and cache most of the same info
<spiv> (But in a different form, of course)
<spiv> I think the primary fix there is "don't use VFS"
<jam> spiv: branch --stacked, so I think most of the 'build-the-working-tree' stuff doesn't use get_parent_map
<spiv> I'd be a little interested in if lp:~spiv/bzr/faster-stacked-tree-build goes better (needs to be run on both server and client)
<spiv> (It doesn't totally eradicate VFS calls, but it does reduce them)
<jam> spiv: hard to run that on LP :)
<spiv> jam: local testing is faster anyway, right? ;)
<jam> spiv: sure, but doesn't compare. Anyway, I do have a -Dhttp -Dhpss log of both, I might grep through it
<jam> in theory, the same calls should be made
<jam> spiv: it is also possible that my machine was more heavily loaded during one of the runs
<jam> spiv: we also read ".bzr/branch-format" 5 times in the http:// version (and branch/format 6 times)... ugh
<spiv> jam: I was thinking specifically that you could measure the client's memory consumption with that branch
<spiv> jam: I already know it is *much* faster
<maxb> Hi spiv, do you have a thought on when bug 793393 might be addressed?
<ubot5> Launchpad bug 793393 in Ubuntu Distributed Development "Please upgrade jubany's bzr-builddeb" [Undecided,New] https://launchpad.net/bugs/793393
<jam> spiv: copying the branch locally, 'time bzr branch --stacked bzr://localhost/..." is then 181MB and 1m38s. "time bzr-spive branch --stacked" is 1m26s and 134MB peak memory.
<spiv> maxb: oh right.  I'll do it first thing tomorrow morning my time unless you convince someone else to do it first :)
<maxb> thanks :-)
<spiv> jam: hmm, less of a time win on this branch than another test case I have, but not too shabby.  (Especially as it has to pay the costs to insert the data into the repo and so validate it where stock bzr doesn't)
<maxb> Once that's done, and assuming the importer branch itself is up to date, sysvinit can be requeued, and I hope should work
<spiv> jam: And the memory improvement is good news :)
<spiv> jam: thanks!
<jam> spiv:  this is also over the loopback, so bandwidth type stuff doesn't really matter.
<jam> and you seem to be fairly out of date vs bzr.dve
<jam> you don't have my groupcompress changes, for example
<jam> spiv: And I should note: "transferred" changed from 95MB to 32MB
<jam> so for anything network bound (like most things) this is a massive improvement
<spiv> It was mainly roundtrips I wanted to improve, happily that approach seems to help lots of other things too.
<fritz[]> poolie: you still there?
<spiv> fritz[]: unlikely at this hour
<fritz[]> sorry, can anyone else help? I'm doing research for one bzr issue and I've modified lockdir.py source
<fritz[]> now trying to recompile my bzr
<fritz[]> (on windows)
<fritz[]> i've done
<fritz[]> python setup.py install --home ~
<fritz[]> without problems
<fritz[]> but where's my bzr.exe? :)
<fritz[]> I've got \bin directory with bzr and bzr.bat
<fritz[]> :(
<spiv> fritz[]: building the windows installer for bzr is a pretty fiddly job
<fritz[]> so I see :(
<spiv> fritz[]: as jam could tell you
<spiv> fritz[]: but you can run bzr from source, I suspect that's adequate to diagnose your issue
<jam> fritz[]: I would recommend running from source, and just using "py setup.py build_ext -i
<jam> which builds "in-place"
<fritz[]> ok, trying exactly that now ..
<fritz[]> sec
<jam> the .exe is much more complex to build. From what you wrote, you can probably run it from the 'bzr.bat'
<jam> which runs the 'bzr' script using your installed python
<fritz[]> ok, I've done python setup.py build_ext -i without error
<spiv> (It *may* be possible to twiddle the library.zip or something of the bzr installed by the official installer, but that will be pretty fiddly and I don't know the exact details)
<fritz[]> ok, so I should use build\scripts-2.7\bzr now?
<fritz[]> grr
<fritz[]> ImportError no module named site
<fritz[]> ignore :)
<fritz[]> got it
<workthrick> jelmer: hiya, around?
<jelmer> workthrick, hi
<workthrick> jelmer: looking into writing the mapping now
<jblue> Hi all,  I was looking at this wishlist request: https://bugs.launchpad.net/bzr/+bug/681792 and was curious if something like this has been implemented yet?
<ubot5> Ubuntu bug 681792 in Bazaar "wishlist: bzr pull --overwrite-tags" [Wishlist,Confirmed]
<jelmer> jblue, as far as I know nobody has looked into that yet
<jblue> what would be be the best practise then, to use --overwrite to sync the tags?
<jelmer> jblue, there isn't really an easy way at the moment
<jelmer> jblue, a workaround would be to remember the current revision tip ("bzr log --show-ids --limit 1"), then "bzr pull --overwrite" and then restore the tip
<jelmer> ("bzr pull -rrevid:<revid> .")
<jblue> jelmer: in essense, overwriting tags, but not pulling in new revisions
<jelmer> jblue, that's what the workaround would do
<jblue> sounds fair, thanks jelmer
<jelmer> jblue, sorry there isn't an easier way (yet)
<workthrick> jelmer: do you see any obvious problems (besides performance impact, of course, but we know it's there already) by mapping revisions with multiple parents to id concatenating all of the parent IDs in the lexicographical order?
<workthrick> hmm
<workthrick> jelmer: that would result in files changing their IDs on the merge revision, wouldn't it?
<workthrick> jelmer: also I see BzrGitMappingExperimental there, doesn't it do what I want already?
<jelmer> workthrick, mapping in way? Using their lexicographically sorted parent ids to generate their id?
<workthrick> yes
<jelmer> what if two revisions (with different contents) in the same repository have the same parents?
<workthrick> jelmer: ah, no, sorry, I wouldn't be touching the _revision_ ids, I just want file ids
<jelmer> workthrick: in that case I'm not sure what you mean by parents?
<jelmer> workthrick, files have just one parent directory, usually :)
<workthrick> jelmer: to make them stable, I decided to give files IDs consisting of "sha1 of first revision in history ever" + path
<jelmer> workthrick, bzrgitmappingexperimental is intended to preserve the file ids if they're imported from bzr, it stores them in a custom file in the tree.
<workthrick> but that obviously breaks if you merge two timelines
<workthrick> ah, so it goes the other way around
<workthrick> jelmer: so I was thinking of a simple mechanism to make it work for all possible graphs
<workthrick> jelmer: so actually, what I _think_ should work would be to preserve the ID of the file if it had one assigned before the merge, and otherwise pick the lexicographically smaller parent sha1 on each merge point until you reach a root
<workthrick> root being a root revision now, not tree root
<jblue> jelmer: thanks, looking forward to seeing that tags issue fixed.  The work-around can be a bit misleading, since if you do a 'pull --overwrite', and there are no changes in revisions, it says "No revisions to pull" and it seems like nothing was changed when it actually has (tags overwritten).
<jelmer> jblue, yeah, there's a separate (higher priority) bug open about that
<workthrick> jelmer: obviously it'll have an impact on the performance, but bzr-git caches the mappings, right? So it'd only happen once for each file, possibly with a trivial refresh for every file after a merge
<jelmer> workthrick, different file ids means it won't be possible to easily merge those kinds of files with bzr though
<workthrick> jelmer: howso? The ID prefix would only change if you merge a completely unrelated tree
<jelmer> workthrick: yes, but that means that if you ever merge an unrelated tree, you won't be able to sanely merge from things derived from that tree beyond your merge
<workthrick> jelmer: that should be covered by "check if the file can be traced to before the merge point", and if so, it'd override the "pick the lexicographically smallest parent prefix" fallback
<jelmer> workthrick: ah, ok - I missed that
<jelmer> workthrick: I can't poke any holes in that :)
<workthrick> jelmer: the only case I can see that'd really fail would be if I have a timeline A, then merge it with B which has a smaller prefix, so it gets picked for newly added files, then I add 'foo' and try to merge A' derived from A which also has added 'foo'. But that'd generate a conflict anyway
<workthrick> jelmer: ah, good. Now if bzr-git caches that for me without too much work on my side, I should be hopefully not that far away from having a stable and unique mapping :)
<workthrick> jelmer: as for the technicalities of my plugin, I should just say import bzrlib.plugins.git to be able to use its APIs, right?
<jelmer> workthrick, yeah, "from bzrlib.plugins.git import ..."
<workthrick> anything that's suitable for a lazy_import?
<jelmer> workthrick, depends on how you're going to use it
<workthrick> OK, I'll just do it the easy way for now, and see what can be optimised later on
<workthrick> jelmer: hmm, now how can I get at the bzr's idea of what the file is in generate_file_id(self, path)?
<workthrick> just a path is insufficient
<jelmer> workthrick, you have to patch the interface to take more information
<workthrick> jelmer: aha. Do I need to do it at the bzr-git level, or bzrlib.foreign level?
<jelmer> workthrick, bzr-git, I don't think this is a bzrlib.foreign method
<jelmer> as the requirements are different per foreign vcs
<gour> do you recommend bzr-svn trunk or 1.0.4 with bzr-2.3.3?
<workthrick> gour: trunk is a bad idea with released bzr versions, since trunk moves to requiring bzr-dev as soon as it gets the chance
<gour> workthrick: i recall having some interface-version problem (on freebsd)...let me try with 1.0.4.
<gour> yeah, bzr plugins complain: "Unable to load plugin 'svn'. It requested API version (2, 2, 0) of module <module 'bzrlib' from '/usr/local/lib/python2.7/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (2, 3, 0), and the maximum is (2, 3, 3)"
<workthrick> gour: that means you need an earlier version of bzr-svn
<workthrick> ah wait, no
<workthrick> a later one
<workthrick> the releases should be tagged with what bzr's they work with
<gour> heh...that's the latest official release
<workthrick> then grab an unofficial one, but not the trunk
<gour> supposed to work with 2.2
<workthrick> since trunk is a moving target, and will probably require 2.4 at this point
<jelmer> trunk supports 2.3 and 2.4
<gour> ok...let's try trunk then
<workthrick> huh, is bzr-standalone for win32 supposed to be able to use paramiko?
<workthrick> because I just updated from 2.2/py to 2.4b3/standalone, and it broke
<workthrick> bzr: ERROR: Unrecognised value for BZR_SSH environment variable: paramiko
<gour> it's ok now (bzr-svn)
<workthrick> gour: btw, bzr tags -d lp:bzr-svn is useful for seeing what versions are tagged
<gour> workthrick: thanks...i had a trust in freebsd ports which says that 2.3.3 is ok
<mwhudson> jelmer: i really hope you've been using scripts to do you code import mangling
<poolie> hi all
<jelmer> mwhudson, nope, it's all me
<mwhudson> jelmer: you are a very determined man, clearly
<jelmer> mwhudson, I managed to convert all the failing svn-via-cscvs imports, hopefully we can get to a point where failing imports can become OOPSes
<jelmer> anyway, there's not much I can do anymore now that Launchpad's down and it's already been a way too long day
<jelmer> ttyl :)
<mwhudson> jelmer: it would be nice to be able to distinguish "the remote server went away" from some of the other problems
<mwhudson> jelmer: bye
<jelmer> mwhudson, we can just catch a handful of bzr errors that are indications of user errors
<mwhudson> cool
<poolie> jelmer: maybe you should write an api script?
<poolie> it might make it easier next time?
<poolie> i don't know
<jelmer> poolie, I'm hoping to have Launchpad do it for me next time :)
<jelmer> the cscvs imports should be the only ones where it's impossible to reliable tell whether it's failing because of a bug or circumstances (repository removed, etc)
<poolie> fair enough
<poolie> having lp do it automatically would of course be far better
#bzr 2011-06-09
<poolie> i wonder how that person went with the retry-lock thing
<spiv> Good morning
<spiv> Gar, unity or compiz or something has lost my mouse buttons again.
<spiv> Hmm, closing a bunch of firefox and gnome-terminal windows at random got it back :/
<poolie> hi spiv
<poolie> -> fixreleased :)
<spiv> poolie: oh wow, that little categorise_failures.py patch has changed it from taking most of a minute to about 3 seconds.
<spiv> I thought it must be broken because the process was only visible for one refresh of top(1) :)
<poolie> way to go :)
<gour> morning
<gour> jelmer: attempt to update git repo, has given me: http://pastebin.com/8nVnUNmn
<poolie> hi gour
<gour> morning poolie
<leo2007> how to view the commit with id b97184973?
<lifeless> bzr diff -c revid:b97184973
<spiv> In general you can just do "bzr log -r REVID" (or "bzr diff -c" as lifeless says), but that doesn't look like a revid from bzr.
<leo2007> lifeless: thanks.
<leo2007> spiv: not if it is a sha1.
<spiv> Well, bzr revids aren't sha1 hashes, or truncations of them.
<poolie> spiv, still here?
<poolie> i might do bug 794631
<ubot5> Launchpad bug 794631 in Ubuntu Distributed Development "package importer has toasted lp:ubuntu/sysvinit" [High,Confirmed] https://launchpad.net/bugs/794631
<spiv> I am
<poolie> by requeing that package
<poolie> just wondered if you had touched the importer recently
<poolie> to deploy max's fix
<spiv> poolie: you mean https://bugs.launchpad.net/udd/+bug/793393 ?
<ubot5> Ubuntu bug 793393 in Ubuntu Distributed Development "Please upgrade jubany's bzr-builddeb" [Undecided,New]
<poolie> yes, though the specific relevant change is https://code.launchpad.net/~maxb/udd/import-ordering-fix-take-2/+merge/63335 i think
<spiv> I'd been hoping the thousands of spurious failures would clear up a little faster :(
<poolie> due to the lp outage?
<spiv> Right
<poolie> francis suggested perhaps we should ask the losas to shut it off during an lp downtime deploy
<spiv> Yes, I think that's probably a good idea
<poolie> generally speaking automation is better than additional manual steps, but...
<poolie> ok
<spiv> It's not going to give wrong results, it just avoids effectively DoSing the import queue for a day
<lifeless> mmm
<lifeless> so
<lifeless> I'd like it if we don't give the losas -more- things to do during the downtime.
<spiv> The importer ought to be able to clear that backlog faster, of course.
<spiv> I'm not sure why it's so slow
<lifeless> can you probe LP and see if its showing the readonly warning ?
<spiv> If there's an API for that, then that's probably fairly easy
<lifeless> Well
<lifeless> the API doesn't work during downtime.
<lifeless> The OAuthToken table can't be written to
<poolie> :/
<lifeless> it *may* work for readonly requests.
<poolie> so we can see if the error you get is comprehensible
<poolie> astr at least some errors are socket.error
<poolie> *istr
<spiv> Yeah.
<lifeless> (Another reason why I want to go to plain old 'its down down down' but make that fast.
<poolie> phut
<poolie> so, there's no clear "are you down" api?
<lifeless> search for readonly mode in the html of https://launchpad.net/
<poolie> ok
<poolie> or a socket error reading that page could also indicate we should make a cup of tea instead
<lifeless> indeed
<lifeless> also a 500 or 400 on that page
<lifeless> all signs that Something Is Wrong Fred
<poolie> maybe it should return a float :-)
<poolie> ok
<lifeless> the other thing you might like to do
<lifeless> is to keep a track of the overall failure rate
<lifeless> and if it shoots up for any reason, stop and wait for an admin
<poolie> hm
<lifeless> this will help you if e.g. a bad bzr build gets on the machine
<poolie> i see what you mean but that would be exactly wrong in the current situation
<poolie> where things will suck immensely for 1-2 hours, then get better
<lifeless> there is a integration pattern around this whose name I temporarily forget
<poolie> i know
<poolie> ok
<lifeless> sure
<lifeless> anyhow
<poolie> i wonder if an "is lp up" function would be accepted into lplib?
<poolie> istm it's the sort of thing that should be there, rather than having crappy implementations everywhere
<lifeless> my key constraint is: we are taking things-losas-need-to-do-during-rollout and throwing them out. So as long as you don't add to that load, I have no particular interest in how you solve it ;)
<lifeless> poolie: yes, putting it in lplib makes sense to me
<poolie> well
<poolie> i thought you would say that
<poolie> was interesting francis said the opposite :-P
<lifeless> he did ?
<lifeless> I shall have to have words with that boy :)
<poolie> that's what i said
<poolie> just pragmatism vs long term view i think
<lifeless> stuart is automating the inner loop of the deploy and working out
<spiv> poolie: ok, bzr-builddeb and udd are now current on jubany, and the sysvinit import requeued as requested by maxb
<poolie> ah
<poolie> i already requeued it, but that should be harmless
<poolie> thanks anyhow
<spiv> Ah :)
<vila> poolie, spiv: There was a discussion about adding some canaries to mass_import so that we stop adding imports if either lp or another mirror went offline
<poolie> yes
<poolie> let's do it
<poolie> bonjour
<vila> helllo :)
<vila> I can't remember if there was a bug for it though
<spiv> *Ah*
<spiv> I think I've figured out this fetch problem.
<spiv> Just because inventory X is present and parent of the set being streamed doesn't mean we can safely assume X's CHK pages will be streamed from a fallback
<spiv> Because the fallback may have an inventory Y that is a present parent that has a same CHK root node as X
<spiv> So it will also think it doesn't need to send those CHK records, leaving the client sad.
<spiv> And this is happening with lp:debian/experimental/libffi + fallbacks.
<vila> jelmer: http://webnumbr.com/imported-branches-on-launchpad is the summary of your recent mail storm regarding imports right ? If so, keep going ! :D
<jam> morning all
<jam> spiv: I should also note one clarification from your stacking invariant post
<jam> we currently *exclude* both parents
<jam> not keep the set relative to P1 *and* the set relative to P2
<jam> it is R - (P1 + P2), not (R - P1) + (R - p2)
<jam> since both parents are in the stacked-on-location
<jam> I can see an argument for doing it the way you said, but that is not how we do it today.
<spiv> jam: Hmm, I'm having trouble relating what you just said to what I wrote.  Is this referring to the paragraph beginning "What about revisions at the stacking boundary with more than one parent?"?
<jam> yes
<jam> let me see if I can quote it
<jam> "All of their parent revisions must be present" is not accurate
<jam> all of the inventories for their parent revisions
<jam> I think the confusion was just "revision" vs "inventory"
<jam> we do hold both parent inventories, because it makes it easier to determine the minimum file texts to hold for the child revision.
<jam> I don't think it is because you may get a fetch from one vs the other parent, more that it means fewer file texts
<spiv> Ah, yes, I think it should say "inventories" rather than "revisions" there.
<vila> jam: still ok to pair ?
<jam> vila: in just a little bit, yes
<jam> mumble?
<vila> jam: ok, find me on mumble ... hehe yeah
<spiv> Oh good, I think I see a spurious failure that manifested in get_testament_sha1 (due to a LP timeout) that is reported better now that I fixed that code to use add_cleanup
<spiv> Nice to see fixes have a visible effect.
<spiv> Ok, time to pick up V etc.  Have a good day folks!
<fritz[]> hi
<fritz[]> poolie, u there?
<fritz[]> I've updated https://bugs.launchpad.net/bzr/+bug/680529?comments=all
<ubot5> Ubuntu bug 680529 in Bazaar ""Lock was renamed into place, but now is missing"" [High,Confirmed]
<jam> fritz[]: poolie is probably done for the day, but you might see him around
<fritz[]> :(
<fritz[]> can you help?
<Riddell> good morning bazaar
<vila> Riddell: _o/
<jelmer> hi Riddell, vila, jam
<jam> morning vila
<vila> jelmer: heya
<jam> hi Riddell
<vila> jelmer: seem my previous comment about imported branches ?
<vila> s/seem/seen/
<jelmer> vila: yes, thanks :) That should indeed be the result of my work
<jam> fritz[]: are you seeing the warning everytime with your patched version of bzr + qbzr, or only with stock bzr or ?
<fritz[]> jam: everytime
<fritz[]> with stock bzr
<fritz[]> qbzr isn't part of bzr?
<jelmer> fritz[], no, it's a separate plugin (https://launchpad.net/qbzr) although it's bundled with the windows bzr installer
<poolie> hi fritz[], all
<poolie> vila, jam, are you going to work on bug 721211? i'd be happy if you did
<ubot5> Launchpad bug 721211 in Bazaar "bzr merge --weave gives superfluous content conflict" [High,Confirmed] https://launchpad.net/bugs/721211
<jam> poolie: we're working on it now. So far it looks like a genuine conflict
<vila> poolie: we *are* digging right now
<maxb> Urgh, the silly package-import queue from the downtime is going to take all day to clear :-/
<bialix> hi, I have question about revision specifiers
<poolie> we were talking before about either making it detect lp is down and back off; or asking the losas to turn it off when lp is upgraded
<bialix> I want to have `bzr log -r after:$REVISION..-r-1`
<poolie> hi bialix, maxb
<bialix> hi poolie!
<poolie> i should go and cook though
<bialix> there is -r before:XXX
<bialix> how can I do -r after:?
<maxb> The problem with after is which parent do you choose if there are multiple ones?
<bialix> left hand parent revision is $REVISION
<bialix> so basically I want `bzr log` excluding $REVSION
<poolie> night all
<jelmer> enjoy your evening poolie
<Riddell> bialix: what version of bzr does bzr-explorer depend on?  for https://code.launchpad.net/~jr/bzr-explorer/781204-fix-deprecated-usage/+merge/63398
<jam> vila: https://bugs.launchpad.net/bzr/+bug/530584
<ubot5> Ubuntu bug 530584 in Ubuntu Distributed Development "File conflict when merge back packaging branch to upstream" [Medium,Triaged]
<vila> https://bugs.launchpad.net/bzr/+bug/364336
<ubot5> Ubuntu bug 364336 in Bazaar "bzr merge should allow user to ignore changes in deleted files" [Medium,Confirmed]
<bialix> hi Riddell
<bialix> Riddell: we don't have a strict policy
<bialix> but new release will definitely be targeted to at least 2.3 or 2.4
<Riddell> hmm, python programming, I should have known :)
<Riddell> bialix: so that change should be ok?
<bialix> guys, with bzr 2.3.3 I have C:\work\Bazaar\plugins\scmproj\tests\test_project.py:1077: DeprecationWarning: bzrlib.plugins.scmproj.tests.test_project.TestSub
<bialix> projects_v1.failUnlessExists was deprecated in version 2.4.
<bialix> why bzr 2.3 told me about Deprecations in 2.4?
<Riddell> it's a warning from the future, very sci fi
<bialix> spiv around?
<spiv> bialix: only slightly
<bialix> spiv: https://bugs.launchpad.net/bzr/+bug/794954
<ubot5> Ubuntu bug 794954 in Bazaar "bzr push to smart server error: bzr: ERROR: Server sent an unexpected error: ('error', 'No module named pwd')" [Undecided,New]
<bialix> just yesterday I've upgraded my server
<bialix> any thoughts?
<bialix> or I should just rollback to older version
<spiv> bialix: what does the server's bzr.log say?
 * bialix looking
<spiv> bialix: there's no obvious unguarded import of pwd in bzrlib, perhaps a plugin added one?
<spiv> Unexpected errors from servers log tracebacks to the server's log
<spiv> (I suppose you could try bzr serve --no-plugins to confirm)
<bialix> spiv: my server usually runs as windows service
<bialix> there is nothing in .bzr.log
<bialix> spiv: it seems I've hit https://bugs.launchpad.net/bzr/+bug/660174
<ubot5> Ubuntu bug 660174 in Bazaar "locking a branch should not try to import pwd when running as a windows service" [Medium,Confirmed]
<spiv> bialix: huh, odd
<bialix> spiv: it works ok if I run bzr serve as regular user
<bialix> so that's indeed that bug
<spiv> That bug does look likely
<spiv> Separately it would be good to have 'bzr serve' keep a log file when run as a windows service
<spiv> My memories of configuring windows services are a decade old though so I'm not quite sure what that would involve.
<spiv> You could explicitly set BZR_LOG in the environment of the service I guess
<bialix> not only BZR_LOG but everything else as well, like BZR_EMAIL
<bialix> the only problem here is that I have no way to set env variables, and I have to use some batch wrapper
<bialix> Riddell: sorry for the delay with review, I should be able to review and land your changes this weekend
<vila> ha, was commenting on the bug...
<vila> bialix: yup, wrapper sounds the most reliable way to work around the issues there
<bialix> vila: but wrappers have their own cons
<vila> bialix: try to reach some point where you at least get some feedback about the failures
<bigjools> is there any reason why a "bzr pull" would update loads of files and then finish with "bzr: ERROR: [Errno 13] Permission denied" ?
<vila> bialix: *then*, once the bugs are identified, we can address them
<vila> bialix: does windows logs give you at least some traceback *now* ?
<bialix> vila: of course, I just need to write a patch, but not right now
<bialix> spiv: thanks for your help, I know what to try next
<vila> bialix: no, that's not what I'm saying, I think you'd better write a wrapper to get useful feedback as I suspect there are several cases where the server will fail for different reasons (log and locks being my first suspects)
<vila> bialix: so it will probably be easier to work around the issues by setting env variables in a wrapper
<vila> bialix: as they may be several ones needed
<bialix> or provide fake pwd module
<vila> bialix: and then we could work on making the wrapper useless
<vila> bialix: I think this one is needed to prompt the user so that won't help
<vila> bialix: hmm, may be not, the bug report traceback points to locks indeed to we're trying to get a valid user
<vila> s/to/so/ grr
<vila> s/indeed to/indeed so/ I meant
<bialix> vila: lol: https://bugs.launchpad.net/bzr/+bug/660174/comments/9
<ubot5> Ubuntu bug 660174 in Bazaar "locking a branch should not try to import pwd when running as a windows service" [High,Confirmed]
<vila> hehe, did the execption explained "why" in your case ? :D
<bialix> rotfl
<spiv> bialix: not that I know of, sounds like a bug report including traceback is warranted
<bialix> spiv: bug report to python itself?
<spiv> bialix: oh, sorry!  I meant bigjools!
<spiv> Time to eat dinner.
<bigjools> spiv: no traceback :(
<bialix> bon appetit
<bialix> jam?
<vila> bigjools: nothing in .bzr.log either ? At least a path ?
<bialix> jam has suggested to set username for SYSTEM user, I don't know how
<bigjools> checking
<mgz> <bialix> or provide fake pwd module <- you're already on the wrong codepath by that point
<bialix> mgz: yep, I see it now
<vila> bigjools: is your .bzr.log owned by you ? Nah, would have failed earlier :-/
<bialix> mgz: os.getuid does not exist either
<mgz> really, bzr shouldn't be relying on having a user for server-like operations
<bialix> mgz: right
<bialix> how can I fix that?
<vila> bigjools: I vaguely remember bugs related to file/dir owner but... What kind of branch is that ?
<bigjools> ah here we go
<mgz> but making getuser_unicode return something bogus like "service" for windows when there's no local user might be the easiest workaround
<mgz> `if sys.platform == "win32" and not "USER" in os.environ` or something
<bigjools> vila: here's the error: http://pastebin.ubuntu.com/622469/
<vila> mgz: in the lock code you mean or in get_user_unicode (hi by the way ;)
<mgz> *USERNAME
<mgz> I mean osutils.getuser_unicode
<vila> bigjools: grr, rename not telling us which one, I hate that
<mgz> which is what uses the python getpass module, which is where the issue is.
<bigjools> vila: yeah :/
<vila> the vagueness clarifies a bit, I'm pretty sure we ran into this recently
<vila> mgz: does this ring a bell ?
<mgz> seems a little familar...
<vila> bigjools: bzr version ? 2.3 ?
<bigjools> vila: 2.1.4
<vila> ouch
<mgz> hm, yeah, probably a fix not backported then
<bigjools> it's what's on lucid I guess, this is a machine in the Canonical DC
<vila> ha, that's why
<vila> crap
<bigjools> vila: I'll see about getting it upgraded
<bigjools> in the meantime, fingers crossed that most of the files got pulled :)
<vila> bigjools: it's a bit hard to predict what can happen there, but if I had local access, I'd try a 'bzr st' and a 'bzr revert'
<vila> to at least get some reasonable confidence the tree is in sync with the branch
<bigjools> vila: ah yes it says "working tree is out of date"#
<bigjools> and just hanging now ...
<vila> lp tree ?
<bigjools> yeah :)
<bigjools> it's returned
<vila> bzr revert [--no-backup] (unless you fear there was some uncommitted changes there)
<bigjools> they can be blown out anyway
<bigjools> ok same error
<bigjools> darn
<jam> bialix: set an env variable for the system user. I'm not 100% sure how. Though you could set it globally, I guess
<vila> two ideas: search for files with "incorrect" owner, inspect .bzr/checkout for left over (pending deletion and limbo)
<vila> bigjools: and while the clock is tickiling, consider re-creating the tree from scratch (modulo shared repo etc)
<bigjools> ARFH
<bigjools> vila: found the problem, files owned by other people.  Thanks for the help.
<bigjools> is bzr more helpful with the error in more recent versions?
<vila> https://bugs.launchpad.net/bzr/+bug/491763
<ubot5> Ubuntu bug 491763 in Bazaar "unhelpful OSError from rename inside transform" [Medium,Fix released]
<vila> bigjools: it should, this bug is part of 2.2
<vila> well, this *fix* is part of :)
<bialix> jam: after I finally translate that to Russian I found the way to set System env variable, it was easy actually. I was puzzled by Russian Windows
<bialix> I think I need to set BZR_LOG as well there
<bigjools> vila: cool :)
<maxb> Grr, what?! sysvinit import failed
<fullermd> 's why you use bsdinit instead   :p
<maxb> wtf, there are sysvinit branches on launchpad
<Riddell> https://code.launchpad.net/~jr/bzr-builddeb/changelog-closes-bugs/+merge/63248 is ready to merge in for anyone who has permissions
<ubot5> Ubuntu bug 63248 in kdebase (Ubuntu) "Konqueror crashes when using zip:/ kioslave with sigegv 11." [Medium,Fix released]
<jelmer> Riddell, more than happy to :)
<jelmer> Riddell, I think you should join the team too, though
<jelmer> Riddell: done, with minor tweak to mention the bug # in the changelog
<Riddell> jelmer: needs james_w to accept me into the team
<james_w> Riddell, which team?
<james_w> ah
<Riddell> ~bzr-builddeb-hackers
<james_w> done
<Riddell> thanks
<maxb> james_w: Can I ask you to rename all the existing ~ubuntu-branches branches at https://code.launchpad.net/ubuntu/+source/sysvinit/+branches to something that the importer will not collide with, and requeue --full sysvinit? It's already been tried once today, but it failed - and I think it failed because it got confused by those remnants from the past
<james_w> maxb, I have 6 meetings in the next 2 hours, so if someone else can do it it would be quicker
<james_w> maxb, I'll certainly get to it after that if no-one else has
<maxb> sure, no problem
<maxb> Hrm. We are getting new UDD import failures that say "debian woody is marked but not imported"
<maxb> Has anyone been deleting woody branches?
<james_w> maxb, maybe the ordering change?
<james_w> I don't see why though
<james_w> I don't think woody branches are on LP are they?
<maxb> Hmm
<maxb> interesting
<james_w> one of the import_package.py functions does a "if it's a debian series that isn't on LP and there are any debian branches at all then we don't have to import it"
<james_w> that might be what is breaking
<jblue> hey all, i'm curious what others are doing regarding tags and releases.  I'm looking for a way to do a 'bzr export' which also somehow dumps the revision or tag information as part of the export, in order to identify what revision that export came from.  I'm not very fond of having to update a hard-coded revision in the sources or readme docs.. but is this what is generally done?  Any other elegant ways to manage revision information in an export?
<gour> jblue: like CVS $id?
<jblue> gour: yeah I was thinking of that as well.. it was pretty useful for it's time
<gour> frankly speaking, i do not see need for it, but i understand it may be useful for you
<jblue> normally I wouldn't do an export, and just create a branch, whould would contain the lastest revision info
<jblue> but often times we're deploying to systems which don't have bzr, and making a full branch seems wasteful
<jblue> s/whould/which/
<gour> what do you mean 'deploying to.." ?
<jblue> gour: making a program/application available for use
<gour> jblue: hmm..so where would you like to see revision? e.g. in 'about dialog' or so?
<jblue> not necessarily, it could simply be dumped into a "VERSION.txt" file or something off the root of the export.. but would be automated when the export is created.  But making it part of the sources via 'CVS $id' type functionality would also be useful, on an export.
<gour> jblue: see this http://www.mail-archive.com/ella-animation@lists.launchpad.net/msg00050.html (if it helps)
<fullermd> The way I do such a thing is 'make light checkout ; run script to stuck info somewhere ; rm -rf .bzr'
<jblue> fullermd: would you be able to post that script somewhere that I can take a look?
<fullermd> It's not a specific script, just $DO_WHATEVER.  'bzr revno > foo.txt', or whatever.
<jblue> ah ok
<jblue> right, I guess I could just roll my own
<jblue> echo $(bzr tags -r `bzr revno`) > VERSION.txt
<jblue> for example
<jblue> was just curious if there was a more common way of doing it
<abentley> vila: around?
<vila> abentley: I'm EODing at this minute :-/
<vila> I may pass around later but probably not for long
<abentley> vila: I'll email you.
<fullermd> jblue: Frex, in the first place that came to mind, I do some sed'ery to get the revid into a .h file.
<fullermd> Just another thing to do as part of the "make tarball" script that already does things like build the docs (hardly anybody will have the necessary toolchain), etc.
 * gour is researching about bento
<gour> ..as build & packaging tool
<maxb> Gah
<maxb> I've failed at getting the udd import ordering to do precisely what I want, again
<jblue> /win 4
<maxb> james_w: Please don't requeue sysvinit after all. I'm going to go and work on take 3 of the import ordering code
<james_w> maxb, ok
<jblue> is is possible to pull a specific change from one branch into another?
<jblue> for example, I have a branch with 5 revisions.  I make another branch off that one, at revision 2, and I want to merge in the changes from revision 4 off the original branch
<jblue> without including revision 3 or 5
<jblue> think I found it.. --change
<maxb> jblue: You can't *pull* in such a scenario, but you can merge. bzr merge -c revspec ../otherbranch
<jblue> thanks maxb, also found that I can something like: bzr merge -r 43..44 .. which has the same effect
<maxb> Yes, -c X is just shorthand for -r before:X..X
<jblue> nice
<mhall119> is there a way to pass bzr builddeb a specific gpg key to use for signing?
#bzr 2011-06-10
<slangasek> mhall119: yes, '-- -k<keyid>'
<slangasek> (can also be set in an env variable; this is actually just passed through to dpkg-buildpackage in both cases, bzr doesn't use it)
<poolie> hi slangasek
<slangasek> poolie: hey there
<slangasek> so I have a fun challenge for someone here :)
<poolie> :)
<slangasek> Linux-PAM upstream recently migrated their VCS from CVS to git
<slangasek> and I had a full import of the CVS history into my bzr...
<slangasek> and now I need to make bzr believe that the git history is the same
<slangasek> how do I do that? ;)
<jelmer> that's the parallel import problem again :-/
<slangasek> so, what solutions have you guys come up with? :)
<slangasek> doesn't have to be particularly automated; I'm willing to do some grunt work here for a one-time fix-up
<slangasek> but I'd prefer not to do this as a rebase, since there are plenty of merge points in the history which I guess would make that painful
<poolie> hm
<poolie> so you have a lot of packaging branches, or other branches, based off that their previous import?
<poolie> thanks for fixing all the import branches, and for the sru, jelmer
<poolie> and for denting about it, for that matter
<slangasek> poolie: a fair number of branches, yes
<poolie> the pragmatic thing now would probably be to rebase them
<poolie> itcould be nice to have a way to tell it to treat some revisions as aliases for others
<poolie> perhaps, rebase them, and file bugs about any aspects of rebasing that don't work well
<slangasek> not having used it before, I'm nervous about what bzr rebase is going to do with these branches that have been repeatedly merged from upstream
<slangasek> but I'll give it a go and see what happens
<poolie> i'd find it useful to at least know what happens
<poolie> generally speaking the parallel import problem jelmer grimaced at is something we will improve in future releases
<slangasek> poolie: so, I can't get bzr rebase to do anything useful :)
<slangasek> it either gives me "Branches have no common ancestor, and no merge base revision was specified", or "Base branch is descendant of current branch. Pulling instead" depending on how I misuse it :)
<lifeless> slangasek: you may find replay is better
<slangasek> not so far as I've been able to understand it so far
<lifeless> bzr's rebase is a bit tightly coupled to the idea of resetting an in-progress branch
<slangasek> replay just gives me a glorious number of conflicts
<slangasek> lifeless: my branch history starts with the CVS-imported upstream branch, branches from that to add the packaging branch, and repeatedly merges the upstream branch into the package branch over time.  What commands should I be using to get the replay I want?
<lifeless> something like replaying your first interesting commit on the matching commit from the git imported branch
<lifeless> sadly hwat you want to do is not well supported yet
<slangasek> my first interesting commit also happens to be a merge resulting from 'bzr join' of the upstream CVS repo with my svn package history ;)
<slangasek> so when I do 'bzr replay -r694 ../pam.debian' and get a bunch of conflicts for all the upstream files, is that expected, or is that a sign I'm running the wrong command?
<slangasek>   Path conflict: <deleted> / debian
<slangasek> that one seems non-negotiable
<slangasek> I suppose I might be able to redo the join
<slangasek> lifeless: given that I know I have a 1:1 correlation between git revisions and bzr revisions, is there any way to directly rewrite the revision ids?
<lifeless> slangasek: yeah, read them in, change them, write them out - which is what bzr-rewrites commands provide *an* interface to
<lifeless> the problem is getting to do what you want
<lifeless> slangasek: I don't have an easy canned recipe for you though
<slangasek> how about pointers to the right documentation to the part of the bzr internals I need to be hooking into? :)
<slangasek> that's got to be a better use of my time than trying to manually resolve merge conflicts for every file in the tree
<mwhudson> you might be able to use fast-import and some sed to translate the imported-from-cvs revision id to the imported from git revision ids?
<mwhudson> would be horrible and fragile, but might work
<lifeless> so in theory generating an appropriate rewrite map for bzr-rewrite
<lifeless> and using that from its library would DTRT
<lifeless> bzr-rewrite started life as a revisionid-rewriter for bzr-svn
<mwhudson> ah right, i guess that's a more tasteful way of achieving the same end
 * slangasek nods and has a look
<slangasek> thanks :)
<lifeless> the frustrating thing about bzr-rebase is its -so close- and yet so far
<poolie> hi vila?
<poolie> vila, it would be great if there was a test fixture that set one config variable just temporarily
<poolie> or a context manager
<poolie> or is there such a thing?
<vila> poolie: hi
<poolie> hey there
<poolie> i'm just finishing 220464
<vila> hmm
<poolie> i'm going to just turn that behaviour off by default
<vila> first thing that comes to mind is: one config variable in *which* context ?
<poolie> well, that's a good question
<poolie> for my purposes, i just need something that will be seen by the code under test
<vila> that's a good answer :)
<poolie> it looks like i can just modify GlobalConfig because that's already isolated
<vila> hmm
<vila> if that fits your needs, go for it
<vila> My gut feeling is that this may break in edge cases (intersection between where the option can be declared and its default value) but nothing really serious
<vila> i.e. I doubt we encounter cases where an option *cannot* be set in GlobalConfig
<poolie> my other question was whether the option registry type thing is landed
<poolie> i could just look :)
<vila> yes
<vila> err
<vila> yes it has landed
<vila> not yes you can look :)
<poolie> ok
<poolie> perhaps since this is already so big i should do that in a follow on
<poolie> are we going with a style like 'bzrlib.lockdir.break' or 'locks.break'?
<poolie> i might have argued for the former but for something people have to type it now seems too long
<poolie> i like the second though, because it will group things together
<vila> same here, I think I summarized that in devnotes after jelmer's review
<vila> eseentially it goes one step further by removing 'bzr.' for options everybody share and leave plugins decide to prefix with their name if/when needed
<poolie> wfm
<vila> my initial goal was to clearly tear the various name spaces apart but in retrospect that was too much
<vila> collisions are guarded by the registry so we are pretty safe
<poolie> so i could move the documentation and the default into the registry?
<vila> yes. If you want the default value to be taken into account, you need to use GlobalStack, not GolbalConfig though
<vila> fixing tyops of course ;)
<vila> hmm
<vila> depending on whether your tests inherit from TestCase or TestCaseWithTransport you can even use _load_from_string for the former but that's maybe the fixture you're after ?
<poolie> ok, so i've made the option off
<poolie> i might send it in
<maxb> jelmer: First time I've ever seen "review needsfixing" and "merge approve" used together! :-)
<jam> morning all
<poolie> news-file merge doesn't seem really to be working on pqm
<poolie> hi max, jelmer
<poolie> vila, ok, sent
<poolie> and, i think that's it for me for now
<maxb> Hi poolie. Thanks for the udd reviews. Are you happy for me to land them, though you didn't toggle the MP status as well as commenting?
<vila> poolie: \o/
<vila> poolie: enjoy your week-end
<poolie> max, yes
<jam> poolie: I'm pretty sure it isn't configured in pqm since we moved to the new layout
<jam> (news-file merge)
<vila> poolie: the news conflicts I've seen recently strongly hint that indeed it's not configured properly
<vila> spiv knows better and commented that something weird was going on there as he didn't manage to make it work with losas (with weird == *I* don't remember/understand the details)
<vila> mgz: ping
<jam> vila: I think the main issue is that news-merge is configured to merge NEWS and not "bzr-2.2.txt bzr-2.3.txt, etc."
<vila> really ? It's *that* simple ? That would be nice and be easy to fix then
<jam> vila: I don't know 100%, but that is at least a start
<vila> jam: juggling eggs right now, could you check with a losa ?
<stewart> hi all!
<stewart> i'm pretty sure there's at least one bug with a shared repo and several processes branching a RepositoryFormatKnitPack1 into it
<stewart> (e.g. what you'd typically do for a jenkins setup of having the /jenkins working dir be a bzr repo)
<Riddell> stewart: so report a bug?
<stewart> Riddell, yeah, i should really do that :)
<stewart> Riddell, i'm also going to upgrade the repository formats of those branches, and that'll certainly fix it
<Kamping_Kaiser> hi, are new bugs forwarded to this channel?
<Riddell> Kamping_Kaiser: no but they get triaged by bazaar developers
<Kamping_Kaiser> Riddell: thanks. i wont expect to see it here when i report it then :)
<Riddell> canonicalers: what shall I do about bug 777507 ? it's a problem in qbzr in maverick, the fix is already backported to qbzr/0.19 branch
<ubot5> Error: Launchpad bug 777507 could not be found
<Riddell> so I guess the resolution is either to do an SRU or just tell the guy to checkout the branch and use that
<Riddell> I'm not sure why this bug is marked private, there doesn't seem to be anything very private about it, but he seems to have done so explicitly
<vila> jam: thanks for the reviews, can you look at https://code.launchpad.net/~gagern/bzr/bug112390-kind-marker-optional/+merge/63080 again now that Martin answered your previous review ?
<ubot5> Ubuntu bug 63080 in linux-source-2.6.22 (Ubuntu) "snd-intel-hda requires options to work on AD1986A" [Undecided,Won't fix]
<vila> good bot, but no sugar :)
<Kamping_Kaiser> while bzr import-dsc is running, where is the import cache stored? ( i assume ther is one). i'm waiting for linux-2.6 to import an its taking its sweet time.
<Kamping_Kaiser> on the subject of speed, does anyone else have speed issues trying to tab complete import-dsc? i have a 4-5second lag from hitting tab to the complete happening
<spiv> stewart: yes, there is
<spiv> stewart: https://bugs.launchpad.net/bzr/+bug/709349
<ubot5> Ubuntu bug 709349 in Bazaar "bzr: ERROR: bzrlib.errors.RetryWithNewPacks: Unprintable exception RetryWithNewPacks" [High,In progress]
<spiv> stewart: The Twisted buildbot has encountered the same problem(s).
<Kamping_Kaiser> hi all. bzr import-dsc has failed, claiming to be out of disk. but its on a filesysem with 91GB free. http://paste.debian.net/119421/ is the output. i'm running again with --verbose atm
<vila> Kamping_Kaiser: what about /tmp ?
<Kamping_Kaiser> vila: 1.4gb untill this filled it. i'll clear it out and try again
<Kamping_Kaiser> (its a tempfs)
<vila> Kamping_Kaiser: right, probably where the problem is coming from then
<vila> Kamping_Kaiser: overriding TMP (or TMPDIR ?) may address the issue for this command
<Kamping_Kaiser> vila: i'l try them out, thanks
<vila> Kamping_Kaiser: if import-dsc doesn't respect them, it may be worth filing a bug (your use case is damn valid), I don't know the implementation well enough to say
<Kamping_Kaiser> vila: it takes 15-20 min to fail, so i'll tinker with those variables and let you know how i get on
<Kamping_Kaiser> maybe tomorrow :/
<vila> Kamping_Kaiser: you mean filing the bug or re-trying with the variables ?
<Kamping_Kaiser> vila: re-trying with teh variables
<vila> k
<Kamping_Kaiser> i tried to patebin the failing run, but pastebin won't take > 90KB of text (scary, i didn't think it was that big)
<vila> !paste
<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.
<vila> That paste ?
<Kamping_Kaiser> it was paste.debian.net, i can try that one if you'd like
<vila> If you intend to re-run tomorrow, try this one if you think it may help confirm/infirm TMP support, otherwise better wait
<Kamping_Kaiser> ubuntu paste accepted it... all 18000 lines. http://paste.ubuntu.com/623335/
<Kamping_Kaiser> anyway. i'll let you know how hte others go. thanks again for your help vila
<vila> good paste site ;) But yeah, no way be conclusive about TMP support  without either trying or reading the source :-/
<Kamping_Kaiser> definitely disk space, failed at a later point that time. now trying with TMP="~/bzr-temp"
<jelmer> Riddell, hi
<jelmer> Riddell, in ~jr/bzr-explorer/unstable you seem to have updated the version string but not merged in a new version
<vila> Kamping_Kaiser: gee, tomorrow already ? Your days are short :)
<Kamping_Kaiser> vila: very fast clocks
<vila> ha, I see, one more overclocking freak :)
<Kamping_Kaiser> hehe
<Kamping_Kaiser> back in the day *reminices*
<Kamping_Kaiser> vila: \o/ TMP worked, sans a directory creation bug
<Kamping_Kaiser> vila: you are a god among men :D
<vila> just lucky ;) And owing to our elders defining TMP... ;)
<Kamping_Kaiser> :)
<dreamkxd> Hello, I am Yonggang Luo
<dreamkxd> Calling for Jelmer Vernooij
<jelmer> hi
<jelmer> dreamkxd, that's me
<dreamkxd> OK, do you see my comments?
<dreamkxd> OK, I explain my idea again,
<dreamkxd> Suppose trunk is the first directory we created, we called it the start folder, named with "default"
<jelmer> dreamkxd, yeah, replying now
<dreamkxd> We know under svn, there is an copy operating. we can using it to tracking new branches, and new tags.
<dreamkxd> almost every tags and branches is created like this, if it's not, we can using config file to show that.
<dreamkxd> After this, we have some rules.
<dreamkxd> 1.if directory A copied from directory B, and B is an existed branch or tag, then A is an branch or tag, this is the most frequently condition
<jelmer> dreamkxd, how do you know which folder is the "default" folder?
<jelmer> dreamkxd, also, this requires looking at the entire history. Some repository have over 1 million revisions
<dreamkxd> Yes, we suppose trunk is the default folder.
<dreamkxd> Yes, but that's worth, we only convert it one time, and that's necessary, compare to the fact time about converting the content, the revision log is much more quicker
<dreamkxd> So we just ignore the speed problem first:) we won't converting the whole repo day by day:) we need suffer one time:)
<jelmer> dreamkxd: at least for the default behaviour, O(history) is unacceptable
<jelmer> dreamkxd: what about situations where the original trunk was removed and a new trunk is created?
<jelmer> dreamkxd: also, are there any situations you've found where the existing behaviour doesn't work?
<dreamkxd> Indeed, I think the current bzr-svn is not as fast as we think, at least at the last time when I using bzr-svn import llvm, it's struggled:(
<jelmer> dreamkxd, in other words, what's the problem you're trying to fix?
<jelmer> dreamkxd: That's not a good reason to make it even slower though.. :)
<dreamkxd> Now, It's will getting it's faster,
<dreamkxd> indeed, i've ever using hgsubversion to convert llvm, and it's OK, at least on the time:)
<dreamkxd> but bzr-svn toggled....
<jelmer> dreamkxd, have you tried bzr-svn trunk? launchpad doesn't seem to have problems with llvm and it worked fine on my machine too
<dreamkxd> you means bzr svn-import ?....
<Riddell> jelmer: my main concern with that bzr-explorer packaging branch was to update the bzr dependency, but I could do the package update too
<jelmer> Riddell: is the new dependency only since bzr-explorer 1.3.0?
<dreamkxd> What's your command, I may have an try:) Anyway, llvm is complicated, I don't think at the current stage, bzr-svn will convert it well..
<dreamkxd> Well, I am not meas only import the trunk.... but also retains the branches and tags informations....
<jelmer> dreamkxd: Have you tried? I don't see anything in the repository that could confuse bzr-svn
<dreamkxd> Err....
<jelmer> dreamkxd: "bzr svn-import http://llvm.org/svn/llvm-project/llvm/" is what I would try
<jelmer> or http://llvm.org/svn/llvm-project/llvm/trunk
<jelmer> I mean "bzr branch http://llvm.org/svn/llvm-project/llvm/trunk"
<dreamkxd> Yes, that's what I was tried..
<jelmer> dreamkxd: did that create incorrect branches?
<dreamkxd> bzr svn-import http://llvm.org/svn/llvm-project/llvm/ that's I wanted.
<dreamkxd> So, can you give me an list of branches?...
<dreamkxd> Then I can tell you what's lost.
<dreamkxd> Because I was failed:(
<jelmer> dreamkxd: Sorry, can you be more specific? How did it fail?
<jelmer> what was missing?
<dreamkxd> It's running for an long time, about 8 hours, I didn't finished it, and then I closed it....
<mgz> vila: pong
<dreamkxd> OK, I'll try it again, now I was using subvertpy 0.8.1 and tip of bzr-svn and stable bzr 2.3.3
 * vila swaps in . o O (What was it ?)
<mgz> eheh
<vila> mgz: oh yeah, about leaks, I kind of lost track about what I should ping you what, is it the cleanup hook stuff
<mgz> that's the bad thing about pings vs just saying what you were thinking of
<mgz> right, I need to track down a bug, then I think I can just propose
<vila> mgz: about this specific topic, since you started by trying to fix a bad cleanup, how about just talking with jelmer about it ?
<dreamkxd> BTW, I think the old way of bzr-svn is still O(history) D:\CI\bld\brepo>bzr svn-import svn://localhost/llvm/ Using repository layout: trunk1   2084kB    44kB/s | copying revision 304/130322
<vila> mgz: a better test coverage can come later
<mgz> ah, that's a different one. I did bug jelmer a bit about it.
<dreamkxd> Well, we'd better using gtalk,, freenode is not suite for long conversation....
<jelmer> dreamkxd, not when finding the layout
<vila> mgz: ha, right, he's busy right now :)
<vila> dreamkxd: it is. and the logs are archived which is better for our collective unconscious :)
<jelmer> vila: I think you mean it's not.. at least, my gtalk logs aren't accessible by anyone but me :)
<vila> jelmer: hehe, I meant freenode is suited :)
<dreamkxd> Er, my input box only one line,sign....
<dreamkxd> Is there any freenode client?....
<vila> dreamkxd: what are you using ?
<dreamkxd> Chrome ,,, http://webchat.freenode.net/
<dreamkxd> sign....
<vila> dreamkxd: oh, webchat, which OS ?
<dreamkxd> Chrome 12, under WinOS.
<dreamkxd>     def find_branchpaths(self, layout, from_revnum, to_revnum, project=None):
<dreamkxd> This function is O(history) time...
<dreamkxd> If I wan't to using the history, I need to do something here.
<dreamkxd>  23369kB    56kB/s / copying revision 4776/130322
<jelmer> dreamkxd, that function is used in a specific codepath which only kicks in if there are bzr-svn file properties in the repository
<dreamkxd> that's my progress.
<jelmer> dreamkxd, that's while copying the revisions; I'm all for making that faster, but I don't see what it's got to do with the repository layout stuff..
<dreamkxd> e....OK.
<dreamkxd> 2.if directory A copied from directory B, and there eixst an branch or B/X that under directory B, then we have an new branch or tag A/X
<dreamkxd> 1.if directory A copied from directory B, and B is an existed branch or tag, then A is an branch or tag
<abentley> vila, thanks for your reviews.
<dreamkxd> 3.ignore the branches that comes from outsite
<dreamkxd> That's all...
<abentley> vila: re: new_ids / changed_ids, we care about files whose inventory entries have changed, but a transform could remove the old file_id, and then restore the same file_id, and then we shouldn't care about it.
<vila> abentley: thanks for the hard work, impressive, hope you don't mind adding comments, they cruelly lack
<vila> err, crossed on the wire, was replying to your first comment
<abentley> vila: I do mind adding comments.  Comments get stale.  The code should be clear enough by itself, and if it's not, it should be made clearer.
<dreamkxd> example :cfe/branches/cfe-1203/tools/llvm copied from llvm/trunk then tools/llvm should not be an branch, and also those files should not be contained in cfe?
<vila> abentley: well, that's a shame then, because you modified code without modifying comments
<abentley> vila: Like I said, comments get stale.
<vila> ...
<dreamkxd> Is there question?
<abentley> vila: so it's better not to need any.
<vila> abentley: in an ideal world, sure
<vila> and even there I strongly doubt comments are useless
<jelmer> dreamkxd: I'm not following, you're proposing creating branch on whether they were derived from the original trunk branch right?
<dreamkxd> Now only derived from original trunk branch, but also derived from other already existed branches..
<vila> abentley: comments are for readers, you can't argue that reading one method gives enough contexts to understand it however perfect the code is
<abentley> vila: I certainly can.
<dreamkxd> It'slike an set, we inserting element into it, and delete element from it.
<jelmer> dreamkxd, see http://pastebin.ubuntu.com/623402/
<vila> abentley: why bother writing cover letters then ?
<abentley> vila: And if it doesn't, it's badly written.
<abentley> vila: To express motivation.
<jelmer> dreamkxd: I'd like to discuss the problem first before discussing the solution - what's the problem you're trying to solve, can you give an example of a repository that breaks?
<dreamkxd> llvm/branches/Apple
<vila> abentley: pff, your code doesn't express motivation ?
<dreamkxd> That's the problem, under Apple, there is a lot branches..
<dreamkxd> Apple is not an branch, but an branch container:)
<abentley> vila: my code doesn't express motivation for the change I propose, it expresses motivation of the changed version.
<dreamkxd> http://pastebin.ubuntu.com/623402/
<dreamkxd> http://llvm.org/svn/llvm-project/llvm/branches/Apple/
<dreamkxd> And in this repo, there is other kinds of examples:)
<dreamkxd> such as http://llvm.org/svn/llvm-project/cfe/branches/Apple/whitney-IB/src/tools/
<dreamkxd> The path  http://llvm.org/svn/llvm-project/cfe/branches/Apple/whitney-IB is an branch of llvm
<dreamkxd> but the path http://llvm.org/svn/llvm-project/cfe/branches/Apple/whitney-IB/src/tools/clang/ is an branch of cfe.
<dreamkxd> These problems is what I want to solved.
<vila> abentley: right, this discussion is useless then, you won't convince me that comments aren't needed especially in in an read where so many of us could't understand the code motivation without comments, feel free to start a discussion on the mailing list
<jelmer> dreamkxd: Ah, ok. That makes sense
<vila> abentley: if you disagree with the comments I proposed, explain why
<abentley> vila: We are getting off track, because I have a different coding philosophy than you, and "cruelly lack" was too strong for me to let it pass.
<vila> abentley: if you think you can do that with only code, great
<abentley> vila: I can tell you that "Summarize all changes to the inventory" is less accurate than "Get the trans_ids and paths of files needing new inv entries."
<dreamkxd> Now, I have already got an peace of python code implement the following functions.
<jelmer> dreamkxd: You should be able to create a custom layout class with a custom "layout guess" function to see if your approach will work better
<dreamkxd> Yes, I wan't to do that..
<dreamkxd> But I need to access to the history:)
<jelmer> dreamkxd: You should be able to create your layout in repository_guess_layout() and pass in the logwalker there
<dreamkxd> And now I've toggle where to get the log into it...
<vila> abentley: "cruelly lack" is how I view the actual state, I consider that this code has been written by the bzr team, I don't throw stones at you, I want to make it easier to understand for mere mortals which may not be part of this team and lack the background (also in this case, I lack a lot of background)
<vila> I won't even pretend (and I said so) that my *proposed* comments are accurate or complete
<abentley> vila: If you'd phrased it less aggressively, I'd have accepted those changes that are accurate and we probably wouldn't be having this discussion.
<vila> but I wasn't aggressive damn it ! I felt that this method was important and there is *no* comments there in trunk.
<vila> How is it said in English ?
<abentley> vila: "cruel" is an emotionally intense word.  If you use it about someone else's work, you are likely to get a reaction like mine.
* maxb changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | UDD failures: 486
<abentley> vila: You say "I think this method should have comments because it is important" in English.
<dreamkxd> Well, is there anyway to specify the layout you want to use?
<vila> But why did you take for you when I was saying that the lack of comments was cruel for *me* ?
<jelmer> dreamkxd: It's an option to "bzr svn-import", or you can set it in your bzr configuration ("layout = trunk1")
<vila> abentley: right, thanks for the correction, but next time ask me what I mean if you think I'm aggressing or insulting you. WHy on earth would I do that ?
<vila> abentley: especially when I said great job ?
<abentley> If the lack of comments was cruel to you, then I was being cruel to you.
<dreamkxd> bzr svn-import layout=trunk1?
<jelmer> dreamkxd: bzr svn-import --layout=trunk1
<vila> abentley: these two reviews were some of the most interesting I did lately and required me to think hard and try various tricks to understand what was happening
<vila> abentley: I felt I couldn't write the comments myself, gave it a try and ask you to polish them
<dreamkxd> OK, thanks, well is there any way that I need not build and install bzr-svn and then using of it?
<vila> abentley: and roughly your reply was: comments are useless, if you can't understand the code, you're an idiot
<abentley> vila: Okay, let's stipulate for now that the right approach is to add comments rather than clarifying the code.
<abentley> vila: No, my response is that if you can't understand the code, the code isn't clear enough.
<jelmer> dreamkxd: If you have the plugin installed in your home directory you can modify it there directly
<abentley> " The code should be clear enough by itself, and if it's not, it should be made clearer"
<jelmer> dreamkxd, alternatively, you can set the BZR_PLUGINS_AT environment variable to point at the location where the plugin is
<dreamkxd> Well, if I directly copy the bzr-svn folder into bzrlib plugin folder, will that working?...
<jelmer> dreamkxd, that should work too
<vila> abentley: well, both are valuable, I share the value that code should be crystal clear but... well, we're just humans for once and then there are cases where comments are just easier to explain either why *this* implementation is better than others or just give some context without requiring the reader to load the whole problem/solution in his head
<dreamkxd> Ok, thanks...
<dreamkxd> My bzr-svn playground is https://code.launchpad.net/~luoyonggang/bzr-svn/perfect-layout .. I will commit to there first, it's it's stable enough, I'll request for merge:)
<abentley> vila: let's stipulate that adding comments is the right approach for this code, and talk about the comments themselves.
<vila> abentley: also, the clearest code sometimes is just not obvious and adding comments makes it easy to read again
<vila> abentley: great
<abentley> vila: I don't understand the motivation for the docstring changes to _inventory_altered.  Could you explain that?
<vila> abentley: It's unclear to me what part of the transformations are captured here
<vila> abentley: are they all ? If not which ones are and which aren't ?
<abentley> All trans_ids that need an inventory entry change are there.
<vila> abentley: Imagine I have no idea about which transformations requires an inventory change
<dreamkxd> I was already do this layout_registry.register_lazy("perfect", "bzrlib.plugins.svn.layout.perfect",  "PerfectLayout")
<abentley> vila: there are two possible answers.  Either we should document every kind of change that requires an inventory update, or we should say that is prerequisite knowledge for working on this code.
<vila> abentley: also, one of my hesitations was 'new' in 'needing new inv entries'. Is it new as in needs to be created or new as in needs to be updated
<vila> abentley: well, the idea is to help people *get* this pre-requisite knowledge
<vila> so probably something between the two
<abentley> vila: The knowledge is not particular to TreeTransforms, however.  It's about knowing what an inventory entry reflects.
<vila> true, we don't want a full book either :)
<abentley> vila: In any case "Summarize all changes to the inventory." seems false, since we're not returning any information about the inventory itself.
<jelmer> dreamkxd: That wouldn't really help in this case - I think you want to change repository_guess_layout as that's a location where you actually have access to the layout
<jelmer> s/to the layout/to the history/
<abentley> vila: It's not a summary, it's just a list of paths and trans_ids.
<vila> abentley: sure, this was more a placeholder
<vila> but list of paths and trans_ids doesn't tell me much about what they represent
<dreamkxd> You means directly create CustomLayout under function repository_guess_layout?
<abentley> vila: I don't know what you mean by "represent".  If you mean you don't know what a trans_id represents, that is definitely prerequisite knowledge for TreeTransform.
<dreamkxd> such as return CustomLayout (repository._log)
<jelmer> dreamkxd: I think you mean PerfectLayout rather than CustomLayout?
<dreamkxd> Yes, PerfectLayout
<jelmer> dreamkxd, Also, presumably all the analysis would happen there, and you wouldn't need to access the history again after that
<vila> no, I have an imcomplete understanding of what a trans_id is, I'm talking about the whole list with respect to the current transformations
<Riddell> how come requeue_package.py doesn't work for me on jubany? http://paste.kde.org/80443/
<dreamkxd> But, I need all history ..., did logwalker_guess_layout will iterate the whole history?
<abentley> vila: so by "represent", you really mean "why would a trans_id be included in this list"?
<vila> abentley: if the inline comments are valid they defines that. I don't know if there is a good way to capture that
<vila> yup
<jelmer> dreamkxd, well, that's what you intended right?
<vila> abentley: when you don't know TT, it's not obvious to translate: _removed_contents means deleting and/or unversioning for example (may be not the best one other attributes are needed to get the full answer but... well)
<dreamkxd> Yes, that's I wanted, I need to iterate every revision's log, and If I there is no cache, every time running bzr svn-import, I need to iterate on SVN log, if there is cache, then I only need to iterate when guess, but after guess, if new revisions appeared, I also need to iterate on it:)
<dreamkxd> That's means, I need iterate EVERY svn revision LOG at least ONE time.
<jelmer> dreamkxd: I guess another thing you could do is in Repository.get_layout() check for a config variable
<jelmer> dreamkxd, and if that variable is set, return PerfectLayout(self._log)
<vila> abentley: yet another way to think about it: Imagine someone not knowing TT at all and  encountering _inventory_altered for the first time. What will help him understand the code without giving imprecise and hard to maintain hints ?
<dreamkxd> And remove the statement layout_registry.register_lazy("perfect", "bzrlib.plugins.svn.layout.perfect",  310    "PerfectLayout") ?
<jelmer> dreamkxd, yes
<vila> abentley: and yes, this may require other knowledge not explained here, but that doesn't mean good hints can't be provided
<abentley> vila: it feels like an extremely high burden of documentation.
<abentley> vila: like a manual for laymen for doing heart surgery.
<vila> hehe
<vila> not at all
<dreamkxd> OK, I see, I think my proposition can not be guess:) so just direct using of it:)
<vila> I wrote the proposed ones quite quickly and I'm sure you can fix/complete them without spending hours on them
<abentley> No, really, it does.  I expect people who hack on TT to know what _removed_contents is.
<abentley> _removed_contents is documented, and I'll happily improve the documentation if needed.
<vila> what are you aiming for ?
<vila> Convince me that all my proposed comments are not needed ?
<abentley> vila: sorry.  I am reacting to your suggestion "Imagine someone not knowing TT at all...".
<vila> <shudder> Sorry, I don't know how to express that in English as well as I can do it in French :-(
<vila> Assume I agree with you about TT (as all code) requiring )some* pre-requisite but that I disagree about where to stop/start commenting ? And that I'm searching a middle ground
<vila> Comments can be as hard to write as code (IMHO), I try to write them as a way to facilitate the code *reading* (as opposed to understanding)
<abentley> vila: What do you think of this as a docstring: http://pastebin.ubuntu.com/623446/
<vila> The former occurs more often than the later as you can read code without understanding it most of the time
<vila> abentley: +1 +1
<vila> abentley: so, when is the filtering needed in: +        changed_id = set(t for t in self._new_id
<vila> +                         if self._new_id[t] != self.tree_file_id(t))
<vila> abentley: I mean, I can see that if the id is the same it's not changed, but when is it needed ?
<abentley> vila: The filtering is so that we don't return spurious entries, and do more work than needed to update the tree.
<vila> but which entries are spurious ?
<chrisvj> hi
<abentley> vila: entries where the file id was deleted, and then restored to the original value.
<chrisvj> does anyone have any idea why bazaar stops downloading files at 59%?
<vila> abentley: wow, *that* is what I'd like to find in the comment because it will take a long time to find it otherwise
<vila> s/take/&*me*/
<maxb> If someone ~canonical-bazaar has a moment, please bzr pull jubany's bzr-builddeb and requeue_package.py --all-of-type dipy  ?
<abentley> vila: similar to changed_kind = (t for t in changed_kind if self.tree_kind(t) != self.final_kind(t))
<vila> abentley: hehe, who knows why I understood this one more easily...
<vila> maxb: how safe is that ? :D
<maxb> vila: Pretty safe, we already did the big pull, this pull should only be a handful of revisions
<vila> maxb: 2 indeed, I'm unclear about the needed dependencies for jr's hook ?
<Riddell> vila: none needed, it won't use it unless bzr >= 2.4
<Riddell> vila: do you run commands on jubany as pkg_import?
<vila> ha, good, you tested it against 2.3.1 ?
<vila> Riddell: yes, you should do a su first
<vila> well, sudo su -
<Riddell> vila: yes it checks for the bzr version
<vila> Riddell: would you try to help maxb there or should I just finish this ?
<Riddell> vila: I don't have sudo permission so I can't do anything :(
<vila> k
<vila> pull done
<maxb> Also, the hook should not be invoked because the importer doesn't invoke editors? Or did I misunderstand?
<vila> maxb: and requeue done
<maxb> thanks
<mgz> I spent yesterday replacing code using python modules with Qt things.
<Riddell> mgz: oh?
 * vila blinks
<vila> mgz: can you elaborate on that ??
<vila> mgz: I'm not sure where to put the comma...
<vila> or the parentheses
<mgz> it was an interesting experience. just a little gui a friend had written with pyqt and it turned out using as little python as possible generally made for better code.
<mgz> QProcess does async reading properly, and handles unicode commandlines, subprocess doesn't.
<mgz> QDirIterator avoids having to filter inside os.walk and is more efficient
<mgz> QString has a builtin normalized method so don't need unicodedata.normalize
<mgz> QSettings is a bit easier to use than ConfigParser and I'm mor confident it does sensible things with unicode
<Riddell> Qt devs know API is everything for libraries
<mgz> I'm down to `import datetime, os, sys` at the top.
<barry> any code hosting/bzr experts online that could do a quick mumble with mvo and myself?
<Riddell> can I recommend QDateTime? :)
<jelmer> barry, sure
<mgz> I looked at it :) it's literally one line for getting a timestamp though so didn't seem worth changing.
<barry> jelmer: awesome, thanks
<vila> barrym jelmer: Mind if I listen ?
<barry> vila: of course not!
<vila> thanks
<abentley> vila: http://pastebin.ubuntu.com/623473/
<vila> abentley: THANK YOU !!!!
<abentley> vila: Any improvements still needed?
<vila> abentley: let see...
<vila> abentley: nah, kidding, that's great !
<jelmer> barry: I'm in Bazaar
<mgz> QProcess was the big win, I'm fed up with subprocess not doing what I want. Helps that there's an event/callback thing built in anyway.
<barry> jelmer: can you hear us?
<jelmer> barry, I can hear you
<jelmer> barry, not sure how to talk myself yet though..
<mgz> open your mouth!
<mgz> irc make people forget...
<abentley> vila: re self.addCleanup(fork.lock_write().unlock), that's an improvement but I'd rather write self.useContext(write_locked(fork))
<vila> abentley: sure, I'm not sold on the new trick myself
<abentley> vila: did you merge my changes into trunk?
<abentley> vila: for some reason, my diff is lacking the changes from before.
<vila> abentley: I didn't
<vila> abentley: otp
<abentley> vila: okay, it's that submit_branch behaviour.
<vila> abentley: err, I misread, self.useContext() ? Is this from testtools ?
<abentley> vila: I believe it's only in Launchpad, but the implementation is simple.
<vila> Ha ok, yeah, sounds nice
<abentley> vila: val = foo.__enter__(); self.addCleanup(foo.__exit__, None, None, None); return val
<vila> hehe
<vila> abentley: you'll have to talk slowly while we get up to speed with 2.6 ;)
<vila> abentley: -fixups approved, want me to submit to pqm ?
<abentley> vila: no, I'll do it.
<vila> k
<abentley> vila, jam: you guys seem to disagree about whether a test that proves no error is raised should have an explicit assertion.
<Riddell> I now have access to pkg_import on jubany, requeue-package still doesn't work, what am I doing wrong? http://paste.kde.org/80473/
<vila> abentley: the double with ?
<abentley> In test_apply_retains_root_directory, I have no assertion and vila complains.
<abentley> In the shelf_ui test, I have assertions that no exception is raised and jam complains.
<vila> hehe
<vila> abentley: is the shelf_ui one the onw with the double with ?
<abentley> vila: yes.
<vila> abentley: I had to play with it to understood how it works, it seems to me *both* with are required or the test will be wrong
<vila> err, to understand
<abentley> vila: yes, but you can remove both, which is what jam asked for.
<vila> abentley: I agree with you and disagree with jam here
<vila> Adding 'InconsitentDelat not raised' makes it clearer (and the comment may help understand how this construct works ;)
<jelmer> abentley: btw, what's the relation of your fix to bug 82555 ?
<ubot5> Launchpad bug 82555 in Bazaar "Merging to an empty branch doesn't work" [Medium,Confirmed] https://launchpad.net/bugs/82555
<vila> well, not only clearer but also stronger, AssertionError is quite wide
<vila> otherwise
<abentley> jelmer: I don't think it's related.
<jelmer> abentley: ok - thanks
<abentley> vila: Yes, but that would allow other InconsistentDeltas to be raised, and I don't think we want that.
<abentley> vila: e.g. what if the text changes, and then it starts raising?
<vila> huh ?
<vila> what text ?
<abentley> vila: The text of the error.  But I'm thinking of the inner with statement.
<abentley> I think it's fine in the outer one.
<vila> ha ok, yeah, I meant addind the text in the outer one
<vila> adding, gee, tyops festival
<abentley> vila: I find your comment change unclear "if there's no 'other', or it's not versioned (unversioned being one such case), we leave it alone."
<abentley> vila: unversioned is the only case where it's not versioned.
<vila> what about files created but not yet added ?
<abentley> vila: they're unversioned / not versioned.
<vila> unvesioned implied it *was* versioned but is not anymore
<stewart> spiv, thanks for bug URL there. isn't high priority to us as we can upgrade bzr repo formats everywhere (and it's not the only cause of any build/test failure :)   - but good to know is already known
<vila> abentley: IIRC correctly this changes is needed because otherwise unshelving a file added but not yet committed fails
<abentley> vila: I would think "unversioned" can also mean "not versioned", not the past tense of "to unversion".  Maybe my bzr jargon has gone a bit fuzzy.
<vila> abentley: hehe he is still probably better than my English ;)
<abentley> vila: But why would you want to talk about "unversioning" in the context of tree state?  Does it matter why the file is not versioned?
<vila> my point here is that not versioned wasn't an obvious to justify switching from other-name None to a other_tree.has_id()
<vila> shudder
<vila> my point here was that "not versioned" wasn't an obvious reason to justify switching from other_name is None to a other_tree.has_id()
<vila> so I revert the change to see which test was failing without it, understood the change and thought it may be clearer
<vila> now...
<abentley> vila: I don't understand.
<abentley> If you want to know whether a file is versioned, you wouldn't use has_id?
<vila> well, the code didn't it :)
<vila> and the specific failure was about a file which *was* versioned
<vila> so I thought the subtle difference may easily be missed
<vila> but may be unvesioned is not the right word
<abentley> vila: I can make you tests where the file was never versioned.
<vila> gah
<vila> sure
<vila> oh, you mean the bug was larger ?
<vila> and specifying unversioned add no value since all cases were other wasn't versioned were failing ?
<abentley> vila: I mean that merge cares about states, not changes, and so "unversion" is an alien concept to it.
<vila> err, sort of, or you wouldn't need parents
<abentley> vila: I can only make "unversioned" make sense if it means "not versioned", and then it's redundant.
<vila> abentley: not versioned includes never versioned
<abentley> vila: right.  "never versioned" and "unversioned" are distinctions that merge does not care about.
<abentley> vila: so it doesn't make sense to talk about them.
<vila> huh ?
<vila> Why did you introduce versioned then ?
<abentley> vila: "versioned", meaning "has a file id" is a state, and merge does care about it.
<vila> It seems to me you're nit-picking here, if merge cares about A it cares about not A as well
<abentley> vila: Sure, it cares about whether a file is versioned, or not versioned, but it doesn't care whether it's unversioned or never versioned.
<vila> abentley: where are we disagreeing then ?
<abentley> vila: because your change to the comment doesn't seem to add any information.
<vila> ha, right
<vila> The reason I added it was that I didn't realize unversioned was part of not versioned,
<abentley> vila: "has no file id"?
<vila> so may be the whole comment should be rewritten to an even simpler form
<vila> yup, something like that: there is no other, bye
<vila> so yeah, 'has no file id, we leave it alone'
<vila> will wfm
<abentley> wfm
<abentley> vila: re 87 you said "it looks like this is as side-effect of your change that is not described in the cover letter."  Cover letter said "fixup_new_roots does not generate a conflict if a new root is added and the old root is not deleted."  is that not it?
<vila> I think the test is about a conflict with a regular file, not the root, the context was (roughly):
<vila> 1) a directory and its contained files are merged,
<vila> 2) lives goes on
<vila> 3) a file is added in the directory
<vila> 4) the directory is merged again
<vila> where should the file go ?
<vila> ha crap,
<vila> 1.1) the merged directory is renamed
<vila> I don't remember the specifics but I think the file from the first merge are tracked correctly but we are not able to reparent the new file
<vila> So it's not really the same problem that adding a new root, it's more about tracking where the root went
<abentley> vila: it might be because we now apply the OTHER root_id.
<abentley> vila: In cases where there's an id conflict.
<vila> I don't think we apply the new root but instead re-parent the merged files in the existing one
<vila> so basically before your change we were putting the new file into root but with a conflict that were warning the user that he had to move the file in the right place,
<abentley> vila: at line 164, the outcome will now be different.
<vila> err, which file /
<vila> ?
<abentley> vila: At that point, test_merge_from_branch
<abentley> Sorry, file is bzrlib/tests/per_workingtree/test_merge_from_branch.py
<vila> line 164 is in make_outer_tree ?
<abentley> vila: right.
<abentley> vila: the merge from null
<abentley> vila: That will replace outer's root id with inner's.
<vila> argh, gtg :-(
<abentley> vila: okay.  Have a nice weekend.
<vila> the case I was referring to is a merge in an existing branch not an empty one
<vila> abentley: you too
<vila> abentley: may be the *test* had a bad focus
<abentley> vila: I can rewrite it so it fails like it used to.
<abentley> vila: I mean conflicts, not fails.
<vila> abentley: if that means not merging from null:, this may be the way to go
 * vila really off
<maxb> james_w: Hello, are you potentially around and able to make the sysvinit import happen?
<maxb> https://bugs.launchpad.net/udd/+bug/708655/comments/6 if you are
<ubot5> Ubuntu bug 708655 in Ubuntu Distributed Development "sysvinit package import failing" [Undecided,In progress]
<james_w> maxb, I am potentially around
<maxb> Sorry for picking on you -  this needs someone who is in ~ubuntu-branches
<james_w> no problem
<james_w> happy to help
<james_w> maxb, are there debian branches too?
<maxb> no, not on launchpad
<maxb> Which is odd, yes
* maxb changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | UDD failures: 485
<james_w> maxb, branches renamed
<maxb> ok....
<maxb> Are you also able to do the rest at some point, or shall I accost someone else for the jubany bits?
<jseabold> We have a developer who merged trunk into his branch, but the revision in trunk merged into the branch was deleted. He has pushed several commits since. Can I back out these changes with shelve and remerge with the correct revision in trunk?
<james_w> maxb, it's just import-package fixes that you need from lp:udd 455 right?
<james_w> just wondering if we need a mass-import restart before continuing
<maxb> james_w: No recent changes to mass-import, it can be left running
<james_w> maxb, requeued
<maxb> Yay
<james_w> maxb, it's chewing on it and importing something in dapper currently
<maxb> Great, I expect it to take several hours
<maxb> sysvinit has a LOT of ubuntu revisions :-)
<james_w> maxb, thanks for your persistence on this :-)
<maxb> low priority: requeue_package.py --all-of-type enigmail  (they'll all fail again, but it will group them in with the same failure signature as a larger group)
<james_w> maxb, done
<maxb> thanks
<james_w> sysvinit is still on dapper :-)
<maxb> I'm not too concerned about that - I remember watching the logs of my test import. It spend aaaaages on dapper
<james_w> edgy \o/
<maxb> james_w: it looks like the --all-of-type enigmail did not actually take effect?
<james_w> maxb, oops, sorry, I didn't read the output and I got the command wrong :-)
<james_w> done now
<maxb> thanks
<brady> help
<brady> my bzr uploads a ~300mb pack file everytime I push. is this normal? the files being versioned are ~800mb.
<brady> i noticed that the main repository uses repository format 2a and my branch uses format 7. not sure if this is optimal either.
<lifeless> 2a is good
<lifeless> pack files in 2a contain (possibly many) entire compressed files.
<lifeless> this is for data safety and integrity
<brady> i am only changing a few files, and they are relatively small.
<lifeless> there is a plan to have a network-push facility that will send deltas
<brady> yet, when I push ....the entire 300mb pack file is uploaded to the server
<brady> oh, ok. so this is normal behavior.
<lifeless> 'packing' which happens automatically combines pack files
<lifeless> and different versions of files stored inside a /single/ pack are *very* tightly delta-compressed
<brady> it's just a bunch of php files
<lifeless> brady: well, if you are only changing small files, not its not expected that you would be pushing 300MB each time
<lifeless> brady: its the weekend now for the core bzr devs - I suggest asking on the mailing list, or even filing a bug.
<brady> lifeless: thanks
#bzr 2011-06-11
<poolie> hi all
<poolie> mgz: are you here?
<poolie> i get an error on unix from your 220464 changes
<spiv> stewart: to be clear, that bug affects all pack-based repository formats, including 2a
<spiv> stewart: so upgrading to 2a probably won't workaround it (it *might* by accident, by affecting the timing of the race)
<spiv> stewart: not doing concurrent identical fetches into the same shared repository will avoid it (e.g. give each build slave its own repo)
<stewart> spiv, ahh... for one project I noticed it went away with 2a upgrade (although as part of building that project it bzr branch another one... so still hits it that way)
<stewart> spiv, although I certainly don't have a large enough sample size to say it wasn't just due to timing changes.
<maxb> bah, sysvinit udd import failed with a transient connection error
<maxb> Could someone requeue? (*NOT* with --full)
<mgz> poolie: I am now, what's the error?
<mgz> ah, win32utils importing on non-win32 platforms
<mgz> that change looks fine... but pqm still didn't land?
<kazade> does bzr have support for nested branches?
<maxb> It's partially developed, but not ready for production use
<maxb> I am beginning to hate TreeTransform's cryptic error messages telling you nothing but a transient transaction id
<vila> maxb: yeah, welcome to the club :-/ sysvinit requeued by the way
<maxb> :-)
<maxb> thanks
<maxb> Depending on how busy you are, you might apply "bzr break-lock" to these - http://package-import.ubuntu.com/status/67061a280d79e806c089681dd8b4a524.html
<maxb> They all relate to requeued imports from a long time ago
<vila> not overly busy but not there for long either (SO waiting :-})
<vila> where are the branches ?
<maxb> where? in /srv/package-import.canonical.com/new/updates/(packagename)/*
<vila> yeah, found them, not all are locked, will be tedious, on it
<maxb> tedious? Could you not just do "for i in *; do bzr break-lock $i; done" in each package directory?
<vila> Isn't this tedious ? :)
<vila> Bad ENglish again ?
<vila> oh, you mean breaking the lock without checking first ?
<maxb> well, the locks should all be really old ones
<vila> ha, silly, the check occurs while trying to break it of course
<vila> yeah, hey, be patient I'm just waking up :)
<fullermd> Always a bad idea.  I recommend against it.
<maxb> Hah
<maxb> (And the requeue_package.py --all-of-type ktorrent )
<maxb> *then
<vila> maxb: done (and gone ;)
<vila> maxb: I'll be around for a bit later
<vila> maxb: they all seem to fail (I didn't check the previous cause). locks will need to be broken again ?
<vila> maxb: this sounds like a good command to add no ?
<vila> maxb: ha, I see you're already on this track (catching up with udd mail)
<maxb> This is a case of shuffling failures from one failure signature to another to organize the failures page better :-)
<vila> lol
<maxb> AHA
<maxb> bzrtools' tarball import code dislikes it if a symlink to a directory turns in to a real directory in successive versions
<maxb> Hmm
<maxb> So, if I have this directory structure:
<maxb> lenny/
<maxb> lenny/foobar
<maxb> squeeze -> lenny
<maxb> And I call tt.trans_id_tree_path("squeeze/foobar"), and get the same trans_id as for "lenny/foobar" ..... is TreeTransform wrong?
 * maxb wonders why trans_id_tree_path ever wants to follow symlinks, actually
<hicham> does bzr have a git-format patch equivalent ?
<spiv> hicham: yes: a) bzr help merge-directive, or b) install bzr-git plugin, use --format=git IIRC
<hicham> thanks spiv
* maxb changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | UDD failures: 484
#bzr 2011-06-12
<Noldorin> what's the easirest way to upgrade bzr on windows?
<lifeless> Noldorin: run the newer installer AIUI
<lifeless> jelmer: ping (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574603)
<ubot5> Debian bug 574603 in python-testtools "testtools: Does not have a Vcs-Bzr header set" [Minor,Open]
<Noldorin> lifeless, AIUI?
<lifeless> Noldorin: As I Understand It
<Noldorin> lifeless, oh yes. this confirms what i thought...just install over the previous installation
<Noldorin> thanks.
<bpierre> hi
<maxb> hello
<bpierre> I'm fixing a bug in version-info (it does not handle dotted revnos)
<bpierre> now, the problem is with the python format, revision_id_to_dotted_revno returns a tupple, should I keep it as is?
<bpierre> or convert it to a string? or keep using a fixnum for simple revnos?
<bpierre> (to avoid changing the API for most use cases)
<maxb> Hmm. Interesting conundrum
<maxb> I don't think there's an obvious right answer here
<maxb> Worth posing the question on the mailing list, I think
<bpierre> yeah, thanks
<maxb> I could be convinced that either approach was plausible
<bpierre> I think keeping the tupple makes more sense, it's simpler, and the format you need to go back for example to a revision id when using the bzrlib API
<gour>  /set plugins.var.perl.buffers.color_hotlist_message lightred
<maxb> errr
<maxb> So apparently the maverick elilo branch has the tag 3.10-1ubuntu1 set on two different revisions simulataneously
<maxb> ?!
<maxb> or not, it's just stderr / stdout interleaving in a very odd way to mess with my mind
<visik7> hi
<visik7> I'm planning to use a  DVCS as a client for SVN I investigate over git-svn, but many says that it's unusable if you commit over a bit branch that is a clone of svn, this is because of some problem of git-svn, does bazaar address those issues ?
<visik7> things like rebase or merge in git-svn screw up the SVN repository
<visik7> commit without  git-svn-id doesn't know where to be placed
<thumper> visik7: AFAIK, bzr handles working with svn really well
<thumper> visik7: the person to ask for complete detail though is jelmer
<thumper> but there are probably many others that have used SVN with BZR a lot
<thumper> but I'm not one of them
<visik7> I would offer this solution for a supplier to avoid them to do slow integration phases
<visik7> but I need to investigate more
<visik7> or probably the best way is to tell them to publish their code and I merge in my local branch and then push into svn
<workthrick> hiya, I have a bound branch that somehow managed to diverge from the remote location, so now the (unintended) local commits are pending as merges
<workthrick> how can I flatten the history and rebase them onto the proper tip instead?
#bzr 2012-06-04
<indio> Hi. What to do when getting "maximum recursion depth exceeded in cmp" when running `bzr break-lock' ?
<indio> Hi. I hope I did not miss my answer.
<lifeless> you did not
<vila> indio: my first guess would be a cycle in branch references. What does 'bzr info -v' and 'bzr config' display when run in the directory where 'bzr break-lock' fails ?
<indio> Thanks.
#bzr 2012-06-05
<lduros> I have a dev branch and a trunk branch
<lduros> for some reason I did bzr pull ../trunk
<lduros> to the dev
<lduros> and now I'm on my trunk in the dev
<lduros> since it was checkout, the remote is just teh same
<lduros> how can I revert back
<mgrandi> i believe pull just pulls the revisions and sets the head, you might be able to set the head
<mgrandi> maybe 'bzr heads'?
<lduros> ?
<lduros> but there used to be 889 revisions to dev
<lduros> now it's the 539 from the trunk
<lduros> I'm lost
<lduros> haha
<lduros> most of the stuff in dev were merged in trunk thank god for that
<bob2> throw it away and reclone
<mgrandi> they are in the repository most likel;y
<lduros> bob2: but the remote is also 539 now
<bob2> so ypu pushed it?
<bob2> or did you unfortunately use a bound branch
<lduros> no but it was checked out
<lduros> or something
<lduros> yeh
<lduros> bound branch
<bob2> sadness
<lduros> so there's nothing to do?
<lduros> it just gets replaced like that in an instant
<lduros> seems pretty crazy to me
<mgrandi> there has to be a way to set the head
<lduros> took like half a second
<mgrandi> since all the revisions are there
<lduros> here is the dev: http://bzr.savannah.gnu.org/lh/librejs/dev/changes
<mgrandi> did you try bzr heads and see
<mgrandi> if it listed the dev one?
<lduros> here is the trunk: http://bzr.savannah.gnu.org/lh/librejs/trunk/changes
<lduros> bzr heads doesn't seem to exist
<lduros> unknown command heads
<bob2> it's easy
<lduros> it says
<mgrandi> says its in the bzrtools plugin for me
<bob2> repush the correct branch
<bob2> and heads is a plugin
<lduros> bob2: but I don't have the correct branch anymore
<bob2> get it then
<lduros> where?
<bob2> do you not know the old revision id?
<lduros> 889 I think
<mgrandi> the full revision id
<mgrandi> the one you get from testament i think
<lduros> from testament?
<lduros> I don't get it
<mgrandi> revision-id: markgrandi@gmail.com-20120602005836-b3b0uowcgjql8epb
<mgrandi> like that
<lduros> I use bzr but not in an advanced way
<lduros> how can I tell the revision id like that?
<bob2> it's definitely possible to recover
<bob2> maybe ask on the mailing list
<mgrandi> look in bzr.log
<bob2> ps bound branches are bad mmmkay
<lduros> haha
<mgrandi> when you commit
<lduros> well i'm learning that now
<mgrandi> it will tell you the revision id
<mgrandi> so look for when you commited revision 889 or whatever
<lduros> because it's pretty easy to do a pull ../trunk instead of merge ../trunk
<lduros> but that commit is gone
<lduros> since it's the other branch now
<lduros> dev is trunk
<lduros> no?
<mgrandi> its still in teh repositiory
<mgrandi> so you can recover it.
<lduros> oh yeh
<mgrandi> so search the log file for 889 or whatever it was
<lduros> ok
<mgrandi> and bound branches arn't that bad, although it does seem silly that a pull will automatically push to the remote branch
<lduros> if you look at the branch changes: http://bzr.savannah.gnu.org/lh/librejs/dev/changes/541?start_revid=541
<lduros> it's only those for trunk
<lduros> that are now in dev
<mgrandi> just search for the 889 string in bzr log
<mgrandi> see if you can get the revision-id
<lduros> ok
<lduros> like that right: bzr log | grep "889"
<lduros> I can't see anything
<mgrandi> try 'commited'
<mgrandi> did you commit the last revision on this computer?
<lduros> i don't think so
<lduros> ah well, I'll just give up I guess
<lduros> haha
<lduros> It's not the endo f the world, but it does suck
<lduros> what if you are in charge of a huge project :-)
<lduros> and that happens
<mgrandi> you can get it back
<mgrandi> the data is still there =P
<mgrandi> just gotta find that number
<mgrandi> or ask on the mailing list, maybe there is an easier way
<lduros> it's still even in the remote repo?
<mgrandi> yeah.
<mgrandi> i think this would happen in git / hg / whatever too =P
<lduros> hehe
<lduros> ok i'm writing to the mailing list
<fullermd> If pull didn't require --overwrite, then trunk _did_ have everything dev did.
<mgrandi> yeah. you just have to reset what is the 'head' revision
<fullermd> Right, I'm pointing at "<lduros> most of the stuff in dev were merged in trunk thank god for that"
<fullermd> It wasn't most, it was all, else the pull wouldn't have Just Worked.
<lduros> fullermd: really?
<lduros> it would have choked on it?
<fullermd> bzr: ERROR: These branches have diverged. Use the missing command to see how.
<fullermd> Unless you did a --overwrite or something, pull won't run if the remote isn't a superset of the local.
<fullermd> Or less stiltedly, if the pull will mean your local branch no longer has something it had before.
<lduros> ah ok
<lduros> so that's one good news
<lduros> I still posted that email on the mailing anyway
<lduros> just curious :-)
<lduros> but thanks it really makes me feel better now
<lduros> 541 seems less "important" than 889 though
<lduros> I thought I'd get to a 1000 commits all by myself and throw a party
<lduros> :-P
<mgrandi> heh
<fullermd> Oh, but it's more fun this way.  It means you can get to a thousand commits MULTIPLE times!
<lduros> haha
<fullermd> The real trick is spacing them out enough that you're in good enough shape for each party...
<lduros> it's funny how revision numbers really mean nothing in bzr
<mgrandi> they do
<mgrandi> just in the context of the branch
<lduros> well they do but only in a branch
<lduros> yeh
<mgrandi> if you do a qlog then you see that all the merged ones are like 400.1 - 400.100 etc
<lduros> it's a completely different take than git
<lduros> i like the revision numbers though, easier to remember
<lduros> that SHA1 hashes
<lduros> :-P
<mgrandi> its the same idea, kts just that bzr gives you numbers, yeah
<mgrandi> sha1 are the most unmemorable things ever
<fullermd> It does have its downsides.  It means when you compose a clever little jingle from the revno in the commit message, years later nobody will get the joke   :|
<lduros> hehe
<lduros> also I have to stop running rm -rf dev/
<lduros> everytime there's a problem maybe :-)
<lduros> better to do mv dev dev-bck
<lduros> haha
<fullermd> Well, doing it once or twice in / will cure you of that...
<lduros> hha
<lduros> everytime there's a problem I tend to run rm never think to run mv
<fullermd> Funnily enough, I needed to make a new FS for working on something last week.
<fullermd> Needed a name.  Well, it was just for development, so I can just call it /dev!
<fullermd> Hey, wait, why is bzr suddenly blowing up when I try to run it?
<fullermd> Hm, everything else is too.  What the he...   oh, no...
<lduros> hehe
<lduros> that reminds me I should make backups of my ssh and gpg keys
<lduros> haha
<fullermd> Anyway, back a little less off-topic.  Probably, the last thing on the dev branch was part of a recent merge to trunk, so if you look back through log (paying especial attention the merges), you may be able to spot it that way to restore if you want to.
<lduros> hmm
<lduros> so when you make a merge
<mgrandi> yeah, thats what i suggested, i think lduros did it on another computer so
<lduros> all of those revisions are kept
<lduros> those revisions from the other branch? they're not merge into one revisions in the new branch
<lduros> i guess i can't wrap my head around how things work
<lduros> yeh I do a lot of my gnu development during my work lunch break
<lduros> so some is probably at work
<lduros> I guess I'll keep working on trunk for the night
<mgrandi> they are kept in the repo, it doesn't delete any revision
<mgrandi> just creates new ones
<fullermd> Merge makes a new rev to connect the merged revs in, but they're all still there individually.
<lduros> ah
<lduros> Fixed! :-)
<lduros> I guess that's what you all were talking about: https://lists.ubuntu.com/archives/bazaar/2012q2/074860.html
<lduros> the reason I couldn't find revno 889
<lduros> is because it was 886
<lduros> haha
<fullermd> Well, we can hardly be held responsible for you running around with your monitor upside-down   :p
<lduros> heh
<bob2> ps unbind
<lduros> bob2: yes, definitely
<sbarcteam> hi.
<sbarcteam> I have revisions 121, 122, 123 the last revisions.
<sbarcteam> I want to remove changes introduced by 122
<sbarcteam> how do I do this ?
<sbarcteam> bzr revert -r-3..-2 ?
<sbarcteam> or bzr merge . -r-3..-2 ?
<matanya> why do I get : bzr dh-make hello-2.7 hello-2.7.tar.gz  bzr: ERROR: command 'dh-make' requires argument TARBALL
<bob2> bzr help dh-make
<matanya> than ks
<matanya> but how does that help?
<bob2> because then you'll know how to use it
<matanya> I use the right syntax, don't I?
<matanya> bob2: I didn't understand
<bob2> ok
<bob2> good luck
<matanya> ?
<matanya> anyone else?
<gthorslund> matanya: I've not used it, but looking at http://doc.bazaar.canonical.com/plugins/en/builddeb-plugin.html#dh-make it appears you're missing a VERSION string.
<matanya> 2.7
<gthorslund> so the name of your tar ball is used as version string instead.
<gthorslund> you've only got two strings as argument for dh-make
<gthorslund> 1) hello-2.7 2) hello-2.7.tar.gz
<matanya> so  bzr dh-make hello 2.7 hello-2.7.tar.gz
<gthorslund> #2 should have been #3
<gthorslund> guess that would be more right
<matanya> bzr: ERROR: Either run the command from an existing branch of upstream, or move hello-2.7 aside and a new branch will be created there.
<matanya> ok. rm hello-2.7 worked
<matanya> thanks
<gthorslund> you're welcome. good luck.
<Merwin_> hey
<Merwin_> I've got a question ! I use colo-switch to move between branch. The problem is that if I'm working on a new Python module, I always got a conflict because bzr does not remove *.pyc, *.pyo files from the new module's dir. So I got a "unable to remove directory : not empty" when switching back to my old branch.
<Merwin_> That's just really annoying, how can I fix that ?
<wgz> Merwin_: to resolve that conflict, just delete the directory and vestigal pyc files then do `bzr resolve dir`
<wgz> to avoid it in future there's a config setting that will move stuff like that to a seperate directory rather than causing conflicts
<wgz> which I'm failing to find the name of, vila will know.
<vila> bzr.transform.orphan_policy=move
<vila> in either bazaar.conf or your branch.conf
 * vila thinks we should 1) rename it to something more sensible, 2) turn it on by default
<vila> I think we'll get less reports for people searching for their orphans than we get for the spurious conflicts
<Lo-lan-do> Hi allÂ :-)
<Lo-lan-do> I'm wondering about checkouts (bound branches) and how a commit works there.
<Lo-lan-do> I know that the revision is half-committed locally, then pushed, then fully committed locally if the push succeeds and rolled back otherwise.
<Lo-lan-do> But my question is: could that push be turned into a dpush if, for instance, the remote branch were stored in a git repository?
<Lo-lan-do> This way we could keep a normal workflow of simply committing and not worrying :-)
<Merwin_> wgz, vila bzr resolve --action=take-other should work fine ?
<Merwin_> Yeah but anyway, I'll still have the conflict :x
<Merwin_> I'll try the bzr.transform.orphan_policy
<vila> Merwin_: yeah, the idea it to *avoid* the conflict
<Merwin_> yep :D
<abentley> vila: Is there any way to use a colocated branch's name in a config, the way I can use appendpath to add a branch's location?
<vila> abentley: I'm not sure I understand what you call a colocated branch's name
<vila> appendpath was only usable in locations.conf
<abentley> vila: the part that comes after the = in "file:///foo/bar,branch=name"
<abentley> vila: I would be fine with a solution that was  only usable in locations.conf.
<vila> abentley: there are 'relpath' and 'basename' that replace what appendpath was providing but it's still unclear to me on how you would specify a section for a colocated branch (or if it will work)
<abentley> vila: I don't want to specify a section for the colocated branch, just the container.  e.g. "[/foo/bar]" for the previous example.
<abentley> vila: Say I have project bar, and I'm using colocated branches, and I want to push them to Launchpad without having to specify the push location.
<vila> abentley: each colocated branch into its own launchpad branch ?
<abentley> vila: Yes.
<vila> well, I don't think push supports that :-/
<vila> and I never looked at how config behaves for colocated branches to be honest
<vila> does launchpad authorizes the additionnal paths used for colo branches ?
<abentley> vila: Sure push supports that.  It's not a colocated branch on Launchpad, just a regular branch.
<abentley> vila: I'm doing it manually all the time.
<vila> That's not what I meant by supporting the additional paths used by colo branches :)
<abentley> vila: I doubt launchpad authorizes the additional paths used by colo branches.  Since launchpad wouldn't recongnize colo branches if it did, that's for the best.
<converge> I created a local branch and commited my code, how can I push it to remote branch ?
<converge> I created a local branch and commited my code, how can I push it to remote branch ?
#bzr 2012-06-06
<littlegirl> Hey there, I'm using svn2bzr from http://wiki.bazaar.canonical.com/svn2bzr and I'm getting deprecation warnings for sha and md5. Do I need to fix them before I can do the conversions or can I ignore them?
<littlegirl> These are the warnings I'm seeing: http://paste.ubuntu.com/1026196/
<spiv> littlegirl: you can ignore them
<littlegirl> spiv: Will the resulting branches be accurate despite them?
<spiv> Yes
<littlegirl> spiv: Oh, thank you so much! I've just spent the past day or two researching Bazaar and comparing it to Subversion, which is what I've been using, and it sounds like a major improvement, so I look forward to switching. (:
<spiv> It's just a warning saying that "from md5 import md5" should be updated to "from hashlib import md5" in the code at some point, because the old module is going away Python 3 or something
<spiv> The functionality is unaffected
<littlegirl> As long as you understand it, it's all good. (:
<spiv> You might find the bzr-svn plugin to be a nicer way to connect bzr and svn
<littlegirl> I'm using the command line. Does it work in there?
<spiv> Yes.  It allows bzr to interact with svn:// URLs etc more-or-less as if they were bzr branche.
<spiv> *branches.
<spiv> (Including pushing back to svn)
<littlegirl> I've got one project that I contribute to thjat uses Subversion, and I'll just leave my Subversion branch for that project as is. I would like to convert all my personal repositories to Bazaar, though. (:
<spiv> In particular, it means that importing your SVN branch to bzr is typically just "bzr branch SVN_URL my_shiny_new_bzr_branch"
<spiv> And it's a repeatable, deterministic import, which IIRC isn't true of svn2bzr
<littlegirl> Oh! Is it in the Ubuntu package manager?
<spiv> (i.e. two independently generates conversions with bzr-svn will be identical with the same revision-ids etcc)
<spiv> Yes, just install the 'bzr-svn' package.
<littlegirl> Absolutely perfect! So I can do bzr branch svn_url new_bzr_url on all of them and not even bother with the svn2bzr?
<littlegirl> I'd like to preserve the entire commit history to date.
<mgz> morning!
<mgrandi> means i should be in bed
<mgz> night mgrandi :)
<mgrandi> not yet =P
 * fullermd lumps off to bed...
#bzr 2012-06-07
<mgz> morning
<vila> mgz: \o
<mgz> hey vila
#bzr 2012-06-08
<knielsen> Hi, how can I check if some revision revid:xxx is included in my branch? I used to do `bzr log -rrevid:xxx` and it would fail with internal error if revision was not present. Now (2.6.0dev2) it seems to just pull out the version from my shared repo, even if the revision is not part of the current branch?
<knielsen> Well, I can do: `bzr branch -rrevid:xxx --no-tree mybranch tmp; cd tmp; bzr missing --line --mine-only ../mybranch` - it will be empty if revision is included in mybranch. But I was looking for something a bit more convenient?
<vila> knielsen: 'bzr log -rrevid:xxx..' note the final '..'
<knielsen> ah
<vila> or something along those lines, there was a bug about that with more details
<knielsen> vila: seems to work fine, thanks!
<vila> cool
<vila> knielsen: you may want to add a '-l1' so you don't get flood when the revision is present
<knielsen> right
<jelmer> 'morning mgz, vila, jam
<jam> morning jelmer
<vila> jelmer: \o
<mgz> morning
<vila> hi mgz
 * jelmer waves to mgz
<awilkins> I have some suggestions for the mergetools support ; re: adding some extra substitutions
<mgz> hm, git diff and bzr diff with bzr-git should have the same actual changes right?
<mgz> `bzr st` is right but diff is stuck in the past
<jelmer> mgz: yeah, working tree support in bzr-git is incomplete
<mgz> ah, okay, thanks.
<mgz> 50 characters or less is punishing.
<jelmer> mgz: 50 characters or less of what ? :)
<mgz> git thinks I should be able to write a summary of any change in that.
<mgz> "rote sum coad"
<mgz> anyway, done with that little distraction now and sent for review.
<Mook_as> when doing bzr push, can I push only a subset of tags defined? (instead of pushing all tags in the branch)
<jelmer> Mook_as: at the moment, no
<Mook_as> alright, thanks!
#bzr 2012-06-09
<Corey> Hmm.  I have a checked out bazaar repo; how do I figure out what the upstream / origin / remote repo is?
<fullermd> Check info.
<lifeless> Corey: 'bzr info'
<Corey> Thanks.
<Corey> Much appreciated.
<LeoNerd> If I have say, -r1 to -r100 on my trunk, then a branch adds a few more; then I make one more commit on the trunk, -r101 and replay that into the branch - Will a later rebase on the branch be able to cope with this, or will it get upset?
<LeoNerd> I'm not sure I want to do the entire rebase operation -every- time I write a tiny oneline bugfix on trunk
<gour> hello, curious what's new in bzr world...found the following http://stackoverflow.com/questions/8973636/what-problems-can-be-expected-with-bazaar-2-x-vcs where is says: "As of January 2012 you may observe the following restrictions...With bzr you'll be forced to use mainline concept of the history. I.e. the left-hand parent of the revision is special and forms mainline of your history, while your merged
<gour> revisions make merged history. " is it really something new 'cause i believe it was present in bzr for quite some time, if not even from the beginning (by design) ?
<LeoNerd> Pretty sure that's always been the case
<LeoNerd> The lefthand parent is the one that is chosen as "canonical", for such purposes as numbering revisions
<LeoNerd> So if -r100 is a merge revision, we know which one is -r99 vs which is the various parts of 100.1, 100.2, etc..
<gour>  LeoNerd: yeah, i've the same opinion...but wonder why experienced bzr user says: "as of jan 2012..:"
<gour> has something changed in regard to th points mentioned in http://zakalwe.fi/~shd/articles/why_not_bazaar.html ?
<gour> e.g. 2.1?
<gour> bzr docs (http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html#rename-tracking-and-smart-merging) says: "Rename Tracking and Smart Merging" while http://zakalwe.fi/~shd/articles/why_not_bazaar.html says "Bazaar's Merge Algorithm Is Incomplete" what is true today?
<littlegirl> Hey there, I noticed an error in the Bazaar 2.6.0 User Guide. Is this a good place to mention it?
<littlegirl> In the event that it is, the guide mentions the use of bzr add and bzr remove when it should be bzr add and bzr revert. An example is here: http://paste.kde.org/496202/
<littlegirl> Scratch that. I just did bzr version and I'm not even using 2.6.0, so for all I know it works. (:
<gour> bzr-git fails on github repo with "AttributeError: 'RemoteGitRepository' object has no attribute '_transport'" ?
<gour> ahh..false alarm...i had some obsolete version of the plugin in ~/.bazaar
<jelmer> gour: that has never been true
<jelmer> gour: that article is very ignorant
<jelmer> gour: bazaar has supported merging trees without common ancestors since its early days
<gour>  jelmer:hmmm...it would be good to have some "counter-article" refuting that one...btw, congrats for bzr-git...i did import some repos today and it is quite speedy ;)
<gour> jelmer: what about this info: "As of January 2012 you may observe the following restrictions..." (1st answer http://stackoverflow.com/questions/8973636/what-problems-can-be-expected-with-bazaar-2-x-vcs) ?
<jelmer> gour: You're welcome to write a counter-article; I'm not sure if responding to all the nonsense on the internet is particularly useful...
<jelmer> gour: those 3 restrictions are still present
<gour> jelmer: excuse me...we had power outage here
<gour> jelmer: but that's not something new
<jelmer> 22:33 < jelmer> gour: You're welcome to write a counter-article; I'm not sure if responding to all the  nonsense on the internet is particularly useful...
<jelmer> 22:36 < jelmer> gour: those 3 restrictions are still present
<gour> :-)
<lifeless> jelmer: gour: http://xkcd.com/386/
<gour> lol
<jelmer> lifeless: :)
<gour> is there some roadmap for bzr after 2.6?
#bzr 2012-06-10
<gour> morning
<gour> we're considering to adopt bzr instead of hg, but like bitbucket's free repos (although we don't need much space) and considering that, afaik, bzr-git is more mature than bzr-hg, we wonder what would we miss of bzr's metadata if using bzr-bzr-git @bitbucket?
<jelmer> gour: hi
<gour> jelmer: hiya
<jelmer> gour: bzr-git pushing into git is still experimental fwiw, there are some known corner case bugs
<jelmer> gour: you'd miss text revision information (used during merge), support for ghosts (data referenced but missing), multiple author support, support for revision properties (--fixes, etc)
<gour> jelmer: hmm...this is expensive
<gour> i think about adopting bzr considering it's even simpler/safer for potential contributors than hg (we don't consider git)...another option might be fossil...
<gour> jelmer: any estimation when bzr-git might be good-enough (if nto already) for collaboration with git projects?
<gour> i also wonder how does bzr-git compare with hg-git? does it offer better collaboration tool with git projects?
<jelmer> gour: I'm not sure; nobody is actively fixing those issues in bzr-git at the moment.
<gour> jelmer: you're the only developer?
<jelmer> gour: These days I'm just using git itself for projects that I work on that are in git.
<gour> jelmer: ahh, i see...i consider life is too short to think about git :-)
<jelmer> gour: I'm not sure how it compares to hg-git; the way in which hg-git hooks into mercurial seems a lot more hackish, but it might work a lot better in practice.
<jelmer> bzr-git's support for importing from git repositories works really well btw, it's mostly pushing from bzr into git for which there are some known issues
<gour> what is the future of bzr-hg then? even less bright?
<gour> ..in any case, it seems it's better to stick (if we decide so) to use bzr & LP despite LP's lack pf private repos and use hg/bitbucket when we need it...LP's bugtracker is, imho, much better than bb/github
<gour> pipeline is bzr's 'equivalent' for hg's MQ?
<jelmer> gour: I'm doing occasional bug fixing to bzr-git; I haven't used or contributed to bzr-hg in a long time, also because none of the projects I'm involved in use it anymore.
* jelmer changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/
<jelmer> gour: bzr-pipeline and bzr-loom are equivalents to MQ I think (have never used MQ)
<gour> jelmer: ok. thank you
<gour> i believe bzr-git & bzr-hg could be useful in general as a mean to stay with bzr & work with git & hg projects isntead of always switching between different VCS-es
<gour> otoh, it's shocking to see that github is populated with so many projects...
<jelmer> gour: sure, I agree that's why they're useful as well; and one of the reasons I work on bzr-git
<jelmer> gour: there's just 24 hours in a day though ;)
<gour> jelmer: you're not workin for canonical?
<jelmer> gour: I am, but most of my contributions to bzr-git and bzr-hg I did before I joined
<gour> jelmer: well, i like to hear that...it means there is future for bzr ;)
<gour> congrats; btw ;)
<evillyEvil> I accidentally pushed my branch to a wrong location (that is, suppose it should be pushed to A, but I pushed it to B). Is there anyway to remove the change from B?
<lifeless> evillyEvil: bzr uncommit B
<evillyEvil> lifeless: That will revert the latest changes in B?
<evillyEvil> What if I've added multiple revisions before accidentally pushing the branch to B? How do I specifically say what revisions I want uncommit?
<lifeless> you can pass -r -2, for instance
<lifeless> or just run it multiple times
<evillyEvil> I see. Thanks for the tip
<gour>     i'm looking to return back from hg to bzr and wonder whether looms or pipeline is closer to hg's MQ?
<lifeless> pipeline
<lifeless> loom versions the queue, and its evolution, which is substantial added complexity, something MQ doesn't do.
<gour> thanks...let me read about it
#bzr 2013-06-03
<hypnocat> i'm hearing in some other channels that "bzr is not maintained"
<hypnocat> is this true?  if so, is there somewhere i can read about the reasons for this?
<hypnocat> now the person who told me this is backpeddaling
<spiv> hypnocat: it's maintained, but not actively developed.
<hypnocat> why not?
<spiv> hypnocat: the mailing list archives from the last few months are probably the best place to read about it
<hypnocat> thanks
<spiv> (and see just how much the volume of discussion has dropped offâ¦)
<fullermd> Volume of discussion?  I think I remember having that...
<jelmer> fullermd: oh, you're one of those loud people, are you?
<kZard> hi. I'm having a problem with Bazaar in windows. I can't find any reference to the problem on the internet
<kZard> running bzr from whithin a repo directory, I get the following:
<kZard> bzr: ERROR: Not a branch: "C:/Program Files (x86)/Bazaar/".
<kZard> (note that the period is part of the result I get)
<kZard> so it seems to pass the installation directory of bazaar before passing the '.'  (or something like that)
<kZard> okay, well, in case anybody is interested, I seem to have fixed it by removing "C:/Program Files (x86)/Bazaar/" from the PATH variable, and making a new shortcut with an empty "start in" field, putting that in a directory that is already in PATH
<kZard> seems to work :)
<adamsonj> Hello
<adamsonj> I tried to pull a specific revision from another branch and ended up pulling all the changes, i.e. switching to that other branch
<adamsonj> Can I undo this?
<adamsonj> command I used: bzr pull -r1406 ../revtex/
<adamsonj> this put me on revision 1406 of the other branch, and now I have its history in the current directory
<adamsonj> I have reverted to the merged branch and gotten back the original branch nick, but I still have the history of the other (undesired) branch
<adamsonj> I wanted to keep the branches parallel and make certain changes to one and pull some to the other branch but not others
<adamsonj> now they're totally mixed up
<adamsonj>  I don't want to push changes in branch X to the parent of branch Y
<bob2> do you mean "I want to cherrypick"
#bzr 2013-06-04
<adamsonj> good mornin'
<LarstiQ> adamsonj: good evening
<adamsonj> LarstiQ: Good afternoon ;)
<LarstiQ> adamsonj: that would place you somewhere in the americas? ;)
<adamsonj>  #latex
<jonathanj> hello!
<jonathanj> i'd like to do something but i'm not sure what the name for it is, which is making it hard to search for
<jonathanj> i have feature branch A that was merged into trunk, other feature branches were merged afterwards, later it was decided that feature A needed to be reverted, so i committed a reverse merge for feature branch X to trunk. now the time has come to merge feature branch X back into trunk, but obviously if i simply try to merge the branch bzr tells me there is nothing to do
<jonathanj> (oh whoops, i mean feature branch X not A at the beginning)
<thumper> abentley: how to I make a working tree match a particular revno?
<thumper> I'm trying to work out which commit introduced a problem
<abentley> thumper: bzr revert -r $revno
<thumper> ta
<lifeless> thumper: you might like bisect too
<thumper> hi lifeless
<thumper> it is only a choice of 3 commits
<thumper> so not too bad
<lifeless> o/ thumper
#bzr 2013-06-05
<awilkins> Traitorius question : how to do looms in Git ?
<awilkins> :-)
<jelmer_> topgit?
 * awilkins looks at topgit
<^Mike> I'm trying to get a checkout of the mysql-server repo on launchapd, but I keep getting this access denied error: http://p.hashbang.ca/ez I guess it is using SSH transport, which I'm not allowed to do. How do I make it use some other (unauthenticated) transport?
<jelmer> ^Mike: unset the launchpad user setting in your bzr config
<^Mike> How do I do that? I expected ~/.bzrconfig to exist, but no :(
<lifeless> ^Mike: it only uses SSH if you have told it to.
<lifeless> ^Mike: e.g. by using lp-login. What do you mean by 'you are not allowed to do' ?
<^Mike> I mean SSH is saying access is denied.
<^Mike> Like I showed previously.
<lifeless> that doesn't mean you cannot use SSH, it means your SSH setup is incorrect
<lifeless> have you changed SSH keys recently, or not added the key you have registered in launchpad to your local agent?
<^Mike> I didn't say "cannot use" I said "access denied"
<^Mike> wtf, why does launchpad have an ssh key for me at all O_O
<lifeless> You said "which I'm not allowed to do" actually. Which is why I asked you what you meant.
<lifeless> I have to go, a meeting is starting. I strongly suggest you get ssh working, as branching mysql is massively faster via ssh.
<lifeless> massively.
<^Mike> I've given launchpad a current ssh key, and it's cloning or whatever you call it in bizarre
#bzr 2013-06-06
<ovnicraft_> hello i want to debug bzr, so i get this error https://gist.github.com/ovnicraft/5717722, i read about it and it was caused by delete a file and i want to debug to identify what file_id
<ovnicraft_> i activate BZR_PDB
<ovnicraft_> i get postmortem but i don know what var use
<ovnicraft_> i found this https://bugs.launchpad.net/bzr/+bug/1179527
<ubot5> Launchpad bug 1179527 in Bazaar "bzr: ERROR: No final name for trans_id 'new-26'" [Undecided,New]
<ovnicraft_> there are many old bugs
<ovnicraft_> and this http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/74886
<ovnicraft_> looks like unversioned files cause the problem
<ovnicraft_> i this post http://old.nabble.com/Error-during-merge%3A-No-final-name-for-trans_id-'new-70'-td34444552.html he use pdb to identify trans_id refer
<ovnicraft_> but dont describe how to use pdb in bzr postmortem
<jelmer> ovnicraft_: set BZR_PDB=1 in the environment
<jelmer> and you'll be dropped into pdb when an error occurs
<ovnicraft_> jelmer: yes i got pdb
<ovnicraft_> jelmer: so i want to know how to identify trans_id
<ovnicraft_> i dont know bzr code
<ovnicraft_> jelmer: i am here https://gist.github.com/ovnicraft/5722285
<jelmer> ah, that's a more complex question - I don't have time to help with that atm unfortunately
<ovnicraft_> so first Q: i am in right channel ?
<jelmer> yes
<ovnicraft_> jelmer: there is any dirty solution ?
<mgz> ovnicraft_: broadly speaking, you want to use 'u' and 'l' till you find something pathy
<mgz> I'm not sure if this is the shortest path (ho ho) to finding out what the issue with your tree state though
<mgz> running a diff between the branches prior to merge (if that's what's failing? you weren't explict) may be easier
<ovnicraft_> mgz: i am running the diff now
<barry> hey folks, perhaps mgz, jam, or abentley: have any of you seen crashes in bzr on saucy, e.g. doing `bzr info`?  i think the svn plugin may be broken as it's trying to import CommittedQueue from subvertpy.wc
<jelmer> barry: yes, there is a bug
<jelmer> barry: bzr-svn has been removed from saucy
<jelmer> pad.lv/1187840
<barry> jelmer: thanks, i shall purge it from my existence then :)
<barry> jelmer: got it, thanks
<mgz> hm, how hard is that sru with the dep to do I wonder...
<thumper> morning
<jelmer> hey thumper, how's life in juju land?
<thumper> hi jelmer
<thumper> interesting
<jelmer> mgz: it should be a one line change
<thumper> just like python, there is the "go way" of doing things
<thumper> which often rubs with me ATM
<jelmer> thumper: ah, you're working on Go juju ? is that version 2.0?
<thumper> jelmer: well, 1.11.x right now, but yes, heading to 2.0
<thumper> I wanted to get back into a dev role, and also learn go
<thumper> I hadn't learnt a new language in a while
<jelmer> thumper: what do you think of go, any improvement over C++?
<thumper> jelmer: well, that depends...
<thumper> C++ is horribly complicated, but powerful in the right hands
<thumper> Go is much simpler, but is missing a lot of what I'm used to
<thumper> like generics
<thumper> I'd say 90% of C++ devs write bad code
<thumper> just due to language complexity
<thumper> go reduces that number somewhat
<thumper> I've not done any real benchmark tests
<thumper> but go does provide some nice library stuff that C++ is missing
<thumper> around network and general process control
<thumper> I guess it depends a lot on what you are writing :)
<jelmer> yeah, the complexity in C++ is my main gripe with it
<jelmer> I'm not sure what to think of go yet. The exception handling/return value stuff seems kind of arbitrary but some of the other features, like - as you mention - the libraries and goroutines are really nice
 * thumper nods
<thumper> I love the power of C++
<thumper> but it is too easy for people to get things wrong
<thumper> I have heard that D is better
<thumper> but never used it
<LeoNerd> goros are just CSP. "yaaay". That's been around since like, 1970
<LeoNerd> mvreturn is cute, but eh.. Perl and most Lisps have those
<LeoNerd> Python too come to think of it
<LeoNerd> Sortof ish
#bzr 2013-06-07
<sil2100> Hi everyone!
<sil2100> I have a question related to bzr bd
<sil2100> I am using bzr bd --split -S to build a source package from a branch, which should also generate the .orig file
<sil2100> How can I force the inclusion of the generated .orig file in the upload?
<sil2100> Scratch that
<morsicus> Hi all, I have a problem with 'bzr push' I cannot transfert any files. I'm blocked here :      2kB     0kB/s \ Fetching revisions:Inserting stream:Estimate 1715/254
<morsicus> Do you have any suggestion ?
<mgz> morsicus: pushing over what protocol? you probably want to enable some debug options `bzr help debug-flags` then look at your .bzr.log `bzr version` tells you where that is
#bzr 2013-06-08
<ale`> hi, how can I get my working tree status? I would like to know which revision I checked out.
<lifeless> bzr revision-info
<ale`> thanks!
#bzr 2014-06-02
<mgrandi> I've noticed on windows, that using pythonw.exe with plink seems to make bzr freak out
#bzr 2014-06-04
<LeoNerd> Any way to make  bzr shelve   diff chunks smaller? It's merged two of my changes in one
<LeoNerd> I'm aware of 'e' but I can't ever make that work without having two layers of merge conflict markers when I unshelve it again
<LeoNerd> (alternatively: someone could tell me how to do that)
<LeoNerd> .. anyone? :)
#bzr 2014-06-05
<mgrandi> so, I have a script that basically runs a commit on a repo i have every day
<mgrandi> but I want to have it running in pythonw.exe so i don't see the command line window when it starts, however when that happens, python seems to exit abnormally
<mgrandi> Task Scheduler successfully completed task "\Backup tomboy" , instance "{252792fc-7fe8-4f38-a6d5-6538e81fe375}" , action "C:\Python27\pythonw.exe" with return code 2147942401.
<mgrandi> its also related to me having a bound branch that its trying to push to through ssh (plink in this case)
<mgrandi> any idea? =(
#bzr 2015-06-04
<grepper> This is probably offtopic, but can I ask a quilt question here? I mistakenly used 'quilt add <patch>' instead of 'new' and quilt added it the top patch. How can I undo that?
<grepper> ah, quilt remove <patch>, duh
#bzr 2015-06-05
<grepper> I can't count how many times I've got The program 'bar' is currently not installed ... I think I'll have to do alias bazaar=bzr  :P Probably alias bar=bzr is a bad idea ...
<fullermd> You've got it backward then.  I can't type 'bar' anymore without going back and correcting it twice (just had to there).
<grepper> hehe
<grepper> probably because I'm new to bzr and have been overusing 'bar' for 14 years
<LeoNerd> Anyone know if there's a fixed-constant URL I can use to point at the "latest" revision of a branch on LP?
<LeoNerd> I can get as far as  http://bazaar.launchpad.net/~leonerd/pangoterm/trunk/files  but then the "view revision" embeds the revno in it
<LeoNerd> Ideally I'd like to have a statically-fixed URL that points directly at the "download tarball" location
#bzr 2016-06-06
<erry> Hi
<erry> I accidentally committed into thhe wrong branch
<erry> how can  i undo it before i get fired?
<LeoNerd> uncommit ?
<erry> i don't want to make it any worse D:
<Peng> "bzr uncommit" removes the most recent commit(s) from a branch, but it doesn't expunge the data from the repository, so you're still in trouble if this was the nuclear launch codes.
<erry> it's ok, i got a colleague to do it
<erry> (RIP erry'#s career, 2016-05-27 - 2016-06-06 :()
<Peng> RIP humanity, if you launched the nuclear weapons
<fullermd> To launch the nukes?  Man, I need more fun coworkers.
<grewalkamal> Hi I am new to bzr. I am working on a project to which I do not have direct push access. I created my own development branch to work upon. Now when I pull the changes from the main trunk branch, the revision id there is say 101. And I did my last commit at revision 90. Now pulling the changes upto revision id 101, when I merge the trunk to my branch and push the changes, the revision id I get for my branch is 90 instead of 102.
<grewalkamal> *revision id I get for my brnach is 91
<grewalkamal> Will the revision ids synchronize once my changes are merged in the repo?
<fullermd> The question isn't really meaningful.  revids are a branch-local construct; there's nothing to synchronize.
<grewalkamal> Okay
<grewalkamal> Being a newbie, I considered my branch revision id will be same after I merge changes from the upstream.
<grewalkamal> Same with revision id of trunk.
<fullermd> Mmph.  Sorry, I got lead into fuzzy expression.
<fullermd> The revision _id_ is; that's nailed to the revision and stays with it forever.  The revision _number_ isn't, that's potentially going to differ depending on what branch it's in.
<grewalkamal> Yh now it looks like fuzzy to me too. Well the difference is anyhow clear.
<grewalkamal> Thanks.
<fullermd> http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/RevNumbering  may help a little
<grewalkamal> Helped. :-)
<fullermd> So, "90" could mean pretty much any commit anybody ever made on any project anywhere.  But "foo@bar.com-2016060612345678..." will always refer to exactly one revision.
<fullermd> It's just a giant PITA to type or tell someone or remember.  Hence, the number, which works OK as long as you're both talking about the same branch.
<grewalkamal> Yep. These numbers are local to branches I believe now.
<grewalkamal> Thank you once again fullermd
<fullermd> 's what I here for   :)
<fullermd> I mean, that, and smartass comments.  But I need another cup of coffee before I'm in top form for that, so...
<grewalkamal> :-)
#bzr 2016-06-08
<faenil> good morning
<faenil> is there a way, in Bazaar, to get the ID of the "next" revision? (I can ignore the timestamp)
<fullermd> "next" in what sense?  As in child of a particular rev?
<faenil> usecase: I want to create a commit which has some code changes, + a benchmark file with the results produced by that change, and I want to name the benchmark file with the ID of the WIP revision, so that I can see that ID_A becnhmark file was obtained with changes coming from ID_A revision, although before comming ID_A does not exist yet
<fullermd> Not necessarily a unique answer to that.  There's certainly no UI for it...
<faenil> no ui needed :)
<fullermd> Oh.  Not unless you specify it.
<faenil> as in?
<fullermd> I mean, when you _create_ a rev, you can assign it an arbitrary ID.  If you take sufficient precautions for the level of uniqueness you care about, you could just choose them yourself.
<fullermd> (pretty sure there's also no UI for that, but it's certainly possible at the API level)
<fullermd> e.g., the way a lot of the foreign VCS converters do.
<faenil> fullermd: I'd rather trust the generator, I just need to get the same ID that bzr commit will get
<fullermd> From here, it seems like a lot of trouble and hackery for a pretty marginal case in this particular case, but...
<fullermd> Yeah, no way you can pull that off.  bzr won't have any idea what it'll be until it gets there.
<faenil> fullermd: mm ok...why though? how is the ID computed?
<fullermd> Well, part of it is random, so...
<faenil> fullermd: so I guess it uses the current time of the commit as a seed
<fullermd> I don't think bzr explicitly seeds it.  I think it's just the standard python PRNG, which may autoseed with the current time...
<faenil> ok
<fullermd> 'd have to look at the code to be sure.  But it would be an incredibly hacky and fragile construct trying to predict no matter what.  So, I really don't think there's any way you can get there short of generating and choosing revids yourself.
<faenil> I've got to find another way to choose a filename so that it is somehow linked to the commit that is going to be created
<fullermd> You could just 2-step it.
<faenil> as in?
<fullermd> Make a random name, commit it, then rename it to the revid you now know.
<faenil> ah well, sure
<faenil> I'll think about it some more, thanks anyway ;)
<fullermd> You wind up with extra revs, but that's probably not a huge deal.
#bzr 2016-06-11
<nopf> hey peoples. what is the state with the "no kex" problem of the prepackaged windows version? i cannot connect to my servers (bzr+ssh), whereas the newer versions on linux work there
<nopf> when trying to install newer versions via 'pip', it complains about some vcvars file and generally it seemsa pita. do i need vs installed on each system where i want to bzr?
<nopf> (prepackaged windows version "of bzr-explorer" that is...)
<nopf> (or is this called bzr only?)
<GyrosGeier> is there a way to tell merge to overwrite any files in the working tree that are in the way?
