#bzr 2008-08-11
<beuno> lifeless, http://ftp-master.debian.org/new/bzr-search_1.6.0~bzr49-1.html
<Leefmc> If i ignore a folder, it will ignore the contents aswell, correct?
<beuno> Leefmc, yeap
<Leefmc> k, thanks
<poolie> hello beuno,
<poolie> spiv, ping?
<spiv> poolie: hi, doing a standup with lifeless atm
<poolie> np
<beuno> poolie, mornin'
<mwhudson> hi poolie
<LeoNerd> 'bzr branches' seems to eat up massive amounts of RAM on my system....
<LeoNerd> I've caught it eating 45% of 512MiB. I killed firefox by mistake thinking it was that
<tacone> poor firefox :(
<lifeless> poolie: hi
<lifeless> poolie: we started at 9 :)
 * spiv grabs some breakfast
<poolie> :-P
<lifeless> poolie: I'd like to chat with you about .bzrrules in 1.6
<lifeless> poolie: I think this is an urgent-to-have chat because 1.6 is looming
<lifeless> also
<lifeless> http://abstrusegoose.com
<poolie> lifeless, sure
<lifeless> should I ring?
<lifeless> or irc or ...
<poolie> wait a bit
<lifeless> ok :)
<poolie> lifeless, just doing a brief mail pass, then will be with you
<poolie> lifeless, now?
<poolie> here, or phone?
<lifeless> phones easier
<markh> less fun for us though ;)
<spiv> markh: just because you can't hear them doesn't mean you can't heckle ;)
<markh> :)
<poolie> abentley, BB seems to be down
<abentley> poolie: BB's Back up
<lifeless> markh: maybe less fun, but a lot quicker
<lifeless> markh: your question last night ...
<markh> yah...
<lifeless> markh: try merge --lca
<lifeless> or --reprocess
<markh> ok, thanks - I'll try that next time I merge.  I think its a matter of getting into the mindset and understanding what is really going on
<markh> my mind makes certain assumptions about the models, then struggles to fit reality with that flawed model :)
<markh> oh - roght - wrong question :)  You are referring to the conflict markers question
<markh> what does "reprocess" do? - help isn't very illuminating...
<markh> and if it magically prevents spurious conflicts, why isn't it the default? ;)
<lifeless> it reduces the region of a conflict
<lifeless> our conflicts are often better than difflib would create
<lifeless> but it keys on unique lines; and in some files that can make things worse rather than better
<lifeless> its a 3-way merge of base, other, this, with common regions determined by doing patience-sorting on unique lines then expanding out from there along common lines
<lifeless> this is a bit strange to think about at first - but important: repeated lines are never the reason for a common region to be identified; they are found by being adjacent to a common unique line
<markh> right - interesting.
<markh> is there any scope for detecting conflicts and attempting different strategies to come up with the smallest amount of conflicting text?
<lifeless> sure, though that may not be the most useful thing for the user :)
<markh> no - so the merge options would allow that control.  But in the general case, I'd say giving the smaller the conflicts, the happier the user :)
<markh> spiv: should I add a patch for the docstring to that bundle even though it isn't directly related to making a test pass?  Or a separate one bundle?
<markh> s/one bundle/bundle/
<spiv> markh: which ever you prefer, I don't mind.
<markh> same bundle is easier :)
<spiv> I thought that might be the case :)
<markh> spiv: to save email ping-pong: at the end of the first para in the docstring body (ie, line 6) of transport.local.abs_path, I'm appending "The returned path will always contain forward slashes as the path separator, regardless of the platform."  Sound OK?
<markh> oopa - local_abspath
<markh> *sigh* - transport.local.local_abspath
<lifeless> I don't really see why thats needed; we do that *everywhere*
<lifeless> I mean, perhaps there is some other doco that should be made stronger rather than playing whack-a-mole with developer confusion?
<spiv> lifeless: well, I guess perhaps I was reading too much into that docstring's mention of realpath
<markh> the "abspath" in the name mislead Andrew and me
<markh> and that :)
<lifeless> vs \ is orthogonal to "/" and "C:"
<markh> the "local" kinda implied "native" too
<spiv> I'd be equally happy with the docstring emphasising that it's an internal path rather than specifically the \ vs. / issue.
<markh> and the author of the test seemed to assume native seps too
<spiv> markh: right
<lifeless> I just want to ensure we've covered enough bases that in 2 weeks we don't get another such patch for transport.other_foo
<lifeless> given that *everywhere* except _perhaps_ display functions we use /
<spiv> lifeless: I'm open to alternative suggestions for avoiding the confusion that happened here.  (Including "it's good enough as is" if you think so)
<markh> the patch wasn't to change the transport - the intent of the tests wasn't clear
<lifeless> its clearly not good enough; markh got confused
<markh> well - to be fair, I assumed the test author knew what they were testing ;)
<lifeless> so if you guys think the specific function is all that needs tweaking, I'm +1
<markh> the test used realpath, and the function name implied "realpath", and the docstring *said* realpath :)
<lifeless> but please do consider checking we have some overall statement (perhaps in the HACKING-collection) about / vs \
<spiv> lifeless: well, this is the only Transport method with a "local_" prefix, so I think there's a good chance that it's just this method.
<spiv> e.g. Transport.abspath already clearly returns a URL, so we don't have this confusion there.
<spiv> There's a "Filenames vs URLs" section in HACKING, but it doesn't seem to address this point.
<markh> OK, I'll mail a bundle with the doc change I mentioned, and leave the HACKING doc change to another day when I'm *supposed* to be working on bzr ;)
<spiv> Ok.  I'll whip up a quick addition to HACKING after lunch.
<lifeless> spiv: YHBTHANDHTH (re monkey patching)
<spiv> lifeless: I know :)
<spiv> lifeless: but it *is* tempting, regardless :)
<lifeless> could do one that checks the stack
<spiv> (The problem with making silly suggestions is occasionally people implement them!)
<spiv> lifeless: That's less tempting :P
<spiv> Lunch is more tempting.
<markh> the ".replace("/", os.path.sep)" change in the tests is pushing those lines to 90 chars.  I see a couple of others in that file at 89 ;)  Should I split the lines?
<markh> s/should/must/ ;)
<lifeless> hmmm
<lifeless> 1m51 to pull 3 days changes to bzr.dev :(
<spiv> Hmm, a schooltool user is getting a MemoryError doing an upgrade from knits: https://bugs.edge.launchpad.net/bzr/+bug/256757
<ubottu> Launchpad bug 256757 in bzr "upgrade from <RepositoryFormatKnit1> to the newest format eats all my ram" [Undecided,New]
<lifeless> yes, I'm wondering if its a bug in VFs
<spiv> markh: see mailing list, your test_plugins changes fail for me
<markh> spiv: yeah, saw that - thanks.
<markh> it only fails for me in a .exe - so I might just take the easy option and disable it there :)  I'll have one more stare at it though, but probably not for a day or 2...
<markh> or just revert that part of the patch - with 100+ failing it doesn't really matter.
 * markh will think about it ...
<lifeless> spiv: FYI: 58 seconds to pull one change from bazaar-vcs.org  :/
<lifeless> spiv: I haven't analysed why yet
<spiv> lifeless: :(
<gnomefreak> is it still posssible to remove a bzr branch with the beta launchpad?
<thekorn> gnomefreak, there is a delete icon right to the branch title
<thekorn> it points to <branch-url>/+delete
<gnomefreak> https://code.edge.launchpad.net/~gnomefreak/firefox-extensions/firegpg.ubuntu
<gnomefreak> i dont see it
<gnomefreak> oh damn the red X
<gnomefreak> sorry
<poolie> night all
<robsta> hi, could someone help me out with a bzr error?
<robsta> bzr commit says "bzr: ERROR: Working tree is out of date, please run 'bzr update'."
<robsta> then update hits an internal error
<robsta> bzr: ERROR: exceptions.TypeError: 'NoneType' object is unsubscriptable
<robsta> it all started with the following, committing a change involving lots of file renamings:
<robsta> bzr: ERROR: An inconsistent delta was supplied involving 'libccd/examples/internal.c', 'drawing.c-20080703141534-hfdtbme1gtdl6g10-1'
<robsta> reason: basis tree does not contain removed entry
<Peng_> This isn't very helpful, but are you using the latest version of bzr (1.5 or 1.6rc1)? This may have been fixed.
<Peng_> Other than that, I have no idea. Sorry.
<robsta> apparently stable ubuntu has 1.3.1-1ubuntu0.1
<AfC> robsta: that's pretty old, but as Peng_ noted, that may ore may not have anything to do with your problems.
<robsta> any chance that the upgraded version will automatically fix the state of my repo?
<robsta> or any general recommendation of what to do in such a case?
<mwhudson> 'bzr check' and 'bzr reconcile' might be worth trying
<luks> heh, I love benchmarks, somebody compares bzr/hg/git branch and then bzr/hg/hit clone
<luks> and then have different values for bzr branch and bzr clone, when it's in fact the same command
<robsta> mwhudson: no improvement, unfortunately
<Peng_> Worst case, "bzr remove-tree" or "rm -rf .bzr/checkout" to delete the working tree, throwing out your changes, then use "bzr co" to recreate it.
<robsta> will that help?
<robsta> the file that made it bail was bzr moved like 20 commits ago
<luks> 'Cherrypicks are just "merges" that are not tracked (cf. Git)'
<luks> people really shouldn't be allowed to write about anything they don't know well :(
<robsta> Peng_: now renaming the dir that holds it broke things
<AfC> robsta: the other outside possibility is that if you can branch from that repo at an older revision into an entirely new tree, then you may or may not be able to extract the branch (at that point) safely. That works surprisingly often, using -r -5 or something
<robsta> well
<AfC> (or -1 or -10 or 570 or whatever you need to do to get before the borked state, assuming that there is some interaction between your working tree and your branch that is confused. If the repository is corrupted, then of course it won't work, but that is *exceedingly* rare)
<AfC> [and you reporting that `bzr check` passed makes it sound like the repo is ok]
<robsta> er, bzr check
<robsta> bzr: ERROR: Revision {('rstaudinger@meqbuq-20080704140118-zfu9ft5a61y34252',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x85d99ac>".
<AfC> oh goodie
<robsta> this is pre 0.1 stuff anyways, maybe i should just move from bzr-playground to gnome svn and start over
<AfC> robsta: Are you just using Bazaar or are you simultaneously also trying to use Subversion?
<robsta> just bazaar
<robsta> this is bzr-playground only
<AfC> robsta: that' constrains things, at least. Ok, so you said you were renaming things. You didn't go and do something like manually move a top level directory tree out from underneath one shared repository to another or something like that, did you?
<robsta> heh, no
<lifeless> hi
<AfC> robsta: [there's a revision no present in whatever repository that branch is using. This tends not to happen because of something bzr did wrong. /me knows this from having shot himself in the foot once]
<robsta> AfC: i'm the only person who ever committed to that repo
<AfC> lifeless: dunno if you can help this fellow, but robsta has a bzr 1.3.1 reporting a missing revision.
<AfC> robsta: fine
<lifeless> robsta: when did it start giving this problem?
<robsta> lifeless: 10min ago
<lifeless> robsta: and had you been working normally up to then ?
<lifeless> robsta: is this a pure-bzr tree, or one of the bzr-svn imports on the playground?
<robsta> lifeless: bzr + add, mv, commit, push; guess that's pretty much all i did
<robsta> lifeless: pure bzr
<lifeless> robsta: if you haven't done something obviously wrong like 'mv branch /outside/repo' or 'bzr init-repo path-between-branch-and-repo'
<lifeless> ?
<AfC> lifeless: (that's kinda what I suspected)
<robsta> really just the above set of most plain commands
<lifeless> robsta: ok
<lifeless> then its time for a bug report with a back trace
<robsta> https://bugs.launchpad.net/bzr/+bug/256865
<ubottu> Launchpad bug 256865 in bzr "bzr internal messup with moved files" [Undecided,New]
<lifeless> I may lag a little bit from time to time, I'm in a wow raid; but bear with me and I'll check on stuff after deaths :)
<AfC> robsta: can you at least recover with `cd /tmp ; bzr init rescue ; cd rescue ; bzr pull -r -1 ~/path/to/branch` ?
<lifeless> robsta: ah, inconsistent delta
<lifeless> there is another bug on this
<lifeless> so
<AfC> bah, duh, `cd /tmp ; bzr branch -r -1 ~/path/to/branch`. There's good old Andrew, over complicating things as usual.
<lifeless> AfC: :) theres more than one way to do things :O
<AfC> (or revno -5 or 57 or whatever)
<robsta> AfC: this gives a new error: bzr: ERROR: Revision {robsta@gnome.org-20080723094759-xjsiakuuex5nhc2b} not present in "cbdunused.sgml-20080723094649-6cdasqyczacflh6z-2".
<AfC> lifeless: /me is surprised to hear the Perl motto coming from such a dedicated Pythoner :)
<lifeless> AfC: my favourite language flips between smalltalk and erlang
<AfC> robsta: ok, so you may need to twidle with a different revspec
<robsta> well, the history is not so important for me
<robsta> so if the problem is known and i can not provide new insight to the bzr devs i can as well start over brute force
<AfC> robsta: judging by the dates in those revids, I'd also guess that something like `bzr branch -r date:2008-07-02` might work
<AfC> robsta: (mostly I was emphasizing a) get somewhere not that current branch+repo, and b) reach back [some arbitrary amount)
<robsta> ya, gotcha
<robsta> no problem if i nuke it, really
<AfC> robsta: loss "not so important"; fair enough, but I am also interested in people being able to recover as much as possible. Perhaps no big deal for an project early days, but if this was 2 years on there would be bitterness
<AfC> robsta: hard to be believed to be unbiased in this channel, but this really is quite rare around here.
<lifeless> robsta: I think bug 256409
<ubottu> Launchpad bug 256409 in bzr "inconsistent delta with deleted directories" [Undecided,Triaged] https://launchpad.net/bugs/256409
<lifeless> same thing
<lifeless> bumping to crit
<AfC> lifeless: (if so, perhaps add into that quiet little list of things that might need to be back ported to 1.3.2 or whatever you are doing for the Ubuntu mob. Just a thought)
<robsta> does "bzr remove-tree" touch my files?
<AfC> yes
<lifeless> robsta: ok
<lifeless> robsta: is your project big ?
<robsta> no
<lifeless> take a backup
<lifeless> if you can tar up your tree and repository I'll use that for diagnostics
<lifeless> separately here is what I think is going on
<lifeless> you've found a serious bug
<lifeless> until I do a root cause diagnosis I can't say for sure exactly what is occuring
<robsta> lifeless: email, bug attachment, web download?
<lifeless> bug attachment is fine
<lifeless> what I think you'll have to do is probably discard those 10 commits
<lifeless> so, in a backup copy initially, just copy out using cp your entire source
<lifeless> then use bzr uncommit to pop off all the commits since the one that errored
<robsta> lifeless: attach to duplicate or original
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/256409
<ubottu> Launchpad bug 256409 in bzr "inconsistent delta with deleted directories" [Critical,Triaged]
<lifeless> having done uncommit
<lifeless> you should be able to just bzr commit again and have it work
<lifeless> if it errors we'll look at workarounds, getting you to use 1.6rc1 etc
<lifeless> robsta: how has that worked for you?
<robsta> still on it, i'm so cackhanded with VCS
<lifeless> this isn't your fault :)
<lifeless> by uncommit I mean something like
<lifeless> bzr uncommit -r -10
<robsta> just did that
<robsta> lifeless: now should i just do the same renamings again?
<robsta> or do you mean in a single commit, rather?
<robsta> in any case, my working tree after uncommit seems to be different from what it really was at that point
<robsta> the deleted dir is not restored
<lifeless> robsta: uncommit won't change your working tree
<lifeless> robsta: 'revert' changes your working tree
<lifeless> robsta: so your edits etc - including renames - are still in the working tree
<robsta> lifeless: oh, so i just commit all at once
<lifeless> yes
<lifeless> and we cross fingers that it won't blow up again
 * robsta a bit slow-witted
<robsta> ok, thanks lifeless
<lifeless> did that work ?
<robsta> the commit went thru
<lifeless> does 'bzr st' etc work ?
<robsta> oh, check still bails
<lifeless> where does it bail ?
<lifeless> because the damaged commits are still in your repo
<lifeless> so I would expect a fail; but the tree should be alright
<lifeless> just pastebin the output ?
<robsta> way back at one of the initial commits
<robsta> did another renaming back then
<lifeless> same issues?
<robsta> looks like
<lifeless> do you remember if it errored ?
<lifeless> renames per se are actually trivial inside the code base
<robsta> no error back then, AFAIR
<lifeless> I'd like to see the error
<robsta>  bzr check
<robsta> bzr: ERROR: Revision {('rstaudinger@meqbuq-20080704140118-zfu9ft5a61y34252',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x85fa58c>".
<robsta> shall i uncommit til then?
<lifeless> that looks like the original error up above
<lifeless> hang on a sec
<cyberco> hi, I've accidentilly commited sensitive data. How can I undo that?
<lifeless> bzr uncommit
<lifeless> then tweak your tree as needed
<AfC> (assuming you didn't also push those revisions outside of your immediate control)
<cyberco> hi, thanks, but i've commited another revision afterwards (in which I removed the sensitive data)
<cyberco> can I uncommit 2 revisions?
<AfC> cyberco: yes
<cyberco> I've pushed those revisions to a remote repository, but I can access that as well
<AfC> cyberco: `bzr uncommit` twice, (or `bzr uncommit -r -3` which I just learned about 2 minutes ago :))
<AfC> cyberco: that gets more serious
<cyberco> can I just uncommit on the remote repository and pull in the changes locally again?
<AfC> cyberco: you'll have to re-create the branch(es) in a new repository remotely, delete the original, and then replace it with the new one.
<AfC> cyberco: uncommitting will merely change the state of your current branch. It will not remove revisions from the repository (as I understand it)
<cyberco> maybe I can uncommit twice on both the remote and the local repositories?
<lifeless> cyberco: for the remote repo, the easiest thing is to just remove the repo and repush
<lifeless> robsta: revision 11 seems to be the issue
<AfC> cyberco: you need to differentiate between "Branch" and "Repository" here.
<cyberco> afc: sorry, you're right
<AfC> cyberco: (if you understand the difference, then I don't need to go on. If you don't, then we need to go over it, as in this case it is important)
<cyberco> afc: repushing will keep the history in tact (on the remote repository)
<AfC> cyberco: so, for that side of things, a branch is a branch is a branch; all branches are ultimately peers
<cyberco> ok, thank you very much, I'll try that
<AfC> cyberco: so the answer to your question is "if you have the history locally (and of course you do) then [re] pushing to a new remote branch (more to the point, a branch in a new repository, shared or otherwise)  will transport that history"
<cyberco> afc: great help! Thanks again
<AfC> cyberco: as an example, I have a bunch of branches under one [shared] repository; the 'mainline' branch is revno 538 (though actually composed of 1358 revisions); however, if I do `bzr info -v` I see that the [shared] repository [at ..] has 1674 revisions in it. Some of that is other unmerged branches, but I bet most of it, though is uncommits :)
<AfC> Hm. Is there a proper way to find out the number of revisions (ie, not revno) on a _branch_? I just did `bzr log | grep timestamp | wc -l` but that seems a bit hacky
 * AfC has always thought that `bzr info -v` could do better to report this number under "Branch history" rather than the current left hand revno, which most of us are fairly abreast of
<lifeless> robsta: so the added cbd directory in revision 11 is dud
<lifeless> robsta: if you can sit tight for a day, I'll see if all the issues are on directories (fingers crossed) and if so write a fixup for you
<robsta> lifeless: that'd work, much appreciated
<lifeless> robsta: its 10pm here though
<lifeless> so I don't recommend me doing it right now :)
<awilkins> Not with your head full of Night Elf Mohawks
<lifeless> :P
<robsta> lifeless: nah, this is just a fun project
<awilkins> Sucka!
<lifeless> awilkins: actually, we just downed archimonde, now getting some BT done
 * awilkins ducks as the WOW terms whoosh over his head
<lifeless> don't start something you can't finish :)
<awilkins> I finished playing EVE ages ago...
<awilkins> No more MMORPG for me. Some Battlefield 2142 occasionally
<rocky> yeah i recently gave up wow myself... mmorpg's are serious time sinks
<rocky> lifeless: we just finished killing second boss in hyjal ... only been in BT once ;)
<lifeless> gotta be careful
<lifeless> balance in all things :)
<spiv> AfC: "bzr ancestry | wc -l"
<rocky> well... if you're raiding BT and finished up archimonde that takes serious dedicated raiding time... so balance... hmmm.... ;)
<lifeless> rocky: dedicated aggregate time
<lifeless> anyhoo
<lifeless> night!
<robsta> cheers lifeless
<lifeless> oh one thing
<lifeless> if you can figure out what bzr commands / shell commands you did on revision 10->11
<lifeless> that might help me reproduce tomorrow
<lifeless> cheers!
<beuno> g'night lifeless
<AfC> spiv: neat
<awilkins> Anyonw know of an OSS UML modeller for Eclipse where 1 class == 1 file ?
<ahasenack> beuno: hi, ar you planning on uploading bzr 1.5 for hardy to the ppa anytime soon?
<ahasenack> are, sorry
<beuno> ahasenack, it can't be uploaded due to a problem that occured. 1.6 will be uploaded as soon as it's released
<ahasenack> beuno: can't you just bump the release number?
<beuno> ahasenack, 1.6b2 was uploaded already
<beuno> so we can't upload 1.5
<ahasenack> ah, it sticks
<ahasenack> even if there is no 1.6b2 there
<beuno> yeah, sorry  :/
<beuno> ahasenack, yeah, you can use the bzr beta ppa
<beuno> lemme get the URL
<dato> beuno: sometimes in debian we do stuff like 1.6b2.really.1.5-1
<ahasenack> beuno: thanks
<dato> (I'm guessing in ubuntu too :P)
<ahasenack> beuno: I don't see bzrtools in the bzr beta ppa
<beuno> ahasenack, https://launchpad.net/~bzr-beta-ppa/+archive
<beuno> ahasenack, poolie is the one uploading currently
<ahasenack> beuno: ok, so I should wait
<beuno> dato, that would make sense, but the rc has popped up already, so it gog superceded, and moved, etc
<ahasenack> dato: debian doesn't have something similar to "epoch" in rpm?
<ahasenack> dato: deb, I mean
<dato> beuno: yeah, at this stage is probably not worth it anymore.
<dato> ahasenack: yes, it does have them, but we tend to dislike them if the issue can be solved with a (very) temporary hack.
<dato> (because the hack disappears, but you carry the epoch forever)
<ahasenack> I guess it's valid for beta and rc releases
<ahasenack> the temporary hack, I mean
<ahasenack> the wrong upload was on   	2008-05-17 though, quite temporary ;)
<ahasenack> no, wait, 07-17
<ahasenack> well, something like that
<quicksilver> FYI, ghc considered bzr but opted for git
<quicksilver> http://www.haskell.org/pipermail/glasgow-haskell-users/2008-August/015134.html
<Toksyuryel> :(
<luks> I'm glad I choose bzr before the trend of benchmarking VCS tools started :)
<awilkins> The bzr benchmarks on the wiki are rather old
<awilkins> I'm sure the performance has improved since then
<evarlast> I find bzr to be easiest to use. It is also plenty fast.
<awilkins> I agree ; the last release has got much faster on Windows too. It's rather embarassing when you switch to Linux though and find that some things literally occur before you lift your hands form the keyboard
<evarlast> i've only used it on windows. :(
<liw> while I rarely notice that bzr is slow, I am always happy to get more speed
<liw> even when I'm not importing 60 gigs of source into one repository
<awilkins> The new _win32_fast_walkdirs extension makes it whistle along on trees with lots of files
<awilkins> I think that's in 1.6rc1 now
<awilkins> A couple of core devs are now using windows so it's getting some sugar :-)
<awilkins> Anyhow, train time
<PeanutHead> Hey everybody, I need some help installing the bazaar's eclipse plugin
<PeanutHead> I already ran "python setup-py build_ext -i"
<quicksilver> we've been using bzr for two years
<quicksilver> and yes, I do find it slightly slow for some things
 * beuno pokes Verterok 
<quicksilver> our repo has about 700 revisions in
<quicksilver> probably about 1200 including merged revisions, actually.
<quicksilver> and is rather small.
<quicksilver> I can imagine it might be annoyingly slow for projects the size of GHC.
<quicksilver> I love using it, though.
<PeanutHead> it says that it is running the build_ext
<PeanutHead> but then when I tried to run the bzr plugins, its says Unable to load plugin u'xmloutput_0_5_0' from u'C:/Program Files/Bazaar/plugins'
<PeanutHead> does anyone know what is going wrong with that?
<evarlast> quicksilver: did you upgrade to the newer bzr repo formats?
<quicksilver> evarlast: yes
<quicksilver> evarlast: and, that certainly improved things.
<quicksilver> let me check.
<PeanutHead> quicksilver: could you help me installing the bzr plugin for eclipse??
<quicksilver> sorry, I've never tried that.
<quicksilver> eclipse makes me feel queasy.
<quicksilver> evarlast: Checkout (format: pack-0.92) apparently
<PeanutHead> alright
<evarlast> quicksilver: yes, pack-0.92 improved things greatly.
<quicksilver> evarlast: bzr log still takes longer than I want it to.
<pickscrape> There are plans afoot to speed those up though
 * emmajane waves and has a question.
<emmajane> I'm trying to get bzr up and running on dreamhost. I would have thought it'd be a very simple matter based on the instructions I found ( http://joshstaiger.org/archives/2007/01/bzr_on_dreamhos.html ), but when I try to run it, I get bzr: command not found.
<emmajane> (i.e. after implementing the instructions)
<Peng_> If you just want to push and pull to and from DreamHost, you don't need to install bzr..
<emmajane> I have three machines that are all vaguely synced and which I log into directly on occasion to make fixes.
<emmajane> (i.e. updates are made from three machines: sandbox (will become dev), dev (will become production) and laptop)
<emmajane> I think it'll be easier if I have bzr on two of the three machines for what I want to do?
 * emmajane goes back to figuring it out. :)
<emmajane> Peng_: but thanks for the suggestion. I actually already have the push to dreamhost working.
<Peng_> FWIW, I have bzr running on DreamHost successfully (last I checked -- I don't use it on DH much anymore). I'm using virtual-python.
<emmajane> do you have one of the VPS machines, or just a standard account?
<Peng_> Standard account.
<emmajane> ah. I've got a VPS. Oh well. I'm sure I'll figure it out. :)
<beuno> pickscrape, howdy
<pickscrape> beuno: Good afternoon :)
<beuno> pickscrape, how are you?
<pickscrape> beuno: tired, but getting by. Yourself?
<beuno> pickscrape, trying to get everything setup for my first day at Canonical, so a bit hectic  :)
<beuno> I didn't get to your branch on saturday
<beuno> did you do any further work on it?
<Peng_> emmajane: The PSes are still the same environment, right? You don't have root access..
<pickscrape> No. I had a quick look at the revno link thing, decided it was going to take longer than the time I had
<pickscrape> But then thought about it again later and think it might be easier than I first thought
<emmajane> peng_ it's fine, I've submitted a ticket to tech support. no worries. :)
<Peng_> emmajane: A ticket about what?
<beuno> pickscrape, cool. I'm going to work on it now, I just wanted to make sure I wasn't duplicating work
<pickscrape> I think it might depend on the branch root thing too though, so it works in both cases.
<emmajane> peng_ the fact that the install isn't working the way it ought to.
<pickscrape> No, unfortunately I'm doing real work right now so I can't really work on it. Happy to talk though.
<Peng_> emmajane: Err, wait, you probably just need to set your $PATH..
<emmajane> peng_ I did that.
<beuno> pickscrape, ok, I'll figure it out and re-ping you.  It
<emmajane> peng_ I'm pretty good at following instructions...
<beuno> pickscrape, it's part of my *real* work now  :)
<emmajane> peng_ and that was part of the instructions.
<pickscrape> Yeah, lucky you :)
 * pickscrape is currently buried in PHP code
<Peng_> emmajane: Those instructions only mention PYTHONPATH, not PATH.\
<emmajane> peng_ it's fine, you can stop worrying about it. :)
<Peng_> What if I don't want to stop worrying? :P
<Peng_> emmajane: $ export PATH="~/bin:$PATH"
<Peng_> emmajane: (or wherever you installed it)
<beuno> mwhudson, ping
<mwhudson> pickscrape, beuno: hi
<pickscrape> mwhudson: hello
<beuno> hi
<beuno> mwhudson, did you take a peak at pickscrape's branch>
<beuno> ?
<mwhudson> yeah
<mwhudson> so my first comment is that i think the breadcrumbs should probably be on all pages, not just the inventory page
<beuno> I quite liked it
<beuno> ah, interesting
<mwhudson> i do like the basic idea, yes!
<beuno> I can do that
<mwhudson> i'm also not quite sure that the last 'crumb' should be a link
<pickscrape> mwhudson: I noticed that while I was playing around. I was going to add it to them but didn't see the point until it was working properly on the inventory page first
<mwhudson> pickscrape: fair enough
<beuno> mwhudson, can you think of a good way to solve the I'm-serving-from-root problem?
<pickscrape> As for the last crumb being a link, that's just laziness really :)
<mwhudson> beuno: an if name == '/' in an appropriate place?
<mwhudson> beuno: i haven't really looked at it though
<beuno> mwhudson, name being?
<mwhudson> i also worry slightly what this will do to non-serve-branches uses of loggerhead
<mwhudson> like that launchpad thing i keep hearing about :)
<beuno> mwhudson, I suppose we will have a hierarchy for that too
<beuno> based on the config
<pickscrape> mwhudson: name == '/' is all I thought it needed at first
<mwhudson> pickscrape: oh, how does that go wrong?
<pickscrape> There is an if statement in inventory_ui.py at line 80 that basically need to be filled in. It needs to know if loggerhead's root is a branch
<pickscrape> Because if it is, the link to the root needs to be different.
<mwhudson> so if the name of the branchwsgiapp object is '/', then the root is a branch
<mwhudson> i think
<pickscrape> By name do you mean 'friendly_name'?
<mwhudson> maybe :)
<mwhudson> on the phone now, biab
<pickscrape> I just tried outputting that with a branch as the root and got the branch's nick
<mwhudson> hm
<mwhudson> right, i should look at the code again and stop speculating!
<beuno> mwhudson, should pop up quickly, pickscrape even added a "if False" statement as a placeholder
<mwhudson> i saw that much :)
<gimaker`> Does anyone have a recipe for how to use rebase to shave off, say, the hundred first revisions of a branch? I haven't used rebase before and after reading the docs and fooling around with it I still don't understand how to do it.
<lifeless> gimaker`: the first hundred?
<lifeless> gimaker`: you'll need to init a new repository, then do rebase -r 100.. ../otherbranch
<gimaker`> lifeless: bzr init purged, cd purged, bzr rebase -r100..<lastrev> /path/to/before/purge ?
<lifeless> gimaker`: offhand, yes
<lifeless> gimaker`: I'd need to give it a spin to tbe sure
<gimaker`> lifeless: I'll try it out, hold on a sec
<gimaker`> That didn't work, I get this error: bzr: ERROR: Requested revision: u'100' does not exist in branch: BzrBranch6('file:///tmp/purge/')
<lifeless> oh, take a new branch, and do 'rebase --onto=100 -r 100.. .'
<lifeless> I think that will do it
<gimaker`> lifeless: should I do that from the empty (new) branch, or the original one?
<lifeless> gimaker`: from a backup of the original one, I would say
<lifeless> gimaker`: I never use rebase myself, so I'm just reading the docs and hoping :)
<gimaker`> lifeless: well, we're in the same position then - except that maybe you have an ever so slight edge in interpreting the docs ;)
<gimaker`> lifeless: I'm getting the same error again, no matter if I execute the command from the empty or the original branh
<gimaker`> lifeless: I'm giving up for the moment, but thanks a lot for the help! Re-reading the docs after a good night's sleep might help in cracking this nut :)
<lifeless> gimaker`: good luck
#bzr 2008-08-12
<poolie> hello
<poolie> spiv, jam, good morning
<spiv> morning
<lifeless> hi poolie
<poolie> hello beuno, lifeless
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/256409
<ubottu> Launchpad bug 256409 in bzr "inconsistent delta with deleted directories" [Critical,Triaged]
<lifeless> I'm working on this
<lifeless> I think its quite serious, I'm trying to understand it enough to create a test and figure out if its just 1.3.1 or if 1.6 is affected too
<rocky> so did jelmer ever wake up today? :)
<beuno> I haven't seen him
<lifeless> jelmer won't be around for a bit
<beuno> I've been expecting a
<beuno> "w00t, bzr-upload and bzr-search are in Debian", but nothing
<beuno> lifeless, is he OK?
<lifeless> beuno: yup all good
<jam> hey poolie, where's the call?
<poolie> hi
<poolie> i was waiting for you here
<jam> ah, sorry
<jam> I saw the hello
<poolie> np
<jam> you usually just call without response :)
<lifeless> jam: youhave a reply - and thanks for reading my essay :/
<spiv> jam: I admired your ascii art.
<mwhudson> hardly ascii
<spiv> Well, yeah.
<lifeless> back shortly
<mwhudson> hm
<mwhudson> are 'location aliases' documented anywhere?
<lifeless> are what now?
<mwhudson> things like :this
<mwhudson> (which turned out to be the one i wanted)
<abentley> mwhudson: no.  I should do that.
<abentley> lifeless: I thought bug 256409 was a solved problem!  What's up with it?
<ubottu> Launchpad bug 256409 in bzr "inconsistent delta with deleted directories" [Critical,Triaged] https://launchpad.net/bugs/256409
<jjesse> good evening i'm having problems chceking out the ubuntu-docs branch from #lp and getting this error: http://pastebin.ubuntu.com/36701 in regards to a KnitPackRepository error
<lifeless> abentley: I'm trying to reproduce at the moment
<lifeless> abentley: I'm leaning towards 'what I found and fixed has just been causing trouble for people'
<lifeless> abentley: but until I can trigger it with test code in 1.3.1, I can't check it against 1.6/1.7 either
<lifeless> abentley: its pretty scary regardless of whether its now-fixed or not, because 1.3.1 is widely spread
<lifeless> abentley: if you want to poke at it too that would be great
<abentley> lifeless: Oh, I had this confused with something else.
<abentley> lifeless: You remember we had a problem where file kinds weren't being properly updated by TreeTransform.apply()?
<lifeless> vaguely
<lifeless> this seems to be a cluster of problems - my note about what we need to do itemises them
<emmajane> beuno: thanks :)
<beuno> emmajane, :)
<emmajane> beuno: is it not possible to have something on the launchpad page to that effect?
<beuno> emmajane, the explanation itself?
<emmajane> I mean, I'm all about increasing karma points by asking easily answered questions, but... ;)
<emmajane> yeah
<beuno> hahah
<beuno> I agree. I haven't done so because vila should be back from his vacation any day now, and we should be able to wrap it up and release a tarball
<emmajane> that'd be fantastic.
<emmajane> I know it's going to be discussed at a BoF at the DrupalCon in two weeks.
<beuno> so, that and a .deb will supersede the bzr co...
<beuno> bzr-upload?
<emmajane> bzr generally.
<beuno> ah, how cool!
<beuno> please get us some feedback on whatever comes out of that
<emmajane> absolutely!
<emmajane> I'm just looking for the session description.
<emmajane> http://szeged2008.drupalcon.org/program/sessions/bzr-bazaar-source-revision-control-system
<emmajane> The workflows page in the documentation is excellent, btw. Not sure who wrote it but my full compliments go to them.
<beuno> emmajane, that would be Ian Clatworthy, which I don't see around at the moment
<beuno> he's done most of the docs
<emmajane> The Five Minute intro had a few leaps of logic that I wasn't able to make (I only know CVS and SVN...and basic skills at that)
<beuno> emmajane, like?
<emmajane> This will expose my naivety. ;)
<jam> poolie: see my email on the list, the log performance slowdown is because of the VersionedFiles changes and how it changes how we get at the per-file graph.
<beuno> good, that we wat we can learn
<jam> I proposed a "possible" fix.
<poolie> jam, i just saw it
<poolie> thankyou!
<jam> Though it probably needs some discussion with lifeless
<emmajane> beuno: the --push felt like it was the equivalent (mirror) of a checkout but in the opposite direction. This is not the case at all.
 * beuno looks
<emmajane> an extra sentence which read, "This will upload only the .bzr directory." would have helped me immensely.
<emmajane> I think of a branch as being a set of files that I download to work on in CVS.
<emmajane> which is an incorrect interpretation of that word, if I've correctly understood the first little bitof the full intro.
<beuno> emmajane, is this the part you are reffering to?  http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html#publishing-your-branch-with-sftp
<poolie> hello emmajane
<emmajane> beuno: that's the part, yes.
 * emmajane waves at poolie
<beuno> emmajane, I see, it would make sense to explain that it only uploads the repository
<beuno> as a side note, if you push locally, you actually do push the full working tree (the actual files) as well
<emmajane> but not if you're going over the 'net?
<beuno> emmajane, not if it's something remote  (sftp/ftp/ssh)
 * emmajane nods
<emmajane> I think the five minute intro would also benefit from having a link to the workflow page. It seems as though the setups are different depending on what you want to set up (go figure).
<beuno> emmajane, are you subscribed to our mailing list?
<emmajane> not at this point.
<beuno> if you'd like to (it's fairly high traffic though), and maybe send in your views so we can discuss them, I can put together a patch to fix it
<beuno> I can fix it anyway, it would just be more interesting if you could put it all together, and we can ping-pong with everyone else to see what else we can improve
<emmajane> I'd be happy to once I've actually figured out where I think the documentation is unclear. :) Sometimes it's just my fault that I'm skimming. :)
<emmajane> I'm keeping notes on what I'm doing to set up my environment though.
<beuno> emmajane, that information is still intersting, because we can change things so they get cought while skimming too  :)
<emmajane> heh
<poolie> emmajane, yes if you send a mail with it all in one place that would be good
 * emmajane nods. I'm keeping very careful notes at this piont, but I thought it would be better to get things running the way I want and then go back and evaluate my notes and the original documentation to see what would have really helped.
<markh> I'm getting a strange error when trying to branch from an smb mounted share with bzr.dev: "ERROR: Transport error: [Errno 12] Cannot allocate memory.../filename.rix".  Is that a known problem?
<lifeless> markh: no
<abentley> beuno: Actually, I wrote the workflows page, and Ian polished it.
<markh> its a little strange - a branch seemed to fail, but a checkout worked.  Then I did "bzr up" on the checkout, annd it said it applied all (1) changes, *then* gave the error.
<markh> I'll look in the log once the test suite finishes
<lifeless> markh: we have another bug open with SMB shares
 * markh decided he should try to test his patches on Linux ;)
<beuno> abentley, my apologies then. emmajane ^
<abentley> And I forget who did the images.
<emmajane> abentley: The workflows page is /fantastic/
<abentley> emmajane: Glad you like.
<lifeless> markh: bug 255656
<ubottu> Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when "bzr pack" is executed manually or when "autopack" is triggered on a repository located on a windows network share" [Undecided,New] https://launchpad.net/bugs/255656
<lifeless> markh: my guess is there is a commonality of some sort
<lifeless> (beyond 'windows sucks')
<markh> :)
<lifeless> markh: if you could look into that it would be really good
<Verterok> mornin' all
<beuno> evening Verterok
<Verterok> Hi beuno, g'evening
 * beuno is off to bed
<markh> lifeless:   File "/home/skip/src/bazaar/bzr.dev/bzrlib/osutils.py", line 598, in sha_file_by_name
<markh>     f = os.open(fname, os.O_RDONLY | O_BINARY)
<markh> OSError: [Errno 12] Cannot allocate memory: '/home/skip/o/src/bazaar/bzr.work.tests.blackbox//bzrlib/bugtracker.py'
<markh> but immediately after that, Python can do a normal open(fname, "rb") on that file
<markh> maybe samba's just running out of file handles.
<lifeless> interesting
<lifeless> try a gc.collect() before that call ?
<markh> ok
<markh> seems to work!  removing it again to make sure
<lifeless> so
<lifeless> I speculate its a HANDLE leak
<lifeless> we do a lot of readvs
<markh> probably the same one causing test suite failures all over windows :)
<markh> both LockContentions and warning messages about loads of test dirs being left behind
<markh> I can't make it fail again.  Did bzr pack the remote branch?
<markh> it failed when it said "Finishing Pack" on the progress bar.  Now it completes every time
<lifeless> hi jonnyde1
<jonnyde1> hi lifeless :)
<jonnyde1> just got an email about your new bug comment message
<jonnyde1> I will try your suggestions when I'm back at work, today...
<jonnyde1> need to have my breakfast now and then go to work... best regards and many thanks for your help :)
<lifeless> bug 256409
<ubottu> Launchpad bug 256409 in bzr "inconsistent delta with deleted directories" [Critical,Triaged] https://launchpad.net/bugs/256409
<gour> morning
<gour> i'm advocating usage of LP to GNUmed project...how is it possible to report bugs via email? does one configures separate email-list (i did something similar with roundup) or something else?
<lifeless> https://help.launchpad.net/BugTrackerEmailInterface
<gour> thanks a lot
<mwhudson> i'd like to be able to stick stuff on the end of location aliases
<mwhudson> bzr push :parent/../other
<poolie> mwhudson, that would be good
<mwhudson> i guess it's even not that hard
<mwhudson> just a bit more code in AliasDirectory.look_up
<poolie> lifeless, i have a clue
<lifeless> yay!
<lifeless> alexander graham bells invention time?
<lifeless> poolie: whats your clue?
<poolie> see mail
<poolie> (phone)
<gour> today is bazaar-1.6 release day?
<thumper> gour: I don't think so
<thumper> poolie: do you have a release day for 1.6 specified?
<jamesh> running "bzr upgrade" on a dirstate-tags branch prints a deprecation warning telling you that the branch is in ann old format and that you should run "bzr upgrade" ...
<jamesh> (that's with 1.6rc1)
<gour> hmm, someone told me the other day that something is gonna to be released today...
<markh> hrm - merge.py's do_merge takes 3 locks, then sets up a finally to release them all.  Shouldn't there be a finally per lock?
<spiv> jamesh: yeah, it's a known bug that "bzr upgrade" does that (it's not specific to this particular format transition).
<spiv> markh: probably that would be more correct, although the risk of the two unlocks for the lock_reads failing is pretty slim.
<markh> I'm thinking the test suite as much as anything...
<lifeless> markh: so, gc.collect() worked ?
<markh> lifeless: yeah, I replied.  After that though I can't repro it by taking it out.  Is that because bzr would have packed the remote branch?
<lifeless> markh: packing occurs on write operations only
<lifeless> markh: you can check your bzr.log to see if a pack occured
<markh> and gc.collect() fixes failure to remove test directories in some cases, so I'm wondering if cases like that do_merge might be responsible...
<lifeless> so, we do have a high volume of file operations
<lifeless> is there some way to tell python to suck less?
<markh> so now I can't repro it again :(
<robsta> hi lifeless, sorry, i don't remember what exactly i did back then :/
<lifeless> robsta: ah hi
<lifeless> robsta: so, the branch is a bit of a mess, I've spent all day trying to figure out WTF happened
<lifeless> I'm probably your number #1 spammer in your INBOX as a result :)
<robsta> lifeless: "bzr mv" i did , that's for sure
<lifeless> what was revno6 about by the way
<lifeless> you said 'repaired' ...
<robsta> lifeless: i did something that broke my local repo, therefore cloned again and copied over changes
<lifeless> when you say broke
<lifeless> what do you mean
<robsta> oh, a stale lock
<lifeless> oh
<lifeless> ok
<lifeless> 'bzr break-lock'
<robsta> oh (:
<lifeless> we avoid os-locks for our core data - the don't work well on e.g. FTP :)
<robsta> lifeless: so can i do anything apart from starting over in a new repo?
<lifeless> because we don't use os-locks, its possible to get stale locks, and thats what happend; probably you had some external event, or possibly triggered some actual assertion
<lifeless> robsta: I've written several test cases to try and reproduce and I have failed to date
<lifeless> robsta: can you attach your ~/.bzr.log* to the bug report
<robsta> done
<lifeless> thanks, looking
<lifeless> I'm going to study this
<lifeless> until I can reproduce it its pretty hard to say how-long the piece of string is
<lifeless> I think yes, copy the whole tree, rm -rf .bzr, init and start over :(
<lifeless> I'm not happy about this advice
<robsta> can i do something to fix the repo on gnome's bzr-playground too, or would that need manual intervention?
<lifeless> that will probably be fine if you do push --overwrite
<lifeless> it will have cruft that can be garbage collected but unreferenced data is not fetched
<lifeless> or propogated
<robsta> oh, good
<lifeless> ok, interestingly you used mkdir cbd
<lifeless> I'm going to use this log to try to reproduce again
<robsta> possibly i used "bzr mv" with wildcards a few times
<Peng_> Could someone do me a small favor and "bzr upgrade lp:~bzr/bzr-push-and-update/trunk"? It's still using knits.
<lifeless> beuno: ^
<jml> Peng_: done.
<Peng_> jml: Thanks. :)
<ronny> is there a simple howto for using bzr's api to controll workdirs?
<lifeless> theres some stuff on the wiki
<ronny> (i need to rewrite pidas bzr integration, currently its a ugly hack with subprocess))
<lifeless> robsta: good, news I seem to have reproduction
<robsta> lifeless: it's easing my pain a bit to know the suffering was not in vein :P
<poolie> lifeless, yay
<lifeless> robsta: I have duplicated the failure at revision 11
<lifeless> robsta: I suspect the others will be dups, reflecting how you used the tool
<robsta> lifeless: oh, what's triggering it?
<lifeless> robsta: I am reducing the size of test at the moment
<lifeless> robsta: still a lot of variables
<lifeless> damn
<lifeless> missed a change in my test, still can't reproduce
 * lifeless tries real-old-fashioned reproduction
<RAOF> That's a wonderful out-of-context quote :)
<lifeless> RAOF: heh
<lifeless> robsta: have you been using the same bzr version the whole time ?
<robsta> lifeless: think so, unless ubuntu changed it
<robsta> that is, no dist upgrade
<markh> I'm tracking down LockContention on Windows and I don't understand how it is supposed to work.  I've instrumented 'do_merge' and can prove that in some cases, self.this_tree._dirstate._filename == self.base_tree._dirstate._filename
<lifeless> markh: things like revert could do that
<markh> then that method takes a WriteLock on the lhs, and attempts a ReadLock on the rhs - the readlock fails - which seems to be correct.  But it works on Linux (and the paths compare true there too)
<lifeless> markh: yes, oslocks are different on windows and linux
<markh> heh - no wonder then :)  Is that by design?
<markh> ie, what do we do about the test failures?
<poolie> markh, it's the documented behaviour of locks
<lifeless> no; see my mail to the list about a simple change to reduce the issues here
<poolie> i would say we made a poor choice (in hindsight) to use them
<markh> so we just skip those tests on Windows?
<poolie> (on phone to lifeless)
<poolie> i think there is a 'known failure' for the fact that they're not exclusive on linux
<poolie> i _think_ the general approach is meant to be that we should detect that they're the same object and handle that at a higher level
<poolie> i don't have your context here
<markh> many tests on Windows are failing with a LockContention error - as the locks are exclusive on Windows.
<markh> so if Linux had exclusive locks, I guess all those tests would fail there too?
<markh> best I can tell, do_merge, in some cases at least, is taking a read and write lock on the same dirstate (and failing to take the read lock)
<markh> I hit 54 such cases
<markh> s/I/the test suite/
<markh> heh - which is more than 1/2 the total remaining errors ;)
<Stumbles> hi, I'm just starting to develop using Bazzar. I've been merging back and forwards between two branches. If I merge again I've just merged and committed when there's nothing to be done, it seems to create a "pending merge" in the destination. Am I doing something wrong?
<alex_muntada> i commited and pushed a change that contains a bad log entry; is there way to fix the log for that revision? should i uncommit my last revision and push it again? i've search in bazaar-vcs.org docs with no luck, so i'd appreciate some help or advise, whatever you like
<lifeless> Stumbles: no, its normal behaviour (though not very useful)
<lifeless> Stumbles: I plan to enahnce the 'nothing to do' check to catch that as well
<lifeless> alex_muntada: if you really care about it, uncommit and commit and push --overwrite
<Stumbles> lifeless: so I should just `bzr revert` to back out of that?
<lifeless> Stumbles: yup
<markh> will he need to --forget-pending-merges too?
<alex_muntada> lifeless: it's not a typo and it could be misinterpreted, so thanks for the tip :-)
<lifeless> markh: no
<lifeless> robsta: so
 * robsta perks up
<lifeless> robsta: I suspect something is going on that is outside the variables I can meaningfully choose to examine here
<lifeless> robsta: I'd like to ask you to do a few things for me, if I may
<Stumbles> lifeless: cheers
<lifeless> Stumbles: happy to help
<lifeless> robsta: you're using a deb package right?
<lifeless> robsta: can you do dpkg -l bzr?
<robsta> lifeless: yes and dpkg -l bzr
<robsta> Desired=Unknown/Install/Remove/Purge/Hold
<robsta> | Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
<robsta> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
<robsta> ||/ Name                      Version                   Description
<robsta> +++-=========================-=========================-==================================================================
<robsta> ii  bzr                       1.3.1-1ubuntu0.1          easy to use distributed version control system
<lifeless> ok cool
<lifeless> I did grab that packages source and test with it myself to no avail
<lifeless> robsta: are you using NFS or anything other than a local filesystem (for the branch that glitched)
<robsta> no
<lifeless> have any other branches done this sort of thing to you ?
<robsta> no, this is my only bzr project ATM
<lifeless> ok
<lifeless> can you, in a terminal somewhere, run 'bzr selftest --noplugins'
<robsta> bzr: ERROR: no such option: --noplugins
<lifeless> --no-plugins
<lifeless> this will take a bit of time
<lifeless> but if it fails in an unexpected manner it may help explain things
<lifeless> also, I'd like you to take a copy of the corrupt branch
<lifeless> and in that copy:
<lifeless> rm -rf .bzr/checkout
<lifeless> bzr branch -r 10 . ../FOO
<lifeless> cd ../FOO
<lifeless> bzr mkdir cbd
<lifeless> bzr mv ../src/css-border.c ../src/css-border.h .
<lifeless> (oh, cd cbd first :)
<lifeless> bzr mv ../src/css-color.h .
<lifeless> bzr mv ../src/css-gtk.c ../src/css-gtk.h .
<lifeless> bzr mv ../src/css.h .
<lifeless> bzr commit -m "test commands"
<lifeless> bzr check
<lifeless> (and post the output)
<robsta> "bzr mv ../src/css-border.c ../src/css-border.h ." fails, the paths are wrong
<lifeless> yeah cd to cbd first
<lifeless> I forgot to mention that cause its not in .bzr.log ;)
<robsta> lifeless: sorry, you even wrote it above
<robsta> didn't read that far
<lifeless> thats ok :)
<robsta> here goes
<robsta> bzr check
<robsta> checked branch file:///home/rstaudinger/Desktop/Devel/FOO/ format Bazaar Branch Format 6 (bzr 0.15)
<robsta> checked repository <bzrlib.transport.local.LocalTransport url=file:///home/rstaudinger/Desktop/Devel/FOO/> format <RepositoryFormatKnitPack1>
<robsta>     11 revisions
<robsta>     32 file-ids
<robsta>     64 unique file texts
<robsta>    179 repeated file texts
<robsta>      0 unreferenced text versions
<lifeless> one final check
<lifeless> cd ..
<lifeless> bzr branch -r 10 FOO BAR
<lifeless> cd BAR
<lifeless> bzr pull ../FOO
<robsta> from "FOO/cbd" i need to "cd .." twice, right ?
<robsta> just trying to make sure everything is exactly right
<lifeless> ah yeah
<robsta> "All changes applied successfully.
<robsta> Now on revision 11.
<robsta> "
<robsta> the self test is thru too
<robsta> Ran 10755 tests in 511.042s
<robsta> OK (known_failures=9)
<robsta> 663 tests skipped
<robsta> Missing feature 'FTPServer' skipped 76 tests.
<robsta> Missing feature 'Internally performed glob expansion' skipped 5 tests.
<robsta> Missing feature '_winreg' skipped 2 tests.
<robsta> Missing feature 'case-insensitive filesystem' skipped 2 tests.
<robsta> tests passed
<lifeless> ok
<lifeless> the good news, is that doing what you appear to have done previously, has worked
<lifeless> and there isn't anything obviously wrong system wide
<lifeless> what plugins do you have installed (bzr plugins)
<robsta> bzr plugins
<robsta> launchpad
<robsta>     Launchpad.net integration plugin for Bazaar.
<robsta> svn 0.4.9
<robsta>     Support for Subversion branches
<lifeless> yeah, fine
<lifeless> so the bad news then is that if this is representative of your system, bzr behaved correctly previously, so something must have caused the confusion subsequently
<lifeless> now you said you'd had a locking problem
<lifeless> has that happened more than once?
<robsta> no, and it was my fault, closed the terminal while bzr was prompting for commit msg
<lifeless> heh
<robsta> that works in svn
 * robsta ducks
<lifeless> mmm, wonder what signal bzr got, perhaps it could handle it better
<lifeless> feel free to file a bug
<robsta> not that important
<awilkins> Use vim, it ignored ctrl-c
<awilkins> It chastises you and makes you use :q!
<lifeless> awilkins: closing the terminal is a little harsher
<lifeless> robsta: still, be a nice bit of polish
<lifeless> robsta: I'll file it
<lifeless> done
<robsta> awilkins: $EDITOR ignores it too, nano or whatever is default
<lifeless> now, the icing on the cake
<lifeless> is that there is only one missing key
<lifeless> the one for the new directory
<robsta> lifeless: out of interest, have you ever regretted writing bzr in python?
<robsta> for lack of compiler checks and whatnot
<lifeless> nope
<lifeless> compiler checks catch such a small number of genuine bugs
<lifeless> by which I mean code that would be syntactically correct, pass selftests but a compiler can tell you about
<awilkins> Hmm ; I find checked languages to be easier going in a good IDE
<awilkins> If nothing else the IDE usually helps you out more
<robsta> lifeless: yeah, that was my next question; figured it might be an advantage being forced to write tests for just about everything
<awilkins> When I'm hacking bzr I am often stymied by what "interface" a given class is supposed to support (and where in the hierarchy it gets it from)
<awilkins> Hunting around in text files is the usualy result
<lifeless> awilkins: static analysis is reall quite orthogonal
<lifeless> awilkins: consider erlang for instance
<lifeless> or ocaml
<awilkins> I'm too tired to think right now ; was up all night installing Windows (a thousand curses to Dell for fiddly BIOSes that only boot USB with legacy support on)
<awilkins> And another thousand curses to IT beurocracies that insist on Windows-only full-disk encryption tools
<lifeless> awilkins: heh, ouch
<awilkins> And a small curse to my wife for giving in to them
<lifeless> awilkins: just install windows in a linux VM :)
<awilkins> I was all prepared to reinstall Ubuntu on dm-crypt partitions for her
<lifeless> robsta: I'll look at possible corruptors tomorrow
<awilkins> I could have left that running and gone to bed
<lifeless> robsta: I did find *one* code path that could cause it, but it doesn't look like it could possibly have been involved with the parameters you used
<robsta> lifeless: well, thanks for the awesome support
<kiorky> uhm, i have a merge problem, i try to recouncile two divergeant branches
<kiorky> it tells me that i must precise a reivsion base, so i tell it which reivisions to apply
<lifeless> robsta: and I've sent a patch up for that which will be in trunk tomorrow
<kiorky> the merge occurs succesfully
<kiorky> then i try to push, but then, it tells me again that the branches diverge
<lifeless> robsta: this is the first seriously borked repository we've ever had that wasn't quite obviously a NFS FAIL or memory bit-errors or the like
<lifeless> robsta: so I'm taking it very seriously
<kiorky> No one for an idea ? :)
<lifeless> kiorky: are you sure they are diverged and not just completely unrelated?
<kiorky> lifeless: they are unreleated
<kiorky> lifeless: why i thought why something like that : i merge from the other branches, what is different
<kiorky> then i pushed back the changes
<kiorky> lifeless: thing is that i update my bzr-svn repo, more nicely, and i try to merge back a locally branched thign.
<kiorky> (that was done before i updated my "svn" branch"
<kiorky> lifeless: What i have suceed to do is to get the svn changes in the local branch. What is left is to push back things to the svn branch
<kiorky> lifeless: Am i clear ? :)
<lifeless> kiorky: I have no idea what you're talking about :) - I think my brain has melted, its been a long day
<kiorky> lifeless: hang on, i ll make a draw :p
<lifeless> spiv: are you around perchance?
<kiorky> lifeless: http://www.friendpaste.com/MH3aG9k2
<kiorky> lifeless: is that more clear for you ?
<lifeless> kiorky: after you merge, you need to do a commit
<lifeless> because merge puts the result in a pending state
<kiorky> lifeless: i forgot in the pastebin
<kiorky> but its commited, of course
<lifeless> if you have done merge oldsvn; commit; then push oldsvn should just work
<kiorky> uhn, and stupid question, do you have a tip referrer like "head" or "tip" in bzr world ?
<kiorky> lifeless: nope
<lifeless> yes, -1 is the head of a branch
<kiorky> lifeless: http://www.friendpaste.com/5h5axg9V
<kiorky> lifeless: ok
<lifeless> 73 does not look like a merge to me
<lifeless> if it was a merge there would be merged revisions
<lifeless> what does bzr missing oldsvn show?
<lifeless> actually, I *have* to go
<lifeless> hopefully someone else can give you a hand
<kiorky> lifeless: just go :)
<lifeless> sorry
<kiorky> i hope, i just have to rumble the channel
<kiorky> *rumble*
<kiorky> lifeless: missing just make a lot of noise
<kiorky> lifeless: i ll try to merge thez others, so.
<strk> does any backup occur on 'bzr revert' ?
<weigon> strk: nope, use $ bzr shelve if you need a backup
<lifeless> strk: yes
<lifeless> strk: bzr makes .name~X files
<strk> great
<lifeless> (just passing through again)
<strk> they change on 'bzr switch' right ?
 * lifeless is really gone
<Peng_> beuno: With LH, does ?start_revid do anything useful on /annotate/ URLs? Particularly for Googlebot? (I don't think so, but I'm not sure.)
<Peng_> beuno: What about on /revision/?
<mwhudson> Peng_: on revision at least it makes a difference
<Peng_> Oh, hi.
<Peng_> ISTM it causes start_revid to be appended to most of the URLs, and changes the Previous/Next links.
<mwhudson> dang, i blew my cover
<mwhudson> Peng_: yeah, that's about right
<mwhudson> Peng_: by default loggerhead views the mainline of the branch
<Peng_> mwhudson: So...not useful?
<Peng_> Oh?
<mwhudson> if you give it a start_revid, instead of mainline it views what you get by starting at the start_revid and repeatedly taking the left-hand parent
<mwhudson> (which will converge with mainline sooner or later)
<mwhudson> i'm not at all convinced this makes sense as an organizing principle of navigation
<mwhudson> but i haven't really thought up anything clearly better yet
<Peng_> Well, does it lead to anything Googlebot would otherwise miss out on?
<mwhudson> (i have thought up some stuff that would be mostly better)
<mwhudson> er
<mwhudson> probably not
 * Peng_ feels very confident. :P
<Peng_> I've managed to whittle down most of the useless pages Googlebot finds, and start_revid is the only thing left.
<mwhudson> well
<markh> can I convert a checkout to a branch?
<mwhudson> Peng_: start_revid certainly doesn't affect the content of the page over much
<Peng_> markh: bzr unbind
<markh> Peng_: thanks!
<Peng_> :)
<mwhudson> Peng_: there might be pages that are only linked to with start_revid=<something> though
<Peng_> I know start_revid is useful on some pages (/changes), but I think it's added to a lot where it isn't.
<markh> hrm - "bzr: ERROR: Local branch is not bound" - its a light-weight branch - does that matter?
<Peng_> (Well, by "useful" I mean "useful to Googlebot". It usually does change the page in some way.)
<mwhudson> i'm not going to dispute that
<mwhudson> markh: reconfigure can probably do it
<Peng_> I'm just not sure which pages those are. :P
<mwhudson> Peng_: ah right, it's added to non-/changes pages so that it can be preserved for links to /changes pages, is all
<mwhudson> Peng_: this much i am actually fairly confident on
<markh> mwhudson: it could indeed - thx
<markh> I've ~ 95 commands staring me in the face with 'bzr help commands' :)
<Peng_> Hmm.
<Peng_> OK, it's definitely useless on /atom.
<kiorky> jelmer: i tried to update bzr-svn this morning, and it seems broken for me
<kiorky> jelmer: http://www.friendpaste.com/EYAgFfR4
<kiorky> jelmer: http://foo is a svn repo.
<kiorky> jelmer: syncing my bzr.dev helped, sorry for the noise.
 * beuno opens one eye and gets coffee
<Peng_> Good morning.
<beuno> g'mornin Peng_
<beuno> how are you today?
<Peng_> Um, I'm fine. How are you?
<beuno> I think I'm good too, but I should find more about that after the caffeine kicks in
<Peng_> Heh.
<awilkins> Here's one for you ; bzr rm <folder> complains about not wanting to delete files that you have already bzr mv'ed out of the folder
<beuno> awilkins, makes sense in my pre-caffeinated state
<beuno> maybe --force it?
<awilkins> Hmm, this is part of a merge.
<awilkins> I'm bzr mv-ing the files out of folder.moved to folder
<awilkins> The complaint is from bzr rm folder.moved
<beuno> are you suppose to bzr mv things in  .moved, or just plain mv them?
<awilkins> I think you have to bzr mv them ; "folder" is the new folder, folder.moved is still a owefwef
<awilkins> a part of the inventory
<awilkins> It seems to think that by deleting folder.moved (which is now empty of files) the files I have renamed to "folder" will be deleted
<awilkins> Which doesn't make sense to me
<markh> woohoo - both "failures" and "errors" are under 100 on windows :)
 * beuno cheers markh 
<awilkins> (skipped is now sadly above 12,900 and rising.....)   :-P
<awilkins> What fixed the liargest proportion of those errors?
<markh> heh - skipped remains under 1000 :)
<awilkins> And is there a fix for the evil "Can't delete temp folder" problem?
<markh> closing file handles, changing out of the directory being removed, etc :)
<markh> yeah - all of them are gone :)
<markh> s/all/most/ ;)
<awilkins> I can't help thinknig that test framework support for that would be nice
<Keybuk> how do I remove part of a pending merge from my working tree?
<markh> test framework has some support, but when a test explcitly makes a dir, then changes into it, then tries to remove it, there's not alot that can be done
<Keybuk> the merge brought in two revisions, but I only want one
<markh> most of the remaining errors are LockContention errors, which apparently is known
<gimaker`> Keybuk: bzr revert, bzr merge -rX..X+1 /merged/branch ?
<Keybuk> gimaker`: I've already resolved the conflicts for the bit I want, and don't want to lose that
<gimaker`> ah
<gimaker`> can't you use shelve to store the conflict resolution you done, then do what I said and unshelve the fix?
<Keybuk> is there a way to "fake merge" ?
<Keybuk> ie. just bring in the merge reference without the diff?
<lifeless> Keybuk: merge thing; revert .
<Keybuk> lifeless: great! thanks
<Pilky> Does anyone know if there's any sort of plugin to allow you to do something like 'bzr resolve --other' which will resolve everything to the .OTHER files?
<Peng_> Patches are probably welcome. :P
<Pilky> yet another of the projects I need to do when I find the time to learn Python I guess :P
<Peng_> You could file a bug.
<Peng_> (There might already be one, of course.)
<Pilky> I'll have a look and file one if there isn't, might get it in quicker than waiting for me to have time to learn python ;)
<Peng_> :)
<gimaker`> Any rebasing experts in here? I'm (still) struggling with trying to remove history at the beginning of a branch
<mheld> hey
<mheld> does anybody know of any OS X specific GUIs for bazaar?
<Pilky> mheld: yes and no
<mheld> i know there's gtk-bzr
<Pilky> I'm the project lead on one but it's not even got to 0.1 yet
<Pilky> launchpad.net/bazaarx
<mheld> but, i don't want to have to install mac ports on all of my computers
<Pilky> plus we're doing a major re-write of the core parts so it could be a while before we get to 0.1
<mheld> ah
<Pilky> hopefully within a month
<bvk> hi, is there any bzr extension similar to mercurial's patch-queues (MQ) extension ?
<gimaker`> bvk: bzr-loom, I belive (haven't used it myself yet)
<bvk> gimaker`: ok, i will try it out :-)
<TheEric> dumb question - if someone removed all revisions, is there a way to revert back on launchpad?
<beuno> TheEric, removed al revisions?
<TheEric> removed from the branch, yah.
<luks> how?
<TheEric> no clue.
<luks> how do you know they are removed then? :)
<TheEric> "1264 revisions were removed from the branch."
<luks> that's from which command?
<TheEric> That's from an email I received.
<TheEric> Manfre : Heh.
<luks> from launchpad?
<beuno> TheEric, ah, someone merged and pushed
<beuno> TheEric, you can do push --overwrite
<luks> no, somebody did push --overwrite
<beuno> ah, right, makes more sense
<luks> merge will never decrease the number of revisions
<luks> it might decrease the number of mainline revisions, but not the total number of revisions
<luks> TheEric: what is the branch?
<beuno> right, well, LP only shows mainline, so it makes me wonder...
<luks> TheEric: or, to be sure, you want to rever the branch to the original state?
<Manfre> lp:xpattern should be reverted to rev 1264
<TheEric> Exactly. to Revision 1264
<TheEric> It shows as 1 revision right now.
<luks> so somebody made a new branch and ran push --overwrite?
<TheEric> *shrug*
<luks> probably
<beuno> something's not right: http://bazaar.launchpad.net/~xpattern/xpattern/xpattern-1.0/changes
<james_w> yeah
<beuno> it may be LP being dumb
<luks> TheEric: this is recoverable, but I still wonder how did it happen
<beuno> luks, it doesn't seem like a problem with the actual branch
<TheEric> Manfre is listed as the admin with all the requisit access. (points at Manfre)
<luks> beuno: bzr log shows exactly one revision
<beuno> luks, that's interesting, loggerhead shows 1256
<luks> loggerhead is probably cached, isn't it?
<beuno> nope
<beuno> reading straight off the repo
<luks> oh, the cache code was removed?
<Manfre> this the most recent subscription update http://xpat.pastebin.com/m8676527
<beuno> yeap, a while ago
<beuno> it only caches changed files
<Manfre> i truncated the file contents out of it
<luks> oh, I see
<luks> hmm
<luks> this is interesting
<TheEric> yah, and the removal of the revisions was done after the push
<luks> looks like the parent is a ghost
<TheEric> but the two events were done ~ seconds of each other.
<Manfre> i need to step away  from the computer for a bit. So I'll defer any magically sign offs to TheEric...but i'm pretty sure it's obvious this is an error that needs correcting
<luks> I wouldn't touch the branch for now, as it looks like a bug
<luks> but all the data are on the server, so it should be recoverable
<luks> TheEric: can you please file a bug report?
<TheEric> Sure.
<luks> hmm, even more interesting, bzrlib has no problem reading the missing revisions
<luks> so it looks just like an UI bug
<luks> but a really serious UI bug, I think
<thorwil> hi. it now happened 2 times that a bzr push would hang at 0. needs 2 times ctrl-c to kill it. i then need break-lock and afterwards push works and takes almost no time
<thorwil> any ideas on what's going on?
<luks> TheEric: well, I've found the problem
<TheEric> oh?
<luks> the branch data is broken, the repository data is not
<luks> http://bazaar.launchpad.net/~xpattern/xpattern/xpattern-1.0/.bzr/branch/last-revision is not supposed to list revno 1
<TheEric> any idea how that happened?
<luks> I have no idea at all
<luks> you better way for some bzr devs for that
<luks> but make sure you file the bug report
<TheEric> I am.
<TheEric> or already have.
<TheEric> I just added your current comment to the description.
<TheEric> I'm out to lunch. bbl.
<luks> the fix is as simple as changing 1 to 1265 in .bzr/branch/last-revision
<luks> but I wouldn't do that on the official branch until you head from a bzr dev
<luks> *hear
<luks> TheEric: hm, what's the link to the bug report? I can't find it in launchpad
<luks> I wonder if this could be some stacking related bug
<rockstar> Manfre, TheEric, do either of you have the branch that was used to push lp:xpattern ?
<rockstar> On branching that branch, I get bzr: ERROR: bzrlib.errors.NotLefthandHistory: Supplied history does not follow left-hand parents
<Lea> is there any way of turning off this message? -- bzr: ERROR: no changes to commit. use --unchanged to commit anyhow -- I want to commit changes every 15 minutes from cron, silently doing nothing if there's nothing changed
<james_w> Lea: "if bzr diff >/dev/null; then bzr commit -m 'autocommit'; fi" may what you want
<Lea> james_w, thanks for the idea
<luks> rockstar: works for me using bzr.dev, which version are you using?
<james_w> Lea: you may need to invert the test
<rockstar> luks, whatever's in the PPA currently.
<luks> it fetches all the ancestry, correctly packs it into a single pack, but leaves last-revision broken
<rockstar> luks, yea.  I've seen this bug once before.
<Lea> james_w, yeh, already noticed that
<james_w> luks: does "bzr check" fail?
<rockstar> I thought it was a user error, because I didn't have much confidence in the user...
<luks> I've seen mismatch between the two numbers, but never last-revision reset to 1
<james_w> if not then check should probably check for "len(branch.revision_history()) == branch.last_revision_info()[1]"
<luks> james_w: I don't think it has a reaso n to fail, but I'll check
<luks> hm, true
<luks> rockstar: oh, it fails for me now, too
<luks> I'll check what's changed since then
<luks> interestingly, lp:xpattern fails, http://bazaar.launchpad.net/~xpattern/xpattern/xpattern-1.0/ doesn't
<luks> I thought it uses the same code path
<rockstar> Interesting.
<luks> ah, that's probably bzr+ssh vs http
<rockstar> Yea, that's probably what it is.
<luks> http just fetches the last-revision file, with bzr+ssh it has to recreate it
<luks> and recreating it fails on the assert
<rockstar> So maybe the bug is in the transport.
<luks> I still suspect it has something to do with stacking
<luks> I can't see why would anything in bzr reset the number to 1
<rockstar> luks, do you have the original branch on your system?
<rockstar> I saw this bug long before stacking was even CLOSE to being in trunk, back in maybe May.
<luks> rockstar: this is not my branch, so no :)
<rockstar> Yea, I figured.
<rockstar> Whoever has the original branch would probably be helpful.
<luks> the original .bzr.log would help more than the branch, though
<luks> since the branch is already broken and the last-revision file overwritten
<luks> the state before the commit would help
<rockstar> Yea, but the original branch would have everything we need, unless that branch is also screwed
<luks> I guess it is, unless this is indeed a bzr+ssh bug and it rewrote the number on push
<rockstar> Which would make sense.  I don't think it has much to do with stacking, but I have no clue how to reproduce it.
<luks> I didn't mean stacking directly, but some bug introduced with stacking
<luks> Manfre: I understand you were the one who pushed the branch? was it just 'bzr push' or 'bzr push --overwrite'?
<beuno> TheEric, 'bzr reconcile lp:xpattern' will fix the problem
<beuno> (as mentioned by abentley)
<abentley> So, what would be interesting: the source branch this was pushed from.  An idea of when the branch was created.  The .bzr.log from the most recent push.
<beuno> TheEric, ca you get in touch with the person you pushed last?
<abentley> Oh, the bzr version used for pushing, of course.
<TheEric> Back
<TheEric> Manfre is the project lead, and not the person who last pushed.
<Manfre> i'm back
<Manfre> so the person who did the last commit needs to run "bzr reconcile lp:xpattern" ?
<beuno> Manfre, anyone who has access can do that
<beuno> it will fix it
<beuno> although, if you could grab the person who pushed and get everything abentley mentioned above, it would be very helpful to us in the future
<TheEric> the reconcile didn't fix the problem.
<TheEric> it completed about ten minutes ago, I tried to download the branch, and it's still giving me the same error.
<TheEric> https://bugs.launchpad.net/launchpad-bazaar/+bug/257340
<ubottu> Launchpad bug 257340 in launchpad-bazaar "Revision History set to 0 following push" [Undecided,New]
<beuno> TheEric, thanks for the report
<beuno> could you pastebin the last bits of your .bzr.log?
<TheEric> from the reconcile?
<beuno> yeap
<TheEric> Umm. Interesting....
<TheEric> I don't seem to have that in the .bzr folder and the contents of my local xpattern directory is now, empty.
<pickscrape> TheEric: ~/.bzr.log
<luks> I wouldn't trust reconcile over bzr+ssh
<TheEric> it's on a windows install.
<Manfre> my documents folder
<pickscrape> TheEric: in that case I have no idea where it would be :)
<TheEric> I'm just a bit confused as to why -all- my local files for xpat are gone.
<TheEric> just bazaar.conf and ignore
<Manfre> odd
<luks> TheEric: are you looking to the right folder?
<Manfre> i wonder if the reconcile wiped it
<TheEric> I am.
<luks> bazaar.conf and ignore should be in Application Data/bazaar/2.0
<luks> not in .bzr dir of your branch
<TheEric> I looked in the .bzr dir in the branch, and there wasn't any sort of log file.
<TheEric> of course, the xpattern directory is empty except for that folder.
<luks> .bzr.log should be in the home folder
<Manfre> .bzr.log is in the My Documents folder on my system
<TheEric> found it.
<TheEric> and it's blank.
<TheEric> yah, did a further search, and no other .bzr.log - only the blank file. That's odd as I've used bzr on this computer, multiple times.
<abentley> TheEric: bzr --version will tell you where it's putting the log file.
<TheEric> same exact location where I found the blank log.
<abentley> TheEric: can you post the output that bzr reconcile gave you?
<abentley> ubottu: pastebin
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<TheEric> Well, there's nothign really to post - the .bzr.log file is blank. 0 bytes.
<Manfre> i think they want the console output from the command
<Manfre> hopefully you didn't close the prompt
<TheEric> http://pastebin.com/d3404dfe6
<abentley> TheEric: I meant the console output.
<TheEric> yah, that's above.
<abentley> TheEric: Strangely, it seems to think your revision_history is okay.
<abentley> TheEric: I was able to branch successfully over http, but not bzr+ssh.  Reconciling over sftp might work correctly.
<Manfre> abentley: is it possible to revert to 1264 over http?
<abentley> Manfre: Not over http, but it would be possible over sftp.
<Manfre> i'm not familiar with using bzr with sftp...only http and bzr+ssh
<abentley> Manfre: it's very similar to bzr+ssh, but a bit slower.  You just change the URL.
<abentley> i.e. replace "bzr+ssh:" with "sftp:"
<Manfre> unsupported protocol
<Manfre> don't have module paramiko
<abentley> Manfre: Okay, try changing "bzr+ssh" to "nosmart+bzr+ssh"
<abentley> Manfre: But I'd recommend getting paramiko at some point.  All the full installers should have it.
<Toranin> I just installed Bazaar via ports and wanted to work with svn.  After installing the svn 1.5 bindings and the bzr-svn plugin, I ran "$ bzr co -v svn+https://server/repos/trunk" to test and got "Assertion failed: (*path != '/'), function svn_ra_get_log2, file subversion/libsvn_ra/ra_loader.c, line 940." followed by a SIGABRT coredump
<Toranin> ideas?
<Toranin> same assertion fails in bzr selftest svn after: "[9/824 in 4s] bzrlib.plugins.svn.tests.test_branch.WorkingSubversionBranch.test_create_checkout"
<Toranin> I tried to check out from http://people.samba.org/bzr/jelmer/bzr-svn/0.4/ and build, but then it fails to load the extension altogether
<jam> abentley: hey, I can't seem to "bzr merge http://bundlebuggy...." anymore. I sent a message to the list
<jam> It seems that BB isn't returning 404 for missing documents
<jam> it is returning 200 OK, with a 404 page.
<jam> Toranin: you might try running "bzr command -Derror" which might help figrue out why the extension is failing to load.
<abentley> jam: Yeah, it does look broken.  You might be able to work around it with nosmart+http.
<jam> abentley: nope, "Unknown bzrdir format: <!DOCTYPE ..."
<jam> same thing if I revert to an earlier version of bzr
<jam> When it probes for .bzr/branch/format it gets a 200 OK document
<jam> but then doesn't recognize the contents.
<abentley> It's supposed to try to use the bundle, and if that succeeds, not use the branch.
<jam> abentley: well, neither seems to be working ...
<jam> I can 'wget' and then merge from that, though.
<jam> and it is still broken for bzr.dev @ 3400, 3500, etc
<jam> so it doesn't seem to be something new for bzr
<Toranin> jam: it already gives an exception output now
<Toranin> jam: let me pastebin it for you
<mxpxpod> jelmer: ping?
<Toranin> jam: http://pastebin.com/d1f33eabd <-- says 'did you build it?' in there, but I did
<jam> Toranin: did you use "build_ext -i" or just "build" ?
<Toranin> if I go into the ~/.bazaar/plugins/svn directory and do 'PYTHONPATH=. python', I can import the modules it's failing on
<jam> I'm guessing you built it into a "build/XXX/...." directory
<jam> so it can't find it
<jam> python setup.py build_ext -i
<Toranin> okay
<jam> *should* be what you want
<Toranin> will do
<jam> but I'm guessing a bit
<Toranin> I just did gmake
<Toranin> there's a makefile that invokes setup but not sure exactly how
<Toranin> ran your command, didn't appear to do anything
<Toranin> I already have 4 .so files in the svn dir
<Toranin> the makefile appears to invoke python setup.py build_ext --inplace by default, which I presume is the same
<mxpxpod> Toranin: do you have editor.o in your root directory?
<Toranin> no -- what the build_ext did was put the o file in the build/... tree and then copy the .so (module) files back up into the root dir
<Toranin> I just tried copying the .o files into place, didn't help any
<Toranin> is this new?  I notice there are no c or so files in the 4.10 tarball
<mxpxpod> Toranin: https://lists.ubuntu.com/archives/bazaar-announce/2008-August/000172.html
<Toranin> noted
<Toranin> hmm, does bzr do some kind of magic overrides on the import statement?
<Toranin> otherwise I can't see how the imports in question are supposed to work
<Toranin> ahh, I see
<Toranin> the svn plugin as written assumes it's installed under bzrlib/...
<Toranin> which is not the case for a homedir install
<abentley> Toranin: Plugins are always loaded into bzrlib.plugins, regardless of their filesystem location.
<Toranin> abentley: I'd have thought so
<Toranin> but given the error I tried just installing it unto site-packages
<Toranin> didn't help any, as you probably expected
<Toranin> I'm just weirded out by the error, because I can manually import the .so file from the command line
<lifeless> moin
<lifeless> abentley: ping
<lifeless> abentley: bb seems to think squid bundles are bazaar project bundls
<lifeless> abentley: or is it the wrong target branch leading to the confusion ?
<abentley> lifeless: It would be the wrong target branch, I expect.
<lifeless> ok,
<lifeless> I'll tweak the squid doco; what do you think about categorising by history as well?
<abentley> lifeless: I think that merge directives should be mergeable.  A merge directive with the wrong target branch isn't mergeable, because the target branch isn't available as a resource for retrieving revisions.
 * Toranin tried upgrading bzr to 1.6rc1
<lifeless> abentley: ah yes
<lifeless> abentley: however, if the base is a revision I know about in my repo then the target doesn't strictly matter
<abentley> lifeless: I'm not completely against adding more heuristics.
<abentley> lifeless: But someone sending a merge directive doesn't typically know what's in your repository.
<lifeless> abentley: agreed; kinkies patch was against trunk though; as a user he did the right thing but is missing public_location
<lifeless> abentley: are you still suffering some contention issues on the BB database?
<abentley> lifeless: I've got a load average of 6.24
<lifeless> all from BB?
<Toranin> well, that's working much better...the tests are running, though there're some failures
<abentley> lifeless: No, that machine handles my mail and web site as well.
<lifeless> ah whew, I'd hate to think review was using up that much order ;)
<abentley> Order?
<lifeless> well doing work increase entropy, so decreases order :)
<beuno> lifeless, do you have a minute to discuss bug #248018 - I can't reproduce it, really
<ubottu> Launchpad bug 248018 in loggerhead/1.6 "slow search results override fast ones" [High,Confirmed] https://launchpad.net/bugs/248018
<lifeless> beuno: yes
<beuno> lifeless, well, for starters, I can't get LH to override results  :)
<beuno> the code is in place to prevent it
<beuno> so I need to reproduce it to find out where it's slipping
<lifeless> go to http://bzr-playground.gnome.org/accerciser/trunk/
<lifeless> type 'a', wait a 1/2 second, type b
<lifeless> you should get ab showing a tad later, then the results for a
<beuno> lifeless, yeap, got it.  Is it running the latest LH?
<lifeless> search thumper
<beuno> lifeless, nm, it has the same js, enough for me
<beuno> now, let's see how to debug that...
<lifeless> see, easy :)
<lifeless> jam: so btree - 3 times faster
<lifeless> jam: I'm really starting to feel it would be of benefit to drop the core btree support into bzrlib in some form real soon
<lifeless> beuno: you need more from me on that?
<beuno> lifeless, nope, thanks
<jdobrien> statik: nice changes to the scripts
<beuno> mwhudson, did you manage to figure out the "I'm serving from root" issue in https://code.edge.launchpad.net/~pickscrape/loggerhead/directory_breadcrumbs ?
<mwhudson> beuno: no, didn't really look at it properly
<beuno> mwhudson, k, np. I'll come back to it after I finish the remaining 1.6 bugs, if you haven't managed to before
<mwhudson> beuno: i'll try to look at it now
<beuno> mwhudson, you rock, thanks!  :)
<mwhudson> beuno: your 'bundles' branch looks mergeable to me
<mwhudson> beuno: can you rename the 's' StringIO variable though?
<beuno> mwhudson, it still needs a link to download the actual diff  :)
<jdong> hey guys, thanks for bzr, helped out GREAT at work for some badly VCS'ed jumble of code :D
<beuno> mwhudson, sure, rename to...?
<jdong> I am guilty of trying Git on Windows XP first though....
<jdong> that was not fun
<mwhudson> it would also be possible to stream the output, dunno if that's worth it though....
<jdong> at all.
<mwhudson> beuno: 'diff_content' ?
<mwhudson> hm, maybe not that
<beuno> mwhudson, just 'content'?
<mwhudson> 'diff_content_stream' ?
<pickscrape> mwhudson: should I delete that superseded branch?
<mwhudson> pickscrape: if you like, no real need though
<pickscrape> I like to keep things tidy :)
<mwhudson> i guess it could be marked 'abandoned'
<mwhudson> mark it abandoned then, it will disappear from almost all listings that way
<pickscrape> Will that make it drop off the loggerhead branch list?
<pickscrape> OK, I'll do that.
<beuno> mwhudson, I'll tweak the remaining bits, and rename, and propose for merging
<mwhudson> beuno: ok
<mwhudson> beuno: and yeah, a link to it would be handy i guess :)
<jam> lifeless: I agree that we should bring them in, possibly before GC
<jam> I would probably bring them in without blooms
<jam> We have very little evidence that it will be better, and if we do tweak them to get better
<jam> it will likely be incompatible with existing bloom code anyway
#bzr 2008-08-13
<lifeless> jam: yes, thats my thoughts too
<lifeless> jam: want to work up a patch, or shall I?
<lifeless> the packing heuristics still bother the heck out of me
<jam> obviously I won't have time to do so today... :)
<lifeless> :P
<jam> "packing heuristics"?
<lifeless> I'm still looking at this critical bug today I expect
<lifeless> keys to nodes
<lifeless> the gzip magic
<jam> ah, that part
<jam> well, we can punt on it
<poolie> jam, spiv, hi
<jam> but it is fairly useful
<lifeless> jam: its needed I think
<jam> hi poolie
<lifeless> jam: but its gets very bad on bzr-search indices
<jam> IIRC it shrunk them by a significant amount
<jam> lifeless: how long are your bzr-search keys?
<lifeless> jam: tiny
<lifeless> jam: 4, 5 bytes
<jam> the pack work was certainly tuned around 60-byte keys, and often 120 bytes as tuples
<lifeless> the keys are document ids
<lifeless> e.g. '1'
<lifeless> well, ('1',)
<spiv> Good morning.
<poolie> jam, merging from BB urls was working for me on monday
<jam> poolie: it seems to be a BB thing
<jam> as BB is giving a 200 OK, Status: 404 results
<mwhudson> beuno: hm you said something about making the breadcrumb stuff less inventory specific
<poolie> make up your mind :)
<mwhudson> beuno: did you get to that?
<jam> so something is confused about the return code
<mwhudson> spiv: hello
<jam> I don't know HTTP well enough to know if "Status: " is supposed to overwride
<beuno> mwhudson, no, I didn't. I left that for after we fixed the root issue
<lifeless> jam: so, inventories
<mwhudson> beuno: hmm
<lifeless> jam: I mailed,  you replied - is it paused now ?
<lifeless> hi poolie
<jam> lifeless: today was painting the deck redux
<jam> I want to follow up
<spiv> mwhudson: hi
<lifeless> jam: ok
<lifeless> jam: I'd like that
<mwhudson> beuno: http://bazaar.launchpad.net/~mwhudson/loggerhead/directory_breadcrumbs/revision/209
<beuno> mwhudson, I knew you'd find a simpe way around it  :)
<mwhudson> it's a bit of a hack, but then hey! it's loggerhead
<mwhudson> at least it's a localized hack
<beuno> hahaha
<aquarius> I'm a bit confused by bzr init and init-repo. I'd like to store my home folder on my laptop in bzr, with a centralised repo on a remote sftp server (so I can check out from there to other machines).
<james_w> hey aquarius
<james_w> you probably don't need init-repo in that case
<aquarius> ah. I'm not clear what the difference between init-repo and init is...
<james_w> you may want it on the server if you are going to have branches "desktop" and "laptop" that are slightly different and you merge between them
<beuno> mwhudson, so you think it's ready for merging, or do you want me to have another look at it?
<james_w> but I doubt you'll be making feature branches on your laptop to try out experimental new settings
<james_w> hey besonen_mobile__
<aquarius> so can I just, on the laptop, do "bzr init sftp://server; bzr checkout sftp://server $HOME" ?
<james_w> hey beuno
<beuno> hey james_w, how are you?
<mwhudson> beuno: which?  directory_breadcrumbs? no
<james_w> good thanks beuno, you?
<james_w> enjoying work?
<aquarius> james_w: for the moment, assume that I want all checkouts to be identical on every machine. (I may add cleverness later. :))
<james_w> aquarius: that will work in principle, though it would probably fail as $HOME already exists
<beuno> james_w, good good, enjoying it very much, yes  :)
<james_w> aquarius: you probably want to create the branch locally and then push to the server
<james_w> beuno: cool :-)
<aquarius> james_w: OK...see, now I'm confused again. How do I do that, then? :)
<james_w> aquarius: "cd $HOME; bzr init; bzr add <files you want to version>; bzr commit; bzr push sftp://server/" or similar
<james_w> aquarius: plain "bzr add" is probably not what you want, so I would avoid that.
<james_w> judicious use of "bzr ignore" will probably help you avoid problems
<aquarius> james_w: excellent. A few questions. can I just do plain "bzr add" if I already have a .bzrignore file that correctly ignores the stuff I want to ignore?
<james_w> unless you actually aim to version ~/Videos/ and ~/Music/
<aquarius> second: does sftp://server/whatever/I/put have to exist before I push to it, or will push create it if it doesn't exist?
<james_w> aquarius: yeah, if you've set up ignores then bzr add won't add them. If you "bzr add <something you've got in .bzrignore>" then it will be added
<aquarius> *nod* win
<james_w> aquarius: no, it doesn't have to exist, but if sftp://server/whatever/I doesn't exist then you will need --create-prefix
<aquarius> third: once I've done all that, on machine2 can I just "cd $HOME; bzr checkout sftp://wherever/ ." ?
<aquarius> fourthly: imagine that I'd tried to do all this a couple of weeks ago and got it wrong (this is why i have a .bzrignore file). If I just remove $HOME/.bzr then all my previous screwups are eliminated, yes? bzr doesn't keep my info anywhere else magic?
<james_w> in principle, but again, I think it will fail due to . existing, though it's probably worth a try
<aquarius> *nod*
<james_w> a workaround is to checkout in to a tempdir, then move .bzr from that tempdir to $HOME
<james_w> you will also need to move any files not already on the machine from the tempdir
<james_w> just running "bzr diff" will tell you what is missing and modified
<aquarius> final question (you've been really helpful!): if I want to work on other projects hosted in bzr (say, a project currently in launchpad) and I grab a branch into $HOME/Projects or similar -- is this going to screw up because I'm putting one bzr project inside another?
<james_w> you can add anything else you like of course
<james_w> 4) there's no secret hidden stuff, so removing .bzr should be enough
<james_w> the exception would be if you had run "bzr init-repo ." in / or /home, which is very unlikely
<aquarius> nah, I didn't do that :)
<james_w> you can check "bzr info" output before removing the old .bzr to make sure
<james_w> finally, no that's not a problem.
<james_w> let me find you a reference on what init-repo actually is
<james_w> aquarius: does http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#repositories explain what "init-repo" is for sufficiently?
<aquarius> james_w: sorta, yeah. So if I'm not doing multiple branches then I don't need init-repo at all.
<james_w> aquarius: yeah, that's the main point for you in this case
<aquarius> right, ok. makes a bit more sense now, I think :)
<james_w> but if you do work on a project and use multiple branches for it, then shared repositories (in the bzr sense) are a big win
<aquarius> *nod* I can imagine.
<aquarius> if I don't create a shared repo now (on my sftp server) and later wish I had created one after all, can I take the existing pushed-to repo and "upgrade" it to be a shared one?
<james_w> aquarius: yup, see the reconfigure command
<aquarius> coolness. so, it sounds to me like doing it the simple way first is the best plan and then being more complex later if I need to will work :)
<james_w> aquarius: I've never done it myself, so I can't give you the recipe, but if you do come to need it then swing back here and someone will be able to help
<markh> lifeless: fyi, that samba issue yesterday turns out to be fairly non-deterministic - it randomly fails and works without the additional gc.collect().  Would it be useful to keep it added and to try and determine if it ever fails *with* it?
<lifeless> markh: well its not a 'solution'
<lifeless> markh: but if we can track down an actual cause - ftw
<markh> yeah, hence me not knowing if that avenue is worth spending more time on...
<markh> I figure than in the short-term, if we can get everything working correctly on native windows (ie, no attempts to move/delete open files), then we can be fairly confident we aren't leaking such handles in a major way.  Which led to me looking at those test failures yesterday I submitted a patch for
<lifeless> right
<beuno> mwhudson, bundle branch up for review. Is pickscrape's branch ready?  Do you want me to merge it?
<mwhudson> beuno: it should have breadcrumbs on all pages
<pickscrape> beuno: once the branch root problem is solved I need to apply it to a few other pages before it should be merged
<mwhudson> and the last 'crumb' shouldn't be a link
<beuno> pickscrape, lp:~mwhudson/loggerhead/directory_breadcrumbs
<beuno> it's fixed
<mwhudson> and we should think about how it interacts with the --user stuff
<mwhudson> but perhaps that's less important
<beuno> ok, so a few more things to chew before
 * beuno is going office -> home   bbiab
<pickscrape> mwhudson: excellent, thanks!
<pickscrape> I'll get to spreading that feature out to other pages as soon as I can
<mwhudson> pickscrape: cool
<mwhudson> pickscrape: please try to find some way of extracting the common code, not copy+paste :)
<Toksyuryel> That seems like bad advice, except the last one.
<mwhudson> Toksyuryel: ?
<Toksyuryel> komputes's quitline
<mwhudson> oh
 * mwhudson has mental filters for those
<Toksyuryel> heh
<poolie> markh, it would be interesting to do a test transport decorator that forbids moving/deleting open files
<markh> yeah, that would be cool.  How would it work?  monkeypatching?
<lifeless> wouldn't help with tree transform stuff
<lifeless> but I don't think we actually do that; I think its more reference leaks and the like due to slack gc
<markh> I think most of the problems I found last night were caused by exceptions keeping files alive slightly longer than normal.
<poolie> that's true it won't particularly help with tree transform
<markh> and most of these were fairly close to the "surface" of the API - so its only a problem in practice for a single process doing multiple bzr "commands" before terminating - eg, the test suite.
<poolie> i guess you could either monkeypatch or otherwise intercept file open/close
<markh> ie, I haven't yet found a problem a user of normal 'bzr' would see.
<poolie> oh i see
<markh> there is actually one strange bit of code in a decorator that might be responsible for the exception causing the cycle - lemme find it
<markh> decorators._fast_needs_read_lock() - it has a try/except/raise construct where a try/finally appears more logical.  Keeping the traceback alive in a local variable is potentially a cycle that wouldn't otherwise exist.
<poolie> i was thinking of something similar but a bit different, which is catching on unix problems that might break windows
<markh> the fact the name includes "_fast" though makes we worry someone has benchmarked things or something and found that to be faster
<poolie> specifically relating to transport/control file stuff
<markh> yes, I think that would be beneficial
<poolie> see for example fakevfat.py
<lifeless> markh: the fast refers to docstrings
<markh> similarly for locks ;)  Was there some conclusion to that?
<lifeless> markh: and the like
<lifeless> markh: did you read the dirstate RFC I posted a few days back
<markh> lifeless: regarding the ability to avoid locks in many cases?
<lifeless> yes
<poolie> it seems to me we want to run most tests with the lowest-common-denominator transport...
<markh> lifeless: it sounds good to me, but I have to admit the conversation was a little too far over my head to make any meaningful contribution :s
<lifeless> I think we should run the entirely in memory - but we can make that as low as we want
<jml> hmm. running bzr selftest --no-plugins only drops about 700 tests compared to the full suite for me.
 * jml should write more tests for his plugins
<markh> poolie: fakevfat does seem to be the way to approach it
<markh> they even list that as the first feature to be added ;)
<poolie> i don't know if there are any interesting behaviours in ntfs that wouldn't occur on vfat
<poolie> lifeless, i'd think we should gradually go to running on vfat+memory
<poolie> it would be interesting to profile how many tests use which transport class
<markh> not many we use.  ntfs has recently grown links
<lifeless> poolie: ntfs won't do things worse for us than vfat
<markh> but - back to the locks in the short term.  Many tests on windows are failing due to an assumption locks are not exclusive - any ideas about how to handle that in the short term?  Just leave them failing?
<lifeless> poolie: it simply has additional capabilities we could use if we wanted [but generally explorer dies in the arse if you use them, so we shouldn't]
<lifeless> markh: its in the definition of behaviour for that tree type; I don't know that there is much we can do
<poolie> sure
<poolie> lifeless, i was thinking of things like unicode handling
<poolie> it may not differ meaningfully to us
<markh> we could arrange for them to be either skipped or known failures if it was worth the bother, and if it wasn't going to stay that way for the long term :)
<poolie> at any rate the code that's affected should mostly not use transports
<lifeless> vfat is the same as NTFS for unicode to all intents and purposes -
<poolie> markh, so one approach here is to avoid having two objects addressing the same file
<lifeless> poolie: so, tree rules, whats the outcome there?
<poolie> we're seeing the conflict aaiu because we have that aliasing
<markh> I'm still not sure of the impact of the locks - do_merge is being called by the test suite with the same dir - are there real user scenarios that would hit this?
<lifeless> markh: yes
<lifeless> markh: I answered that yesterday FWIW
<markh> oops
 * markh scrolls back...
<poolie> lifeless, well, i think we should still do what i said: remove the code that reads it
<poolie> unless someone proposed an alternative?
<lifeless> its a real bug, it causes problems and its not amenable to changes without changing the format, because of old bzr clients
<poolie> lifeless, re _buffer_all, would those repos have also OOM'd in 1.5?
<lifeless> poolie: no, just hadn't got the go-ahead
<lifeless> poolie: yes, but they won't in 1.6
<lifeless> unless we start triggering _buffer_all
<poolie> but at the price of getting substantially slower for things that currently _do_ work
<lifeless> yes
<lifeless> constraints and accomodations again
<poolie> lifeless, i had in mind to make the api just something like _readahead_hint('per_file_graph')
<poolie> or 'per_file_log'
<poolie> then those repos in this release can buffer everything, but there's no implied promise it's doing so
<jml> lifeless: btw, I was looking around the test scenario stuff. It seems that objects in the scenario dict are shared between tests?
<lifeless> jml: bzr's scenarios?
<lifeless> jml: the parameterisation stuff ?
<poolie> markh, re do_merge, i didn't see lifeless's specific answer but it seems possible
<poolie> but, i would think that locking the same object twice should not be a problem- it will just increment the internal counter
<markh> I looked and failed to find his specific answer too :)
<poolie> the problem we want to avoid is having two objects pointing to the same file
<markh> 2 different objects involved IIRC
<lifeless> markh: it wasn't as detailed as I just gave
<poolie> if you can do that, there should be no problem with locks being exclusive or not
<lifeless> the case it occurs for users is when the working tree is two of the coordinates in a merge operation
<lifeless> one readonly one write, it will self-exclude on windows
<poolie> if this is only happening in tests not in real use this may be a problem of, say
<poolie> an api that implicitly opens a wt when it should allow the object to be passed in
<poolie> jml, in the scenario they're just directly assigned to the test object
<poolie> they're typically strings or valueobjects
<poolie> if you pass a mutable object then yes, it may cause contamination between tests
<lifeless> jml: we could deep copy to actively prevent bugs
<poolie> which would be bad ;-)
<lifeless> jml: but we've never had mutated objects there to day
<jml> right.
<poolie> lifeless, that kinda sounds like an accomodation ;-)
<jml> I guess you guys use format specifiers and the like.
<lifeless> poolie: python doesn't have 'const' :)
<poolie> i mean it's pythonic to have mutable objects and tell people to use them carefully
<lifeless> poolie: its also slow
<lifeless> and many other things; we accomodate all the time
<poolie> lifeless, slow to copy?
<lifeless> poolie: just slow :>
<poolie> anyhow there's no guarantee that deep copy would work correctly on arbitrary objects
<lifeless> actually there is
<poolie> oh you're agreeing?
<mwhudson> sockets, for example :)
<lifeless> there is a deep copy protocol
 * markh wonders why the merge code can't detect the same tree is being used and not bother taking the second read lock...
<jml> so, I'm thinking that I want to do something a lot like what TestScenarioApplier does, except have it take a scenario *factory*
<lifeless> jml: pass the factory in as the scenario
<lifeless> jml: ?
<jml> lifeless: right, that's what I'll do in the short term.
<lifeless> jml: whats the use case?
<poolie> jml, for instance, just put a callable as the scenario parameter
<poolie> or a class
<poolie> (which is a callable of course)
<lifeless> we pass in factories all the time
<jml> poolie: right, that's what I'll do in the short term.
<poolie> jml, this would be worth documenting though
<lifeless> so I'm keen to understand the use case that makes you think of this as a short term solution
<lifeless> rather than the right solution
<poolie> want to send a one-para patch to the hacking file?
<jml> poolie: maybe a bit later -- after I've successfully used it.
<poolie> markh, having two objects and not locking one of them would be risky
<poolie> also probably futile as the object might implicitly lock itself
<poolie> however, saying 'oh these should be the same object i'll fix them up' would be,
<jml> lifeless: it's short term because in the slightly longer term I want to try doing things my way and see if it's better :)
<lifeless> jml: there are many varied examples in bzrlib; I'd be delighted to help you choose a good one to cult from
<poolie> um, maybe not optimal but worth looking at
<poolie> jml, lifeless, i was wondering whether it is really tasteful to have the scenario written into arbitrary test attributes
<poolie> rather than .scenario
<lifeless> jml: so we started with a fully general thing that was called per function if I remember correctly
<poolie> for instance
<markh> poolie: but if its an oslock, its only purpose is to keep others out isn't it?  And as we work correctly when the locks aren't exclusive, I don't see much risk.  But I'm sure I'm just blinkered :)
<lifeless> poolie: I think its tasteful; you can always have a scenario that puts everything on .scenario
 * jml disagrees
<jml> but taste is a matter of... taste.
<lifeless> jml: which statement do you disagree with ?
<markh> I can imagine all the decorators failing though...
<poolie> markh, you might get two in-memory objects that are out of sync with each other
<lifeless> markh: no, they are exclusive
<poolie> but, presumably it already has to deal with this on unix
<jml> lifeless: I disagree that it's tasteful.
<lifeless> jml: to write to any attribute?
<markh> yeah - that's what I'm a little lost with still...
<jml> lifeless: yeah.
<lifeless> markh: so, on unix they are exclusive *cross process*
<poolie> markh, btw, today's my last day here, do you want to catch up?
<lifeless> markh: its a special case that it doesn't exclude the same process
<poolie> i do have a bunch to do
<markh> lifeless: right - so in process you could theoretically detect and avoid 2 locks on the same file?
<lifeless> markh: not locking would allow two bzr processes to stamp on each other on windows *as well* as allowing a single-process to behave as bzr on linux does
<markh> but I'm only saying not to lock when we already have a write lock
<lifeless> markh: I guess you could reinstate the global dict we used to have
<lifeless> markh: but IIRC we took it out cause it caused other bugs
<markh> but why not just compare paths, and if we already have a write lock on the same path, just don't take the read lock.  Could theoretiucally be all detected in do_merge
<poolie> lifeless, do you agree that the general approach is to try to have one in-memory object corresponding to each real-world or fs object?
<lifeless> jml: I think forcing the core code to only write to one attribute is not treating callers like adults; and it doesn't stop people having all the issues arbitrary attributes have in micro
<lifeless> poolie: no, I don't agree with that
<poolie> ok
<markh> it would just solve the problem for a single "Merger" object, that that seems the only real use case that its a real problem with
<lifeless> poolie: I think its good when we do that but aliasing can trivially stop that working, so we need to be correct regardless
<lifeless> poolie: consider z: and f: mapped to the same SMB drive, for instance.
<poolie> sure
<lifeless> jml: I will agree that as a convention having stuff on .scenario is good for documentation and predictability; but thats up a layer in the 'userspace' of the facility
<lifeless> markh: I think we should just fix the underlying bug and issue a new recommended format for windows
<jml> lifeless: well, actually, I think that the nicest way would be to call a method on the test.
<lifeless> jml: to set stuff?
<jml> lifeless: yes.
<lifeless> jml: kind of like _setattr_ but different?
<jml> lifeless: kind of like setScenario(scenario)
<lifeless> jml: I think that would be great; I also want python unittest compatibility
<lifeless> jml: but doing a getattr for setScenario first would be fine IMO
<jml> lifeless: of course, then the way you set attributes would have to match whatever the default implementation of setScenario does.
<poolie> jml, that seems pretty close to just poking into .scenario_* then letting setUp() run...
<poolie> lifeless, yeah i was thinking of .scenario* just as a convention not a requirement
<jml> poolie: well, the difference is that the test decides what to do with the scenario.
<lifeless> jml: yes, but hopefully both are in the same codebase
<jml> lifeless: I've got use cases for doing otherwise.
<lifeless> jml: you're making me guess here
<poolie> i guess in my experience it's often just storing them
<poolie> but your cases would be interesting
<jml> lifeless: bzr plugins
<jml> lifeless: like bzr-loom
<poolie> jml, out of curiousity, did addCleanup go from bzrlib to pyunit3k?
<jml> wait, wrong example
<jml> poolie: no.
<markh> lifeless: I'm not sure exactly what the bug is?  I got the impression from yesterday that they were *intended* to be exclusive?
<jml> poolie: I implemented addCleanup using test-driven development for Twisted and then re-implemented it with TDD as a patch to Python
<jml> poolie: the one in pyunit3k is from the latter.
<lifeless> markh: WT4 is designed with a built in flaw; its a design bug we need to fix
<markh> and that would impact the recommended default format for windows?
<jml> poolie: the addCleanup in bzrlib isn't tested, per se.
<lifeless> markh: for everyone
<markh> or you mean we'd end up with a wt5?
<markh> right
<poolie> really?
<lifeless> wt5
<jml> poolie: really no tests.
<lifeless> markh: 'bzr commit' -> opens editor
<lifeless> in the editor, !bzr diff, or similar
<lifeless> -> FAIL
<markh> right - you mean implement your RFC?
<lifeless> yes
<markh> gotchya - cool
<markh> which will still leave us with the longer term problem of how to disable the existing tests once this new wt comes out - the old tests aren't going away...
<jml> poolie: the Twisted one allows cleanups to return Deferreds and ensures they are run in serial, fwiw.
<markh> disable on windows
<markh> but that can wait ;)
<jml> poolie: and as such is way more complex than any other implementation I've seen.
<poolie> jml, i meant did the idea come from bzrlib or was it independent reinvention
<jml> poolie: oh, the idea is from bzrlib.
<lifeless> markh: we'd add a feature
<lifeless> markh: and requireFeature those tests
<markh> ahh - nice clue - thanks!
<jml> poolie: in fact, I don't know of anyone else who's done it apart from bzrlib and myself.
<lifeless> the feature would be something like
<lifeless> BrokenInProcessLocksFeature
<lifeless> jml: I think that bzrlib is one of the drivers of testing facilities in unittest tests in python
<poolie> let's use a more specific word than 'Broken'
<lifeless> jml: other than e.g. nose which seems half cool half terminally confused
<lifeless> poolie: :)
<lifeless> poolie: I tried to think of one, to represent what linux os locks do
<lifeless> poolie: but nothing other than 'fucked' and 'broken' came to mind
<lifeless> so I went polite
<poolie> <stephane> don't goof off too much
<poolie> ^^ at me laughing at you
<markh> :)
<lifeless> :)
<jml> lifeless: well...
<jml> lifeless: Twisted and Zope have both explored new testing territory.
<poolie> ProcessWideFileLocks
<jml> lifeless: Zope, for example, has definitively shown that layers are a terrible idea.
<poolie> jml, congratulations on the user reviews of the code review feature!
<jml> lifeless: that's progress.
<poolie> markh, so do you need anything from me before i go?
<poolie> (at about 5pm today)
<poolie> it looked like the questions about packaging were fairly well answered?
<markh> poolie: yeah, thanks.  Over that period I ill have binaries available and I'm not sure what I should do with them exactly :)  Current plan is to mail the mailing list and host them on that starship server I have access to.  Anything else I should do with them while you are gone?
<poolie> you can put them up as file downloads on launchpad?
<poolie> s//can't you/
<poolie> you might need to join the right team there...
<markh> yeah - will that give them much visibility?
<poolie> https://edge.launchpad.net/bzr/+download
<markh> yeah - that's what I'm thinking - I'm still a total newb with launchpad
<poolie> and then link them from the /Download page on the main site
<poolie> do you get an 'add download file' link there?
<markh> the fact mailing lists were attached to teams is what threw me before
<lifeless> jml: :)
<lifeless> jml: I meant positive directions
<lifeless> jml: we're still on for sunday?
<poolie> markh, yeah that's one of those possibly too clever ideas
<jml> lifeless: I thought it was Saturday
<lifeless> jml: ah yes, it is
<lifeless> I was thinking with my wow-addict-hat for a second
<lifeless> jml: btw, can you log in sometime and hit return on the stuff in your mailbox ;)
<markh> poolie: no "add download file" link
<jml> lifeless: to which machine?
<poolie> what's your lp userid?
<lifeless> caelstraz
<markh> mhammond
<poolie> lifeless, jml, i assume you wouldn't object to me adding him to ~bzr?
<lifeless> not at all
<lifeless> though perhaps you meant jam & abently there :)
<jml> lifeless: oh, right. I guess so.
<poolie> markh, try again?
<thumper> is there any easy way to check the revno of the public branch?  like `bzr revno -d :public`?
 * thumper waves hands around
<spiv> thumper: "bzr revno :public"
<thumper> spiv: thanks#
<markh> poolie: awesome, thanks!  You now have my permission to enjoy yourself for a couple of weeks on that BMW riding north! :)
<poolie> :-)
<jml> spiv: bzr://rhino.local/addCleanup-args
<thumper> abentley: I don't suppose bzrtools has a command that does the equivalent of "branch X into shared repo, then do a lightweight checkout" ?
<abentley> thumper: Sounds like cbranch.
<thumper> abentley: can I tell cbranch to --hardlink from a different working tree though?
<thumper> abentley: normally I go `bzr cbranch local-a local-b` and that's exactly what I want for that use case
<abentley> thumper: Yes.  --files-from
<thumper> abentley: but if I want to go `bzr cbranch lp:~a/b/c` that works?
<abentley> thumper: Yes, you can cbranch from any location that bzr understands.
<thumper> abentley: you rock!
<abentley> btw, you need to supply *both* --hardlink and --files-from if you want that.
<thumper> abentley: gotcha
<thumper> abentley: I have cbranch aliased to `cbranch --lightweight --hardlink`
<abentley> Me too.
<abentley> thumper: If you forget to supply --files-from, you can use "bzr link-tree" to hardlink after the fact.
<spiv> Hmm, "bzr diff -r submit:" is including the changes in the common ancestor revision in the diff.
<spiv> That's weird.
<thumper> abentley: and that converts copies to hard links?
<abentley> thumper: Yes.
<thumper> cool
<thumper> is link-tree in bzrtools or trunk?
<thumper> s/trunk/core/
<lifeless> poolie: there is a squid meetup in sydney while you are away
<lifeless> poolie: ok if I pop down there for a bit? not sure how much time I want to spend; its monday and tuesday next week
<spiv> Ah, it's because my mirror of bzr.dev is older than the branch I'm making a diff of.
<lifeless> beuno: around still?
<poolie> lifeless, np
<pickscrape> mwhudson/beuno: ping
<beuno> lifeless, pong
<beuno> pickscrape, pong
<lifeless> beuno: hi
<beuno> hi lifeless
<lifeless> beuno: uhm, what was it, oh yeah - does loggerhead have a way to get favicon.ico from a branch ?
<lifeless> beuno: wondering if I should file a bug for that
<pickscrape> beuno: hi. I was looking to move the breadcrumbs markup out into a shared place. It looks like metal is what I'm after
<beuno> lifeless, I've seen your comments on the bug.  What do you mean "from a branch"?  from the actual tree?
<beuno> pickscrape, yes, or in macros.pt
<pickscrape> There is a template there already called 'macros.pt', but it contains a full-HTML macro and it doesn't like it if I try to define any outside of the html element
<beuno> but that will just make rockstar move them to a separate tempalte later on
<pickscrape> Ah, he's unifying or something like that isn't he
<lifeless> beuno: I mean from the branch, so for non-launchpad installs of loggerhead
<beuno> he's spliting things up so it's more themeable
<beuno> lifeless, currently LH gets it's favicon statically from it's own dir
<beuno> you would want to add a favico.ico to each dir of each branch?
<pickscrape> favicon just gets served from root doesn't it?
<lifeless> beuno: sure, why not :)
<lifeless> pickscrape: I think documents can override per-document
<beuno> pickscrape, I can help you place it in the templates, if you get the python code in place to spit out the content
<beuno> lifeless, no reason why not, it would make projects more personalized. Although I wonder how many people will go through the trouble of creating one per project/branch
<pickscrape> beuno: I'm actually keen to learn how this works myself. I've been playing around and have actually got it working from a separate macros template, though I'm sure that's not ideal
<beuno> lifeless, I'm all for it, just not on the top of the list right now. I agree with you  :)
<lifeless> beuno: well, if it was (say) .favicon.ico, I'd happy put one in most of my projects
<beuno> pickscrape, separate macros template?  embeded in each template?
<pickscrape> I created a breadcrumbs.pt file in the same location as macros.pt, and also had to add a line to loggerhead/templatefunctions.py to get it to recognise it
<beuno> pickscrape, that sounds correct  :)
<rockstar> pickscrape, the "unify" was because the branch was started with a different idea then what actually came out of it.  :)
<tacone> favicon can be specified in <head> as well
<pickscrape> Is that the approach that rockstar will be taking?
<beuno> pickscrape, yes, that's why it sounds right  :)
<rockstar> Yes, absolutely.
<rockstar> The idea is that someone might want to put the breadcrumbs somewhere else.
<pickscrape> Oh sweet. I was concerned that calling it 'breadcrumbs' was being a bit too granular.
<rockstar> So they should just have a template function that generates the  breadcrumbs, and they can call that wherever they like.
<pickscrape> Yes, that makes sense
<pickscrape> In that case it doesn't sound like I'll be conflicting with rockstar as much as I was afraid I might be.
<rockstar> beuno, are you gonna merge my branch before or after 1.6?
<beuno> rockstar, not at all, ASAP
<beuno> so, before
<rockstar> Cool.
<beuno> anything that's laying around and intersting goes in. I just don't want more features, or it will be like bzr's 1.6
 * beuno ducks
<rockstar> :)
<lifeless> beuno: so I should file a bug?
<beuno> lifeless, haven't you already?  Where have you been ping-ponging with poolie about this then?
<lifeless> bazaar-launchpad, different use case
<lifeless> almost entirely unrelated in fact :)
 * beuno looks
<beuno> ah, right. I pictured it in my head on how I'd implement it, so I ended up thinking it was on LH  :p
<beuno> lifeless, sure, go ahead
<pickscrape> night all
<lifeless> done
<thumper> beuno, rockstar: I've commented on the review, and I think they should be looked at before merging
<mwhudson> lifeless: oh, i thought your bug report was about loggerhead too :)
<beuno> thumper, just saw it and replied. I fully agree with most of it. Does answering by email automagically work?
<thumper> beuno: it should do :-)
<beuno> pickscrape, g'night
<beuno> thumper, it did, yay!   Now I like reviews better
<mwhudson> oh, it was
<thumper> beuno: :-)
<thumper> beuno: you can thank abentley
 * beuno thanks abentley
<abentley> beuno: just doing my job
<beuno> abentley, still worth thanking you  :)
<beuno> hm, LP's sends me back the email I sent as a review
 * beuno takes back 1/8th of his thank you from abentley 
<abentley> beuno: Mailing lists generally do that.
<beuno> abentley, isn't it disabled on most of em?
<lifeless> beuno: no
 * beuno can't think of any lists he's on that work that way
<abentley> bazaar@lists.canonical.com, bzr-gtk@lists.canonical.com
<beuno> the bzr ml doesn't send me back my own emails AFAIK
<abentley> beuno: It sends me mine.
<mwhudson> it's a per-user option in mailman
<spiv> Mailman lists let subscribers opt out of having their own messages sent back to them.
<beuno> (I'm not actually complaining anymore, just truthfully curious now)
<spiv> By default those lists will send them back, I believe.
<abentley> beuno: I find it essential to have the mail sent back to me so that I can read mail threads I've participated it.
<abentley> participated *in*
<beuno> hm, I wonder if it's gmail "doing stuff for me" then
<lifeless> abentley: speaking of this
<lifeless> abentley: I find I miss reviews when folk use BB's web interface because it doesn't mail me
<lifeless> abentley: how do you feel about reimplementing mailmain in turbogears/
<lifeless> ?
<beuno> ROFL
<lifeless> beuno: gmail hides N>1 instances of a mail with the same id
<abentley> You miss reviews because they aren't addressed to you personally?
<lifeless> yes
<beuno> lifeless, ah, ok. So I've been protected from reality up to today.  Why doesn't this apply to LP then?
<lifeless> I send in a patch, someone reviews on the web, I notice a few days later when I'm doing a list-scan or BB web UI check
<AfC> "I've been protected from reality". Heh. I'm going to steal that.
<lifeless> beuno: LP sends its mails with a different id
<lifeless> beuno: rather than as a bounce
<abentley> lifeless: I am too busy reimplementing Mailman in launchpad to reimplement it in TurboGears :-)
<abentley> beuno: This is arguably a bug.
<beuno> abentley, yeah, it at least felt odd to my normal workflow.  Mind if I file it then?
<abentley> Not at all.  It should have had the same id.
<lifeless> abentley: is it actually the same content?
<abentley> lifeless: More or less.  May have a header prepended or a footer appended.
<lifeless> then I agree
<lifeless> FWTW
<beuno> \o/
<lifeless> thumper: hi
<beuno> abentley, I found bug #240564
<lifeless> I keep asking this
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/205416/+addbranch
<lifeless> can we make the whiteboard be shorter so I don't have to scroll on that page?
<beuno> fixing that would fix this too, wouldn't it?
<beuno> https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/240564
<lifeless> thumper: if you say yes I'll file a bug
<lifeless> thumper: also, at least for me, the common case is 'fix available' not 'work in progress', so could we change the default too ?
<thumper> lifeless: please file a bug, and assign it to rockstar
<thumper> lifeless: I know you've been asking, but I've been implementing something else you asked for ;-)
<rockstar> Yes please.  Assign all bugs to me.
<rockstar> :)
<thumper> rockstar: something for you to do :)
<rockstar> thumper, job security  :)
<thumper> :)
<mwhudson> watch out, at current rates our team will run out of work ... in 2120 or so
<lifeless> thumper: rockstar whats your lp id ?
<rockstar> rockstar
<rockstar> :)
<rockstar> mwhudson, after my talk on LP and bzr tonight, people were telling me all about the bugs they've discovered, as if I was the bug tracker myself.  :)
<mwhudson> yeah, people do that
<beuno> abentley, so, still file a bug inspite of https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/240564 ?
<beuno> it's the last thing I'm doing before *really* going to bed
<abentley> beuno: Yes.  This bug is "The message id isn't being preserved when handling incoming mail"
<abentley> 240564 is "Only code review messages are threaded, not other messages about the merge proposal".
<beuno> abentley, thanks, filed as #257494
<beuno> I'm really off now, g'night everybody
<abentley> beuno: g'night.
<lifeless> gnight beuno
<Peng_> This is late, but good night.
<abentley> lifeless: If Bundle Buggy CC'ed the submitter, would that stop you from missing reviews?
<lifeless> abentley: yes indeed
<abentley> lifeless: I've got Mailman configured not to mail me duplicates.  So I think if it sent a message to bazaar@lists.canonical.com that was cc'ed to me, Mailman would not forward it to me.
<abentley> That would mean we've covered both cases without having to introduce any per-user settings on BB.
<lifeless> abentley: cool
<lifeless> spiv: bb:tweak on the testing docs btw
<lifeless> spiv: I think I forgot to say
<spiv> lifeless: oh cool, thanks
<lifeless> spiv:
<lifeless> if I could ask for a review, my InterTree + remove tweaks would be a lovely pair to do
<spiv> lifeless: I'll take a look.
<poolie> lifeless: hm this might have been faster if i'd re-read your rfc before we talked for so long
<poolie> it's good
<lifeless> poolie: :)
<lifeless> poolie: thats good to hear
<poolie> hm
<poolie> so it's basically like being split by directory, except not necessarily by directory
<poolie> i'm not sure if explaining that way is going to cause more or less confusion
<lifeless> split by directory achieves some of the goals
<lifeless> but conceptually its what a lot of people reach for first
<poolie> right
<lifeless> I think its important that we explain why that isn't sufficient; and also why its good so that we can use the good bits
<lifeless> the good bits are having a canonical form, being updatable in < tree
<lifeless> the bits that are not sufficient are being == dir size, and pathological cases have such a strong habit of turning up
<lifeless> (also not mapping fileids -> paths at all well)
<poolie> that last one may be a challenge for many designs
<lifeless> if its too hard its too hard
<lifeless> but trivially consider three things
<lifeless> a path->id index
<lifeless> a id->path index
<lifeless> content
<poolie> sure
<lifeless> making the indices outside the core data is possiblty doable
<lifeless> and another thing to consider
<lifeless> if we put them outside and use a parallel design to implement the index, it might make the 'core' smaller but is it simpler
<lifeless> right now we have no path<->id indices, instead we derive them on th efly
<lifeless> we could do that too
<lifeless> as long as there was an index on (say) basename<->fileid, and fileid->content
<lifeless> then path-> content is 'basename) -> fileid set, repeat lookup on fileid->content until a parent  mismatches
<poolie> hm
<poolie> i do feel very excited about trying to write such a thing
<poolie> :/
<lifeless> :)
<lifeless> thats a good sign
<lifeless> it indicates the design sounds attractive
<poolie> hm
<poolie> i want to talk more about how to prototype it but really should not
<lifeless> :>
<lifeless> thanks for the feedbackm its was good
<lifeless> I have replied
<poolie> i'd be inclined to start by prototyping something that takes an in-memory inventory and writes it out in a new form
<lifeless> yes, that would give you a canonical form
<lifeless> the converter has to do that anyhow :P
<poolie> sue
<poolie> sure*
<poolie> i mean that might be an interesting place to start
<lifeless> I am inclined to start by crisping-up the interfaces for diff etc
<lifeless> so that we pass inventory deltas around more
<lifeless> rather than upcasting dirstate to an inventory
<lifeless> so diff -r -3 internally becomes
<lifeless> a call to diff -3..-1 updated by -1..current:
<lifeless> poolie: if you do want to chat, I am around for 30 more minutes, raid is at 6
<poolie> i have some more mail to send and then need to clean up here
<poolie> sadly
<poolie> i kind of wish i was disconnecting with a laptop and less interruptions
<lifeless> heh
<lifeless> would be less of a holiday wouldn't it :)
<robsta> hi
<robsta> is it possible to push a sequence of bzr commits to an svn repo as a single commit?
<james_w> robsta: hi, it's not as far as I know, you need to do a squash merge first.
<lifeless> robsta: do you want to discard the history, or to make it look like a single merge?
<robsta> make it look like a single commit in svn
<lifeless> robsta: bzr checkout svn:/// fo
<lifeless> cd fo
<lifeless> bzr merge <your branch>
<lifeless> bzr commit
<lifeless> that will result in a single commit to svn
<lifeless> you'll want the latest bzr-svn which has a raft of bugfixes
<robsta> ok, so i need two branches
<lifeless> jelmer announced it monday or something
<robsta> fair enough
 * robsta wondering how to best leverage the combination of gnome's svn and bzr-playground
<lifeless> spiv: ping
<rjek> Incase it's not been reported before; http://rafb.net/p/cqMCzd70.html
<rjek> (bzr explosion when doing bzr vis with no DISPLAY on 1.3.1)
<lifeless> fun
<lifeless> please file a bug?
<rjek> Sorry, I don't have an account on Launchpad.
<lifeless> oh, ok
<lifeless> uhm, perhaps a mail to the bzr-gtk list?
<lifeless> you don't need to subscribe, moderator can let it through
<rjek> Right, OK.  I'll do that.
<rjek> Do you happen to know its address, or an URL of a page that describes it?
<lifeless> http://bazaar-vcs.org/bzr-gtk
<rjek> Ta.
<rjek> sent!
<rjek> Thanks.
<Peng_> BB down?
<Peng_> Oh, good, just slow.
<markh> I think I'm still missing something conceptually to do with merging. Let's say i have 3 branches, 'bzr.dev', and 2 'work' branches 'bzr.1' and 'bzr.2'.  I periodically update bzr.dev then pull from 'bzr.dev' into 'bzr.1' - but in the meantime I also make a number of changes in bzr.2, then 'bzr merge' them into bzr.1 and commit them (into bzr.1).  When a do 'bzr log' of bzr.1, all I see is a single 'merge' commit, and not the individual comm
<james_w> markh: even with "bzr log --long" (the default, but you may have it aliased)?
<markh> james_w: yeah
<james_w> and I assume you didn't do "bzr revert --forget-merges" at any point?
<james_w> and the merge wasn't a cherry pick?
<james_w> i.e. it was just "bzr merge ../bzr.2" not "bzr merge -rx..y ../bzr.2" ?
<markh> actually, when I first started looking at this, the initial merges were '-r x..y' - but even then I'd expect to see the logs for r..y?  I'm experimenting now with trying to stitch 2 related branches together without a '-r' though...
<james_w> if you use "-rx..y" then it's a cherry pick, and so all of the commits will be collapsed
<markh> (for x..y)
<james_w> -ry or no -r won't do that
<james_w> could you pastebin a transcript showing what you did, and the resulting log?
<markh> this is all kinda "post-mortem" - I do need to try some controlled experiments (or find clear docs :)
<markh> yeah, merge without -r does what I expect.  So maybe I'm confused about how to make 2 branches "re-converge", so a simple 'bzr merge' keeps them up to date even when they previously diverged.  IIUC, 'bzr pull --overwrite' will lose history too.  I'm still too confused to phrase a reasonable question though :-S
<james_w> yeah, pull --overwrite is the wrong thing
<james_w> if you "bzr merge" one way you can "bzr pull" the other way afterwards, then the branches should be mirrors
<james_w> if you run "bzr pull" and it succeeds then the two branches are mirrors
<james_w> "bzr merge" allows you to bring in the changes from another branch regardless of whether a pull would succeed
<markh> but once I've done a merge, how do I then get a pull to work again in the future once things are back together?
<markh> eg, I checked in locally, then sent a bundle which was merged to bzr.dev - but in the meantime, I've had to "bzr merge" from bzr.dev.  But now it was merged upstream, what do I do?
<markh> start a new branch?
<markh> (but in the meantime I've also merged various other branches in - although everything in bzr.dev is now in my branch)
<markh> eg, I've 3 outstanding merge requests with bundle-buggy - all these are already in my branch that I'm otherwise keeping up-to-date with bzr.dev.  hence my general confusion :)
<awilkins> Here's a thing ; the smart server requires the dumb server to work
<awilkins> On modern webserver ; fine, on IIS 6 ; annoying
<awilkins> How much work would it be to get the smart server to just serve the files that normally come from the dumb server?
<Peng_> The smart server already provided VFS access, so I think it should be *possible*.
<Peng_> The ideal solution is for the smart server to do everything through RPCs.
<awilkins> IIS7 works fine
<awilkins> IIS7 has a way of catching /smart links though
<awilkins> IIS6 only likes directing things with dotted file extensions to ISAPI modules though
<markh> yeah - merging into a new tree seems to be much closer to what I expect.
<markh> it avoids the need to cherry pick.  I think trying to stick to an initial "base tree" that has diverged from public branch is the problem
<markh> (and it seems I also get to learn about "criss-cross merging" :)
<james_w> markh: if you are merging multiple things in to a branch, including bzr.dev then you won't be able to resynchronise to bzr.dev, but you can keep merging it
<markh> i've got myself into the state where the only merge that works is to cherry-pick - which collapses the merges as we mentioned.
<james_w> hmm, I'm not sure why that would happen
<markh> I think I'm looking for the "--oh-yeah-i-know-i-merged-something-silly-before-but-please-just-reconcile-things" option ;)
<james_w> heh :-)
<james_w> does the command say that you are not allowed to do it, or are you hitting an error?
<james_w> the only way I know of to prevent merge working is to have no common ancestor, which shouldn't be the case here
<markh> it actually just ended up merging more than I wanted.  things got very confusing when I ended with with both 1.6 and .dev branches
<james_w> hmm, interesting
<markh> so I've got patches I'm submitting against bzr.dev, but still applying locally to a 1.6 based branch
<markh> starting with a clean, new branch up the upstream, then merging in the various ".work" branches seems to be working fine.
<markh> I think I just got myself working on the "rhs" of a branch, not the left.
<markh> (or something like that :)
<markh> s/branch up the upstream/branch *of* the upstream/
<markh> I've now got 6 branches based, at some stage in the past, on bzr.dev
<markh> each with their own changes, each less or more important
<markh> so each now targetting either .dev or both .dev and 16
<Toranin> How do you get a proper log of bzr selftest results?  Piping to tee seems to truncate the test names to 80 characters wide, which is not really useful.
<jam> markh: I might be able to add a bit more to the locking discussion if you are around
<epsy> hi, i've just filed a bug, and i'm not sure what priority to give it
<epsy> it affects storage(dirstate), blocks me from using the repository, but is something that could only happen in a very specific setup
<epsy> well, i think it could only happen in a very specific setup, that is
<james_w> epsy: I'll give it a priority if I triage it
<epsy> ok
<james_w> epsy: drop the number here and I can do it now
<epsy> https://bugs.launchpad.net/bzr/+bug/257599
<ubottu> Launchpad bug 257599 in bzr "exceptions.AssertionError: no parent entry" [Undecided,New]
<epsy> heh, nice
<james_w> Toranin: are you sure it's not what you are using to view the log that is truncating?
<james_w> epsy: that's a dupe I think, let me find it
<Toranin> james_w: fairly sure but I'll try it again -- I'm just doing (more or less) bzr selftest -v | tee testlog
<epsy> was the other report resolved?
<james_w> epsy: yeah, it will be fixed in 1.6
<epsy> is there any way i can fix my repo or should i trash it?
<Toranin> output looks like:
<Toranin> running 14456 tests...
<Toranin> ...hon2.5/site-packages/bzrlib/doc/api/branch.txt)   OK                1294ms
<james_w> epsy: there's a way to fix it
<epsy> phew :)
<james_w> bug 150438
<ubottu> Launchpad bug 150438 in bzr "corrupt inventory deltas are not detected by dirstate" [High,Fix released] https://launchpad.net/bugs/150438
<Toranin> "COLUMNS=$COLUMNS bzr selftest -v | tee testlog" <-- this widens it out to my terminal width in the log at least.  218 ought to be enough for most test names, I think
<james_w> epsy: I think it's "mkdir dir; bzr add dir; bzr st; bzr rm dir"
<james_w> where "dir" is the directory that was removed that it is complaining about
<epsy> the way to reproduce it or the way to fix it?
<james_w> the way to fix it
<epsy> ok
<epsy> in my case, it's images/avatars/ that i have to add again, right?
<epsy> Great, it works! thank you very much :)
<james_w> no problem
<jonnydee> lifeless: Just wanted to let you know it seems like you have found a bugfix for https://bugs.launchpad.net/bzr/+bug/255656 :)
<ubottu> Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when "bzr pack" is executed manually or when "autopack" is triggered on a repository located on a windows network share" [Undecided,New]
<jonnydee> Thank you very very much!!!!
<jam> beuno: ping
<beuno> jam, pong
<jam> beuno: were you the one that helped me make deb releases?
<jam> markh: ping
<beuno> jam, yeap. You ready to release?
<jam> Not quite yet, but I just wanted you on hand because it makes my life easier :)
<jam> I'll *probably* do a 1.6rc2 today if at all possible
 * Peng_ predicts 1.6rc7 will be released on October 24.
<jam> Peng_: :) Martin is gone so I have release powers now
<jam> And I'm planning on forcing it out the door.
<Peng_> I'll believe it when I see it. :P
<pickscrape> Wasn't this a long release in order to get something in for the gnome project? Was it successful?
<Peng_> Are you sure you don't want to wait for groupcompress to be merged?
 * Peng_ hides.
<jam> :)
<beuno> jam, I'm here for the next 8 hours or so  :)   probably more
<cody-somerville> beuno, :-)
<jam> anyone know what markh's hours are? He seems to be only online late at night or early morning CST time, which seems a bit odd for someone in the US
<Peng_> jam: I'm in the U.S.
<Peng_> Maybe he's just crazy like me.
<jam> Peng_: you're online late morning :)
<Peng_> Yeah, my schedule is slipping.
<beuno> jam, isn't he in australia?
<james_w> yeah, that's what I thought
<jam> Well, according to this: http://www.swfwmd.state.fl.us/about/staff/hammond.html he is in Florida (yes I know that's not him :)
<jam> It was never clear to me where he lived, you could be completely right.
<jam> great, on non win32 WindowsError isn't defined, so you can't just blindly put it in your exception handler... :(
<jam> ah, but WindowsError is a subclass of OSError
<beuno> jam, his LP page says australia: https://edge.launchpad.net/~mhammond
<LarstiQ> jam: he's in .au
<jam> LarstiQ: you know, for how active you are  in #bzr, I'm surprised I don't see you at all on the mailing list :)
<LarstiQ> jam: that's scheduled for september
<LarstiQ> jam: I have been reading some mail again for starters.
<jam> what's in Sept? You start school again ?
<LarstiQ> stop school actually.
<jam> abentley: ping
<abentley> jam: pong
<jam> abentley: In the interests of getting 1.6rc2 out today, I want to make sure I've evaluated everything that people want to land
<jam> And I'd like a bit more info why your patch is necessary for 1.6
<abentley> jam: It fixes readability of "info" for branches in the new formats.
<jam> well, I'm getting something even weirder here
<jam> using bzr.dev
<jam> I get a traceback with
<jam> bzrlib.errors.UnknownFormatError: Unknown branch format: 'Bazaar Branch Format 7 (needs bzr 1.6)\n'
<jam> though that might be my 'nick' script
<abentley> jam: I can't reproduce that with bzr.dev
<jam> abentley: And this looks perfectly readable: http://rafb.net/p/Or1iue87.html
<jam> The indentation is a little odd, I guess
<jam> but not unreadable
<abentley> jam: It gets away with it because it comes last.  If both branch and working tree formats were multi-line descriptions, it would be very hard to parse.
<abentley> But it's always been a single line in the past, and I believe that's what people want and expect.
<jam> true, though arguably info-v should be updated to support multiple lines.
<jam> I kind of like the more verbose description
<jam> I'm willing to merge what you have
<jam> I'm just not sure I agree 100%
<abentley> jam: It's a very poor answer to the question "What is my repository format?"
<abentley> jam: additionally, the docstring for the RichRoot variant is flat-out wrong.
<jam> hmm... I find it a pretty good response
<jam> I agree that RichRoot is just wrong.
<abentley> jam: Not in my opinion.  It's not the reply I'd want on IRC, or when discussing things in email.
<jam> abentley: well *I* would want "RepositoryFormatKnitPack5" as that fully encapsulates it ,and is short for IRC, etc.
<jam> I don't think that is suitable for "bzr info" though
<jam> so I'm not sure if that is the best test
<abentley> It's a fine reply to "What does my repository format support, etc"
<abentley> jam: So how can people find out what their repo format is, if not through "info"?
<jam> abentley: well plain "bzr info" gives: Shared repository with trees (format: pack-0.92)
<jam> If we were going to do it *right*
<jam> then we should be using the short names for them.
<jam> for some definition of "right" because of the permutation problem
<abentley> It shouldn't say pack-0.92
<jam> abentley: that was a different repo
<jam> Shared repository with trees (format: 1.6)
<jam> If you prefer
<jam> I'm really tending on the "get 1.6 released" already and postponing everything that isn't an actual regression.
<jam> But if you feel strongly, I'll merge it
<abentley> Many are unhappy with using the short strings.
<abentley> Especially when you're talking about a shared repo or checkout where it could be one of many.
<abentley> The current docstrings are unacceptable to me because they don't say "RepositoryFormatKnitPack5" or something like that anywhere, and because they make false statements.
<abentley> I don't insist on fixing the multi-line thing for 1.6.
<abentley> Though of course, the simplest thing to do would be to apply my patch.
<jam> abentley: so you *do* feel like the strings need to be updated for 1.6
<jam> I'll probably just merge your patch
<jam> you know, I wish Thunderbird wouldn't include BB emails when I search by your name
<jam> I think it is because bb's email address includes yourname.com
<abentley> Yeah.  Sorry.
<jam> If I use your full name with a space, then BB is filtered out
<awilkins> jam: Would your proposed consideration of kind == 'file' to kind == None as a content change mean that the deltetion of a file would show up as a revision it participated in, in the log (desirable, IMHO)
<jam> awilkins: something else entirely
<jam> bzr log -v already does that
<jam> Just that bzr log -v file doesn't IIRC
<awilkins> Someone was asking about it last week and this reminded me
<jam> abentley: any chance you could look at: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48A307FB.7060905%40arbash-meinel.com%3E
<jam> I think it is the last patch which is specifically blocking 1.6rc2
<jam> Though you may not be comfortable reviewing it
<abentley> jam: I don't think I have time today.
<jam> It's rather small
<jam> just win32 specific
<awilkins> He wanted to know which revision a file(not in present inventory) was deleted in ; it's easy enough to extend bzr log to support --file-id, but then the log alas, doesn't show the deletion :-(
 * awilkins would review it if his vote carried any weight
<jam> awilkins: I'm well versed in the problem, and know why it is an issue
<jam> awilkins: all reviewers carry some weight
<awilkins> But if I voite, BB ignoreds me, right ?
<jam> BB probably does
<jam> That doesn't mean *I* would :)
<abentley> jam: I'm not supposed to be working on bzr during paid hours, and I'm in the middle of reviewing other stuff, and I have plans this evening.
<jam> I'm surprised you aren't supposed to do any bzr work, given that you are in launchpad-bazaar, but sure
<jam> I mean, you *did* just submit a patch because it effected LP :)
<jam> We just don't have any other reviewers in this TZ
<jam> Unless jelmer is awake ...
<awilkins> I can work on it during paid hours (with a clean conscience) as long as it benefits my project
<awilkins> I can work on it (with a dirty conscience) anyway :-P
<abentley> jam: It doesn't affect LP.  I've already overridden those strings for LP.
<jam> awilkins: :)
<jam> abentley: so I should make the request in #bzrlp, right ? :)
<abentley> jam: I don't think anyone there is awake and in my chain-of-command.
<jam> no, I just mean then it appears as a bzrlp request
<jam> We've taken longer discussing it than it would have taken you to review it
<jam> Don't worry about me, I'll find someone else
<awilkins> Pulling patches via URLs is very convenient
<jam> awilkins: I agree
<awilkins> jam: Well, it makes the test pass ; but I see a few other places where ENOTDIR is used
<jam> awilkins: sure, I'm just looking for a *regression* fix
<jam> not a full solution to all problems
<jam> For a release, I want it to not be worse than it was in the last release.
<jam> And we *really* need to get a release out the door
<awilkins> I suppose it does lower the footprint
<awilkins> jam: I agree about the release, building my own is a PITA (and worrying, if I've patched it off the main line)
<awilkins> This will fix my last issue with 1.6 (all my other patches are in)
<jam> beuno: ping
<jonnydee> jam: hi, regarding the bug https://bugs.launchpad.net/bzr/+bug/255656 -- what do you think? will my nomination for release 1.6 be considered?
<ubottu> Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when "bzr pack" is executed manually or when "autopack" is triggered on a repository located on a windows network share" [Undecided,New]
<beuno> jam, pong
<jam> jonnydee: well, the fix robert proposed isn't really an official fix, more of a workaround to see what the bug was
<jam> as such, I'm hesitant to make it into 1.6 without a real fix and test (as I'm trying to get 1.6 pushed out the door)
<jam> I would be surprised if it didn't land in 1.7, though
<jonnydee> so I will have to copy with this bug in release 1.6, too?
<jam> jonnydee: 1.5 performs the same, right?
<jonnydee> well, I'm not sure...
<jonnydee> sorry, I meant "cope"
<jam> jonnydee: I'm really trying to keep changes to 1.6 as regressions only
<jam> we have slipped 3 months because of delays
<jonnydee> yes, I understand...
<jam> when we get back into a regular release
<jam> 1.7 will come out within a couple weeks
<jam> so no big "must get it right now" issues
<jam> jonnydee: so... if it is a *regression* you have a chance otherwise, not really
<jam> beuno: any chance you could look at: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48A307FB.7060905%40arbash-meinel.com%3E
<jam> I figure 2 non-core people looking over the code for obvious flaws is enough for me to merge it
<jam> and then I'll be ready for 1.6rc2
<jonnydee> how can I support to get it to a *regression*
<jam> jonnydee: If 1.5 *works* and 1.6 *doesn't* that is a regression
<beuno> jam, sure, looking
<jonnydee> ok, I see
<jam> jonnydee: which is why I'm trying to get the "rm" patch merged
<jam> and not the 10 other things that are pending review in BB that I've written :)
<Toranin> jam: FWIW, the patch looks sane to me, presuming your comments on Python's behavior are correct
<Toranin> however, I've not read or worked on the context code at all
<jam> Toranin: thanks, we have some strong hints that it is correct because we've been using a variant in workingtree_4.py
<Toranin> my only concern would be that you strip the comment explaining WHY the exception is okay in the first use case
<awilkins> jam: I't OK on Python25 but for a (related/unrelated?) reason I am running into an error on Python24
<jam> awilkins: what specific test are you running?
<awilkins> jam: Is pywin32 supposed to be a cast-iron requirement for bzr on windows?
<jonnydee> anyway, thanks for your help! :) You do great work!!! :)
<awilkins> jam: I'm running test_switch, which is where I found it at first
<jam> awilkins: are you python extensions rebuilt?
<awilkins> jam: nope, hold on
<jam> I get: NotImplementedError: We must have one of fcntl, pywin32, or ctypes available to support OS locking.
<awilkins> awilkins: But I think it's because my Python24 lacks pywin32
<jam> but that just means I need to install pywin32
<jam> which sounds the same as yours :)
<beuno> jam, sent my thumbs up to the list
<jam> beuno: thanks
<awilkins> Does gmane work well for list posting?
 * awilkins has just used it to post approval
<awilkins> jam: That means that pywin32 is required to run the test suite?
<jam> awilkins: We either need ctypes or pywin32
<jam> Python2.5 bundles ctypes directly
<awilkins> Ah, yes
<awilkins> Hey, Python 2.6 !?
<jam> beuno: ok, well, I'll merge this patch, and one more to get the version strings to show 1.6rc2
<jam> And then I'll be ready for some packaging.
<jam> This won't be 1.6 final, so that people can respond to my comments in the 1.6 thread
<beuno> sounds good
<dato> heh, persona non gratis
<awilkins> Bugger, I meant "grata" didn't I....
<dato> :)
<pickscrape> Interestingly, bzr 1.6_rc1 is already available in the bzr gentoo overlay :)
<LarstiQ> jam: unless it's python2.5 on win64 of course, sigh
<pickscrape> Gah, ignore me. You're talking about rc2 aren't you. :)
<jam> pickscrape: yep
<jam> LarstiQ: yeah, but we probably have a raft of issues with p2.5 on win64 anyway
<jam> And nobody has stepped up to complain yet :)
<pickscrape> Is anyone aware of a problem deleting a symlink that points to a directory that doesn't exist?
<awilkins> They tried to get me to buy Vista64 at my friendly retailer
<rockstar> beuno, lp:~rockstar/loggerhead/unify-templates
<awilkins> I laughed in their face and burned their warehouse down
<Peng_> abentley: ping
<rockstar> I've moved the search and rss out of the menu
<pickscrape> It gives me: bzr: ERROR: Not a branch: "/path/to/symlink/target/".
<Peng_> abentley: I just got a mailer daemon error from a message sent to you (just a CC on a mailing list post). time limit exceeded: "procmail -a "$EXTENSION""
<jam> awilkins: well, I got your email from gmane, so it seems to work fine
 * beuno looks at rockstar's branch
<LarstiQ> jam: as does everybody else, yes.
<jam> LarstiQ: especially with the Py_ssize_t stuff
<beuno> rockstar, all changes look good to me
<beuno> I'm happy to merge, unless you want to wait for mwhudson and thumper to re-review
<pickscrape> Is it worth me raising a new bug about the fact that bzr rm <dangling_symlink> doesn't work, or it is amply covered by the existing bugs that deal with the same problem with other commands?
<beuno> pickscrape, I'd say it's worth it. If it turns out to be covered, it'll just get marked as duplicate
<beuno> rockstar, btw, if you ever want to test search, you just need to install the bzr-search plugin, and run 'bzr index' on the branch
<rockstar> beuno, I've addressed everything thumper had in the review.  I haven't seen a review from mwhudson yet.
<rockstar> Although, sometimes it takes him a few days.
<beuno> rockstar, I'll merge. mwhudson can yell at me later.  I think 2 reviews is more than adecuate
<TheEric> How does one reconcile without using ssh?
<rockstar> beuno, :)
<beuno> TheEric, bzr reconcile sftp://...
<TheEric> k, I'm going to try that approach to reconcile our current app as the ssh method evidently doesn't work.
<beuno> TheEric, good luck  :)
<TheEric> fail. Paraminko needs to be installed.. Bah.
<beuno> TheEric, it should be installed by default.  You're on windows, right?
<Manfre> i had the same problem yesterday, gave up since pycrypto needed vs2003..i only have 2005/2008
<Manfre> beuno, it's not installed by default for python 2.5 installer and not for 1.6 bzr iinstaller
 * beuno pokes markh 
<beuno> I don't know much about windows anymore. Mark may be awake already
<TheEric> Gotta love university bandwidth. Downloads around 1000kb/s
<beuno> rockstar, merged
<rockstar> beuno, great, thanks!
<Peng_> Ooh.
<Peng_> beuno / rockstar: The feed button on /changes is broken (not the <link> tag, just the regular old <a> next to the search box).
<Peng_> <a href="Exception: name 'url' is not defined" title="RSS feed for /my/branch">
<rockstar> Peng_, ah, thanks.
<rockstar> beuno, I'll fix it in the existing branch, and you can just merge it again.  Sound good?
<beuno> rockstar, yeap
<beuno> Peng_, as always, you rock  :)
<Peng_> :)
<jam> beuno: There is a release candidate tarball that has been uploaded.
<jam> I'm sending the announcement now
<Peng_> Whee.
<rockstar> beuno, the fix is ready for merging.
* jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6rc2! /  http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/
<beuno> jam, I'll upload packages then.
<beuno> rockstar, cool, I'll merge
<rockstar> I also checked to make sure that nothing else is broken.  :)
<beuno> rockstar, pushed. Sorry I missed that in the review
<rockstar> beuno, yea, I missed it as well.  It happens.
<beuno> jam, when do you expect 1.6 final to be out?  this week?
<jam> beuno: ASAP, within a week if nobody complains about the release
<jam> markh: I would like you to make full-fledged installers if you can. If not, I can put together some bzr-lite ones (I won't be including tbzr, etc.)
<beuno> jam, because it may be worth uploading 1.6rc2 hardy to the ~bzr PPA too, since there's no bzr release on it now
<jam> beuno: can't we just copy the one from gutsy?
<jam> I'm not a big wizard on the ppa side of things
<jam> but I thought the gutsy and hardy package were identical
<beuno> jam, copying packages breaks stuff. I haven't gotten them to work. Ever.
<beuno> there are theories
<beuno> I can try it again
<beuno> last I heard, copyong gutsy -> hardy should be fine
<beuno> but it tends to not work
<beuno> oh, and we can't have 1.5
<beuno> since we already uploaded 1.6b2 before
<jam> "can't have 1.5" ? ouch
<beuno> so it's 1.6b3+
<beuno> yeah
<pickscrape> That seem like quite a limitation to the PPA system.
<jam> well, in that case I'd do 1.6rc2, but still crappy
<jam> pickscrape: you *can* have old versions, but it won't recommend them
<jam> if something newer has been uploaded and then subsequently removed
<beuno> pickscrape, it's apt, not ppa
<jam> beuno: so I believe you *can* explicitly request 1.5
<beuno> jam, ok, cool. I'll upload to both
<jam> beuno: only for hardy though on ~bzr
<pickscrape> Even if you never installed the previously uploaded version?
<jam> beuno: and don't forget the bzr1.6~rc1 :)
<beuno> jam, there may be stuff in place on PPA to prevent that
<beuno> jam, yes, and yes  :)
<beuno> I'll run it by you before uploading
<jam> pickscrape: if you use the 'any' filter you can see it: https://edge.launchpad.net/~bzr/+archive?field.name_filter=&field.status_filter=any
<jam> there is a bazaar1.5 there
<jam> It has status "superseded" though, and it is superseded by the deleted package :(
<jam> beuno: are you sure Superseded isn't only a ppa thing?
<pickscrape> But isn't that status defined on the PPA side, or would changing it break apt?
<beuno> jam, yeah, it works that way everywhere else
<james_w> beuno: you can re-upload 1.5
<jam> james_w: but isn't it superseded by something newer?
<jam> james_w: I mean, the 1.5 package is *still there*
<james_w> just give it a version of "1.6b3+really.1.5-1" or similar
<jam> james_w: evil
<beuno> james_w, right, dato proposed that, but it seemed like too much of a hack
<pickscrape> but crafty :)
<james_w> there's plenty of precedent
<beuno> and, well, 1.6 has been "almost" out for a while now  :)
<jam> james_w: with the downside that 1.6b3 will be "upgraded" to 1.5, right?
<james_w> yeah, if you had the ~bzr ppa, but not the ~bzr-beta
<jam> beuno: well, I'm planning on pushing really hard to see that it does
<james_w> that's normally the intention when you do that
<jam> There was really only 1 thing that Martin had on his list that I'm skipping
<jam> but I have to wait for AU time for everyone to respond to my plans
<jam> beuno: are you going to be around in 48 hours? (My friday)
<beuno> jam, I can't upload to ~bzr-beta-ppa, I haven't been approved
<beuno> jam, yeah, I'll be here friday
<TheEric> well, that reconcile failed with the sftp://
<TheEric> http://pastebin.com/m65dc1423
<jam> beuno: well, we'll have to see if *I've* been approved :)
<jam> I think martin added me a while back
<jam> if you can put them somewhere, I'll upload
<beuno> jam, yeah, you're approved. Once I upload succesfully to ~bzr, I'll place em somewhere so you can upload them to ~beta
<TheEric> Here's the .bzr.log file - http://pastebin.com/m13f08af1 to go with that failed reconcile.
<jam> beuno: once you upload it, I can actually just copy it directly to ~bzr-beta-ppa using LP's copy package feature
<beuno> jam, for hardy you can, not the rest
<jam> beuno: can't I copy ~bzr/hardy => ~bzr-beta-ppa/hardy
<jam> and then copy /hardy => /gutsy, etc ?
<jam> Just not dapper
<beuno> jam, nope. It broke every single time we did that with poolie
<jam> well, that's pretty crummy
<jam> james_w: what's up with that ?
<beuno> OTOH, it's rumoured that uploading to, say, feisty, and then copying "upwards", works
<jam> beuno: was it just a dependencies thing?
<james_w> beuno: what broke?
<jam> and does it change if you check the "copy binaries" flag?
<james_w> if it's just a source copy and you are re-uploading the same source then I would assume it works, but I am probably missing something
<beuno> james_w, dependencies
<beuno> if you re-upload, and it re-builds, it's fine
<beuno> if you copy, it's not
<james_w> yeah, they are generated at build time, so I would have thought that a source copy would cause a rebuild and that would work
<jam> james_w: so you think that copying without checking the "copy binary" should work?
<james_w> that's what I thought, but it hasn't worked previously
<beuno> jam, bzr_1.6~rc2-1~bazaar1~hardy1
<jam> beuno: I thought we weren't doing the ~hardy1 thing ?
<beuno> jam, I'm not, but poolie kept on doing it
<jam> Just plain ~bazaar1
<beuno> yeah, I like that more
<jam> as long as there is precedence, I guess
<james_w> you should to provide an upgrade path
<jam> james_w: but then you have to edit it for each one
<james_w> jam: yup, it's a pain
<jam> to do ~intrepid1, ~gutsy1, etc.
<jam> james_w: and how does *that* work with copying?
<beuno> jam, it copies ~release1
<james_w> don't copy if you are doing that I think
<beuno> which is confusing  :)
<jam> beuno: so if you copy ~hardy1 => gutsy, it changes that value?
<miracle2k> am I crazy or is there now way to link to the latest revision of a file in the launchpad browser?
<beuno> jam, nope
<awilkins> markh: Are you win32 release builder?
<beuno> miracle2k, where are you looking?
<miracle2k> beuno: say I want to link to the latest README.txt from: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/files
<beuno> jam, I'd say, leave ~hardy1, etc, don't copy, and have a talk with poolie when he gets back from vacation
<jam> beuno: um, then I have to re-upload everything
<beuno> miracle2k, ah, I don't think we have a direct link for that now
<jam> miracle2k: There is a secret revision "HEAD" that you can use, just a sec
<beuno> jam, your call. I'll do either
<jam> beuno: I'll just upload it, but I worry because I've never *actually* successfully built and uploaded packages
<jam> way too much hassle to do the N-way release thing
<jam> beuno: this gives me an "internal server error": http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/head?file_id=readme.txt-20061211064337-5lpgd5knbgm7jrgz-2
<jam> I thought that was the right way
<beuno> jam, http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/head:?file_id=readme.txt-20061211064337-5lpgd5knbgm7jrgz-2
<jam> ah 'head:'
<jam> the ':'
<jam> miracle2k: ^^
<miracle2k> jam: thanks a lot!
<miracle2k> the extra stuff in the file_id just refers to the branch itself I assume?
<beuno> miracle2k, it's the unique ID for that file
<beuno> we will probably address that in the next release
<jam> beuno: wasn't there a path= that you could use?
<jam> miracle2k: so using a file_id, means that if you rename the file, it will follow the rename
<beuno> jam, no, I don't think you can use paths ATM
<jam> beuno: so, you have the package available, or it has been uploaded?
<jam> beuno: hmm.. I was pretty sure it used to work, but not that *I* really care
<beuno> jam, uploading hardy to ~bzr
<miracle2k> jam: I get that, but I guess I am confused by the fact that the filename itself is included as well. but nvm, I'll have a closer look at the bzr internals at some point
<beuno> jam, I've never used the path bit, and I can't think of any part of the code that would do it. That said, Loggerhead still has some unexplored places, so anything's possible
<jam> miracle2k: when you 'bzr add' a file, we generate a filename that starts with the path
<jam> after renames, etc, it keeps the original id
<jam> beuno: I just thought someone posted a link using head: and path= as a "nice" url that wasn't exposed anywhere.
<jam> You just had to know it existed.
<jam> But I would guess you have as much info about LH as anyone anymore
<beuno> I remember the head:, because we use bzr's magic underneath.  path escapes me, but, again, it wouldn't shock me that it's hidden somewhere. mwhudson is good with those things
<beuno> jam, [PPA bzr] Accepted: bzr 1.6~rc2-1~bazaar1~hardy1 (source)
<jam> beuno: well the obvious "path=README.txt" doesn't work
<jam> certainly it is just a "path2id()" away
<beuno> jam, maybe we can get a LP admin to approve me in ~beta instead of us uploading/downloading, etc?
<Peng_> Yeah, the feed thing is fixed. :)
<Peng_> Thanks.
<jam> beuno: yeah, poolie added lifeless and I as "Members" but not "Administrators" so we can't approve you.
<jam> I started the copy to ~bzr-beta-ppa
<jam> Which seems successful and seems to want to build binaries for it
<beuno> jam, wanna try copying to intrepid/gutsy/feisty?
<jam> james_w: can you mark a package "Needs building" ?
<jam> beuno: I can certainly try it, right?
<jam> worst case we just upload them directly?
<beuno> yeap, with -2 in 'em
<james_w> jam: don't think so, it should happen automatically if you didn't copy binaries
<jam> james_w: Well, I just tried to copy ~hardy1 => intrepid, and it gave me:
<jam> The following source cannot be copied: bzr 1.6~rc2-1~bazaar1~hardy1 in hardy (same version already building in the destination archive for Hardy)
<jam> james_w: It seems the "series" field isn't being respected?
<jam> Maybe it is being overloaded by the ~hardy1 ?
<beuno> hrm
<beuno> maybe PPA's don't allow the same package in 2 different places?
<jam> beuno: well, that negates the *point* of the copy feature, right?
<jam> I mean, if you can't actually copy to another "Destination Series" then you really can't do anything
<jam> other than between PPAs
<jam> but certainly they are trying to give the option
<beuno> jam, unless it's for a different release, but yeah, I can't get my head around copying in PPA
<jam> beuno: and, of course, there is "expected behavior" and there is "bugs"
<beuno> exactly  :)
<jam> That's why I'm trying to poke at james_w to see what category this sort of thing falls under
<jam> https://help.launchpad.net/PPA?action=show&redirect=PPAQuickStart#Copying%20packages
<jam> Is pretty vague
<james_w> I've never done a package copy, I agree with your expectation of this though jam
<jam> Really, it just says what you should expect on the page
<james_w> it sounds like it's trying hardy->hardy
<jam> and not really what you should expect it to actually do
<james_w> maybe #launchpad ?
<jam> james_w: it does indeed, but I'm definitely changing the "Destination Series"
<jam> trying there
<[reed]> How do I kill a stuck lock on a bzr repo? Trying to commit to a local repo, and it says there's a lock. The pid it claims the lock belongs to doesn't exist (it did the first time, but it's been killed since then).
<awilkins> bzr break-lock
<[reed]> thanks!
<beuno> OMG, jam names his PC after pokemons!
<LarstiQ> beuno: you didn't know? :)
 * LarstiQ fondly remembers jigglypuff
<beuno> no, I should pay more attention
<Peng_> I didn't know. Nice. :)
<Stavros> hello
<Stavros> is there a bzr repo that has the current version of bzrtools?
<Stavros> right now i can install either the latest bzr version or bzrtools :/
<lifeless> jam: ^ I think perhaps you uploaded a beta to stalle ppa?
<beuno> lifeless, I did. There was no bzr for hardy
<beuno> so, I thought, better 1.6rc2 than nothing
<beuno> of course, this breaks bzrtools
<beuno> *sigh*
<beuno> and, good morning lifeless   :)
<Stavros> is there a solution for the bzrtools problem?
<beuno> Stavros, you can uninstall it, and install from source
<Stavros> beuno: but that way it won't be tracked
<beuno> Stavros, right. The other option is wait until someone has time to upload bzrtools 1.6  (is that even released?)
<Stavros> ah :/
<beuno> sorry about that
<Peng_> You could install bzrtools from source, and delete it once an update is available.
<jam> beuno, LarstiQ: Actually after Super Smash Brothers
<jam> Samus == Metroid lady
<jam> Jigglypuff was my old mac
<jam> lifeless: Kiko on #launchpad determined that you *can't* use the copy feature of LP to copy between distributions within the same archive
<jam> because it can't rename the package
<beuno> jam, right, right, smash brothers  :)
<jam> So it would get naming conflicts.
<beuno> jam, btw, uploading for dapper now, that should be the last of it
<jam> beuno: SSB with sudden death mode, and all Jigglypuff characters was very entertaining
<lifeless> jam: AIUI we shouldn't ever be using copy
<jam> lifeless: well, copy is mentioned in the docs
<jam> because it would make our lives a lot easier
<lifeless> our docs or launchpads?
<jam> and you *can* copy the package from ~bzr-beta-ppa => ~bzr
<jam> lifeless: ours
<jam> and launchpad hints that you can use it
<jam> but gives very little as to what to expect.
<lifeless> right, but it lies :)
<jam> LP will *let* you say that you want to copy X package to the same archive
<jam> but that never works
<jam> unless maybe you copy the binaries
<jam> but then you likely have problems with deps
<lifeless> jam: full test run of .bzrrules disabling code is running now
<jam> lifeless: well, you also have to convince at least one other person that it is *correct*, as I don't really think it is.
<lifeless> jam: I've convinced three others
<lifeless> jam: Ian, Jelmer, and Martin
<lifeless> though to be pedantic, Jelmer came preconvinced
<lifeless> and if I could find this damn email rant from Aaron back in the day I'd have more evidence
<strk> bazaar thinks I hold a lock, but I've no bzr process running
<strk> any way to further debug the issue ?
<lifeless> strk: we don't use oslocks, so thats possible
<lifeless> strk: what does bzr break-lock say about the lock ?
<jam> lifeless: If you've convinced Ian, I'm okay with it. I think it falls into the "we keep saying this isn't the right way, but we provide no better way so we have nothing".
<strk> prompts me to break it, said yes
<strk> said it was hold by me (my email)
<strk> one hour, 30 mins
<strk> it was after a merge from trunk
<lifeless> jam: I've just reread Ian's mail to me, I think I had agreement there is an issue.
<lifeless> jam: I'm forwarding it to you
<lifeless> strk: something must have hard-interrupted bzr
<lifeless> strk: e.g. SIGKILL or SIGHUP
<strk> possible
<lifeless> strk: we can't use OSLocks over the network; so we don't use them for data structures that are network accessible
<beuno> jam, all debs uploaded and published
<jam> lifeless: I'm also responding with the last post I saw from igc on the mailing list
<jam> lifeless: or two SIGINTs at the right time (one while we're cleaning up is sufficient)
<jam> beuno: thanks a lot!!
<beuno> jam, my pleasure. You should milk this as much as possible, before I actually get a manager assigned and have something specific to do  :)
<lifeless> jam: did you have more feedback on the inventory docs? I think I have enough to recast it as a tighter set of needs if you don't
<jam> lifeless: I have an email for you I'm finishing, but right now I have to pick up my son from daycare.
<lifeless> jam: go then
<lifeless> jam: think you'll get it to me today?
<thumper> could I get someone who knows about reconcile to take a look at https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/257340 please?
<ubottu> Launchpad bug 257340 in launchpad-bazaar "Revision History set to 0 following push" [Undecided,New]
<thumper> it is beyond me
<lifeless> jam: on the rules stuff
<lifeless> jam: I had a conflict of interests in my head back at the start of the yea
<lifeless> *year*
<lifeless> as a community guy I wanted to flat veto designs involved versioned user files
<lifeless> as a canonical guy I wanted to see features land as fast as possible
<lifeless> I've wrestled with myself and come to the conclusion that landing the wrong thing isn't right for anyone
<lifeless> which is why I'm engaging on this topic again
<luks> I wonder how do you want to handle historical data if you don't version .bzrrules
<samatwork> does anyone know how to fix a bzr: ERROR: not well-formed (invalid token) error?
<samatwork> I've looked all over for an error that explains it and I know that many have had it, but I didn't see any clear-cut solution
<james_w> samatwork: hi, I've never seen that before, do you get a full backtrace, or just that?
<samatwork> just that
<samatwork> I'm getting it on all clients that are referencing a central repository
<samatwork> I fibbed it it also gives a line and column number, but I have no idea what this is referencing
<samatwork> can't find anything at launchpad either
<james_w> could you please run with "-Derror" as an extra command line argument to get a backtrace, and then pastebin that?
<james_w> ubottu: paste
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<samatwork> here you go .... http://paste.ubuntu.com/37261/
<james_w> samatwork: what about "bzr -Derror update"?
<lifeless> luks: its not about historical data; its about decoupling representation and function
<james_w> if it's the same then the problem is on the remote side, I think
<lifeless> luks: if you want to to a fix for squid 3.0, on windows, you need EOL translation
<lifeless> luks: but the 3.0 revision doesn't have .bzrrules
<lifeless> luks: so I think having .bzrrules in the users tree is fine as a presentation layer today
<lifeless> luks: but I want us to retain the ability to change representation in the future; without requiring a 'dump and reload' approach
<lifeless> luks: think about CVS 'b' flags - they were not per-branch, there was no 'propogation' needed
<samatwork> james_w: http://paste.ubuntu.com/37263/
<samatwork> looks like it has something to do with an unexpected inventory format
<james_w> it looks like corruption of the inventory on disk
<samatwork> it must be on the side of the repository though since all clients point to it return the same message
<samatwork> any thoughts on how to fix this short of recreating the repository?
<james_w> I'm not sure
<james_w> lifeless: any hints for samatwork?
<jam> lifeless: my response has been emailed
<lifeless> james_w: I'd use repository.get_inventory_xml to get the raw xml and look at it
<jam> lifeless: I understand your concern, but I also feel you have at least 2 major things on your plate for 1.7
<lifeless> samatwork: are you using bzr-svn ?
<jam> bringing in a 3rd is not really going to happen
<samatwork> lifeless: nope just straight bzr
<lifeless> jam: If it needs to happen to avoid a mistake, it needs to happen
<lifeless> jam: its a lot less stressful for me to do that than to see .bzrrules go in as-is
<jam> I also have to say that the last messages from IGC don't look like agreement
<lifeless> it will make nested-trees harder, join-tree and split-tree, it won't solve the usability problems the folk that I know that want EOL stuff on windows have
<jam> They pretty much say "we need something, and this is the path of least resistance"
<jam> which is where I fall
<jam> I fully understand your conflict of interest
<jam> And feel the same way
<lifeless> if I had resolved it previously, I would have bb:vetoed this code
<jam> I probably am more on the "frustrated by not having things like nested trees"
<jam> for *years* now
<jam> in any form
<lifeless> full ack
<jam> and taking what, >1 year to get any real in-core tags
<jam> and we still have non-optimal ones
<lifeless> note that git doesn't version its tags
<jam> I guess sort of like the OpenGL 3.0 release... wait a year, and still get only something incrementally better.
<lifeless> jam: that is because noone is spending time on these things, not because its a particularly hard problem
<jam> lifeless: well, we had several designs that were possible
<jam> and it was fundamentally a trade-off
<jam> between complexity and handling all cases
<jam> In git, moving a tag is a bad deal
<jam> which it pretty much is in bzr as well
<jam> trying to get it to propagate
<jam> and deleting anything doesn't work
<jam> (well, it deletes locally, but never propagates, etc)
<jam> different topic... With LP, if I upgraded from Knit => pack-0.92 when  I upgrade from pack-0.92 => 1.6 won't that cause a problem with the backup.bzr directory?
<jam> Is there a simple way to delete that?
<jam> (Other than going in with abentley's hitchiker and doing a sftp deltree)
<samatwork> thanks for the help everyone... I have to run
<lifeless> jam: they are just refs in git, and their ref management is quite sophisticated
<jam> lifeless: specifically, change a tag and pull into the next repo
<jam> it won't propagate
<jam> well, maybe just merge
<jam> I think if you force a pull it will overwrite
<jam> And I don't know about delete
<lifeless> jam: I think you need hitchhiker
<lifeless> jam: I'd file a bug on lp :P
<jam> lifeless: I'm not doing it right now, I'm just upgrading a Knit repo
<jam> and realizing we'll probably have a problem later
<ben__> Hi! I have a question on how to clean up a repository e.g.:
<ben__> bzr init-repository foobar
<ben__> bzr init foobar/trunk
<ben__> bzr branch foobar/trunk/ foobar/feature
<ben__> dd if=/dev/urandom of=foobar/feature/random count=10000
<ben__> bzr add foobar/feature
<ben__> bzr ci foobar/feature
<ben__> du -sh foobar/.bzr
<ben__> 5,0M  foobar/.bzr/
<ben__> how do I delete the branch feature out of the whole project?
<Peng_> ben__: You pretty much don't.
<ben__> theere
<ben__> there is no way?
<james_w> ben__: you mean you want to discard the branch, and free up the used disk space?
<ben__> yes
<ben__> the docu says i just have to rm foobar/feature
<james_w> yeah, but that doesn't free up the space
<ben__> but then I have the wasted space in .bzr
<ben__> yes
<james_w> there's no simple command to do this at the moment
<ben__> is there already a bugreport (featurerequest) for this?
<james_w> what you basically have to do is create a new repo, branch the branches you want in to it, and then delete the old one and move the new one in to place
<james_w> I'm not sure
<ben__> yes, that solution came into my mind, but it is not very niceâ¦
<james_w> no, it's not great
<james_w> there's an experimental plugin to do it in one go if you want to test that
<ben__> yes, of course ;))
<ben__> but i didn't found one doing this at the homepageâ¦
#bzr 2008-08-14
<markh> jam: the win32 binaries I'm putting together will have at least a couple of patches from 1.6 (setup.py/inno) - how do you feel about me also keeping those other test suite changes in?  But if you think its important we only apply strictly necessary patches I'll back them out of my local tree.
<jam> hi markh
<markh> hi john
<jam> I'd rather have it be stock 1.6 if at all possible
<jam> For example, getting those patches in, would be something to get into 1.6 final
<markh> I guess you'd say that, which is why I thought I better ask ;)  np
<jam> And would have been something I would have liked mentioned earlier....
<jam> Supporting multiple versions is a real pain whenever there is skew
<markh> what would you have liked mentioned earluer?
<jam> markh: that you are going to need the setup.py/inno patches for the win32 release
<jam> So I would rather bring in something with a bit of cruft if it is going to be the *official* version anyway.
<jam> Though I'd really rather not bring in cruft :)
<markh> these are the same patches I've previously sent for the build process.
<spiv> jam: here
<jam> So... standup meeting for 2008-08-13
<markh> with yet more tweaks as I find issues in testing, such as uninstall problems, etc
<jam> spiv: what are you working on today and yesterday
<jam> markh: I understand the patches you are describing, I wish you had nominated them as 1.6 patches.
<jam> Since you are going to use them for a 1.6 release
<jam> hence.... they need to be in 1.6
<markh> they aren't complete - I last made a change 3 days ago to it
<spiv> Yesterday I got the improved testing docs merged, reviewed some of lifeless's stuff, and made a bit of progress on the HPSS effort tests.
<spiv> Today I'm going to focus on the effort tests, plus mentally willing 1.6 to get released ;)
<jam> markh: I would rather you focused on getting something complete, that can be a 1.6 release, than having it perfect.
<jam> We can make it perfect for 1.7
<spiv> 1.7 isn't very far away, after all.
<jam> markh: I'll be the 1.7 manager, and if I have any say about it, we'll follow a strict timetable
<jam> so pushing 1.6 back
<jam> means that 1.7 will release the next day
<jam> spiv: ok, today was focused on getting 1.6rc2 out the door
<jam> which was successful
<markh> I don't see a huge issue in me releasing my "bzr + tortoise" binaries called "1.6" when they are infact 1.6 + 2 build/installer related patches
<markh> with zero changes to bzr itself
<spiv> jam: hooray!
<jam> markh: Because I can't do "bzr co http://bazaar-vcs.org/bzr/bzr.1.6" and get what we released as bzr-1.6-win32
<jam> markh: aka, I can't easily *reproduce* your work
<jam> It is all on *you*, and I'd rather have it in the system
<jam> markh: If you feel it isn't really worth merging, perhaps it could be a bzr-1.6-win32 branch or something
<jam> but I'd really rather avoid that.
<markh> if I publish those 2 patches, and those patches are only related to the binaries built that include tortoise, then I really don't share your concern.  Release a stand-alone binary without tortoise using the existing setup.py if it bothers you that much
<jam> I *really* want a snapshot we could use.
<jam> markh: I don't want you to be the only person who can make a release of the official binaries. I think that is a valid concern.
<jam> I think for development processes
<jam> having the release be
<jam> tag the branch
<jam> 'make dist'
<jam> publish results
<jam> is a wonderful workflow
<jam> Having it be
<jam> make dist
<jam> then apply 3 patches
<jam> then make win32-installer
<jam> etc
<jam> is not a good *process*
<jam> which is what I'm trying to avoid.
<jam> spiv: Tomorrow is more triaging to make sure we are ready for 1.6-final, as well as getting my stuff together for 1.7 Metronome emails
<jam> (something we have also been missing)
<jam> TWiB should also be happening tomorrow
<jam> as I've missed it for 2 weeks now.
<jam> rockstar: ^^
<jam> And I'd *like* to get to bringing the btree code into core bzr
<jam> I may not get that far.
<jam> lifeless: speaking of which, I'd like to hear your thoughts on a 1.6-final that had the log regression.
<jam> Martin seemed to feel it was a critical blocker
<jam> but he's not here to expand on that
<spiv> TWiB?
<spiv> Oh, right
<jam> This Week in Bazaar
<markh> yes, I agree its not a good workflow and I don't propose it as an ongoing process.  Regardless, I consider myself appropriately scolded
<jam> markh: So make them public, I'll merge them for 1.6-final
<jam> and the problem is solved :)
<jam> As long as they are *usable*
<jam> You've convinced me about bundling TBZR
<jam> And you've almost convinced me about paramiko
<markh> that wasn't your approach when you reviewed them last time!
<jam> markh: I need a release
<jam> that causes friction :)
 * awilkins can build the win32 stuff (up to the python installers so far)
<jam> I don't want to use an ad-hoc release unless we must.
<jam> awilkins: I can build the installers, but I would like to have our "official" build, which will be TBZR + qbzr, etc.
<jam> Either we get it for 1.6
<jam> or it gets delayed to 1.7 IMO
<awilkins> Hmm.
<markh> I'll get it to you in an hour
<jam> I'd rather not have an ad-hoc build for 1.6
<awilkins> Is qbzr better than Olive?
<jam> markh: If they are as unintrusive as you say, I'll be okay bringing them in for 1.7
<johnf> anyone about that can help me track down #254797, _read_bytes not defined when using smart protocol
<jam> awilkins: It is more Windows-like
<jam> as it is built on QT
<jam> there are tradeoffs between the two
<jam> qlog is better than bzr viz (IMO)
<jam> but gannotate is better than qannotate
<awilkins> bzr viz is what I use most
<jam> awilkins: qlog allows folding merges
<awilkins> Hows the conflict dialog?
<jam> which is *huge* for me.
<spiv> johnf: I can
<jam> awilkins: I don't know that qbzr has conflict handling yet.
<spiv> johnf: in a few minutes
<johnf> spiv: cheers
<jam> spiv: I ran into that for _urllib when BB was not giving proper 404's by the way.
<awilkins> I have a patch to the bzr-gtk conflict window for starting my favourite win32 merge tools
<jam> spiv: anything else?
<jam> (for standup)
<markh> awilkins: wrt qbzr and tortoise, its probably fair to say we see better potential in qbzr, rather than thinking qbzr is already more "complete"
<jam> markh: Sounds good. I'll look forward to reading them tomorrow. If you are up late, I'd love to chat with you a bit
<jam> both about the locking issues you were seeing
<markh> and more potential specifically in the context of tortoise!
<jam> and about your development, etc.
<awilkins> Anyway, bed time
<jam> But now is family time
<markh> np - thanks
<jam> I might also be around in a couple hours depending on when everyone sleeps.
<markh> The good thing is that all these branches is actually giving me real experience doing non-trivial merges :)
 * jam => away
<spiv> jam: interesting
<spiv> jml: no, not for the standup, thanks!
<n[ate]vw> is there any way to copy/move a file WITH HISTORY between projects?
<jml> spiv: not for what standup?
<n[ate]vw> I'm developing an app with components I'd like to eventually move into separate libraries
<lifeless> jam: reply, with worked example, which I think is what you wanted
<n[ate]vw> bzr move cannot move between branches, which would be where I'd expect to see that, but was wondering if projects within a combined repo gave any benefits like that
<lifeless> jam: catch you later
<lifeless> jam: I know that martin would really like to avoid the log regression
<lifeless> I'm not sure how to do that :P
<james_w> n[ate]vw: that's not possible as far as I know
 * markh wonders what will happen if he sneaks in a transparent version of bzr.ico rather than the one that is in the branch...
<n[ate]vw> james_w: so no plugins could either? basically, I'd be nice to take files like MyFloatStuff.c and MyMathStuff.c and put them into a separate "NumberLibrary" project without losing the histories
<james_w> n[ate]vw: not possible. You could take a branch and delete everything else from the branch and just have the two files from that point on
<n[ate]vw> that might work alright, especially if bzr ever gets horizons (?) or whatever they call branching just a recent history
<james_w> stacked branches are in 1.6, history horizon is a way off
<lifeless> uhm
<lifeless> bzr split
<lifeless> kthxdone
<james_w> lifeless: your rules patch still has "respectively" in the docs, now for a singular item
<n[ate]vw> james_w: seems like I just skimmed something about stacked branches, but do you have a link?
<n[ate]vw> lifeless: excellent, thanks
<lifeless> james_w: thanks
<markh> I gotta love "merge --reprocess" - it took a 74 line conflict region down to the 1 line it really is :)
<spiv> jml: your nick is too close to jam's :(
<spiv> jml: at least for these pre-coffee fingers.
<jml> spiv: you know the solution to that!
<lifeless> cut off the fingers!
<n[ate]vw> james_w: n/m found http://jam-bazaar.blogspot.com/2008/05/this-week-in-bazaar_29.html which was enough of a memory jog, I think I saw that in the checkouts help or something
<n[ate]vw> oh, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#using-stacked-branches is where I saw it, FTR
<lifeless> abentley: are you around ?
<lifeless> abentley: my fix to iter_changes to be consistent has found a bug in diff that would show up on non-dirstate trees
<lifeless> abentley: but I'm not sure of the right behaviour
<rockstar> jam, TWiB is acknowledged, with high priority.
<lifeless> markh: what does bundling mean?
<lifeless> markh: I hoep it doesn't mean 'import into trunk' ?
<markh> one sec...
<johnf> spiv: so it looks like medium.py is calling read_bytes on HTTPTransportBase but it's only implemented in SmartClientHTTPMediumRequest so maybe the read bytes should be on getsmartmedium??
<johnf> I'm totally poking in the dark here of course since I have no understanding of how this all fits together :)
<mwhudson> lifeless: i don't think abentley is aroudn
<lifeless> johnf: what bzr version?
<johnf> lifeless: 1.6rc2 and  bzr.dev seems to exhibit the same bug
<spiv> johnf: Ok, I'm looking into this one now.
<johnf> spiv: let me know if I can help at all
<johnf> spiv: I'm happy to look into it if pointed in the right direction
<spiv> johnf: I think I have an idea about what's going on
<spiv> johnf: I landed a change in 1.6 that tidied up a bunch of the logic around _read_bytes in bzrlib/smart/medium.py
<spiv> johnf: part of that I think was moving methods from the mediumrequest into the medium
<johnf> spiv: that makes sense
<spiv> It wouldn't surprise me if the HTTP code didn't quite keep up.  I thought I had fixed it (I definitely remember touching the HTTP code during that work), but I guess our test coverage is a bit lacking here.
<spiv> Ah, I think SmartClientHTTPMediumRequest needs to implement read_line
<markh> lifeless: the bzr binary will bundle a few other binaries too (bzr-svn, qbzr, tortoise).  The bzr.dev trunk's setup.py will get that capability, but no other code will be imported.  Is that what you were asking?
<spiv> Otherwise the default implementation falls back to calling that method on the medium, which is unimplemented in this case.
<lifeless> markh: cool; I was wondering if you intended to drop a copy of paramiko into the trunk etc
<lifeless> markh: that would have been concerning
<markh> lifeless: nope - just setup.py will kinda assume it is in-place when you make binaries
<lifeless> markh: windows binaries right ?
<markh> correct
<lifeless> kool
<markh> from a QA POV, we probably need to get the the point where setup.py nominates *exactly* what is bundled and fails if anything isn't there.  It shouldn't be possible to "forget" to include something - but that can wait...
<lifeless> spiv: bug 257730
<ubottu> Launchpad bug 257730 in bzr "bzr crashes during bzr pull" [Undecided,New] https://launchpad.net/bugs/257730
<spiv> johnf: ok, I have a probable fix in hand
<spiv> johnf: http://rafb.net/p/XvhCPc82.html
<spiv> lifeless: that looks like the same bug, thanks
<lifeless> yah
<spiv> jam: I'm going to ask for the fix I'm doing for #254797 to go in 1.6
<rick_h_> lifeless: ping
<lifeless> hi
<rick_h_> hey, first, thanks for the help on the article. The feedback from the head editor was great and it'll be out in pymag in sept
<rick_h_> got bumped up a month
<lifeless> cool
<rick_h_> I got asked to do a follow up article and I was thinking of covering a couple of workflows. Mainly a centralized (for the svn folks) and decentrailzed with share mainline
<rick_h_> as I think those two are pretty common/useful for a large group out there
<lifeless> sounds good
<rick_h_> is that your take or would another workflow better show off bzr or anything?
<lifeless> uhm
<lifeless> I think you should write about things you've experienced or played with
<lifeless> or helped people with
<rick_h_> ok, definitely
<spiv> It doesn't help that pycurl tests give (55, 'select/poll returned error') on my laptop.
<johnf> spiv: that did the trick. Thanks
<spiv> johnf: it has a bug, though :)
<spiv> johnf: you may also be able to work around it by prefixing "nosmart+" to the http:// URL.
<spiv> johnf: I'll send a polished patch to the list fairly shortly.
<johnf> spiv: except I'm using a smart server bzr+https://
<spiv> Ah, in that case not so much :)
<spiv> (The buglet is that there's a "return bytes" line in the _get_line function that needs to be "return bytes, ''"
<spiv> )
<spiv> (Probably not significant in normal use)
<Peng_> Whoever just branched from my server (LP?) managed to download half of a 2 MB pack once, then the entire pack twice. Good going, bzr.
 * Peng_ is away now.
<lifeless> Peng_: bleep
<lifeless> Peng_: same IP ?
<spiv> Peng_: That would be me and my squid proxy I think.
<spiv> Peng_: sorry!
<lifeless> spiv: upgrade it :)
<spiv> lifeless: get it backported to hardy (or point me to a PPA I guess...)
<lifeless> spiv: feh
<spiv> lifeless: that's my attitude too ;)
<lifeless> spiv: need a review for that patch"
<lifeless> ?
<lifeless> also, my rules one needs a review
<lifeless> and I'm wondering if we should file a bug on python for that 'cant write 80MB on smb reliably' bug
<spiv> lifeless: I will need a review soon, not quite yet.
<spiv> lifeless: hmm, probably.  what happens exactly?  Large writes get an EINVAL sometimes?
<lifeless> 22 whatever that is
<lifeless> bug 255656
<ubottu> Launchpad bug 255656 in bzr ""bzr: ERROR: [Errno 22] Invalid argument" when "bzr pack" is executed manually or when "autopack" is triggered on a repository located on a windows network share" [Undecided,New] https://launchpad.net/bugs/255656
<spiv> lifeless: yeah, I'd bugger a file
<spiv> lifeless: I wouldn't be very optimistic about it getting fixed, but you never know...
<jonnydee> lifeless: hi, regarding your solution to bug ï»¿255656: I was told here that the solution is considered to be just a workaround for a bug in python....
<jonnydee> and that workarounds are not likely to be merged into bzr 1.6
<Peng_> Ah, Squid. That would explain it.
 * Peng_ goes back to being away.
<jonnydee> what do you think? will there be a achance to get it merged into future revision (for the case python's bug doesn't get fixed)
<Peng_> spiv: You owe me $0.003 in wasted bandwidth!
<spiv> Peng_: I'll have to buy you 1 mL of beer sometime...
<lifeless> jonnydee: its a bug
<lifeless> jonnydee: bzr supports python 2.4, so we have to fix it in bzr
<jml> rockstar: btw, did you end up doing much with that plugin you were writing in Dunedin?
<rockstar> jml, yes, but I haven't polished it.  I didn't think there was much interest in it, so it got to my needs, and I quit.  :)
<rockstar> Would you like me to make an official lp project for it?
<warren> hmm, is there a way for me to edit the checkin message after it was committed?
<jml> rockstar: do you have a published branch at least?
<rockstar> jml,  no
 * rockstar is ashamed
<jml> rockstar: +junk!
<rockstar> jml, yea yea...
<Peng_> warren: If you haven't pushed yet, and it's the most recent revision, you can uncommit and recommit.
<warren> someone else committed it, but I want to edit the commit message before pushing it to the real trunk
 * Peng_ goes back to being away.
<mwhudson> Peng_: you don't seem to be very good at being away
<jml> lifeless: so, we still hacking on Saturday?
<jml> if so, where, when and can RAOF come too?
<lifeless> I want to buy lingua latina
<lifeless> I think lynne would probably appreciate a little space, so not here
<lifeless> sure RAOF would be good company too
<RAOF> Howdie.
<RAOF> My place _could_ work.  Possibly.  There's a table and couch and stuff.
<lifeless> RAOF: where is your place?
<RAOF> Kensington.  That makes it quite some way from both you and jml
<lifeless> indeedy
<lifeless> jml: whats your place like?
<jml> internetless.
<lifeless> jml: where are you now?
<jml> lifeless: spiv & Mary's place
<lifeless> ah
<lifeless> and next week ... ?
<jml> probably still up at Andrew & Mary's -- I've got a key.
<lifeless> well, there is a possibility. If spiv and mary would be happy with that.
<lifeless> I'll check in with Lynne when she gets home about doing it here
<jonnydee> lifeless: ahh, ok -- thanks, taht's good news :)
<Leefmc> Question: Does bzr have any problem with many commits? Ie, are tiny commits about fixing little bugs, etc, acceptable in BZR?
<james_w> Leefmc: absolutely
<Leefmc> james_w: K
<pickscrape> Anyone else used "Editra" before? I just learned of it today and it appears to have bzr support out of the box.
<jml> lifeless: Kensington isn't that far away.
<markh> where has spiv gone?
<markh> or going? :)
<markh> oh bugger - I see I should have put a 1.6 in the subject line for BB to see it targets 1.6...
<spiv> lifeless: if it means the plants get watered, then we can probably cope with that...
<spiv> markh: I'll be spending a couple of weeks in the South Island of NZ
<markh> ahh, nice :)
<spiv> markh: and trying not to cut my head open with a snowboard ;)
<markh> oh that's right - you do that regularly?
<spiv> Not very, which is probably the problem...
<markh> :)
<spiv> lifeless: fix for #254797 sent to the list, btw
<lifeless> spiv: cool
<lifeless> jml: I know where spivs place is better
<markh> let's all party at spiv's while they are gone!
<lifeless> jam: welcome back :)
<jam> lifeless: well, for a bit at least
<lifeless> so I sent in a patch, its really quite tiny
<fullermd> Mmph.  Has check gotten slower?
<jam> lifeless: so you basically just changed it so there are *no* per-branch config items?
<ToyKeeper> Hmm, I thought there was some easy, obvious way to split a subdir with history into a new branch, but I don't see it.
<jam> I thought the point was to not version them
<jam> not to disable them completely
<lifeless> jam: Martin's request was to disable it rather than not-version
<lifeless> as he says:
<lifeless> If this is not baked yet then I think it would be cleaner to remove
<lifeless> the feature of reading from this file, rather than specially blocking
<lifeless> it out from being committed.  We could still perhaps allow a branch or
<lifeless> plugin for trying filters to turn it back on.
<jam> ah, I do remember that.
<jam> Good enough I guess.
<jam> I still disagree with it, and I don't quite feel that Ian agrees, but I can accept the "lets postpone for now"
<lifeless> thank you
<lifeless> I'll merge that patch to trunk now then?
<jam> lifeless: please don't tie up the pqm yet :)
<jam> If I'm lucky, I'll get the 1.6 stuff merged that people want
<jam> and we can do a rc3 by tomorrow
<jam> so -final doesn't have to be delayed.
<lifeless> that would be good
<lifeless> I'll merge the rules after you go then
<jam> lifeless: It seems your patch is built on bzr.dev, not bzr 1.6
<lifeless> do you want me to merge it to trunk and 1.6, or you'll do the cherrypick ?
<jam> So I'll cherry pick it
<jam> and you can merge it directly to trunk
<lifeless> ok
<beuno> mwhudson, hi
<beuno> I just addressed your review on my diff branch
<lifeless> jam: on inventories; does my worked example demonstrate the things you were concerned about ?
<mwhudson> beuno: hi
<fullermd> lifeless: Did you ever get a chance to look back at bug 255155 (knit file permissions)?
<ubottu> Launchpad bug 255155 in bzr "bzr doesn't use the repository directory for permissions" [Medium,Confirmed] https://launchpad.net/bugs/255155
<mwhudson> beuno: oh right
<lifeless> fullermd: no, I haven't
<mwhudson> beuno: i still think the diff should be against compare_revid if there is one
<lifeless> fullermd: can you upgrade to packs ?
<beuno> mwhudson, and see 2 remaining bugs. The javascript one, I can squash tomorrow. bug #243415, not so sure about where to start
<jam> lifeless: Well you mention "minor variations" which doesn't seem to fit well with validators and "deterministic" values
<ubottu> Launchpad bug 243415 in loggerhead "Tracebacks go to console but not log file" [Medium,Confirmed] https://launchpad.net/bugs/243415
<lifeless> jam: I say that if we *don't do X* there would be
<lifeless> jam: the sentence before described X
<beuno> mwhudson, aaaaaaaaaaaah, I see.  I understand what you meant now.  I tend to ignore the fact that we have compare_id, since the UI for it is so ugly
<fullermd> lifeless: Well...   _can_.  would rather not, for non-technical reasons.
<mwhudson> beuno: yeah, but ...
<lifeless> fullermd: you have users using bzr < 0.92 ?
<fullermd> lifeless: No, but it means a soft-flag day of making everyone upgrade their branches (or swallow abysmal performance).  And there'll be a hard flag coming up shortly when the next and rich-root-capable standard format comes along (in 1.2 or something soon like that)
<lifeless> fullermd: the problem with permissions is they don't really work well enough
<lifeless> fullermd: huh? why would there be a performance hit?
<fullermd> I'd rather only ram that through once.
<fullermd> Because pulling from packs into knits was life-threateningly slow, at least last time I tried.
<fullermd> Re-annotating and all.
<lifeless> fullermd: please try again, it should not be
<lifeless> fullermd: make sure you have the C extensions
<beuno> mwhudson, I'll address the compare_id bit. Any ideas for #243415?
<fullermd> Hm.  I'll try to fiddle with that tonite...
<mwhudson> beuno: well, serve-branches still doesn't actually have a logging section, does it?
<lifeless> fullermd: slower-than-normal yes, life threatening slow - no, jam fixed that weeks ago
<beuno> mwhudson, it looks like it does, yes
<markh> jam: thanks for the approval.  Shall I upload my current rc2 binary directly to launchpad for the project and mail the bzr list, to try and get some feedback in time for a final?  Or would you prefer more controlled testing by people first?
<mwhudson> beuno: well, not one that sets up logging to a file ... ?
<lifeless> jam: this was the quote I think:"If we add a
<lifeless> constraint to the usual LPC rules that we must bubble compression
<lifeless> opportunities as high up the tree as possible, then yes. If we don't, I
<lifeless> think it is possible to have minor variations."
<jam> spiv: ugh... I just hit something nasty
<lifeless> jam: I was trying to be complete, possibly adding confusion.
<jam> I'm using bzr-email on a bound branch over bzr+ssh
<jam> and it seems to be doing the log on the bzr+ssh branch
<jam> and taking *forever*
<jam> markh: well, if beuno is up for it, we may have a 1.6rc3 tonight/tomorrow early
<jam> with your changes in it
<beuno> mwhudson, doesn't line 48+ do that?   http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/210?file_id=servebranches.py-20080618011543-s6ydx5c3bl38zap6-1
<markh> my rc2 binary has only those changes you just approved.
<markh> (oh - and an icon with a transparent background ;)
<beuno> jam, I can do rc3 tomorrow morning, sure  (~10hs)
<beuno> mwhudson, ignore me, it seems it doesn't
<jam> markh: ... what did I just mention about having the official build as part of core? :)
<beuno> mwhudson, I'm tired  :)
<mwhudson> beuno: fair enough :)
<beuno> mwhudson, so, not for 1.6?
<mwhudson> beuno: so loggerhead _should_ have logging and the logging _should_ capture tracebacks...
<mwhudson> beuno: but yeah
<beuno> mwhudson, ok, different bug to address
<beuno> mwhudson, how does releasing 1.6 this week sound?
<mwhudson> beuno: awesome!
<beuno> \o/
<beuno> jelmer even packaged it, so I can probably upload it to PPA
<beuno> pickscrape, how's your branch coming along?  can you make it this week?
<jam> lifeless, spiv: I would really like to include a NEWS entry with your changes.
<jam> Especially for "reasons why we went past an rc" I feel each commit should have a NEWS entry.
<jam> Could you write up a simple one for me?
<lifeless> sure, I guess
<mwhudson> beuno: that's a point
<mwhudson> beuno: how is loggerhead's NEWS doing?
<beuno> mwhudson, well, it's...  uhm...  we try not to push it too hard
 * beuno adds another task to his ToDo list
<mwhudson> i guess we should write some stuff
<mwhudson> beuno: oh, also, we have the issue that if i merge the current loggerhead trunk to launchpad's codebase
<mwhudson> beuno: it will go blue
<mwhudson> we should, um, do something about that
<beuno> mwhudson, ah, yeah, I'd have to merge && revert && commit. If you point me at the branch tomorrow, I'll merge it in
<mwhudson> beuno: ah yeah, that'll work
<Jucato> good day/evening. is there a logout equivalent to bzr launchpad-login?
<lifeless> Jucato: I don't think so
<lifeless> jml: ^
<jam> lifeless, markh, beuno, spiv: Well, after just submitting all 3 patches to the wrong branch (and having them all merged), I'm re-submitting them to the correct branch, and going to bed. I'll work on 1.6rc3 tomorrow.
<RAOF> Jucato: What would it do?
<lifeless> jam: :P
<lifeless> jam: what branch did they land on ?
<markh> jam: ack - thanks!
<jam> lifeless: bzr.dev
<lifeless> jam: also, re - log
<Jucato> before I used bzr launchpad-login <username>, this command worked: bzr checkout lp:~ubuntu-core-doc/ubuntu-doc/kubuntu-intrepid. after logging in, I get this error
<Jucato> bzr: ERROR: Repository KnitPackRepository ('file:///home/jucato/kubuntu-intrepid/.bzr/repository') is not compatible with repostiory RemoteRepository(bzr+ssh://jucato@bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-doc/kubuntu-interpid/.bzr/)
<lifeless> jam: do you have a minute before you go, I can work on it over your night
<spiv> jam: hmm, bzr+ssh should be unaffected by my changes
<spiv> jam: so I'm not sure why bzr-email would be slower...
<spiv> jam: good night.
<jam> lifeless: I've got a bit
<lifeless> RAOF: I think it would remove your credentials
<jam> just don't expect high quality discussions :)
<lifeless> jam: so, AIUI we previously called 'file_vf.versions()' which did the _prefix iteration triggering a full read
<jam> lifeless: something like that, yes
<lifeless> I propose a patch to do the following:
<Jucato> hm.. I just nuked ~/.bazaar and it works now again.. but the reason I logged in was because I got the note "You have not informed bzr of your launchpad login. If you are attempting a write operation and it fails, run "bzr launchpad-login YOUR_ID" and try again.
<lifeless> two things
<jam> spiv: I don't know that you specifically effected it, or if it just that 'bzr log bzr+ssh' is really poor
<lifeless> if the regions-unparsed ever reaches zero, convert the in memory structure to a full-buffered one.
<lifeless> actually no, rephrasing
<RAOF> Jucato: That error looks like you've got an already-existing directory?  Does it work trying to checkout to a new directory?
<lifeless> there is an open bug spiv was looking at on kubuntu-docs
<Jucato> RAOF: nope. I even rm -rf'ed the contents of that directory
<lifeless> I think its something what vis-a-vis repo format preservation
<Jucato> RAOF: I got it working for now by nuking ~/.bazaar. I'll wrestle with the problem again when I need to push something :/
<lifeless> jam: actually, scratch that - you go to bed, I'll get some stats together
<jam> lifeless: I think there are 2 performance bugs
<lifeless> jam: any particular size repo you were testing on?
<jam> 1 is that we don't trigger buffering
<jam> lifeless: http://people.ubuntu.com/~jameinel/mysql-unpacked.tar.bz2
<lifeless> thats going to hurt me isn't it
<jam> lifeless:  a mysql repository, with an "optimally unpacked" layout
<jam> its 652 MB
<lifeless> only got 700M free on disk
<jam> lifeless: It shows up with bzr.dev
<lifeless> I can't even download an untar it ;)
<jam> lifeless: so there is the "if we hit all of history, buffering is faster" bug
<jam> lifeless: and there is the "requesting all (file_id, revision_id) tuples" from a knitpack repo issue.
<jam> I don't know which is the bigger issue
<lifeless> whats the second one?
<jam> lifeless: misses in the knitgraphindex
<jam> it has to bisect search for every non-existing key, into every pack file
<lifeless> right
<jam> so 20 pack files, require 2 bisect searches * N missing keys
<jam> 'require 20 * N'
<lifeless> its the same problem
<lifeless> ok
<lifeless> go sleep, I'll see if I can generate a hack for 1.6/.dev
<jam> I suppose a dict lookup miss is significantly faster
<jam> lifeless: just don't over-engineer it for a regression quickfix :)
<lifeless> jam: we need to fix it
<lifeless> I jave 4 and a bit hour until I raid, so there is time
<beuno> mwhudson, pushed the changes with compare_revid.  I'm heading to bed now, and start tomorrow with the remaining bug + NEWS updates
<mwhudson> beuno: excellent
<beuno> (what I did feels a bit hackish though)
<jam> lifeless: I just feel that if we could get a peak into the per-file graph, we could do it a lot cheaper by walking the ancestry
<jam> without having to buffer_all.
<lifeless> jam: but we do that
<jam> lifeless: by grabbing every possible key, which is bad for KnitGraph.
<lifeless> we do modified_text_versions = branch.repository.texts.get_parent_map(text_keys)
<lifeless> jam: the thing is, we've already walked the graph once to do the revision sorting
<jam> graph.iter_ancestry([known_tip])
<jam> lifeless: different graph
<lifeless> jam: I know
<lifeless> jam: its much better on IO to do what we do today, simply sorting by size to have the largest index first would probably reduce most of the pain
<jam> certainly loading all .tix indices is bad when you want just a single file_id
<jam> I don't know that _iter_prefix is smart enough about how it does it, though.
<lifeless> jam: its better on IO compared to just walking, because just walking is steps latency
<lifeless> _prefix is dumb but fixable
<lifeless> but we're not using _preix now
<jam> _prefix is dumb, but fixable, and 3x faster than get_all() :)
<lifeless> is NEWS, or builtins.py better you think ?
<lifeless> jam: uhm, prefix is basically get_all
<jam> lifeless: actually, you want something that changes relatively little versus the whole tree
<lifeless> rules.py? :P
<jam> lifeless: but done *in order* (I meant to say get_parent_map(all))
<lifeless> _prefix is better because it reads the whole .tix
<JonCruz> hi
<jam> lifeless: _prefix is better because it does 1 linear read into a dict cache, serves results from there (though we may not actually hit the per-file graph much after that point)
<jam> rather than bisecting an in-memory structure 10,000 *20 times
<JonCruz> Perforce revision graph... http://www.perforce.com/perforce/products/tours/p4v/p4v_revision_graph_6.html
<lifeless> jam: yes, and it does those details because it reads the whole tix
<jam> I think we both have a feel
<jam> I'll welcome a patch
<lifeless> jam: I'm talking big picture, you're talking fine detail
<lifeless> I'll see if I can get something sensible for you to consider
<jam> JonCruz: you might take a look at the "qbzr" plugin and "bzr qlog". It allows you to collapse and expand branches, which works a lot better when you have the 100s of branches that we have with bzr
<jam> (i'm personally responsible for >200 feature branches of bzr)
<JonCruz> the functionality is one of the nicer parts.
<JonCruz> jam: it's a little hard to explain without actually using it
<jam> JonCruz: I didn't mean to start much of a conversation, I'm really tired and heading to bed
<jam> I just thought I'd point you to something.
<JonCruz> I'd checked them out a while back
<lifeless> jam:
<james_w> hey JonCruz
<jam> lifeless: ?
<lifeless> http://rafb.net/p/gbv3vY51.html
<jam> JonCruz: it does look interesting, but I don't see it scaling above 4 or so branches
<jam> certainly, above 3 the lines start having to cross somewhere
<JonCruz> Oh, it scales easily to dozens of branches
<JonCruz> I've used it with some large enterprises
<lifeless> 22 seconds with that patch
<james_w> I asked JonCruz to step in, as he was saying that this perforce viewer is great, and so I wanted to find out why so that the bzr gui tools could improve
<lifeless> testing without
 * beuno is off to bed.  night everybody!
<JonCruz> one aspect is that navigator window in the corner. Allows for zooming in and out
<lifeless> 34 without
<lifeless> so its possibly sufficient
<jam> lifeless: looks interesting, unfortunately rafb.net doesn't let me copy and paste easily, I'll test on my mysql repo
<JonCruz> the shapes also show merge, copy, branch start, branch end, etc.
<JonCruz> pick-any-two-and-diff is also handy
<james_w> the navigator is interesting
<james_w> ah, it's not file based as I thought, it's just perforce being different
<spiv> jam: firefox/epiphany copy & pastes from that rafb.net page just fine for me...
<JonCruz> it
<JonCruz> it's a bit file oriented... but it would be nice to track code blobs in a similar fasion.
<JonCruz> that tool helps significantly when tracking down bugs in software that's been around for a bit
<james_w> it's more of a canvas this I think, which would be a bit of work, but if the benefits are there and rely on that then it may be necessary
<JonCruz> also it focuses things for those with a spacial way of thinking, as opposed to the list-based approach of http://qbzr.googlegroups.com/web/qlog.png
<JonCruz> list-based is also good
<james_w> diff between any two is something that I know is missing in bzr-gtk, and there is an open bug I think
<jam> spiv: I seem to get a consistent "malformed patch" with my cut-and-paste attempts
<JonCruz> so in that p4v view the revision numbers are across the top. In the QBzr one they are down the left
<spiv> jam: huh, weird.
<abentley> lifeless: pong
<lifeless> hey
<lifeless> I mailed the list
<lifeless> jam: was it faster?
<jam> lifeless: still copying the repo to this disk
<lifeless> oh heh
<JonCruz> their "blame" tool is also nice live  http://www.perforce.com/perforce/products/tours/p4v/p4v_time_lapse_view_7.html
<jam> lifeless: and, of course, getting distracted trying to actually 'patch' rather than do it manually.
<lifeless> rafb used to allow text access
<lifeless> I wonder why they don't anymore
<james_w> jelmer: http://www.perforce.com/perforce/products/tours/p4v/p4v_revision_graph_6.html <- you can ask me to explain tomorrow if you don't have the scrollback
<mwhudson> hm, somewhere to steal loggerhead ideas from!
<JonCruz> Oooh. their main page has some videos  http://www.perforce.com/perforce/products/p4v.html
<JonCruz> I guess I should check if those are helpful
<jam> lifeless: "time bzr log" goes from 40s => 28s, versus 28.8 for bzr.1.3
<lifeless> jam: so its a win ?
<jam> lifeless: "time bzr log file" seems to be around 43s, which would be a definite win over the 2m+ from before
<jam> I'll finish testing, but yeah, it looks like a big win
<lifeless> ok
<lifeless> it may not be sufficient
<jam> so, for bzr1.3 it was 35s for 'bzr log file' versus 43s.
<lifeless> but as its implementing a TODO from the original design :)
<jam> So you aren't *quite* there
<lifeless> ok
<lifeless> mysql is a very big tree
<jam> but I'm willing to take 43s versus 2min +
<lifeless> its likely that if you print
<jam> and accept a small regression
<lifeless> len(key), self.key_count()
<lifeless> you'll see a ration below 20
<lifeless> *ratio*
<jam> lifeless: sure, and the code you wrote doesn't take into account how much you've already read, right?
<JonCruz> james_w: yes. It appears that their screencast video on the revision graph is helpful  http://filehost.perforce.com/downloads/media/rg/rg.html
<lifeless> jam: right
<jam> lifeless: but it is 2 min 27s without your patch
<lifeless> jam: I aimed for quick
<jam> for 'bzr log file'
<james_w> JonCruz: cool, thanks, I'll take a look tomorrow
<mwhudson> heh heh, diff -r <revno of the last loggerhead release> is bigger than diff -r 1 for loggerhead currently :)
<jam> lifeless: So I think it passes my thresholds
<lifeless> does it help annotate?
<james_w> JonCruz: thanks for the pointers, I've got to sleep now, I'll swing by if I have any more questions
<jam> lifeless: so for the *big* packs, I see 59632 35579 0.60
<jam> aka, the 60,000 revisions are always >1/20th of the size of a text index
<lifeless> that will do _buffer_all :P
<jam> even optimally packed
<lifeless> I'm not sure why its staying slower then
<markh> hrm - its seems that pycurl will wait up to 15 minutes before deciding a read had died and retrying it?
<jam> lifeless: there are other queries that aren't triggering it, but I'm not going to dig into it all. I'll check annotate.
<markh> s/up to//
<lifeless> markh: that smells like tcp
<markh> 2 errors pulling from bzr.dev so far == 30 mins
<jam> lifeless: well, first hand says "within the noise"
<jam> 7.8 for bzr 1.3, 7.9 with your patch, 8.3 for bzr.dev
<jam> so likely it helps
<jam> but the margins are pretty small
<jam> lifeless: ATM, I would give BB:approve, but I think I should sleep first :)
 * jam => to bed
<lifeless> jam: gnight
<lifeless> abentley: I think bb is talking to itself
<lifeless> abentley: :P
<abentley> lifeless: joy.
<lifeless> abentley: what do you think about the diff 'added but missing' issue?
<abentley> lifeless: Dunno.  i've been fixing BB.
<lifeless> ah
<lifeless> can I run it past you ?
<abentley> Sure
<abentley> This the iter_changes bug?
<lifeless> yeah
<lifeless> fixing dirstate to do what inventory based ones does made a diff test break
<lifeless> the diff test did
<lifeless> add('foo')
<lifeless> rm('foo')
<lifeless> diff -> wanted no outout, status 0
<lifeless> now it shows garbage -
<lifeless> kind change, mode change
<lifeless> which is strictly correct but not very useful
<lifeless> I think 'added' with no content would be a better display for diff
<abentley> lifeless: So the iter_changes behavior sounds correct.  The diff behavior sounds whack.  We've usually treated missing files as though they had been removed.
<abentley> So I would expect diff to produce no output.
<lifeless> ah
<abentley> "added with no content" might be more sensible if you land a patch requiring files to be manually removed.
<abentley> But diff has never tried to be as informative about file status as "status".
<lifeless> well, such a patch seems to be contentious :)
<lifeless> sure, I can make it do nothing
<abentley> Cool.
<lifeless> I know diff != status
<lifeless> but deliberately hiding seems a little strange to me
<lifeless> I'll get on hiding it though
<abentley> What would you expect the behavior to be for "removed-but-not-deleted" files?
<abentley> IIRC it's the same as "removed-and-deleted".
<lifeless> well diff shows a full content removal
<lifeless> and assumes no content change
<lifeless> abentley:
<lifeless> === modified file 'bzrlib/diff.py'
<lifeless> --- bzrlib/diff.py      2008-06-11 03:56:46 +0000
<lifeless> +++ bzrlib/diff.py      2008-08-14 05:07:18 +0000
<lifeless> @@ -874,7 +874,9 @@
<lifeless>                  return path.encode(self.path_encoding, "replace")
<lifeless>          for (file_id, paths, changed_content, versioned, parent, name, kind,
<lifeless>               executable) in sorted(iterator, key=changes_key):
<lifeless> -            if parent == (None, None):
<lifeless> +            # The root does not get diffed, and items with no known kind (that
<lifeless> +            # is, missing) in both trees are skipped as well.
<lifeless> +            if parent == (None, None) or kind == (None, None):
<lifeless> seem reasonable ?
<abentley> lifeless: Yes, that seems fine.
<abentley> lifeless: is \> a special string in regexes?
<lifeless> in some engines yes
<lifeless> \<foo\> is 'match the word foo
<abentley> I'm trying to decode what '\[MERGE\>' would match using python's engine.
<abentley> I would expect it to match only "[MERGE>"
<lifeless> hmm
<lifeless> try \\> ?
<lifeless> no, thats wrong
<lifeless> but I mean, perhaps the \ is being caught by python
<lifeless> r'\[MERGE\>' vs u'...'
<abentley> Okay.
<lifeless> abentley: do I have bb:approve from you for that little patch?
<lifeless> if so, I can land the iter_changes fix
<abentley> lifeless: Could you pastebin it so I can see it in context?
<lifeless> that was the entire thing
<abentley> lifeless: I figured, but I wanted to see where it fit in the existing file.
<lifeless> I mean, its independent of the iter_changes fix, because its already broken for WT3 trees
<lifeless> but I can pastebin the whole branch if thats what you mean
<abentley> I meant just pastebinning the patch, so that it's in a form I can appy.
<lifeless> http://pastebin.com/pastebin.php?dl=d62ba1f07
<mwhudson> jeepers
<mwhudson> etag support for loggerhead in about 10 minutes
<lifeless> nice
<mwhudson> ah, not quite
<lifeless> not really an either-or thing is it ?
<mwhudson> well
<mwhudson> i guess supporting etags isn't
<mwhudson> but it's not much use unless i generate some too :)
<abentley> lifeless: bb:approve
<mwhudson> and the changelog view's isn't quite brain-dead simple
<mwhudson> and actually, i only did the templated stuff so far
<lifeless> abentley: thanks!
<jml> lifeless: so, Hornsby's out. Let's go to Kensington (or alternatively go Internetless at mine, pending confirmation with flatmate.)
<lifeless> ok
<mwhudson> lifeless: can you point me to something that explains what a 'weak etag' is?
<mwhudson> i guess i should generate weak etags, as my tags won't change on template upgrades
<lifeless> a datestamp is a weak etag
<lifeless> a hash is a strong one
<mwhudson> lifeless: ta, i found an rfc which made some kind of sense
<mwhudson> lifeless: should i support if-modified-since and so on, or would you say etags suffice?
<lifeless> why are you doing this?
<lifeless> 13.3.3 rfc 2616 btw
<mwhudson> so we can usefully put squid in front of it
<lifeless> oh right
<lifeless> IMS yes, definitely
<lifeless> squid will probably be sending IMS
<lifeless> rather than IAM
<lifeless> sorry, IM
<jml> lifeless: is there a reason why TestCase.make_branch and friends don't accept URLs?
<lifeless> jml: yes
<jml> lifeless: what is it?
<jml> (because it's making my life hard)
<lifeless> because we want one test to run on different transports
<lifeless> what do you need to do that you are having trouble doing ?
<jml> lifeless: I want to make a branch at a specific URL.
<jml> lifeless: I can do this, but it would be more convenient if I could use make_branch.
<lifeless> jml: obviously; I was being a bit more general
<jml> lifeless: oh, ok.
<jml> lifeless: so, I want to make a branch in a test in a place that Launchpad will find it.
<mwhudson> lifeless: right, that's what i was reading, good to have it confirmed though
<mwhudson> nice timing, freenode
<lifeless> jml: go on
<jml> lifeless: I am writing an acceptance test to show that Launchpad stacks branches that it mirrors.
<lifeless> jml: I can tell you what I would do
<lifeless> (other than making lp less picky for testing) :)
<jml> go ahead
<lifeless> I would set self.transport_readonly_server to HttpServer
<lifeless> (as ChrootedTestCase does)
<lifeless> but uncondiitonally
<lifeless> then
<lifeless> self.make_branch('foo')
<lifeless> and the url to give lp is
<lifeless> self.get_readonly_url('foo')
<lifeless> it will be an http url
<jml> that's not the branch I'm worried about creating.
<lifeless> ok
<jml> the branch I want to create is the stacked-on branch.
<lifeless> this is an acceptance test right?
<jml> yes.
<lifeless> so why isn't make_branch(foo), make_branch(bar), lp.mirror(foo), lp.mirror(bar) reasonable?
<jml> there are reasons.
<lifeless> ok
<lifeless> ohohoh I just had a thought
<spiv> lifeless: those can be dangerous
<lifeless> if we used another char
<lifeless> or perhaps two columns
<lifeless> we can sensibly do diff after a merge
<lifeless> say two chars
<lifeless> -1foo
<lifeless> -2bar
<lifeless> + gam
<lifeless> (parent 1 had foo, parent 2 had bar, we have gam)
<lifeless> alternatively
<lifeless> - foo
<lifeless> +Mbar
<lifeless> + gam
<lifeless> basis has foo
<lifeless> the merge had bar
<lifeless> we have gam
<lifeless> I think the former is more useful, because unchanged local lines from the merge can just not be shown
<spiv> Sounds interesting.
<spiv> So, a slightly richer diff format, essentially?
<spiv> That can represent more than just texts from {old,new}
<lifeless> spiv: yeah
<lifeless> I often want to know 'did I resolve this well'
<lifeless> and I think this would let me figure that out
<spiv> I often want to know that too.
<lifeless> did my rm patch get reviewed?
<spiv> I did review it.
 * spiv checks the email escaped the laptop
<lifeless> ah
<spiv> jam and I both voted tweak.
<spiv> (for different issues :)
<luks> hm, what about using the diff's merge format?
<luks> er
<luks> I mean git's merge format
<spiv> (And yes, my mail escaped)
<lifeless> spiv: 'deletes' is wrong
<spiv> lifeless: huh?
<lifeless> your tweak, my mental grammar filter is objecting to using deletes
<spiv> lifeless: I just checked, jml's mental grammar matches mine
<lifeless> I think you're both wrong.
<lifeless> now I need to go looking for singular verbs with plural subjects
<spiv> lifeless: Shall I ask my linguist? :)
<lifeless> sure, though I'm looking for rationale not assertion
<lifeless> and she may not have time/interest to dig up a explanation
<spiv> I'll find out if she does.
<lifeless> bzr is singular
<lifeless> delete is the verb
<lifeless> bzr is doing the deletion
<jml> lifeless: it's just a bad sentence.
<spiv> (that's the official diagnosis ;)
<lifeless> so bzr is the subject, and thus subject-verb agreement ->
<lifeless> jml: so lets reword id
<jml> sure.
<jml> "Break any of these rules sooner than say anything outright barbarous." etc
<lifeless> it will have to wait, I have things to do before 6
<spiv>     This makes bzr stop tracking changes to the specified files.  It will also
<spiv>     delete them if they can easily be recovered using revert.
<spiv> (That's my quick attempt at improving it)
<lifeless> anyhow, suject-verb agreement is why 'bzr delete' is correct, IMO
<spiv> Yeah, I eventually managed to parse it the way necessary to see that.  My very strong intuition was otherwise.
<spiv> Do you like my rewrite?
<lifeless> so, 'bzr will also delete them ..' would work better in your restated sentence; using 'it' means more backtracking
<lifeless> other than that its fine.
<spiv> Sure.
<spiv> +1 on that.
<lifeless> thanks
<lifeless> bbiab
<compubomb> question, does bzr have issues with version control involving binary versions ?
<compubomb> as opposed to say text.
<spiv> Nope.
<compubomb> spiv: so it just stores the entire file of the binary right ?
<compubomb> i believe with txt files version control apps generally use diff / patches right ?
<spiv> "bzr diff" will decline to show you anything useful, but it'll store the versions just fine.
<spiv> bzr's internal storage format isn't patch files.
<spiv> That said, it is currently optimised for text files with newlines bytes.
<compubomb> spiv: but you can use it with binaries though right ? i'd imagine it does some kind of hash to determine modification.
<spiv> So it won't (currently) store them very efficiently.  Depending on the way the file changes it could easily just store the whole file for each new version.
<compubomb> spiv: okay, that was what i was wondering on.
<Peng_> Nonetheless, it's not like it's broken, it's just somewhat inefficient.
<gour> i'd like to use bzr-svn to fetch some svn repos. what is the current situation if one wants to use it with svn-1.4.6?
<gour> (without patching svn)
<spiv> I believe the current bzr-svn trunk (and most recent beta release?) doesn't need any patching of svn
<spiv> Check the README I guess.
<gour> release is supposed to happen soon?
<Peng_> gour: Yeah, pretty soon. See the mailing lsit.
<Peng_> (I think)
<gour> god
<gour> *good
<ubuntu_> hi, why should I choose bazaar over git?
<gour> ubuntu_: simpler UI and safer
<gour> ubuntu_: that's why i migrated from darcs to bzr instead to git. ymmv
<ubuntu_> what do you mean by simpler UI and safer?
<gimaker> ubuntu_, and it works with Launchapd (if you do open source stuff) :)
<gour> ubuntu_: just count how many commands are there in git, read about its model and see how can you shoot yourself in the foot ;)
<gimaker> ubuntu_, why not try both out and choose the one which you're more comfortable with? I tested mercurial and bzr, and bzr just felt a lot more smooth to work with.
<ubuntu_> i use git at the moment. it's fast and actually it's quite easy to use.
<ubuntu_> i heard of bzr not being as fast as git.
<gour> true. but i do not work on linux kernel :-)
<gimaker> ubuntu_, it's not. how big is your source tree?
<gimaker> and how many revisions does it have?
<ubuntu_> well my source tree is like one rails project, so it wouldn't matter i guess.
<gour> ubuntu_: with darcs i started using it after 5mins. bzr is similar - check http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html
<gimaker> ubuntu_, It's pretty snappy with a ~1000 file 1200 revisions repository, so you should be okay too.
<gour> ubuntu_: nice and orthogonal command set supporting many different workflows...(d)vcs should be a tool i do not have to think to much, but just use it
<ubuntu_> but another thing is, that just what i read and heard is that git is used by far more projects than bzr...
<gimaker> I thought all the concepts was a bit confusing at first - shared repos, checkouts, lightweight.. ahh!
<gour> ubuntu_: that's also true. m$ windoze is used by far more users than linux, but i don't care :-)
<ubuntu_> i love my mac.
<ubuntu_> ;)
<gour> :-)
<ubuntu_> another thing: is it possible in bazaar to "change" the history? overwrite a commit, change the commit message etc.
<gimaker> ubuntu_: one selling point for bzr is its plugin system - rumor has it git doesn't support plugins?
<gimaker> ubuntu_: it's possible... afaik, it's not super-simple in the general case
<ubuntu_> ok. thanks to all! i'll give bzr a try.
<gimaker> ubuntu_: in the common case ("doh, i forgot to add file X" or "man, that commit message was really retarded") it's very simple: just "bzr uncommit", fix what went wrong and re-commit
<ubuntu_> yeah that's the simple case. but if it's "doh, that commit message is retarded" on commit 16 and we're at 24?
<luks> then you will have to rewrite the history, which will screw everybody who branched from you
<gimaker> ubuntu_: it's doable, but a bit more involved.
<luks> revision history in bzr is immutable
<ubuntu_> is it documented on bazaar-vcs.org ?
<luks> if you need to do a change like this, you need to make a new history
<gimaker> ubuntu_: not that I know.
<gimaker> ubuntu_: one (painful) way to do it is to "bzr uncommit" repeatedly
<gimaker> ubuntu_: another way is to use the rebase plugin
<gimaker> it should be pretty simple, something along these lines ;) bzr branch -r 16 some_branch fix_msg; bzr uncommit; bzr ci -m "New and improved commit message"; cd some_branch; bzr rebase -r17.. ../fix_msg
<gimaker> but since you're a git-guy I guess you all about rebasing already?
<luks> rebase wouldn't help you in this case
<luks> the replay command from the rebase plugin would
<gimaker> right, where replay command = bzr rebase :p
<gimaker> hmm.. this is interesting. what's the difference between replay and rebase?
<luks> maybe I misunderstand what bzr rebase -r does, but I really hope it does not drop revisions
<luks> replay is mass cherrypicking
<luks> rebase replays your local commits on top of a specified branch
<gimaker> luks, it doesn't. AFAIK, rebase does the same thing.
<luks> the same thing as what?
<gimaker> as replay
<luks> no
<gimaker> so what's the difference?
<luks> didn't I just say it?
<luks> but as I said, I'm not sure what `bzr rebase -r` does
<gimaker> luks: Maybe, but I'm not exactly sure what "mass cherrypicking" means..
<luks> bzr merge -c X OTHER_BRANCH; bzr ci -m COMMIT_MESSAGE_OF_X
<gimaker> replay seems  to be undocumented (bzrtools 1.3 something) so it's kind of hard to tell if the difference :)
<luks> bzr merge -c X+1 OTHER_BRANCH; bzr ci -m COMMIT_MESSAGE_OF_X+1
<luks> etc.
<luks> ehm, and what does bzrtools have to do with this? :)
<gimaker> eh, sorry.. rebase 0.3 :)
<luks> rebase, by definition, should change the base of your local commits
<luks> that means it would not drop the revision with incorrect message
<gimaker> I *think* I see the difference now. It seems it's just a matter of syntax/workflow."
<gimaker> replaying revisions A..B from branchA onto branchB <=> rebasing branchB on branchA
<luks> well, you are wrong, but I'm not going to argue :)
<luks> that is true in some specific case, not in general
<gimaker> luks: ok, I'll take your word for it - I'm a rebase noob.
<gimaker> maybe, in the future, there will be documentation to enlighten me on the difference ;)
<luks> gimaker: http://rafb.net/p/ZfTkuu17.html
<luks> is this more clear?
<luks> or http://rafb.net/p/jE4zBV41.html to be more precise
<luks> as the new revision just look like the originals, they are not identical
<gimaker> wouldnt "(in branch B) bzr replay -r 3..4 A" be the same as "(in branch B) bzr rebase -r3.. branchA" ?
<gimaker>  
<gimaker> sorry, I meant (in branchA) bzr rebase -r3.. branchB
<gimaker> that should also yield A->B->E->F->C'->D' ?
<ubuntu_> definitely too much rebasing here ;)
<gimaker> agreed ;)
<luks> I don't know what -r in rebase does
<gimaker> luks: rebase -rA..B OTHER will replay A..B from the current branch on OTHER.
<luks> gimaker: just tried it, /tmp/branchB$ bzr rebase -r3.. ../branchA/ still results in A - B - C - D - E' - F'
<luks> so, no, it doesn't :)
<luks> and it will definitely not apply it on OTHER
<luks> hm, I honestly don't understnad `rebase -r`
<luks> bzr rebase -r4.. ../branchA is A -> B -> C -> D -> D' -> E' -> F'
<luks> but E was never a parent of D, so I don't know what's going on
<luks> er, I mean D parent of E
<luks> oh, sorry, ignore me, I did something wrong
<luks> bzr rebase -r4.. ../branchA will drop the revision E, and the result will be A -> B -> C -> D -> F'
<luks> I'm surprised it drops the revision so easily though
<gimaker> luks: yes, but rebase -r3.. should give you A->B->C->D->E'->F', no?
<luks> gimaker: yes, as I said above
<gimaker> luks: but after playing a bit with it i can see that you're right...
<luks> so -r in rebase basically means that you can manually specify the 'common anccessor'
<luks> which can be destructive
<luks> (really destructive, not just rewriting history)
<gimaker> you can also use the --onto argument to specify where A..B should be rebased
<gimaker> luks: thanks for clarifying the replay command! it might provide quite useful indeed
<luks> gimaker: well, in the end it looks like you can get the same result using rebase, so technically you don't need it :)
<luks> but for the original question I'd still prefer the (for me) more obvious way: bzr branch -r X A B; cd B; bzr uncommit; bzr commit; bzr replay -R X+1 ../A
<luks> bzr replay -R X+1.. ../A
<gimaker> luks: hehe yeah, that was my point all along :)
<gimaker> but it's more involved, so I think I'll prefer the replay-way in the future :)
<luks> yeah, I didn't realize rebase can drop revisions in the process
<gimaker> maybe these things should be documented somewhere - how to change an old commit message, or how to collapse/remove the first X revisions of the history (which is something I recently did, and it wasn't very obvious)
<luks> yeah, most bzr people don't agree with history modifications, but if users do it according to a document at they won't screw up so badly :)
<gimaker> luks: after trying it, I can see why they don't agree with it :) But it's useful in some cases, e.g. if you're just making a personal project public and want to remove the first 100 commit messages which just says "lol butts" or similar nonsense.
 * Kinnison recommends not being daft enough to commit with that kind of message :-)
<gimaker> Kinnison: it's bound to happen. Put a VCS in the hands of couple of fresh students and there you go!
<Kinnison> They'll learn
<Kinnison> And having the mistake immortalised for all time will help them to learn that just because you were a numpty at one time, doesn't mean you can't improve
<Kinnison> You can't change the fact that at one point you were idiotic enough to think that "lol butts" was a sensible commit message, so why encourage people to hide it like it's a dirty secret or something?
<gimaker> Kinnison: Here's a better reason: http://wiki.freebsd.org/VCSFeatureObliterate
<Kinnison> gimaker: Legal encumberances are about the only reason I can see to change history. Also, in a DVCS, I firmly believe that once you have allowed a revision to reach the wild, attempting to disavow its existence is counterproductive.
<LeoNerd> Even Arch/TLA had a long discussion on the website about why changing history is bad
<gimaker> Kinnison: Not every DVCS is employed "in the wild", e.g. usage in closed-source shops. There was another case where an employee had put some improper comments about a (female) coworker in a commit message. It went to court ... and the company ended up wanting the commit message removed.
<Kinnison> Hmmm
<gimaker> I can agree that it's usually a bad idea, but as someone else put it "when you need it, you really need it".
<Kinnison> I guess. I'm still against promoting the concept though.
<luks> gimaker: if the coworker has a local branch, there is no way to remove it from there
<gimaker> luks: That's not the point, the point is that the company "did their duty" (and I think it was a centralized VCS).
<luks> gimaker: sure, but with DVCS it's not so easy to do such a change globally
<luks> e.g. in case of FreeBSD, everybody in the world would had to redownload the whole history and destroy all old copies
<luks> which seems almost impossible thing to do
<gimaker> There's still a difference... I'm not a lawyer, but if you illegally provide some content you probably get a "take down notice", and not a demand to erase all copies of that file.
<luks> hm, right
<gimaker> it's also useful if you have sensitive business secrets somewhere in your repository (commit messages or not), and then want to distribute the repository to a third party
<gimaker> e.g. "Added feature X. This will enable us to easily implement secret feature Y in product Z later on."
<Kinnison> That's what non-disclosure and similar agreements are for
<gimaker> Kinnison: That does help if you decide to open-source parts of your codebase
<gimaker> GPL and NDAs don't mix and match :)
<TemplePrime> i have a bazaar repo set up on my work computer, however after work i wanna export my work into a tar so I can take home and continue at home. Problem is, starting a new repo at home to host my files would erase my rev logs. Is there a way to transfer repos from one PC to another?
<gimaker> TemplePrime: if you copy the .bzr directory as well you'll get the rev logs too
<luks> the preferred way is to use a computer to which you can connect from both places, and use 'bzr push'
<LarstiQ> TemplePrime: branch or repository? In the first case, `bzr push`.
<luks> but if you don't have such a server, just making a tarball of the directory should be fine
<TemplePrime> computers are not connected, so making a tarball then, but I have to have even the same user on both machines?
<luks> no
<TemplePrime> wow, bzr is flexible
<LeoNerd> cp -r one of them (you only need the .bzr directory within it), shove it on e.g. a USB stick, then   bzr merge /path/to/usbstick
<luks> do both run the same operating system?
<TemplePrime> luks, yeah
<luks> the only problem would be moving windows working tree to linux or vice versa
<luks> then it's not a problem
<TemplePrime> no, they both have linux
<LeoNerd> So.. don't move the working tree :)
<LeoNerd> And use the merge/push trick so you can deal with divergent history and whatnot...
<luks> yeah, repository on a usb stick is a good idea
<uws> Hey guys. I want to share a bzr branch with a colleague
<uws> we're both in the same unix group
<LarstiQ> uws: umask?
<uws> can I somehow make sure all the files are  foo:ourgroup  ug+rwX,o+rX   when I push?
<TemplePrime> LeoNerd, I tarball the whole repo and extract it in my home directory, that's it?
<LeoNerd> TemplePrime: No need even there. cp -r it to the USB stick. Take it home. Do not move it off.. instead, run   bzr merge /path/to/the/USB/repo  from your home machine's workdir
<LeoNerd> Let bzr pull the changes out from the USB stick, don't you manaully trash it
<LeoNerd> (merge or pull or whatever is required)
<LeoNerd> In fact.. when at work, don't cp -r, that's silly.. bzr push it :)
<luks> usually pull, since he can't work on both places at the same time :)
<uws> LarstiQ: How would that work with bzr+ssh or preferably sftp:// ?
<LeoNerd> Depends.. sometimes I forget
<TemplePrime> LeoNerd, on my home machine I dont have even bazaar installed, after I install it dont I need to whoami and init stuff?
<LeoNerd> TemplePrime: Oh probably, yes...
<luks> TemplePrime: you do need bzr whoami, but not bzr init
<TemplePrime> the init and the whoami need to be the same right?
<luks> init creates a new branch, but you already have one
<luks> no, they don't
<TemplePrime> true, so only whoami
<luks> bzr push/pull from an usb stick is really the best option
<TemplePrime> i'll tarball it an email it to myself, dont have usb ports on the server
<luks> you can use `bzr send` too
<luks> if you already have the branch on both computers
<TemplePrime> luks, they are not connected to each other
<luks> oh, right
<ToyKeeper> Does bzr have a way to split a subdir into a new branch, retaining only that subdir's history?
<ToyKeeper> I haven't found one...  the 'split' command seems to basically rename subdir => . and delete everything else, but doesn't change the history at all.
<ToyKeeper> I'm basically looking for the opposite of the 'merge-into' command.
<mheld> hey
<mheld> does anybody know of any frontends for bzr like http://www.versionsapp.com/ ?
<beuno> mheld, bzr-gtk?
<mheld> for OS X?
<mheld> without using fink/macports
<james_w> there's bzrx or something
<james_w> bazaarx maybe
<james_w> http://elliotmurphy.com/2008/06/06/bazaarx/
<james_w> hey beuno
 * beuno waves at james_w
<mheld> i like the concept of bazaarX, but I don't really see how I could install this on 20 computers easily/quickly
<fbond> Is this a problem?  "Standalone tree (format: unnamed)"
<fbond> This is a loom.
<strk> /usr/lib/python2.5/site-packages/bzrlib/plugins/email/__init__.py:57: DeprecationWarning: bzrlib.branch.BranchHooks.install_hook was deprecated in version 1.5. Branch.hooks.install_hook('post_commit', branch_commit_hook)
<strk> just upgraded bzr to Bazaar (bzr) 1.6rc2
<fbond> Oh, I guess all of my looms claim to have format "unnamed".
<fbond> strk: I don't think you need to worry about deprecation warnings.
<fbond> strk: They can safely be ignored, unless you are the author of the plugin using the deprecated API.
<jam> strk: When we get to a full release, we suppress deprecation warnings
<jam> it is just for developers and people running bleeding edge
<jam> so that the authors know they need to fix stuff for the release
<jam> strk: and 'bzr-email' has a fix if it releases a new version.
<jam> (the code is done and in trunk, it just needs to be packaged.)
<strk> thanks
<strk> AttributeError: 'KnitPackRepository' object has no attribute 'get_revision_graph'
<strk> bzr viz ...
<awilkins> strk: Sounds like you need to update your bzr-gtk plugin to a more recent one
<strk> I'm using the custom repository
<strk> http://ppa.launchpad.net/bzr/ubuntu hardy main
<strk> got prompted to upgrade bzr but not bzr-gtk
<jvloothuis> I am trying to merge two unrelated branches with; bzr merge -r 0..-1 ../unrelated-branch      unfortunenately I get an error about Repository KnitPackRepository not being compatible with the other (both are knitpack's), any tips?
<luks> are you sure one of them isn't rich-root-pack?
<jvloothuis> luks: thanks for the tip, you are right
<jam> beuno: ping, I'm submitting the 1.6rc3 to PQM now, it will be a bit and I'll have a 1.6rc3 tarball to package.
<beuno> jam, cool. I'll try and get to that ASAP
<jam> beuno: I'll make sure to ping you again when I've uploaded the tarball
<luks> is this the last 1.6 RC?
<jam> I just wanted to alert you that it was coming soon
<jam> luks: With any luck
<beuno> jam, thanks  :)
<jam> I wanted to do it quickly to give an rc a bit of time before -final
<jam> abentley: do you have a 1.6 release of bzrtools that we can get packaged?
<abentley> jam: I released bzrtools 1.6 in June
<jam> abentley: is it still compatible with 1.6rc?
<jam> It at least seems that ~bzr/ppa only has the 1.5 packages
<jam> and ~bzr-beta doesn't have any bzrtools
<jam> beuno: any chance you would feel comfortable packaging bzrtools as well?
<abentley> jam: yes.
<beuno> jam, yeah, I did it last time too.  Just need time.  I'll upload it around 1.6 for sure
<jam> beuno: k. I would put it in the beta-ppa for now to go along with the 1.6 releases. This will also let us easily copy it into the official repo when 1.6 is final
<jam> If you could do bzr-gtk as well, it would be nice, but I'm not going to make you do *everything* :)
<jam> Did Martin usually do bzr-gtk?
<beuno> no, jelmer did
<beuno> and, bzr-gtk may be trickier as it may have varied dependencies
<beuno> I'd rather we try and trick jelmer into doing that one
<bzr> hi, is it possible in bazaar to checkout to the working directory (like in git)?
<jam> beuno: 1.6rc3 upleading now
<beuno> jam, great, I have some stuff to finish, and then I'll get to that
<jam> beuno: it is at http://edge.launchpad.net/bzr/1.6/1.6rc3/+download/bzr-1.6rc3.tar.gz for your downloading convenience
* jam changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.6rc3! /  http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ | http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/
 * beuno conveniently downloads it
<compubomb> how do i tell bzr to ignore a group of folders involved a directory structure ?
<compubomb> i have a bunch of source, but also a lot of images, the images are not important.
<cody-somerville> bzr ignore
<compubomb> cody-somerville: so > bzr ignore foldername1/ foldername2 /foldername3 filename4 etcnum
<cody-somerville> compubomb, you can also use patterns
<cody-somerville> "bzr help ignore" <-- great info about it
<compubomb> cody-somerville: every time i accidentially do commit without giving it a message, it loads up a text editor on my system that i don't use(not important) but what is pissing me off is i don't know how to save the information that is in this box in order to execute the full commit.
<compubomb> do i save a file or something ?
<compubomb> i don't see a filename.
<cody-somerville> Yes, save without modifying the filename
<compubomb> yup, didn't work
<compubomb> :/
<cody-somerville> You can change the editor by changing the EDITOR environment value
<compubomb> what is annoying me is it's using jed
<compubomb> cody-somerville: i did env | grep "EDITOR" and it's not even in there.
<compubomb> wtf would bzr use jed ?
<cody-somerville> There are several commands in debian based distributions use the "alternatives" system so that scripts and what not can run them and it'll use the preferred alternative.
<cody-somerville> This may be the case with bazaar. I'm not a bazaar developer so I don't know :P
<jam> compubomb: we use VISUAL, EDITOR, and BZR_EDITOR
<jam> Otherwise we fall back to "/usr/bin/editor" which is in the alternatives system
<jam> then vi, pico, nano, joe
<hsn_> how to check plugin version?
<jam> I'm guessing your distribution has "jed" set as the default editor
<jam> when you run "/usr/bin/editor"
<jam> hsn_: If they export it, just do "bzr plugins"
<jam> hsn_: Not all plugins give a version string, though
<hsn_> thanks
<hsn_> is there way to check if i have one plugin in path multiple times?
<jam> hsn_: If the plugin is available via different names, it will probably give a conflict at import time
<jam> if it is the same name
<jam> we have specific precedence
<jam> ~/.bazaar/plugins takes precedence over system-installed plugins
<luks> btw, why is bzr loading plugins from /usr/lib/python2.5/site-packages/bzrlib/plugins if I don't use that bzrlib?
<luks> it might have incompatible plugins, so it's probably not a good idea
<compubomb> jam: ty, just removed the symlink to /etc/alternatives/editor and chnaged it to vim
<compubomb> anyone happen to know where i could find a tutorial on setting up bzr with trac on ubuntu ?
<compubomb> i installed the trac-bzr package but it just installed a folder on my system, didn't do any configuration to apache i believe.
<jam> luks: IIRC, it is setup to search the "Arch independent plugin path" because some people install multiple architectures side-by-side. So you end up with bzrlib installed in /usr/lib-x86/python... and you need to import the python modules from /usr/lib/python...
<jam> luks: otherwise, I agree that when running out of the source tree, it may be good/bad to import site packages.
<luks> jam: yeah, I know it was introduced then, but it doesn't seem logical
<luks> I have maybe 0.90 in /usr/lib/python and I use 1.6 from my homedir
<luks> if I had a globally installed plugin for the 0.90 version, it would break my 1.6 local install
<compubomb> what interfaces other than trac are good for bazaar interfacing ?
<compubomb> bleh, i mean like bug/ticket systems etc.
<hsn_> is there way to disable plugin for example by renaming its directory to something?
<luks> jam: one thing, if I sent a patch to ignore plugins named __init__, is there a change of getting it approved? it currently fill .bzr.log because it tries to load bzrlib/plugins/__init__.py and bzrlib/plugins/__init__.pyc
<luks> for me actually twice, from my homedir and from /usr/lib/python...
<compubomb> is there like a launchpad for local systems ?
<luks> compubomb: I don't think there is anything integrated
<luks> trac is probably the best choice if you want all-in-one solution
<jam> hsn_: I rename them into a subdir
<jam> (happens to be called DEACTIVATED)
<jam> luks: probably I'd review a patch
<compubomb> luks: i installed trac-bzr but i don't know how to access it online, i'm not used to working with python apps. i found the directory in "/usr/share/trac"
<jam> I don't feel like 4 lines in .bzr.log is "filling the log" but it is a bit ugly
<compubomb> do i have to do setup.py install ?
<compubomb> i'm not sure wtf i'm doing.
<luks> jam: well, not really "filling the log", but for most commands it's the only output
<compubomb> trac has these directories in it "cgi-bin/  conf/  htdocs/  plugins/  templates/  wiki-default/  wiki-macros/"
<luks> every time I look at bzr.log I see four "Plugin name __init__ already loaded" entries for each command
<luks> compubomb: sorry, I don't know
<compubomb> luks: np, i asked in #trac, hopefully they will be kind enough to help me and not be like rftm.
<compubomb> sometimes, you need floaties before you get your stride.
<compubomb> rftm=rtfm
<compubomb> rtfm is the equivalent of learning how to read and someone hands you a dictionary and says go at it tiger, and people expect you to be superman off the bat.
<luks> I think trac has some nice tutorials on their wiki
<luks> for all deployment methods
<compubomb> luks: yea, they have it for svn
<pickscrape> compubomb: http://bazaar.launchpad.net/~trac-bzr-team/trac-bzr/trunk/annotate/48?file_id=readme-20061211191445-unb1b1y5dhltbwy7-2
<pickscrape> Once trac and the plugin are both installed, look at line 56 of that file and apply the required changes to trac.ini
<pickscrape> That tells trac to use the plugin for version control instead of its built-in svn layer
<rockstar> jam, TWiB in 15?
<nixternal> does bzr have a function similar to svn:externals? and if so, can it do files or multiple files instead of complete directories?
<jam> rockstar: I'm syncing right now, then i'll reboot and we're on
<rockstar> jam, sounds great
<nixternal> jam: you still in Chicago?
<nixternal> never mind, I did a whois
<nixternal> you going to barcamp this weekend?
<jam> nixternal: I didn't even know it was happening, and yes i'm still in Chicago.
<jam> rockstar: rebooting
<jam> nixternal: to your earlier question, bzr doesn't really have a replacement for svn:externals yet, and the proposed one would be at a directory level
<jam> not for individual files
<nixternal> so that means I have more work in front of me here at work :)
<jam> rockstar: ready? i'm starting up gobby now
<rockstar> jam, I is ready
<nixternal> jam: http://barcampchicago.com - Saturday and Sunday, all day and night, free food and beer, live music, good talks, and some hacking
<nixternal> last year totally rocked and this year is looking good already
<nixternal> it is over at UIC
<jam> nixternal: sounds fun, hopefully I can make it around children's b-day parties
<nixternal> heh, this is b-day party weekend in chicago...my neice's is saturday, but barcamp won there :)
<beuno> thumper, ping
<Toranin> wow, svn2bzr (dumpfile version) is slow on long histories.  Looks like it's going to run for about a week by the time it completes at this rate
<beuno> lifeless, interesting thing just now. I tried to index the launchpad branch, and it brought my core2duo to it's knees. I control+c'd, and it kept on going until I killed the PID manually.  Is that expected?
<phoenix3051> Is there a way to removed ignored file patterns from the ignore file on a per project basis. For example in the default configuration bzr will ignore *.a & *.o but for a certain project I don't what this to happen.
<jam> TWiB is available: http://jam-bazaar.blogspot.com/
<jam> phoenix3051: you can edit ~/.bazaar/ignore, but that will change all branches
<jam> phoenix3051: you can always specifically add files
<jam> by doing "bzr add filename.a"
<jam> it is just that "bzr status" won't show them, or "bzr add" won't add them automatically.
<phoenix3051> Jam: adding them by hand would be a nightmare as there are approx ~10k files.
<jam> phoenix3051: "find . -name '*.a' -print0 | xargs -0 bzr add"
<jam> takes a few seconds?
<phoenix3051> oh never thought of that because I was running the test on a windows machine, of to get cygwin installed now :)
<jam> phoenix3051: I think on windows you could still do "bzr add */*.a */*/*.a" etc
<jam> I don't know if we support "**/*.a" on win32
<jam> no we don't
<awmcclain> Hrm... does 1.6 break tracbzr?
<pickscrape> Not that I've experienced
<awmcclain> pickscrape: I'm getting a mysterious AttributeError: 'BzrDirNode' object has no attribute 'path'
<pickscrape> I'll try updating mine and see if I get anything similar
<awmcclain> My apt-fu is really bad. What's the easiest way to downgrade my bzr version? apt-get install bzr=1.5 doesn't work. I must be missing something obvious.
<LeoNerd> That should be sufficient
<LeoNerd> When you say "doesn't work" - explain in more detail
<awmcclain> e.g. E: Version '1.5' for 'bzr' was not found
<awmcclain> oh let me try updating the cache
<awmcclain> though, if i have 1.6, you'd think it' be up to date
<pickscrape> awmcclain: what page gives you that error?
<awmcclain> pickscrape: Going _into_ a branch.
<pickscrape> via the browser?
<awmcclain> pickscrape: Browse source, yes.
<awmcclain> I see the top level fine, but anything below. pfft.
<pickscrape> I'm getting a different error: "AttributeError: 'KnitPackRepository' object has no attribute 'get_revision_graph'"
<awmcclain> :(
<thumper> beuno: pong
<pickscrape> Wonder if I'm using the right trac-bzr branch...
<lifeless> beuno: drop the group count down
<beuno> thumper, hi  :)   I just committed a fix for a bug in LH's search.  Is there anyway you can cherrypick that into the gnome playground, so I can make sure it fixes the problem?
<lifeless> beuno: the fail-to-close is the refcounter hunting up objects and touching them before free, so its thrashing
<beuno> lifeless, ah, right. So, "known issue"
<thumper> beuno: hmm.. we need to upgrade the branch almost wholesale anyway
<lifeless> beuno: so "python"
<thumper> beuno: it might be easier to reapply the theme to trunk and use that
<lifeless> robtaylor: which reminds me, the thing that concerns me about gobject is the ref counting; its really harsh on memory IO; can GObject run w/o it ?
<beuno> thumper, ok, do you want me to update the gnome branch to the new theme then?  I know you where already working on some of that....
<awmcclain> Nope. I've even tried sudo apt-get install bzr=1.5.0-1~bazaar1~gutsy1. I can't downgrade to 1.5
<pickscrape> awmcclain: my problem appears to be when the branch isn't in a shared repository. If it is, I can browse into it fine
<pickscrape> Which is odd.
<awmcclain> pickscrape: I'm navigating into a shared repository. :(
<pickscrape> Yes, and we aren't even getting the same error message :)
<awmcclain> I'm just trying to downgrade now, but I'm having no luck.
<pickscrape> What version of trac and the trac-bzr plugin are you using?
<jam> awmcclain: well, if you have 1.6, doesn't that mean you are using the ~beta-ppa which doesn't have 1.5 in it?
<jam> don't you need to use the ~bzr ppa instead?
<pickscrape> Hah, just realised I've already raised a bug for my problem (bug #239591)
<ubottu> Launchpad bug 239591 in trac-bzr "traceback when browsing branch with history" [Medium,Triaged] https://launchpad.net/bugs/239591
<awmcclain> jam: I have both in my sources list. Let me double check. Good point.
<awmcclain> jam:  apt-get install bzr=1.5 "should" work, correct?
<awmcclain> i just want to make sure my command looks right.
<jam> awmcclain: I don't know apt
<jam> sorry
<awmcclain> jam: Oh, son of a gun. I must have removed it.
<awmcclain> sigh
 * awmcclain sighs
<jam> I can "upgrade" "update" and "install foo" but I haven't tried a specific version.
<awmcclain> It's going to be a long day, i feel it.
<james_w> awmcclain: what's the output of "apt-cache policy bzr"?
<awmcclain> http://dpaste.com/71509/
<awmcclain> Ah! got it.
<awmcclain> sudo apt-get install bzr=1.5.0-1~bazaar1~gutsy1
<awmcclain> Perfect. Downgrading fixed it.
<james_w> cool
<awmcclain> I should file bug in trac-bzr, yes?
<awmcclain> file a bugt
<james_w> it looks like it, yes
<lifeless> jam: hi
<jam> hi lifeless
<weigon_> what shall I do if I get: bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: revno does not match len(mainline) 13 != 6191
<lifeless> jam: what I"m trying to do with gc is get smooth integration with bzr
<lifeless> jam: which is why sorting out fetch to be solid is important to me
<jam> lifeless: I agree that fetch is important, I don't think the sort order is the most important part of it
<jam> (gc => gc fetch is currently at 27 minutes and still on 0/4)
<lifeless> jam: what do you think is the mort important part of fetch ?
<jam> lifeless: getting it to fetch without recompressing everything
<lifeless> jam: So the way that that will work will depend on the way gc->gc fetch is implemented
<lifeless> I want to implement it via get_record_stream, which is what I'm working on, so I'm working towards that
<lifeless> if it doesn't fit well via get_record_stream, then I'll do a custom thing like pack->pack does;
<jam> lifeless: I feel like you are spending a lot of time getting the "optimal order when recompressing everything"
<jam> but not skipping around it.
<jam> because it isn't ever going to scale.
<lifeless> well, AFAICT git recompresses everything on fetch
<lifeless> it sends existing deltas but always decompresses on receipt
<lifeless> anyhow
<lifeless> I don't want to rush groupcompress, I want to take the time to get it well polished
<jam> lifeless: gc is much more expensive then their compression strategy
<jam> I'm not sure if we can improve it a lot or not.
<lifeless> jam: its cheaper surely
<lifeless> conceptually gc does less work
<jam> I don't see it doing less work
<jam> I suppose if you consider the cached hashes?
<jam> At a minimum creating deltas is more expensive than expanding them
<jam> by about 10-100:1 ?
<lifeless> git does a xdelta (A, B), for a set of (B) to decide which B to insert next, and threads that
<lifeless> it then reuses the one it chose.
<jam> lifeless: I'm not positive, but I don't think it does that for transmission, only for "git pack"
<lifeless> but it generates matching ranges etc from scratch for at least N-1 pairs
<jam> (or repack, etc)
<jam> I agree that it does that for repack --window ....
<lifeless> transmission is less enthusiastic true
<jam> I don't think it does that during "clone"
<lifeless> but its still at least N-1 pairs
<jam> lifeless: except for the ones it can re-use (which is at least what you just said)
<jam> and GC can't be reused except in bulk
<lifeless> we can just put the group on the wire intact
<jam> lifeless: and doing that (IMO) is more important as a priority, and may preclude using get_record_stream
<jam> lifeless: I'm *more* concerned about local branching than network, atm
<jam> lifeless: because after you've gotten the wire stream, you still have to insert it into the local repo
<lifeless> jam: well, if you're interested in scratching that part first, please do so :)
<lifeless> I don't think that non-developer usage feedback is very useful at this stage for gc repos
<jam> lifeless: I've got lots of other things on my plate before I can get to gc. Certainly you are welcome to scratch your itch. But it feels like you are trying to polish something that isn't *usable* yet.
<lifeless> so I don't have any motivation to get the formats and compressor into bzr.dev per se
<lifeless> <sigh>
<lifeless> I'm trying to get the *implementation of fetch usable*
<lifeless> that means either custom-coded, or using get_record_stream
<jam> Ok, I would suggest you are going about it in the wrong way.
<jam> Perhaps not.
<lifeless> you're complaining that its slow using get_record_stream
<jam> I feel like you are polishing the insertion order.
<lifeless> WHICH IS WHY I AM WORKIG ON GET_RECORD_STREAM
<lifeless> jam: I'm working on the interface so that gc->gc using get_record_stream has the room to send an entire group and reuse it while still working correctly for knits
<lifeless> we're trying to squash all these different use cases into one interface
<lifeless> which is fine, but it means polishing the interface to be really nice
<jam> lifeless: sure, and my feeling is that get_record_stream isn't a good fit.
<lifeless> jam: you do realise that you haven't said that at all
<lifeless> until now
<jam> lifeless: I've been saying using an api that requires recompressing everything isn't a good fit. which is basically how get_record_stream() is designed (atm).
<lifeless> not at all
<lifeless> get_record_stream was designed explicitly to avoid recompressing
<jam> And I don't see having: get_record_stream("gc-blobs")
<lifeless> and knit->knit doesn't recompress
<jam> lifeless: because the stream is designed as knit deltas.
<lifeless> no
<lifeless> because the api is flexible
<lifeless> it may not be flexible enough
<lifeless> which is one of the possible outcomes of this discussion
<jam> lifeless: well, at present it talks about everything 1-text at a time
<jam> which isn't possible for "optimal GC transmission".
<jam> Specifically the "get_bytes_as()" portion.
<jam> And 1 factory object per text
<lifeless> I'm irritated because I feel like you are telling me I'm doing the wrong thing, but your objections have been about 'this bit over here is rough' not why the time is wasted
<lifeless> jam: the API is stream->stream
<lifeless> jam: the generic use of the stream is text->text
<jam> lifeless: http://rafb.net/p/T8dpQb85.html
<jam> a stream is an "iterator of ContentFactory objects"
<jam> which is a series of Content objects. I will agree that it doesn't give a definition of what Content is.
<jam> But if it is compatible with Knit
<jam> then it would be 1 Content for each text.
<jam> lifeless: look, *you* wrote the api, and you have the best knowledge of how it can be modified to fit what you are looking for.
<jam> I'm going off the level that I've been exposed to it to date.
<jam> Which isn't truly deep.
<jam> The only flag we have at the moment to indicate what type of stream to produce is "ordering".
<jam> Which doesn't really fit a "give a ContentFactory stream that is useful for knits" versus "give me a ContentFactory stream that is good for gc => gc".
<jam> lifeless: I *do* see that the base-level ContentFactory object has a "self.key" member, rather than a "self.keys" parameter
#bzr 2008-08-15
<jam> I think it would be an incompatible change, or at least a whole lot of shoe-horning to get optimal gc => gc via get_record_stream.
<jam> lifeless: I guess I've felt like you've been optimizing the knit => gc case, rather than the gc => gc case. And the former is transient until everyone has upgraded, while the latter is an on-going issue.
<lifeless> jam: I've been hammering on the interface that is used
<lifeless> we need gc->gc to work when the source is actually a RemoteRepository
<jam> lifeless: I suppose I also haven't seen any visibility of your work. I don't know if you just aren't committing, or if you aren't sending emails
<jam> Certainly I don't see a public URL to get your latest code.
<lifeless> ~lifeless/+junk/bzr-groupcompress on launchpad
<lifeless> and my btree-graphindex bzr branch
<lifeless> which has outstanding uncommitted work, because I need to fix this api
<lifeless> I haven't been able to spend time on the core code for a couple weeks now
<lifeless> helping with 1.6 stuff, analysing nasty bugs, and thinking about the interface problems
<lifeless> so I think you're seeing 'robert has not been working on this'
<lifeless> rather than 'robert has been obsessing about knit->gc'
<beuno> mwhudson, have any idea how/where I can upload the 1.6 tarball in LP?  https://edge.launchpad.net/loggerhead/+download  isn't very helpful
<mwhudson> beuno: i think maybe you go to the release page
<mwhudson> beuno: which you perhaps need to create
<beuno> mwhudson, ah, I see.  Ok, I have to go now, but I'll release 1.6 with NEWS, announcements, etc when I come back (or tomorrow morning), unless you can think of something else we're missing
<lifeless> jam: before you go, what I need to understand is if you think a hint is _wrong_ or just premature
<lifeless> jam: if you think its wrong I'll head back to drawing boards, if you think its premature I'll accept we have a different order on the same TODO list
<mwhudson> beuno: awesome
<jam> lifeless: just premature, not wrong, I thought I made that somewhat clear.
<jam> sorry about th delay
<lifeless> jam: it was getting pretty angsty, I wanted to be sure
<lifeless> no worries about the delay; life does come first :)
<lifeless> jam: do you have an opinion on lexer and cc toolchain?
<lifeless> jam: I'm currently trying antlr3
<jam> lifeless: I do not
<jam> lifeless: what are you trying to parse?
<lifeless> dirstate
<lifeless> initially that is
<jam> seems a bit overboard, but if you feel it is merited
<jam> As far as one I came across a while ago: http://spirit.sourceforge.net/
<jam> it is C++ using templates
<jam> to allow you to write EBNF, I guess
<jam> boost is a very nice advanced C++ library
<jam> not necessarily something you want to use in this context
<lifeless> yah
<lifeless> so if we do C++, I'd grab boost, its nice
<fullermd> Honkin' big.
<lifeless> but I think plain C is probably best at this point
<jam> lifeless: sure, the initial docs for antlr only describe java and c++ output
 * spiv doesn't like Fridays.
<jam> though it seems they have since implemented several output languages
<lifeless> http://www.antlr.org/api/C/
<lifeless> spiv: heh
<mheld> if you had to categorize bzr commands, how would you?
<mheld> transfer, edit, info?
<Peng_> Huh, importing paste is either taking 0.0037 seconds, or 9.5. That makes starting Loggerhead a little slow...
<jam> Peng_: that seems like a bit of variation.
<fullermd> Yeah.  Do we get to pick which it is?   8-}
<jam> lifeless: yeah, the problem is that on the download page, they say you can use the binaries for C++, C# or python, when they really mean C...
<jam> I will also say I have a hard time finding online examples
<lifeless> Peng_: out of cache?
<Peng_> lifeless: Yeah, probably.
<mwhudson> it's not like paste does all that much when you import it
<lifeless> mwhudson: 'python'
<mwhudson> yeah yeah
<lifeless> python, yeah yeah yeah, python, yeah yeah yeah
<lifeless> so I played with freeze
<markh> lifeless: in a packet trace, are you only interested in the few frames before and after the error?
<lifeless> markh: I'm not interested in them at all; I want you to look at it ;)
<markh> heh :)
<lifeless> markh: we're looking for retransmissions, tcp errors etc
<fullermd> Ideally, you'd probably want at least the last few packets before it goes off in the weeds.
<lifeless> and to see what happens after
<lifeless> if it gives up I think it will send a FIN
<fullermd> RST more likely
<lifeless> fullermd: yeah mea culpa
<lifeless> EMEMORY
<fullermd> Of course, it IS Windows; so it might send just about anything  ;)
<lifeless> jam: whats up with NEWS
<lifeless> jam: we seem to be jumping around with sections, I thought we had a fixed set these days ?
<jam> lifeless: I see the same ones IN DEVELOPMENT as elsewhere, what would you have expected?
<jam> lifeless: there has been some motion because of things that were in dev that got merged into a release candidate.
<jam> I tried to keep them in the same sort order, though.
<lifeless> I only ask because I'm running into conflict-after conflict :P
<lifeless> jam: also, did you know that buffer() is a zero-copy tool ?
<jam> lifeless: Is that because we started a new IN DEVELOPMENT?
<jam> lifeless: yes, but buffer() doesn't make the code more obvious, etc.
<lifeless> jam: As we work on memory, I expect we'll want more of it
<markh> I'm not very familar with debugging network traces.  The last packet I see before the timeout is from launchpad and apparently carrying http payload.  The first I see after the timeout is also from launchpad, with the TCP "F" flag set, which apparently means "end of data".
<markh> I'm using a windows network tool and I'm not sure how to export the data in any meaningful way
<fullermd> Well, F would be FIN, which means it's shutting down the connection in an orderly fashion ("Done", rather than RST which means more like "broken, WTF?!?")
<fullermd> You don't see any packets from you in the middle, though?
<markh> right
<markh> nope - I'm filtering by "source=launchpads ip or dest == launchpads ip"
<fullermd> I don't see how it could FIN unless it had at least seen your ACK of that last packet...
<lifeless> does the sequence number match ?
<lifeless> fullermd: I think you can FIN on shutdown() regardless of ack-state
<lifeless> so
 * fullermd reached for Stevens.
<lifeless> I think we should check what the apache front-end has its timeout set to
 * lifeless bets 15 minutes
<lifeless> spm: ping
<spm> lifeless: pong
<fullermd> Assuming your ACK did get through, then yeah, it sounds like HTTP keepalive.  LP sent all its data, and considers that you've gotten it, and after 15 minutes of no activity, decides you're gone and closes the session.
<lifeless> spm: whats the persistent connection timeout configured on bazaar.launchpad.net
<fullermd> 15 minute keepalive timeout sounds insanely long, though.
<lifeless> fullermd: not really
<markh> what pastbin do you guys use?
<markh> pastebin
<lifeless> markh: any that works
<markh> http://pastebin.com/m6aed84b0 - but no column headers :(  2nd col is "packet number", 3rd is "time offset", "eden" is my pc
<lifeless> spm: we have a situation where we are seeing some http data sent to a bzr session
<lifeless> spm: then nothing for 15 minutes
<lifeless> spm: then a FIN
<spm> lifeless: hmm. not good.
<lifeless> spm: working theory is that packets are going AWOL
<lifeless> spm: and then apache is timing out the socket gracefully
<lifeless> spm: finding out the configured timeont on b.l.n will help
<spm> lifeless: sounds reasonable...
<spm> lifeless: sure. just getting...
<lifeless> if its different we can look at other things
<lifeless> if its not configured, it willbe the default
<spm> lifeless: looks to be default
<lifeless> spm: thanks
<lifeless> Default:KeepAliveTimeout 15
<lifeless> Syntax:KeepAliveTimeout seconds
<fullermd> It's 5 here.  But either way, it's a long cry from 15 minutes.
 * lamont mutters about &%)^%^*_ tar.gz packaging of bzr snapshots, again
<markh> KeepAlive is different
<markh> isn't it?
<lamont> 1) orig.tar.gz without debian/; 2) drop debian/.bzr from the source package
<lifeless> KeepAlive is boolean
<markh> a timeout though
<mwhudson> lamont: i'm sure you should be asleep
<lifeless> lamont: bzr itself?
<markh> if it has the connection open, that is how long before it will close it even if the client doesnt IIUC
<lifeless> lamont: you have confused me
<fullermd> markh: No, KeepAlive is just a flag for whether or not persistent connections are allowed.
<lamont> lifeless: see lauchpad.net/~ppa-bzr-beta/
<lamont> ]+archiuve
<markh> yes -
<fullermd> markh: KeepAliveTimeout is the time after which it closes even if the client doesn't.
<markh> and if it is used and the connection remains open, the server has a timeout
<lifeless> lamont: bzr upstream does not have debian in it
<lifeless> lamont: but the packaging rules are a bzr branch
<lamont> the package in the ppa doesn't _HAVE_ an upstream tarball
<markh> fullermd: yeah, I think that is what I'm saying :)
<markh> which is a different timeout than we are looking for?
<lamont> lifeless: which, specifically, is my complaint
<lifeless> lamont: uploaded as a native package?
<lamont> yes
<fullermd> (I don't think there IS a timeout for max length of a persistent session, short of MaxKeepAliveRequests * (KeepAliveTimeout * .9999999)
<lamont> OTOH, at least 1.6rc2 has dapper source for me :-)
<lifeless> lamont: file a bug
<lifeless> lamont: the folk doing these uploads are not DD's
<lamont> yeah
<lamont> I'll do it once I'm awake again, as mwhudson so aptly points out
<lamont> and on that note, bed.
<lifeless> still
<lifeless> 1/60th of the time out is still damn suspicious
<bvk> hi, how do i make a minor edit in an already commited revision, without another commit?
<AfC> bvk: uncommit
<fullermd> Anyway.  I'm pretty certain a FIN won't be set if there's outstanding un-ACK'd data, no matter what.  shutdown(2) will send the queued data and wait for it to be ACK'd before doing it's half-close.
<bvk> AfC: thanks, i will try it out
<AfC> bvk: (followed by a new commit, of course)
<AfC> bvk: (assuming, a) that you are trying to fix the most recent revision, and b) that you haven't sent it anywhere public)
<bvk> AfC: it seems, i cannot go down more than a recent commit and make a fix :-(
<fullermd> Barring really heroic and unportable measures, I don't think there's any way for userland to 'take back' send(2)'t data; once it goes down there, TCP will reset the connection without any more intervention if it can't get through...
<spm> markh: just been looking at that network trace pastebin. those first two packets (4188/89) appear to be identical? Which seems a tad broken.
<bvk> AfC: say, i have revisions 1,2 and want to make a minor edit in 1 (but not in 2) revision 2 also needs to be uncommitted
<markh> shall I go back a few packets?
<AfC> bvk: yes, which is why you should just be making a fix and committing revision 3.
<bvk> AfC: is there anything like mercurial patch queues? where i can do hg qpop; hg qpop; edit; hg qrefresh; hg qpush; hg qpush ?
<spm> markh: yeah... something just seems really odd... I'd expect to see more "stuff" happening. retries whatever.
<fullermd> markh: If you can use something like Wireshark, you can do things like show a trace of the HTTP session, which could be helpful in seeing if it really is "all there".
<markh> those 2 packets look identical here too
<fullermd> Mmm.  That trace looks all sorts of messy...
<mwhudson> bvk: there is the 'loom' plugin
<markh> http://pastebin.com/m78da686f has from the GET request
<markh> I'll look into wireshark...
<fullermd> Look at those 4th and 5th lines again.
<fullermd> First, the 4th line is launchpack ACK'ing your packet in the 5th line.  So the order is messed up.
<fullermd> And secondly, those are from a different session than the first 2 lines (can't tell about the 3rd); the local port is different.
<bvk> mwhudson: i tried loom plugin, but i couldn't get that how to do it right :-( loom doesn't have anything equivalent to hg qrefresh :(
<bvk> mwhudson: i still need to make a commit for minor fixes and it is recorded as another revision
<mwhudson> i don't know what qrefresh does, so can't really answer that :)
<lifeless> mwhudson: its what commit in aloom thread does
<lifeless> bvk: in loom you just do a commit on that thread
<bvk> mwhudson: qrefresh updates the current working patch (in a queue of patches). one patch acts like one revision, so multiple qrefreshes on a single patch will not result in multiple revisions
<markh> I think only one bzr was running in that trace - I was being careful to wait while the 15 minutes expires and not doo anything else with bzr
<markh> I'll see how I go with wireshard
<markh> k
<lifeless> bvk: looms map revisions into a stack rather than replacing revisions
<lifeless> bvk: the stack has the delta each revision needs when submitted upstream
<fullermd> But yeah, that FIN 15 minutes and 10 seconds later is from a different TCP session (local port 60013 instead of 60012), so it's no relation to the other packets.
<fullermd> That first connection apparently disappears totally after that line 7 packet.  Which is absurd; you're running locally, you should be able to see your ACK of it no matter what, even if the other end doesn't.
<bvk> lifeless: um...if i go down-thread, do some edits and did up-thread, will my top thread gets the edits merged?
<lifeless> so, we were looking at the wrong machine in the DC
<lifeless> bvk: yes, as a pending merge like normal bzr merges
<lifeless> bvk: diff -r thread: at any point shows you the overall pending diff
<bvk> lifeless: so, i have to do one more commit in all up-threads from the point of edits?
<spm> fullermd: agreed - good catch on that. which also begs the "what is actually open" question...
<lifeless> bvk: yes, there are some plans to streamline this
<bvk> lifeless: ok
<fullermd> (of course, it's an assumption that that HTTP data packet is part of the 60012 connection, since it doesn't show ports or sequence numbers or whatever on those packets, but I think it's a reasonably good one)
<spm> markh: might be worthwhile seeing how many, if any?, connections you have open to 91.189.90.161; netstat -an | fgrep 91.189.90.161
<bvk> lifeless: one more question, when i do a merge from up-thread, all its revisions are automatically logged in the commit message, can i avoid that with a simple merge notes?
<markh> none apparently :)  I'm installing wireshark now
<lifeless> bvk: they are not logged in the commit message for me; why do you say they are ?
<bvk> lifeless: i saw all revisions logged with some indentation :-(
<spm> fullermd: yeah, the timing is too tight. but still ... coincidence is possible. :-)
<lifeless> bvk: thats display
<lifeless> bvk: try e.g. bzr log --short
<lifeless> copying commit messages around like that would be horrible duplication
<markh> I'm pretty clueless with this :( fullermd - any clues about the syntax for the wireshark filter I'd need?
<markh> or spm of course :)
<fullermd> "host 91.189.90.161 and port 80" should do it
<fullermd> (should show both directions)
<spm> markh: just grab the lot - post filtering with wireshark is a doddle. or ^^ :-)
<markh> it says thats a syntax error
 * markh looks at help
<bvk> lifeless: ok, short is not displaying them :-)
<spm> markh: are you applying that filter as you capture, or post capture? the eg fullermd gave is "as you capture"? The post capture filters are very different syntax.
<markh> um - in the toolbar "filter" box :) - haven't started capturing yet
<spm> Ah! :-)
<spm> No not that one. :-)
<spm> "start a new live capture"
<spm> ... or "capture options"; should then see a "capture filter" - put the filter in there.
<fullermd> The latter is what I always do (make sure you choose the right interface)
<markh> ok, running.  Now to retry a few times until it fails...
<markh> a few "dupe ack" messages are flying by, but its still working...
<markh> ahh - here we go :)  bb in 15 :)
<spm> markh: :-) Once you close the sniffing; go looking for the http GET request that timed out - it should be fairly obvious; select that line; right click; "Follow TCP Stream" - will filter packets to only that connection.
<markh> nice :)
<fullermd> I'd save it right off too; that way you have a copy around to work with.
<markh> fullermd/spm: so I've got a capture - but struggling to get a similar text format out for the selected packets.  What's the best way for you to see the data?
<markh> upload a .scap somewhere?
<fullermd> markh: Well, you can try filtering down to just that session, then saving that out to a pcap file, and seeing how big that is.
<spm> markh: sure - works for me
<lifeless> bbs
<fullermd> If it's not huge, we can just grab that and poke at it.
<fullermd> (or if the whole capture isn't too huge, that would work too, with less effort)
<markh> fullermd/spm: http://starship.python.net/crew/mhammond/bzr-hang-2.zip (151,340 bytes) - it should be from the most recent GET (a few seconds and many packets before the hang), and a dozen or so packets after.
<fullermd> OK, that's a lot of dupe ACK's in a bunch there.  Couple times.  Weird.
 * markh doesn't know what happened to his isp then.
<fullermd> Lot of partial packets there; your MTU is higher than somewhere along the path, which is causing a lot of fragmentation.
<fullermd> That shouldn't break anything, but certainly exposes more edges.  And probably messes with your performance a bit.
<markh> quite possibly my very old dsl modem
<fullermd> If we go to packet 687, which is the last one before the pause, right-click and 'Follow TCP Stream' gives a text dump of the session.
<fullermd> There's two things to note.
<fullermd> The first, is that looking at the very end, it's obviously in the middle of a line, which confirms that you're not actually getting all the expected data.
<fullermd> The second, is that there IS a proxy; see the HTTP response header:
<fullermd> Via: 1.0 proxy3.mel.dft.com.au:80 (squid/2.6.STABLE18)
<markh> yeah, my isp I believe
<fullermd> So, that's suspicious.  HTTP breakage unrelated to proxies happens, but not near as often as related.
<fullermd> lifeless may know more as to whether there's something particular about that version that might be tripped us up.
<lifeless> australian ISP's as a rule have an intercepting squid
<lifeless> squid had a known, serious bug with range requests
<markh> heh - well there you go :)
<markh> in that version?
<lifeless> yes
<lifeless> .19 fixes it
<lifeless> but they should 2.7 or 3 anyhow
<lifeless> http://www.squid-cache.org/Versions/v2/2.6/changesets/11996.patch
<markh> bugger - here goes another support request that will end up in the same bucket my request for them to upgrade their SpamAssassin did :(
<lifeless> also
<lifeless> http://www.squid-cache.org/bugs/show_bug.cgi?id=2329
<ubottu> www.squid-cache.org bug 2329 in src "Range header is ignored for TCP_HIT" [Normal,Resolved: duplicate]
<lifeless> which is fixed in .20
<fullermd> (actually, I could be full of crap on my first point above; I guess the range could just end right in the middle of that line)
<lifeless> fullermd: single ranges can, multi ranges will be multipart wrapped
<Peng_> Australian ISPs run proxies? Ew.
<fullermd> It's multi-part wrapped.  2 ranges.
<lifeless> fullermd: so cutting off part way == incomplete
<fullermd> I forgot that it was ranged, so I assumed it would have a full index, which wouldn't fail in middle of the line.
<fullermd> The range is a little weird, though...
<fullermd> Range: bytes=33100-123726,124238-190665
<lifeless> thats GraphIndex
<fullermd> We really care about saving 500 bytes in the middle, when we're pulling >150k?   :p
<lifeless> no
<lifeless> we want a few hundred bytes from 150000+
<lifeless> and its remote so we expand it to 64K
<lifeless> we also want some bytes from a couple of lower spots, apparently
<fullermd> Yeah, it just seems weird to me that they expand to those blocks, but don't just collapse it into a single range.
<markh> that squid bug appears to only happen for cached content?
 * fullermd does a quickie test of the range
<lifeless> markh: the second bug yes
<lifeless> markh: but note that the first bug will cause the second to show
<fullermd> Oh, I see what you mean.  I missed that it was lacking the MIME boundary marker.
<fullermd> So I was right, for the wrong reason   8-}
<lifeless> markh: I'm not convinced squid is the root cause thouh
<lifeless> markh: you are seeing anomalous behaviour
<fullermd> Yeah.  There's enough weirdness in there to go around.
<xshelf> a quick question: is bzr-fastimport format identical to git-fastimport format?
<fullermd> All the dupe ACK's, in several clusters through the trace, are locally generated, rapid-fire.
<lifeless> xshelf: bzr-fastimport read git-fastexport if thats what you're asking
<fullermd> That may or may not be related to the near-total fragmentation.
<fullermd> I think there's some SACKtion going on, but I don't know SACK well enough to say much about it without a lot more digging than I have time for tonite   :|
<xshelf> lifeless: i was looking at reusing git-p4 for bzr
<lifeless> xshelf: yes, I believe someone is working on that
<lifeless> there is stuff on the list about this
<xshelf> lifeless: i read it in the list, let me followup with that person
<jml> lifeless: hi.
<Peng_> jml: bzr+http? :D
<jml> Peng_: working on it!
<Peng_> Cool.
<lifeless> jml: hi
<jml> lifeless: so, tomorrow.
<jml> lifeless: we're missing a *time*
<lifeless> and a place
<lifeless> I've been trying to grab Lynne, no luck
<jml> lifeless: Kensington is the place
<lifeless> details details details; how do I get there?
<lifeless> markh: is there mtrr for windows?
<markh> no idea!
<markh> I see rio.py has:      if isinstance(value, str):\n      value = unicode(value) - that is always going to be suspect isn't it?  If the string is utf8 or anything else that's non-ascii, we are doomed
<markh> some russian dude is hitting it in 1.5, and it looks like he still might in 1.6
<lifeless> http://beerpla.net/2008/05/12/a-better-diff-or-what-to-do-when-gnu-diff-runs-out-of-memory-diff-memory-exhausted/
<lifeless> agreed
<lifeless> is there a bug?
<markh> https://bugs.launchpad.net/bzr/+bug/256550
<ubottu> Launchpad bug 256550 in bzr "locking fails with non-ascii characters in host/username/something (russian Vista)" [High,Triaged]
<markh> yep
<markh> oops :)
 * markh answered the bot :)
<luks> the problem is not rio, the problem is using non-ascii bytestrings for hostnames
<markh> one path I can see is _auto_user_id() calls socket.gethostname(), which returns a string and may be non-ascii in that case
<markh> yes :)
<luks> personally I'd just decode is using the user's locale
<markh> on windows the encoding would be 'mbcs' (which is also filesystemencoding) - but yeah
<markh> hard path to test - monkeypatching maybe?
<luks> no, that's the filesystem encoding
<luks> it would be cp-something
<markh> windows is likely to return a string that went via WideCharToMBCS (or however it is spelt), in which case "mbcs" would be the appropriate encoding to use IIUC
<markh> the same value directly from the api via unicode would also be an option
<markh> win32api.GetComputerNameEx(0) returns unicode :)
<markh> but - rio is still potentially broken in the future.  ISTM it should probably throw an exception for a string
<markh> as even a utf8 string would blow it up today
<luks> well, is does, UnicodeDecodeError :)
<markh> :) but only when it actually contains non-ascii
<markh> it should raise an exception *every* time it gets a string, as it means one day a Unicode error will happen that is hard to reproduce :)
<luks> yeah, I suspect that would break a lot of bzrlib code
<markh> well, it could be argued that code is already broken for some users
<luks> true
<markh> beer-oclock!
<lifeless> rio probably wants to be asserting on bytestrings rather than decoding
<uws> Hmm
<uws> Will bzr have something like this:  http://www.gnome.org/~federico/news-2008-08.html#12  and http://treitter.livejournal.com/7769.html   ?
<uws> interactive rebasing/stacking patches
 * AfC writes uws a shell script
<AfC> :)
<uws> AfC: Eh, how would that work?
<uws> AfC: This is about merging multiple commits into one
<uws> so that the history is cleaner when merging into mainline
<AfC> [Ok, switching back to reality: I know a goodly number of people around here respect (and in some cases, including my own, absolutely worship) the UI that was presented by Darcs. Nothing to do with patch commutation vs tree snapshot issues; but the console UI was bloody brilliant in its interactiveness and consistency]
<AfC> uws: well, given that rebase is ultimately just a wrapper around `bzr merge -r X..Y ../theirs` (for X not in mine)
<AfC> uws: it's eminently scriptable
<lifeless> uws: yes
<lifeless> uws: there is a bug open on rebase -i
<AfC> (ok, so rebase has nice logic for moving forward and backwards / continuing as conflicts arise)
<lifeless> uws: it has somethoughts on how to make it happen
<uws> lifeless: will that also make it possible to "collapse" multiple commits into one? E.g. a real patch + 2 subsequent typo fixes
<lifeless> uws: sure
<lifeless> uws: I mean, its basically uncommit -r -3; commit
<lifeless> uws: and then rebase replay after that
<lifeless> uws: note that there is a way to do all that rebase does in terms of presenting things without sacrificing history; for the case where you need to evolve a patch-branch rather than simply fake up work done
<uws> lifeless: ...which is?
 * AfC guesses Robert's loom concept
<uws> Something that helps merging stuff into a branch chunks would also do the job right?
<uws> so that if history is like this:
<uws> add-feature-1, fix-typo, fix-typo
<uws> add-feature-2, fix-typo, fix-another-typo
<uws> i.e. 6 commits
<uws> that you can create a branch (preferably in place) that is like this:
<uws> add-feature-1 (add-feature-1, fix-typo, fix-typo),  add-feature-2 (add-feature-2, fix-typo, fix-another-typo)
<uws> where the parenthesized commits are merged revisions
<AfC> uws: this is going to sound silly, but why not just take a branch at point 0
<uws> something like "bzr collapse -r 1:3" which will give you an editor with all commit message
<uws> so you can assemble a new commit messte from these
<AfC> uws: then merge from feature-1+fix-typo+fix-typo,
<AfC> uws: then merge from feature-3+fix-typo
<uws> AfC: Yeah, that's the same net effect.
<AfC> you'll end up with two left hand side revisions (merges, as it happens) that you can write up to your heart's content.
<uws> but it's cumbersome
<AfC> More cumbersome that screwing around with rebase and history erasure?
<uws> No, what I described a few lines back doesn't change history, does it?
<uws> it just "groups" a few revisions into a merge, and then does the same again
<uws> so that a "bzr log" will list only the 2 groups at the top levle
<AfC> [as an aside, I have a slightly different problem, which is that the left hand edge merges are NOT what are significant in our project, and I'm getting rather tired of writing the same detailed log message again and again as features get merged up]
<AfC> uws: {shrug}
<AfC> uws: that is exactly how Bazaar operates today
<AfC> uws: so I guess I'm a bit vague on which part you consider cumbersom
<AfC> e*
<uws> AfC: Well, I branch a project
<AfC> (one possible point that's missing: you can do a merge even if there is no divergence)
<AfC> (instead of pulling)
<uws> AfC: then I start hacking
<uws> commit new feature, fix a syntax error
<AfC> yup
<uws> but when my work goes back into mainline I don't want the typo fix to show up so prominently
<uws> I want to present my branch as a few self-contained revisions (which may be merge revisions containing also the tiny typo fixes)
<uws> right now it seems I can only do this with a 2nd personal "helper" branch in which I merge selectively
<AfC> uws: well, you either cherrypick, thereby losing that history completely, or you merge it, and hope that most people don't pay much attention to non-left-hand-edge revisions. (`bzr log` is so biased; `bzr viz` is not)
<uws> I don't like cherrypicking that much (for the reasons you stated)
<AfC> uws: is the source branch a [bzr-svn] checkout in this case?
<AfC> if it is not,
<AfC> then it's already capable of being the staging area for you to create the merges that are "cleaner"
<AfC> if it is, then really you need a temporary 2nd branch to do the work in before bringing it back to the checkout
 * AfC is ignoring the --local capabilities, which he doesn't know anything about unfortunately
<uws> AfC: Yes it is
<AfC> I thought so
<AfC> In that case, look at it this way
<uws> AfC: --local is just committing without having stuff in the bound branch
<AfC> the bzr-svn branch [checkout == slaved to upstream] really wants to be kept pristine as a copy of upstream
<uws> next non-local commit will just push the whole bunch on top of the bound branch
<AfC> well there you go
<uws> AfC: I have a trunk branch, which I don't hack on (it doesn't have a workign tree)
<uws> then I have my own branch
<uws> I keep trunk/ up to date
<uws> and then merge trunk into my own branch
<AfC> uws: anyway, if this is an upstream like, say, GTK where commit permission is only grudgingly granted after long discussions, then you'll need not just somewhere else to stage your patches, but a whole bunch of somewhere elses to stage each feature.
<uws> AfC: in this particular case it's a read only bzr-svn checkout/branch
<AfC> uws: yup, it all sounds sane
<uws> branched over http://
<AfC> uws: so I guess I'm confused as to why you feel uncomfortable doing the merges of N revisions at a time into your own [writable] copy of trunk vs the place where you are working
<AfC> uws: let me try a different tack on this:
<uws> AfC: My trunk/ access is RO
<AfC> uws: a place to do merges is a good idea
<AfC> [I'm talking here not ex-cathedra as a Bazaar hacker, because I am not one; but having been leaning on Bazaar fairly heavily for almost 2 years now (as you know) some patterns have seemed to serve me well]
<AfC> uws: (if I might suggest, the three branches could be named
<AfC> uws: 'upstream' (that's the bzr-svn RO checkout), 'trunk' (RW bzr branch which you keep in sync by pulling regularly from ;upstream') and 'working' (or otherwise feature named branches, RW bzr)
<AfC> uws: and you'd do your merge work in 'trunk')
<AfC> {shrug} something like that
<uws> AfC: Yeah, I'm not a bzr hacker either. Just a regular user. I shove bzr up my colleague's throats as well
<uws> so I'd better know what/how because they ask me all the time ;)
<uws> AfC: But once I merged my feature into 'trunk'
<uws> I won't be able to 'pull' upstream anymore. Just merge
<uws> Eventually the goals is that my local patches end up upstream after review/chagnes
<AfC> uws: (or, 'trunk' [bzr-svn], 'working', and feature-braches^N)
<AfC> uws: realistically, aren't you maybe overthinking this a bit? You're going to be doing
<AfC> $ bzr diff -r ancestor:../trunk
<AfC> all the time to extract diffs to show people
<AfC> and it's not until a patch is accepted that you can go and merge to a RW checkout of trunk - and that merge sums up the other stuff, no?
 * AfC thinks uws is going to need a whole plethora of branches each containing a feature. They will be individually diffed against 'trunk' for review, but also will be fairly constantly merged into 'working' which is the branch with a WT which is where you are actually hacking.
<uws> AfC: All needing lots of disk space :(
<gour> uws: shared repo?
<AfC> I have found myself doing this; except that since I'm doing the creative work in 'working', creating little branches for individual featurettes which may be mergeable means manually copying the changes over to the little branches, creating revisions there, and then merging back to 'working'. Messy, but at least I'm not cherry picking
<uws> gour: of course, but still lots of disk space
<luks> use treesless shared repository and a single checkout
<AfC> uws: the branches storing the individual features as they grow don't need Working Trees
<uws> hmmm. idea: have branches without working trees, and have one checkout which I can "bzr switch" to the feature I'm working on
<AfC> uws: branches themselves are negligible in size.
<uws> AfC: But the working tree is HUGE in this case
<AfC> uws: that is essentially how I work
<uws> AfC: it's like ~600M
<AfC> uws: that's fine. You only need one (maybe 2 if bzr-svn needs a Working Tree)
<uws> and > 50k files
<AfC> uws: yes, that's fine.
<uws> AfC: (it doesn't)
<AfC> uws: bzr switch should handle it no problem
<uws> oh, for reference: we're talking about Webkit here btw
<AfC> uws: I suspect that reality is that you're going to need 2 Working Trees, then - one for hacking in, and one for doing patch prep & merging
<AfC> the later would be the thing you're switching around.
<AfC> Well, I've said enough. I look forward to hearing how it works out for you.
<AfC> [600 MB? What on earth have they got in there?]
<uws> AfC: millions of tests
<uws> AfC: Like >300MB of them
<lifeless> uws: yes looms are the [partial] implementation of 'edit and manage with history and collaboration]
<gour> what's missing?
<robtaylor> lifeless: not sure what you mean, gobject code dont get that heavy on memory io.
<lifeless> gour: polish
<lifeless> gour: helper routines
<robtaylor> lifeless: the objects are allocated by a slice allocator
<lifeless> gour: and, in the core of bzr, seriously cherrypicking [equivalent to darcs]
<lifeless> robtaylor: so are python objects, but every ref and deref is a memory write
<lifeless> robtaylor: its intrinsic to ref counted systems
<robtaylor> lifeless: uhhu
<robtaylor> lifeless: gstreamer has refcounted objects..
<robtaylor> lifeless: i don;t think its something to worry about
<robtaylor> lifeless: i thought python keeps a live count for objects anyhow?
<gour> lifeless: will something of the above happen in 1.7 time frame?
<lifeless> gour: if someone sends in patches :)
<lifeless> robtaylor: I will bet you significant amounts that gstreamer has refcounted external objects, not every internal detail
<robtaylor> lifeless: GstMiniObject is used for everything
<robtaylor> lifeless: refcounting happens all along the pipeline
<lifeless> yes, but thats still very coarse AIUI
<lifeless> the objects I am working with are 10's of bytes long
<lifeless> with millions in even only moderately large trees
<robtaylor> lifeless: oh, something like that you just do with structs and slices
<robtaylor> lifeless: you only need refcounting if your dealing with complex lifetimes
<lifeless> right, this is kindof my point :)
<robtaylor> ok :)
<AfC> How come you're so interested in GObject this week?
<robtaylor> lifeless: ooi do you always know the size of the objects?
<lifeless> robtaylor: for some yes
<lifeless> robtaylor: something taseful will arise, I'm sure
<lifeless> AfC: I think a better question, is, what is robert writing
<AfC> Which Robert :)
<Jc2k> evil twisted things that shut not be spoken about
<lifeless> Yes
<Jc2k> should*
<lifeless> AfC: Yes
<Jc2k> ever
<AfC> [note that I didn't direct the question in any particular direction :)]
<AfC> That's ok. There's no way you have a monopoly on crazy ideas. I've got an R&D project going to examine what would happen if we let the Java VM manage GObject life cycles instead of letting GObject's Ref and ToggleRefs do it.
<AfC> (so discussion about sizes, access patterns, and what the slab allocator is up to this month are of passing interest)
<lifeless> ahha!
<lifeless> so I'm writing another C extension
<lifeless> somewhat larger than our current ones
<lifeless> and I want to use low level C diagnostic tools
<lifeless> so I want no python VM
<AfC> lifeless: (that's what I vaguely suspected)
<robtaylor> AfC: that crazy R+D project sounds pretty interesting =)
 * AfC imagines Robert will have more luck that him :)
<AfC> robtaylor: well, it's a couple things [and I am only disucussing something so OT here in so far as it seems conceptually similar to Robert's experiments]
<lifeless> well, I have antlr3 running now
<AfC> robtaylor: we have the whole ToggleRef thing in place to manage the relationship between our Java Proxy objects and the underlying GObjects. But it gets complicated;
<AfC> and it's not as effective as I would like, because there is too much lock-step going on between the two sides.
<AfC> It *works* (there are zero leaks)
<AfC> [ok, famous last words. We're pretty good, though]
<lifeless> how does gintrospect fit into your bindings?
<AfC> But I have encountered situations where not everything is cleaned up at once. The last Ref to a GObject is our ToggleRef; our Java object becomes only weakly reachable and so next GC, ta-da, we drop the ToggleRef and the GObject finalizes.
<AfC> That's all good
<AfC> The trouble comes that when it's not something violent like a 'delete-event',  (where violent is code paths in GTK that go above and beyond about breaking references)
<AfC> then it's only now that some of the child Widgets drop down to being us owning the last ref.
<AfC> which means that they won't get destroyed until the *next* GC cycle.
<AfC> Bah!
<AfC> lifeless: (short answer, not yet)
<AfC> lifeless: (longer term answer, our code generator is nicely abstracted, so the .defs data feeding it can be replaced with introspection data when it comes available. But it needs to be fairly complete before we reach that point. When we're generating the C API for GNOME libraries off of that data, then I think we'll be set)
<AfC> :)
<AfC> robtaylor: so anyway, it occurred to me that this lockstep'edness was occurring because the Java VM doesn't have full information about the relationships. If it did, it could see the closed sets and pow them as a group
<AfC> robtaylor: I rather expect that the cost of going across the JNI boundary to reach the Java VM's reference queues instead of using GObject's internal hash tables will be prohibitively expensive, but it's been an interesting exercise so far.
<robtaylor> AfC: I'd be very interested in having a g_objcet_ref_with_association (object, owner)
<robtaylor> AfC: i suspect the Vala people would too
<strk> what's that command to show current revno ?
<AfC> robtaylor: everyone who is proxying would, I imagine
<strk> it's not printed in 'bzr help'
<robtaylor> *nod*
<AfC> strk: `bzr revno`
<robtaylor> AfC: anyhw, the crack project we're working on in our free cycles is http://wizbit.org
<strk> does 'revno' checks revision on remote or local tree ?
<Jc2k> <h1><u><b><blink>CRACK</blink></b></u></h1>
<AfC> robtaylor: I should call you sometime and chat with you about that. It fits in nicely with some areas I'm working in
<robtaylor> AfC: feel free :)
<AfC> strk: so, being pedantic, it will tell you about the "branch"
<AfC> strk: if you do `bzr revno` it'll tell you about this Branch (assuming you're in a Branch)
<strk> damn. I have two builds from two trees. both trees give same revno, but one works in a way, one doesn't
<AfC> strk: if you do `bzr revno bzr://research.operationaldynamics.com/bzr/java-gnome/mainline/` it'll tell you about bzr://research.operationaldynamics.com/bzr/java-gnome/mainline/
<AfC> strk: revnos are only meaningful per branch
<lifeless> strk: because you can have multiple branches, revno's are only relevant to a brnach
<AfC> strk: what you probably need to inspect are the revids (though, in human readable terms, the last few log entries should tell you what's what)
<lifeless> strk: if you want the uuid, 'bzr revision-info' is the right command to use. But I generally would use 'bzr missing' instead, because that tells me what commits are in each
<AfC> strk: `bzr revision-info`
 * AfC gets out of lifeless's way
<strk> matches as well
<strk> (revision-info)
<strk> Branches are up to date.
<AfC> strk: if you `cd ONE` and do `bzr missing --line /path/to/TWO` you should be told what's different
<strk> still up to date
<AfC> robtaylor: anyway, I'm trying to figure out if I can replace (override) the GObject Ref mechanism. That means hijacking g_object_ref and g_object_unref, and all the ways to do such a thing are nasty.
<AfC> strk: silly question, but I assume `bzr diff` shows nothing in each one
<lifeless> strk: you have two separate working trees ?
<strk> right (no diff, two working trees)
<AfC> robtaylor: hijacking GObject's memory allocation would be a second step. That's not just crack. That's ice.
<AfC> And enough on that topic.
<robtaylor> AfC: yeah, pain :/
<strk> after 'bzr switch trunk', altought revision-info didn't change, 'make' is doing something
<strk> this is Bazaar (bzr) 1.6rc2
<strk> is it supposed to touch files even if nothing changed ?
<AfC> (it could)
<lifeless> strk: bzr revision-info changes for me
<lifeless> strk: no, it won't touch files if nothing has changed
<lifeless> strk: it will touch files if they *happen* to have the same content but appear changed to bzr
<strk> it seems a regression was introduced, so I was hoping to figure which revno worked and which not... unfortunately I had the same revno back from the two branches... that's how it all started
<strk> now it's hard to tell (we don't store revno in binary modules)
<strk> and bzr viz stopped working :/
<strk> would switching to a specific revno require online access or my local branch is enough ?
<strk> bzr diff -r 9590 -r 9591 # didn't do what I expected, did it ?
<strk> diffs between two revisions
<strk> it seems it gave me diffs from 9590 to current
<strk> bzr diff -r 9590..9591 # did it, it seems
<lamby> 'lo jelmer .. Curious to why you uploaded bzr-gtk to experimental? :)
<strk> I hope for me
<strk> bzr was to experimental (I guess, as I was prompted for upgrade) but since I upgraded, bzr viz stopped working
 * gour finds 'shelve' command useful...
<pickscrape> shelve is awesome :)
<gour> right. it keeps my history more 'sane' considering i am coming from darcs world and nice interactive 'darcs record'
<Peng_> "record" would be even better than shelve though.
 * gour agrees
 * pickscrape doesn't know anything about record
<gour> pickscrape: http://www.darcs.net/manual/node8.html#SECTION00861000000000000000
<pickscrape> Ah, so it's interactive commit?
<gour> yep
<gour> ..if you want
<pickscrape> That reminds me how I got by without the shelf when using svk: it has interactive commit too.
<gour> it would be nice to have it in bzr as well
<Peng_> The first interactive commit-like thing I used was bzr's shelve. When I found hg only had a record plugin, I was disappointed, and it took a while to get used to, but now I hate having to go to the trouble to use "bzr shelve".
<Peng_> They do have different uses, of course, and I have missed shelving in hg a couple times.
 * gour uses shelve as poor-man's-interactive commit
<lifeless> Peng_: install bzr-interactive
<Peng_> Ooh
<Peng_> How does bzr-interactive work? Does it add a "record" command? Does it change "commit"?
<Peng_> I think it adds "record".
<lifeless> Peng_: also you might like to comment on my tree marks concepts
<Peng_> lifeless: What's that?
<lifeless> a concept I'm exploring
<lifeless> I started a thread about better review support
<Peng_> lifeless: Thanks for suggesting bzr-interactive. :)
<quicksilver> where do I find information about bzr-interactive? I found the launchpad page but it's a bit bare.
<Peng_> quicksilver: The source code, I guess. Or "bzr help interactive" after installing it.
<Peng_> quicksilver: There's not much to say. It adds an -i option to commit.
<Peng_> It also adds a record-patch command.
<quicksilver> I found the author's blog post.
<quicksilver> I have feeling I might consider commit -i harmful.
<quicksilver> After all if you commit -i and commit anything less than all hunks, that suggests that you haven't tested the version you ahve committed.
<quicksilver> That sounds like bad practice?
<Peng_> Hmm, I suppose you're right.
<uws> Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)
<LarstiQ> quicksilver: now hook up -i code that takes the new tree and runs automated tests on that
<uws> ^^ Why do I get this with 1.5 and 1.6 client?
<uws> there's no newer version, is there?
<Peng_> uws: There is.
<Peng_> uws: 1.6 introduces a new network protocol.
<Peng_> I usually use interactive commits when working on non-code files, so testing is moot.
<quicksilver> LarstiQ: indeed; but I think you take my point.
<uws> Peng_: Ok, didn't know that.
<uws> but 1.6 is not stable so I won't upgrade the server :)
<Peng_> uws: OK. :)
<Peng_> uws: You'll have to either downgrade your local bzr to 1.5 or live with that message and the second connection.
<LarstiQ> quicksilver: yes, I personally tend to agree, but there are ways to mitigate that risk.
<jam> LarstiQ, quicksilver: Personally I only make the test suite pass when i'm ready to merge into the next level, so I'm not particularly concerned about the test suite passing on *every* commit.
<jam> One of the nice things about having layered branches.
<LarstiQ> jam: right, I didn't mean the *entire* suite. Just test exercising codepaths you've touched.
<LarstiQ> even that may be too much, ah well.
<jam> LarstiQ: sure, it is just my new response for partial commits, commit -i, etc, etc.
<jam> I used to feel it was a bad deal, because you were committing something untested.
<jam> But as long as you test it at the time of merging it into the next level.
<LarstiQ> hmja.
<LarstiQ> jam: you're ahead of me in feeling comfortable about it :)
<jam> LarstiQ: I have come to realize that feature branches are a *better* way of creating that perfect merge patch
<jam> rather than trying to do it without committing
<jam> Especially when I'm exploring the space
<jam> I'll do snapshots of stuff that I know I'm going to delete
<jam> just to have something I can revert to if I decide.
<beuno> jam, hi  :)  I haven't managed to get to the packaging yet, I will try to on the next few hours
<jam> LarstiQ: I would say the biggest benefit is in development *pace*. I can snapshot as I go, and not fret *too* much about something breaking until I need everything to work
<jam> If too much breaks at the end, I can go back via the snapshots to something earlier, and tweeze the changes out from there.
<jam> So I commit small changes often
<jam> and don't wait for the test suite to finish on all of them
<jam> Though thanks to vila, I *do* tend do run the subset of tests that might be effected
<jam> -s bzrlib.tests.test_foo is great
<jam> we just need to make it shorter :)
<LarstiQ> just - instead of -s? :)
<jam> LarstiQ: well, if we could just get it to read my mind instead
<jam> then it is just ''
<jam> I think my current favorite is aliases, so that BT == bzrlib.tests and BP == bzrlib.plugins
<pickscrape> It would be clever if it picked if you from your working directory (assuming your working directory is a test directory)
<pickscrape> Damn, what happened to my English there?
 * gour is installing bzr-interactive
<james_w> vi
<LarstiQ> jam: a stat to see which files got recently changed?
<jam> LarstiQ: Interesting though I'm not sure if it would be perfect correlation
<gour> hmm, any idea what's wrong with http://rafb.net/p/6VdGNy88.html ?
<jam> gour: you logged in and so are pulling from a different URL into a checkout of the http url
<jam> why not just "bzr update"
<jam> (bzr pull will update both the local branch, and the branch it is bound to, but you are bound to an HTTP branch, and thus updating it fails)
<jam> I'm guessing you've logged in, because it isn't warning you
<jam> which means that it is pulling from bzr+ssh:///...
<jam> and thus doesn't know it is the same branch.
<beuno> jam, older versions of bzr don't warn you
<beuno> gour, are you using 1.3.1?
<beuno> (hardy default)
<gour> beuno: no, 1.7dev
<beuno> ah, then it is odd
<gour> jam: hmm, i just wanted to 'update' upload plugin by pulling latest revs from LP
<gour> ..by pulling from LP to my local machine...strange
<VSpike> probably a dumb question, but I've got a repo on a NTFS partition mounted in linux, and I want to do a commit on it but it shows everything changed because of permission bits (presumably)
<VSpike> I was going to copy it to an ext3 fs and then twiddle permissions, so I used cp -r but then bzr said it was not a branch
<VSpike> I manually copied .bzr because cp left it behind
<VSpike> Is that maybe because it is in a shared repository?
<Peng_> Well, if your copied branch had no repository, that would cause problems...
<Peng_> You should use "bzr branch", and maybe "bzr merge --uncommitted" if you want to pull the working copy changes too.
<VSpike> I've worked around it by using cp -a on the root of the shared repo
<VSpike> How can I get bzr to show me which file properties have actually changed?
<VSpike> I tried using find to remove all permission bits, but that doesn't seem to be it
<VSpike> remove all *execute* bits i mean
<timnik> "bzr diff filename" will show me a diff of filename's changes. How might I tell bzr to use a graphical program such as meld to show me the diff?
<timnik> Uncle google didn't seem to be of much help on this one.
<pickscrape> bzr diff --using=meld ?
<timnik> pickscrape, sweeeet :-)
<ToyKeeper> timnik: bzr alias mdiff='diff --using=meld'   ...  then run 'bzr mdiff'
<timnik> thanks!!
<timnik> ToyKeeper, oooh, I like :-P
<timnik> thank you
<pickscrape> Isn't the bzr alias command new in 1.6?
 * ToyKeeper tries again to figure out how to split a subdir into a new branch, including only the history for that subdir
<gimaker> pickscrape, correct.
<pickscrape> Just in case timnik is running 1.5 and find that doesn't work :)
<gimaker> you can still edit edit bazaar.conf manually though
<ToyKeeper> So far, it looks like 'bzr split foo/' and then 'bzr remove-revision N' for each unwanted rev N.  :(
<gimaker> personally I like to use what ships with ubuntu, which is 1.3.1
<TheEric> found a simple solution to our xpattern bug and bzr/lp with the revision history set to 0 - repush the last revision and *poof* everything was back to the way it was.
<ToyKeeper> bleh, remove-revision seems to be broken.
<Necoro> does bzr-svn support stacked branches?
<Necoro> so that there would not be the need to download large repositories
 * beuno releases Loggerhead 1.6
<james_w> congratulations beuno and mwhudson
<beuno> james_w, thanks!  :)
<Necoro> hmm - ok ... atleast it works
<Necoro> wondering how long - or if I'm missing an important point ;)
<tacone> congrats
<jam> beuno: good to hear
<beuno> jam, next on my list is packaging bzr. So here I go...
<hsn_> bzr check reports: 1 incosistent parent, is there way to determine what file/branches/projects are bad? its shared repo between several projects
<Peng_> hsn_: Just run "bzr reconcile".
<Peng> Ooh, Loggerhead 1.6. Congrats!
<hsn_> Peng: i heard rumours that bzr reconsile takes hours to run
<Peng_> hsn_: Is your repo gigabytes in size?
<hsn_> about 0.5gb
<Peng_> hsn_: Eh. It'll probably take a while then.
<Necoro> hmm ... are stacked branches a good replacement for looms?
<Peng_> hsn_: A couple inconsistent parents aren't a serious issue. Reconcile will fix it, but you don't really need to bother.
<Necoro> or not really
<Peng_> Necoro: Are pencils a good replacement for skateboards?
<Necoro> Peng_: hmm - then I misunderstood what stacked branches were supposed to do
<Peng_> Necoro: They allow you to avoid storing the entire repo locally.
<Peng_> Necoro: Sort of like a lightweight checkout, only it acts like a branch and you can commit locally and everything.
<Necoro> ok ... but if you would make stacked branches of the "trunk" stacked branch you would end up with lightweight feature branches, right?
<Necoro> I just noticed that looms does not work with stacked branches - and I don't want to download this 11k-revs-svn-repo
<Necoro> so I'm looking for an alternative :)
<Necoro> and having a stack of branches seemed reasonable ... because looms are a stack too
<jam> beuno: do you want to send your email to the 'bazaar-announce@' as well. I think it is worthy and I'll "accept it"
<beuno> jam, yes!  I'll send it now, thanks  :)
<beuno> jam, sent
<jam> beuno: Did you see: https://bugs.launchpad.net/bugs/258166
<ubottu> Launchpad bug 258166 in bzr "please package as non-native package" [Undecided,New]
<jam> lamont feels we are being bad packagers
<beuno> jam, yeah, we talked it over, he's right, etc
<beuno> we'll need to change the packaging doc a bit
<jam> beuno: also, update the docs
<beuno> :)
<Necoro> ok ... branching fails if "A" is a stacked branch of an svn-repo and you are trying to create another stacked branch "B" from "A"
<Necoro> then downloading the 11k revs is the only alternative =|
<lamont> jam: I wouldn't care so much if it weren't 3MB+ of tarball and my  link being crap
<jam> Necoro: branching from a stacked branch only creates a stacked branch if you request it
<Necoro> jam: i did: bzr branch --stacked A B
<Necoro> so I requested it :)
<Necoro> but I guess the problem lies in bzr-svn
<jam> I'm surprised, as I believe it is something we implement.
<jam> But it may be something that is rough
<Necoro> tells me something about: bzr: ERROR: Connection closed: Connection closed unexpectedly
<jam> beuno: one thing that would be nice, try to keep a good log of everything it takes you to make a release.
<jam> I'd *really* like to see it more automated.
<jam> It takes far too much dev time to package a new release, considering we want to do 2 per month.
<jam> (rc & final)
<jam> beuno: also, it seems the dapper packaging has the old bug #249452
<ubottu> Launchpad bug 249452 in bzr "bzr overrides the shell prompt settings" [Critical,Confirmed] https://launchpad.net/bugs/249452
<beuno> jam, ok, I'll try and do it this time
 * Necoro just does the 11k revs pull now :)
<TheEric> so, we fixed our issue with the revision history being set to 1 and not being in sync, but now we're getting the revision emails all over again. All 1264 of them.
<jam> lifeless: I know you didn't like the workaround in status, but this seems to be the 3rd or 4th bug report of the status bug: bug #258358
<ubottu> Launchpad bug 258358 in bzr ""bzr status" errors" [Undecided,New] https://launchpad.net/bugs/258358
 * LeoNerd discovers the branch/uncommit/commit/replay  method of fixing earlier commits
<LeoNerd> 7 shades of evil, but cute at the same time
<jam> so what do you guys think about bug #258349
<ubottu> Launchpad bug 258349 in bzr "Special character "Ã" cannot be used in the commit message." [Low,Triaged] https://launchpad.net/bugs/258349
<jam> should I mark it as 'invalid' because it is a limitation of cygwin?
<Necoro> hmm - ok
<beuno> jam, I think it's invalid, as bzr can't really do anything about it
<beuno> jam, btw, it seems the bzr 1.6* announcements are missing in LP
<jam> beuno: hmm... did I make them?
<jam> I think you have to do a separate announcement for a release.
<jam>  And it isn't part of the official "releasing.txt" document that reminds us about all that stuff
<beuno> jam, ah, ok. I just saw that 1.5 was the last one announced, so I thought it was
<jam> beuno: yeah, looks like I manually did that in 1.5 (and for 1.5rc1) I'll go ahead and do it for 1.6rc3
<jam> I know poolie didn't for 1.6rc1 and the betas
<jam> beuno: could it be that they were automatic when being put into the ~bzr ppa, but aren't because it is the ~bzr-beta-ppa ?
<beuno> jam, nah, poolie did it manually
<beuno> they don't get done automagically, although that would be a cool feature
<Peng_> beuno: Thanks for giving me credit in the Loggerhead 1.6 release. I've really enjoyed making my little contributions, and just watching you guys work. :-)
<beuno> Peng_, you absolutely deserve the credits, you're part of our test suite!
<Peng_> Heh.
<Necoro> hmm - is there a way of having a diff of a branch to its parent branch sent per mail? - but not the "bzr send" way of working
<Necoro> just the patch :) w/o having to do "bzr diff > some.patch" and then attach this to some mail
<Kinnison> Necoro: You mean you don't want a bundle?
<Necoro> Kinnison: right ... because the project uses svn - and all the bundle information is just unnecessairy
<Peng_> bzr send has a --no-bundle option. I think t'll still include a bit of meta data, but not that mcuh.
<Necoro> and "bzr send --no-bundle" needs my branch being publically available
<Peng_> Oh.
<Necoro> oh - it works, if I use "." as public branch =D
<jam> Necoro: so as you commit multiple times, you want it to keep growing? Or you don't want this to be automatically done, just as a one-time thing?
<Necoro> jam: just when I finished some work (bug fix for example), I want all commits in one patch sent to the m-l
<jam> Necoro: is there a reason you don't want the branch metadata included?
<jam> As then people can just "save attachment your.patch" "bzr merge ../your.patch"
<Necoro> because they do not use bzr
<Necoro> and it would just be unnecessary noise
<Necoro> probably annoying some guys
<Necoro> I just noticed that git-send-email, which I took at the model for the functionality, actually needs patches as files
<Necoro> but I don't want to have tons of patches lying around -.-
<Necoro> just something like: "bzr send-this-loom --mail-to some@addre.ss"
<Necoro> I guess, I have to write it by myself
<jam> Necoro: 'bzr send -r thread:..-1 --no-bundle' though I guess you want to break apart the loom?
<jam> I think something like that would be more-than-welcomed into the loom plugin.
<jam> Possibly as a wrapper for the 'bzr send' command itself when you are working in a loom
<jam> (like is done for 'bzr status' and some other commands)
<Necoro> jam: you need to specify the public branch ... so the correct command would be: bzr send -r thread:..-1 --no-bundle . .
<Necoro> not the two dots :)
<Necoro> *notice
<Necoro> but I think there is still to much bzr-metadata in it
<jam> Necoro: well, you could set your public_branch location in ~/.bazaar/locations.conf as an alternative
<Necoro> truw
<Necoro> *true
<jam> Though 'bzr send' *is* meant as a way to convey bazaar changes between people (hence a public location if you don't send the metadata, etc.)
<Necoro> jam: yeah - BUT: this is the wrong assumption: not every project is using bzr just because one guy happens to do so ;)
<Necoro> so for the moment I'll go with the normal "diff && attach to mail"-procedure
<Necoro> and see if have some time left next month to write a nice "mail-to-non-bzr-users"-plugin :)
<jam> Necoro: I might point you toward bug #227340
<ubottu> Launchpad bug 227340 in bzr "Simple way to prepare patches for submission" [Wishlist,Confirmed] https://launchpad.net/bugs/227340
<jam> which at least seems related
<Necoro> jam: thx
<beuno> lamont, ping
<lamont> beuno: can I have a couple min first?
 * beuno hands a couple of minutes to lamont 
<rockstar> If I bzr upgrade a local branch, and then push it up to an existing branch on Launchpad, will that upgrade the branch there as well?
<Peng_> rockstar: no
<Peng_> rockstar: You'll have to run upgrade on Launchpad over sftp or (in bzr 1.6) bzr+ssh.
<rockstar> I didn't think so.  Just trying to plan my upgrade properly.  the latest rc seems to have deprecated this specific format.
<lamont> beuno: wassup?
<beuno> lamont, so, I was looking at what I did for the 1.6rc2, and I did name the tarball .orig*
<lamont> if the version in debian/changelog is FOO-BAR then you need bzr_FOO.orig.tar.gz
<lamont> so did you name it bzr_1.6~rc2.orig.tar.gz, or something else?
<lamont> and it needs to be in the parent directory of wherever you do debuild
<lamont> which is to say, in the parent dir of bzr-1.6~rc23
<lamont> s/3$//
<beuno> lamont, bzr-1.6rc2.orig.tar.gz
<beuno> the - screwed me over, didn't it?
<lamont> note the missing ~
<lamont> and the dash instead of underscore
<lamont> once you have the orig.tar.gz as it needs to be, if you forget the -I.bzr -i.bzr it'll bitch about binary files in the diff... :-)
<rocky> jelmer: don't suppose you're around?
<beuno> lamont, ok, let's see how this turns out then...
<Peng_> rockstar: Yeah. Recent changes ruined the performance of pre-pack repos, so they were deprecated. It was about time anyway, since they're old and inferior.
<rockstar> Peng_, yea, I knew there were upgrades needed.  I also know that a few of my last attempts didn't work.
 * rockstar procrastinates an upgrade
<Peng_> rockstar: How large is the repo? If it's small or you have a speedy connection, it's no big deal.
<beuno> lamont, debuild -S -sa -i -D
<beuno> is still the correct command, right?
 * lamont goes looking for what -D does
<beuno> jam, if LP doesn't take up too much of my time next week, I may attempt to script this, and correct the docs
<lamont> I expect that -i wants to be -i.bzr OTOH, if that command successfully builds a source package, and the .dsc references bzr_1.6~rc3.orig.tar.gz, then \o/
<beuno> lamont, lintian is now a bit happier than before: https://pastebin.canonical.com/8231/
<beuno> and: dpkg-source: building bzr using existing bzr_1.6~rc3.orig.tar.gz
<lamont> does debian/rules actually use quilt, or should the build-dep be dropped?
<lamont> line 2 is "meh"
<lamont> line 3-4 are expected
<beuno> well, we don't use quilt in our PPAs, maybe Debian does?
<lamont> dunno
<lamont> in short, it's just saying that you claim to need quilt, but aren't seeming to use it
<chadmiller> Hi all.  One of my cow-orkers says his branch/repo reset its revno to zero.  Sure enough, "bzr log" starts with revno 6193, but "bzr revno" says "15".  Any ideas?
<lamont> --> "meh"
<beuno> lamont, heh, ok. I can either change the standards version and remove quilt, reducing the amount of
<beuno> "meh"'s
<rockstar> chadmiller, bzr reconcile
<beuno> or upload
<lamont> if you change the standards version, you have to actually go read the cheatsheet to make sure you really are compliant
<lamont> IOW, upload
<rockstar> chadmiller, before he does that...
<chadmiller> "'bzr reconcile' seems to have fixed some things.  I'm running 'bzr check' now."
<beuno> since you've been so kind to help me, I'll let you decide
<chadmiller> He made backups, of course.
<rockstar> chadmiller, damn.  That's a bzr bug that I know exists and would like to know the cause.
<chadmiller> 'bzr check seems to be hung however in the "checking versionedfile 0/20980"'
 * beuno uploads
<chadmiller> I told him "check" will tak3e a while.
<rockstar> Can you pastebin the logs ?
<rockstar> From the old branch, the broken one?
<beuno> lamont, thanks a lot for your help, and please poke me if the debs have anymore problems  :)
<lamont> thanks
<chadmiller> rockstar: I'm getting them.
<chadmiller> rockstar: It may be big.  Want it in email?
<rockstar> chadmiller, that would be awesome
<rockstar> paul at canonical com
<chadmiller> 'kay.
<beuno> jam, so, by my calculations, once I've automated everything in my head, uploading bzr to all PPA's, sans bzrtools and other interesting plugins, it takes a bit less than half of my day away.  I wouldn't be surprised if doing it in full takes up a full day
<jam> beuno: right, and we need someone to do that 2x per month
<jam> Not to mention all the PQM time gardening a new release branch.
<jam> (That has gotten better, though)
<beuno> jam, yeah, too much. On the bright side, it should be scriptable, because everything is really automated
<jam> Anyway, out of 20 working days, killing 2 is 10% of a dev's time spent just getting releases out every moth.
<beuno> but a script to do it would take a few days work
<beuno> which seems like a good investment
<jam> beuno: sounds like you get paid back in 2 months
<jam> pretty good ROI
<beuno> absolutely
<jam> beuno: *and* if it is automated enough, then *I* can do it, which gives you an even better ROI
<beuno> jam, heh
<beuno> well, I don't really know if I'll be able to do this. I still don't have a manager, so I'm doing a little bit of everything. That may change enxt week
<beuno> but I'll certainly try to do it
<jam> beuno: who do you expect to be your line manager, btw
<beuno> jam, they're still trying to figure that out  :)
<beuno> I'm hanging around in the lp-bzr team for now, which is where I already know everybody, and can be productive *today*
<beuno> and I expect to be working on LP for the next few months at least
<jam> beuno: well, you've been productive in #bzr today as well, so thanks :)
<pickscrape> beuno: while you're around, are you aware of any good docs on METAL?
<beuno> jam, happy to help!  :)
<rockstar> pickscrape, zope's docs are pretty thorough
<beuno> pickscrape, zope has the best ones I think
<jam> beuno: hey, that's my line :) (At least according to vila)
<beuno> jam, very happy to help  :p
<pickscrape> beuno: ok, I'll have a look. The ones google found for me were really sparse on detail and examples
<beuno> pickscrape, http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/AppendixC.stx
<pickscrape> beuno: thanks :)
<pickscrape> Hopefully I'll be able to make progress on the breadcrumbs tonight. I hit a wall with it not recognising my second template
<beuno> pickscrape, cool!  let me know if you're stuck, I'll be happy to give you a push
<beuno> loggerhead is crack-ish sometimes
<beuno> as rockstar   :)
 * rockstar is indeed crack-ish
<pickscrape> :) Well, tal etc is completely new to me, so I'm learning as I'm going along
<beuno> heh
<beuno> I think I meant "ask rockstar"
<beuno> but it's friday, and it's been a *very* active week for me
<pickscrape> :)
<rockstar> beuno, by the way, paste has all sorts of profiling goodies.  I'm going to take a whack at it this weekend.
<pickscrape> Has the "unification" stuff been merged to trunk yet? If so I'll probably have a bit of fun with conflicts when I merge it :)
<beuno> rockstar, that would be awesome
<beuno> pickscrape, it has
<rockstar> pickscrape, it has
<beuno> and you will  :)
<pickscrape> ok, I'll complete what I'm doing then before merging so I can do it all in one go.
<beuno> pickscrape, it's a great way to learn about resolving conflicts
<pickscrape> Yeah. I'm used to the svk way (which is actually pretty nice)
<beuno> lamont, out of curiosity. All the other bzr releases had the .bzr dir in them, right?
<lamont> only if they were packaged without an orig.tar.gz
<beuno> so just the last one I uploaded?
<beuno> poolie removes them?
<lamont> .bzr has binary files , and .diff.gz doesn't handle them
<lamont> ergo, they're not there, one way or another.
<lamont> -mix 1520 : cat /home/lamont/.devscripts
<lamont> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-I.bzr -I.svn -I.git -i.bzr -i.git"
<beuno> ah, so you can leave them, if you do the .orig bit correctly
<lamont> I tend to just not worry about remembering it. :-)
<lamont> how so?
<lamont> .orig doesn't have a debian/ directory
<lamont> and debian/.bzr is the bit that kills you
<beuno> I'm confused
<beuno> deleting the debian/.bzr isn't in the docs
<beuno> which makes me think poolie doesn't remove it
<lamont> of course, there's no reason that I can think of to ship a stale bzr-1.6/.bzr directory as part of the source, when the current .bzr directory is what everyone wanting to muck with it should be referencing
<lamont> with the -I and -i options, you don't have to delete it, it becomes a -x.bzr to the diff command
<beuno> I see
<beuno> ok, so I don't need to add that extra step to the docs
<lamont> so if you look at poolie's old source packages, you'll find that the diff doesn't have debian/.bzr in it.  exactly _how_ poolie accomplished that, dunno
<beuno> jam, after I finish uploading to PPA's, would you like to help me debug why bzr suddenly is eating *all* my ram + swap bringing my laptop to it's knees, to pull 1 day's worth of the LP source?
<beuno> I've tried it 3 times now
<beuno> and it does it every time
<beuno> have to kill -9 it
<jam> beuno: sure
<jam> quid-pro-quo and all
<beuno> :)
<beuno> lamont, jam, just uploaded the last of 'em. Dapper with the shell fix. I'm off for ~40 minutes, and then I'll check back to fix anything that I might have overlooked, and try to debug my bzr problem if jam is still around
<beuno> jam, nm about the debugging, it was bzr-search still trying to index everything
<jam> beuno: yeah, first thing I was going to recommend was "--no-plugins" :)
<TheEric> What's the "could not acquire lock" error?
<Peng_> TheEric: It means whatever you were trying to operate on was locked (i.e. someone else is using it, or was and they crashed).
<Peng_> TheEric: Or maybe you tried to write to something read-only, like http.
<TheEric> any way to override that?
<TheEric> There was a bit of an error that we -think- was fixed in the revision history where it was out of synch with eveything else.
<Peng_> TheEric: More details plz.
<Peng_> TheEric: Locking has nothing to do with history issues.
 * meteoroid loses 10lb on the treadmill while branching a couple hundred revisions from fricking slow googlecode svn
<meteoroid> :-P
<mwhudson> googlecode svn is pretty terrible
<mwhudson> (especially *because it's google!*)
<meteoroid> i know, i was surprised..
<meteoroid> looks like my idea of offering professional hosted, private SCM and other things for people like Trac is not so bad..
<meteoroid> our svn is really fast, and soon i'll have bzr talking webdav or something fancy so i can use it as my personal primary
<lifeless> in what way is googlecode's svn worse that $vanilla svn?
<jam> meteoroid: have you looked at "bzr-webdav" the plugin Vila wrote?
 * jam is away for a bit
<lifeless> bye jam
<meteoroid> jam: yeah i haven't got the server setup yet
<meteoroid> and i don't have 1.6 going
<mwhudson> lifeless: it's unreliable
<mwhudson> code imports from google code rarely complete if it's more than a few hundred revisions
<mwhudson> (this is partly because cscvs is terrible, of course, but ...)
<meteoroid> lifeless: well, it's terribly slow, is the problem.
<meteoroid> 154 revisions and still maybe 75% complete
<meteoroid> it's been over 20 minutes!
<meteoroid> the servers are either overloaded or excessively throttled
<meteoroid> i mean, i pushed four revisions from bzr into svn at googlecode and it took 5 minutes..
<meteoroid> four revisions! a few config files and a python script that downloads code from elsewhere
<Peng_> I don't have problems with Google Code's svn, but I guess I don't use it for anything large.
<Toranin> anyone here have a recommended best way to convert a very long-historied (well over 90000 revs) svn repos?  I couldn't get the bzr-svn extension to work (may try again later), and it's looking like svn2bzr (dumpfile version) will end up taking like 2 weeks to make it through the whole thing
<Peng_> Toranin: You should use bzr-svn, and get help here if you encounter problems.
<lifeless> Toranin: bzr-svn
<aquarius> I've got one folder which is under bzr control; I've done bzr push to a private sftp repository. If I want to edit it on another machine as well, should I bzr branch sftp://wherever or bzr checkout sftp://wherever ?
<lifeless> Toranin: older versions will leak like a sieve (the bindings to svn were dud, new versions of bzr-svn have their own, and shouldn't leak).
<mwhudson> some kind of fast-import based approach would be the other idea i guess
<lifeless> Toranin: if it does leak, just ctrl-C and resume
<mwhudson> but yeah, bzr-svn would be the thing to try
<Toranin> I have the new version, but the selftests fail
<lifeless> aquarius: thats right
<Toranin> with the same assertions I see when trying it on the repos
<lifeless> Toranin: please do file a bug
<aquarius> lifeless: heh. Sorry, my question was "which of those should I use?" I'm a bit unclear on the difference :)
<mwhudson> Toranin: what version of bazaar
<mwhudson> ?
<lifeless> aquarius: branch will make a new branch; checkout will let you work on the existing branch directly
<Toranin> IIRC (this was a few days ago) 1.6rc1, with bzr-svn 1.4rc1
<meteoroid> Toranin: do you have access to ubuntu hardy? that's how i keep bzr-svn functional
<meteoroid> i just suck it out of svn then i can talk to it from plain-jane bzr from any other box
<Toranin> no, I'm stuck with platform FreeBSD 6.3-RELEASE amd64
<aquarius> lifeless: so if I checkout, then bzr commit commits straight back to sftp, but if I branch then bzr commit goes locally and I have to bzr push to get it back into sftp?
<Toranin> but I do have a jail with separate software
<lifeless> aquarius: exactly
<Toranin> so I can keep a functional bzr around without too much trouble
<lifeless> Toranin: so, I think you need bzr 1.6rc3 because there was a patch to bzr Jelmer put in on wednesday or so
<aquarius> lifeless: ok, I'm starting to get a handle on this, cheers. :)
<meteoroid> well if you can get subversion 1.5 with its' python bindings working, you should be home free on bzr-svn
<meteoroid> and that's the route to go, i think.
<lifeless> aquarius: excellent
<aquarius> and...if I already have the code on the second machine, and I bzr branch in that folder, will it cope with some of the files already being there? Or will it chuck some sort of horrible wobbler?
<Toranin> meteoroid: old bzr-svn (with svn's python bindings) on svn 1.5 gives an assertion failure and crashes the Python process
<Toranin> something about paths not being allowed to start with a '/'
<meteoroid> when does it give this failure?
<Toranin> whenever you attempt to run any command that accesses a repository
<Toranin> whether remote or local
<meteoroid> sample command?
<Toranin> hmm
<Toranin> (this was a few days ago when I last tried it)
<Toranin> bzr log svn+https://url/to/trunk
<meteoroid> try something like: bzr svn-import svn+http://some-svn-repo/
<meteoroid> i had issues with high rev count but if you have the latest bzr-svn it should have a leaking issue fixed..
<Toranin> meteoroid: let me get the latest bzr and bzr-svn as of today, and I'll get back to you with results and selftest failures if any
<Toranin> or to the channel anyway
<lifeless> aquarius: if you run bzr branch somewhere, it will make a subdirectory and put its own files within that
<lifeless> aquarius: you can copy your own versions over the result
<aquarius> lifeless: ah. The folder in question is my home folder...so I wanted to do "bzr branch sftp://blah . "
<Toranin> meteoroid: okay, running a svn-import on a svn+file:// of a backup repos
<Toranin> at 90488 revs
<Toranin> it's at "determining changes" now, we'll see if it gets past there before I have to leave for the evening
<meteoroid> right on
<meteoroid> how much ram on this box?
<meteoroid> you did 'nice' right? heh
<meteoroid> i found, btw, on a multicore, that branching http from localhost was faster because apache used 30-60% of a core and bzr would stay steady around 60-80
<meteoroid> otherwise bzr just takes up like 60-80 wit a file://
<meteoroid> probably would be faster with svnserve because http is chatty
<Toranin> no nice on it
<Peng_> Toranin: You should watch the RAM usage, just to be safe.
<Toranin> *nods*
<Toranin> it's not using much
<Toranin> only a couple hundred MB so far, I have about 700MB of leeway in free/inactive RAM
<Toranin> it's spinning at "determining revisions to fetch 0/33" now
<Toranin> using virtually no CPU and in BSD "lockd" state
<pasky> Hi! I've read http://bazaar-vcs.org/BzrVsGit#head-826d31d333758d3cd08eb5aeecd8bf77b1025373 and now I'm confused, how is that "far more flexible and powerful" than Git's alternates feature?
<bpeterson> hi guys!
<bpeterson> I was wondering if https://bugs.launchpad.net/bzr/+bug/252212 can be fixed before the 1.6 release
<ubottu> Launchpad bug 252212 in bzr "can't stack rich-root-pack repos" [High,New]
<lifeless> pasky: well its quite different, we also have an alternates-like feature
<lifeless> I don't know that its "far more flexible and powerful", just a different want of structuring some things; but it is nicer IMO to be able to manage directories as directories
<pasky> so what's the structural difference to alternates?
<pasky> I'm sorry, I don't understand "manage directories as directories"
<lifeless> alternates are pointers to a separate repository
<lifeless> bzr shared repositories are a single repository which separate branches use for common storage
<pasky> oh, I see
<pasky> git can do that too :)
 * lamont gets popcorn
<pasky> git "has" a git-new-workdir command that does pretty much the same thing
<lifeless> pasky: "directories as directories" I meant to write "branches as directories"
<pasky> the only catch is in the "has", since it's not part of the official command set (it's in contrib/) and it is pretty much completely undocumented
<lifeless> git-new-workdir looks a little raw
<lifeless> it also needs symlinks which are not portable
<pasky> that's right
<lifeless> in a purely technical sense, bzr builds in the capability to do N workdirs -> M branches -> 1 history store, portabilty on windows/macosX/*nix
<lifeless> meh, no caffeine yet, please excuse my syntax and spelling glitches
<pasky> :)
<pasky> how would you feel about "Git can achieve the same functionality by a semi-official git-new-workdir extension that has however many usability and portability problems?"
<Toranin> meteoroid: in case this wasn't obvious to you, if you point SVN_SSH at a script that looks like 'shift; exec "$@"' you can have it run svnserve locally and talk to it directly
<meteoroid> that's pretty neat..
<meteoroid> it's obvious why it works but yeh i never thought of that
<meteoroid> i forget that svnserve is just a different name for same executable
<meteoroid> like sh/bash
<meteoroid> vi/vim
<Toranin> well, actually in this case the script gets run as "scriptname localhost svnserve -t"
<Toranin> and it just pops off the localhost (or whatever hostname) and then passes control to svnserve
<meteoroid> ah sure..
<lifeless> pasky: I don't think its the same functionality
<meteoroid> that's pretty clever :)
<meteoroid> learn something new every day..
<Toranin> mine checks if the hostname is localhost and borks if not
<lifeless> pasky: because there is no constraint linking the workdir to the repository, git can't prevent bad gc actions
<meteoroid> am always telling people to write their admin scripts with bash instead of perl  because they will learn one-liners that are golden in an emergency
<meteoroid> i challenge perl to have a decent one-liner with seven subcommands ;d
<Toranin> I go back and forth between bash and Python depending on how elaborate they get
<meteoroid> yah i'd tend to choose python if i went over bash
<pickscrape> I challenge perl to be readable ;)
<meteoroid> had a new client who needed me to clean up tons of deploy scripts
<meteoroid> and i'm like
<Toranin> I have an equals sign!
<pasky> lifeless: the refs/ space is shared so this would only cover *quite* a corner case when you have uncommitted objects in your index for more than 14 days, and even in that case it would be usually trivially repairable
<meteoroid> this is the same script, with variables changed in each copy
<pasky> lifeless: so I don't know if that's practical concern, unless you have something else on your mind?
<meteoroid> why not set defaults that are for staging build and then have it accept options
<Toranin> maybe by the time I leave I will have two, or maybe THREE equals signs on the "determining revisions to fetch"
<meteoroid> even my bash scripts do that ;d
<lifeless> pasky: you get a copied index?
<meteoroid> i mean, sure, chomp is funny sounding, and ~= is cool looking, but there is more to life ;d
<pasky> lifeless: well obviously, each workdir has to have its own index
<lifeless> pasky: I guessed it would but confirming is useful
<lifeless> pasky: I'm not a git dev :)
<Toranin> RAM usage is creeping up, but it still looks heavily I/O bound -- <0.2% cpu use
<lifeless> If you wanted to change to the sentence you wrote, I'd be ok with that
<pasky> so if you git add something and wait 14 days without committing and then git gc in another shared repository, the object will go away
<pasky> ok
<lifeless> I'm sure other folk will tweak it back and forth
<lifeless> these things are dynamic :P
<lifeless> pasky: while you are here, can you answer a couple of questions about git?
<pasky> sure
<pasky> BTW, I'm also confused about "Git is not a realistic option on Windows"
<lifeless> when you fetch, and get a pack over the network
<pasky> I'm now using MSysGit daily and I'd appreciate if yo ucould elaborate on that :)
<lifeless> It seems obvious to me that you decompress every text to get its sha1 and index it
<lifeless> but do you keep the pack, or unpack to single files?
<pasky> we don't decompress the text, the object id is part of the header of each object record; and we keep the pack
<pasky> unpacking to single files is extremely rare operation that is used pretty much only for repairing corrupted packs, I think
<lifeless> ok, so if someone gave you garbage, you'll only notice when you access the object?
<pasky> interesting question :) let me check
<lifeless> I mean e.g. a bit error in an object
<lifeless> you could hash the entire pack
<pasky> ok so I was wrong on at least one count, we do unpack to single files if there's less than 100 objects in the pack
<lifeless> but that doesn't prevent targeted attacks (not that they can get you to use wrong data, just to make you think you have content you don't)
<pasky> (which makes sense since having many little packs is not much good, and sooner or later git gc will automatically fire up and collect the objects to a larger pack)
<LeoNerd> Can I do a   bzr log -r a..b    which starts at the revision -after- a, i.e. the output doesn't include a itself?
<LeoNerd> I tag all my releases with a 'RELEASED ...' tag, so I have a little script which finds the latest such tag...
<lifeless> LeoNerd: its half-open by default I think :)
<LeoNerd> bzr log -r `bzr-find-latest-RELEASED`..    <== includes the released tag itself
<pasky> on your other question, there is a hash of the entire pack
<lifeless> LeoNerd: hmm
<pasky> and I currently don't see your targetted attack scenario?
<LeoNerd> I vaaaaugely recall a VCS that can do   -r after:somespec   and so on.. is that bzr or something else?
<lifeless> pasky: its would be just a nuisance
<pasky> (I'm still reading the code :)
<lifeless> pasky: take a pack, edit some delta content to nulls, rehash the pack, and then give that when requested
<lifeless> pasky: you'll have some unreconstructable content and no warning
<LeoNerd> Oooh.. boo
<LeoNerd> bzr can do  before:tag:whatever   but not after:tag:whatever
<LeoNerd> Feature request? :)
<lifeless> pasky: anyhow, the key question I had was about the work done during fetch
<pasky> hmmm
<lifeless> pasky: I've read the pack creation code closely
<pasky> the code is trying to confuse me
<pasky> since it suggests that objects in fact are uncompressed
<lifeless> I would expect for correctness a full decompress
<pasky> which comes as a surprise to me :)
<pasky> but I guess it's so
<lifeless> LeoNerd: uhm, please bring up on list?
<LeoNerd> "the list"? Ooh.. a mailing list?
<LeoNerd> I suppose I could add another; I'm only on about 15 already :P
<lifeless> LeoNerd: yeah, we have one of those :)
<LeoNerd> Ya.. most people do
<pasky> hm, so yes, we do a full decompress and verify correctness
<pasky> I currently don't see the code that verifies correctness of delta-based objects but that's probably just because I'm kind of tired :)
<lifeless> LeoNerd: I think the bug is that log is not half-open when given a range
<LeoNerd> It is half-opten
<LeoNerd> Just at the wrong end
<lifeless> LeoNerd: no its not
<lifeless> log -r 1..2
<LeoNerd> Most people expect that   bzr log -r 10..20   should include 10
<pasky> lifeless: so thanks for teaching me more about git internals ;)
<lifeless> shows 1 and 2
<lifeless> pasky: :)
<LeoNerd> Oh..
<LeoNerd> Yes..
<LeoNerd> But.. I want   bzr log -r 10..    to show 11 onwards, and not 10
<LeoNerd> I imagine most people would complain
<LeoNerd> Isn't   after:   easier to add?
<LeoNerd> bzr log -r after:10..
<lifeless> LeoNerd: if you can define it sanely
<lifeless> we have a graph ;)
<LeoNerd> after:10  is 11,   after:anythingelse dies
<lifeless> LeoNerd: well you want after:tag:foo
<LeoNerd> Yes,..
<lifeless> but sure - lets raise
<LeoNerd> But tag:foo   is just a "nice" name for 10, no?
<lifeless> no
<lifeless> its a nice name for revid:SOME_UUID_HERE
<LeoNerd> Ooh.. hrm...
<Peng_> Well, what does before: do?
<lifeless> I'm sure its doable
<lifeless> Peng_: left hand parent
<lifeless> LeoNerd: I'm just saying we should take a minute to discuss
<LeoNerd> Right..
<lifeless> if we can tweak a fundamental to be more consistent
<LeoNerd> OK.. I'll take a peek at the ML then
<lifeless> e.g. merge -r x..y does not include x
<lifeless> then we can be simpler
<LeoNerd> https://lists.canonical.com/mailman/listinfo/bazaar  <== this?
<lifeless> LeoNerd: yes
<LeoNerd> Aww.. I don't get a choice of English (UK) ? :P Boo
<james_w> bazaar is gone from Debian apparently
<LeoNerd> ?
<lifeless> LeoNerd: the old C version
<LeoNerd> Ohdear... so you're right.
<james_w> oh yeah, sorry :-)
<LeoNerd> Oh.. ohyes. Got me all in a panic for a moment
 * LeoNerd recalls the SAS
<lifeless> pasky: I can't comment on windows, I put away my windows-hacker cloths some time back
<pasky> lifeless: ok - I've just edited that section too to clarify a bit wrt. current state of msysgit, I look forward to seeing further edits by others :)
<pasky> now my hands are off again ;)
<lifeless> ok ;)
#bzr 2008-08-16
<jdub> hey hey
<jdub> is there a loggerhead package in a ppa somewhere?
<beuno> jdub, not yet. Hopefully I'll get to that next week
<beuno> regular setup should be easy enough, if you don't want to wait
<jdub> cool, ta :-)
<beuno> jdub, all you need installed is python-paste and python-simpletal. Then just either run from source, or run: setup.py install
<beuno> (optionally you can install python-sqlite and bzr-search, to get some caching for speed and super-cool searching)
<jdub> tasty
<jdub> is it pretty anal retentive about code, so i can display branches i don't control?
<jdub> s/code/content/
<beuno> jdub, define "don't control"
<jdub> i'd like to suck down branches from other core developers (so, semi-trusted) and display them in the one place with loggerhead
<beuno> without having the branches locally?
<beuno> I mean, if you branch them to a dir, just serve that dir with LH, and you're set
<jdub> yeah
<lifeless> jdub: do checkout --lightweight URL
<lifeless> jdub: then it should work
<lifeless> jdub: or just branch and maintain a mirror, if you don't want LH sucking data over the network
<jdub> and you're pretty confident LH won't screw me for 'trusting' that external data?
<jdub> :-)
<beuno> jdub, I can't really think of anyway you can get screwed. What do *you* have in mind?
<lifeless> jdub: what do you mean by trust
<jdub> evil co-developer putting evil in their branch that abuses my LH
<lifeless> jdub: we use loggerhead do display 10^4+ branches on launchpad
<mwhudson> loggerhead is reasonably careful to not allow xss by displaying user content unmunged, for example
<lifeless> if you pull their branch to a local mirror and show that, you'll have precisely the same level of condom loggerhead on launchpad has
<jdub> cool
<lifeless> jdub: also, if you mirror locally you can setup a bzr-search index of the same branch
 * jdub levels up his condom by grinding...
<Peng_> If it's remote, will bzr-search still work?
<lifeless> Peng_: yes
<lifeless> Peng_: if there is a search index on the remote branch
<lifeless> Peng_: or if you add a mapping to bzr-search telling it to use a different index for that branch, and then sync the index from time to time
<lifeless> -> train to catch
<Peng_> Oh, neat.
<Peng_> lifeless: Bye. :)
<lifeless> jdub: ring me if you want more info
<jdub> beuno: congrats, btw :-)
<beuno> jdub, not sure exactly for what, but thanks  :_
<beuno> :)
<jdub> canonical
<beuno> ah, yes!  I'm thrilled  :)
<cody-somerville> :]
<beuno> how was your first week btw, cody-somerville?
<cody-somerville> beuno, fairly productive
<cody-somerville> beuno, Yours?
<beuno> cody-somerville, productive too. Lots of setup stuff though, took away a chunk of time. I'm really enjoying it so far  :)
 * cody-somerville nods.
<cody-somerville> beuno, I dunno how I'm going to like getting paid monthly instead of biweekly though
<Peng_> But do you get beanbag chairs?
<beuno> Peng_, I have a beanbag 2m away from me!
<cody-somerville> Peng_, I opted for the hoody
<cody-somerville> Anyhow, I'm starving! :-) It has been a long day. One of the drawbacks of working from home is that you have to force yourself to actually stop working :P
<mwhudson> cody-somerville: yeah, i find that a lot
 * cody-somerville forms Canonical Workaholics Anonymous.
<rocky> is there a standard way to "disable" a widget like a TitlePane so that all of it's inner contents become greyed out and can't be edited/focused ?
<markh> it looks like I can get similar http weirdness with a 'http+urllib' url... - bzr: ERROR: Invalid http response for http://bazaar-vcs.org/....rix: Expected a boundary (squid/2.6.STABLE18:...9C890B4)line, got ''
<Leefmc> Question: How do you create a working directory again?
<Leefmc> Or is it just a lightweight checkout.. i forget heh
<Peng_> "bzr co --lightweight whatever/" to create a lightweight checkout.
<Peng_> "bzr co" to create a working tree in the current branch.
<Leefmc> I'm confused, a normal checkout creates a working tree?
<Peng_> The  checkout command is overloaded.
<Peng_> If you have a branch with no working tree, run "bzr co" to create one.
<markh> and my hardy box on the same network can give the same error.
<Leefmc> Peng_: Huh.. i gatta go, so i'll have to ask again later, because im still confused. I spose i must just be confused on BZR's version of a working tree. Anyway, thanks :)
<Leefmc> later
 * markh wonders where the release manager is when you need him :)
<tacone> if he is european he could be in bed :-)
<markh> I think he is in the US which means he would be getting ready for it (or better still, hopefully something even better on a friday night :)
<meteoroid> so i have a relatively old bzr and bzr-svn from ubuntu hardy, should i build from source, or are there newer packages from alternative sources?
<meteoroid> jelmer says the new bzr-svn has fixes for issues i have, and bzr-webdav says it "only works with 1.6"
<lifeless> RAOF: http://piumarta.com/pepsi/?C=M;O=D
<fullermd> markh: He's in my TZ, which means that if he's sensible, he's in bed   :p
<lifeless> beuno: hi
<lifeless> beuno: rant
<lifeless> http://bazaar.launchpad.net/~jml/subunit/split-right/revision/51
<lifeless> beuno: can't read the entire line, no scroll bar in my window to make things wider; kthxhelp
<mwhudson> i think there's a bug report about that already
<lifeless> mwhudson: great
<lifeless> mwhudson: number plx?
 * mwhudson looks
<mwhudson> lifeless: maybe not, actually, i think it was just complained about on the mailing list
<Jc2k> Zooming out FTW
<Jc2k> (i have to zoom in to see the bug :P)
<lifeless> Jc2k: :P
<lifeless> beuno: ^^^^ more hai!
<jml>         self.failUnless(self.suite._tests == [self.case1, self.case2,
<jml>                                               self.case3, self.case4] or
<jml>                         self.suite._tests == [self.case3, self.case2,
<jml>                                               self.case1, self.case4])
<Kazade> Hi everyone, I've just recently tried moving a project to Bzr (from GIT) so that I can use it on Windows easily. I've set up putty etc with my private key so I can ssh into my other PCs without entering a password, but no matter what I do, bazaar on windows crashes when I try to clone a project with the error "ERROR: socket.error: Socket is closed". Any ideas?
<gour> jelmer: someone from #ghc asks me about bzr's rebase...
<gour> jelmer: is it possible to drop shortly in #ghc
<gour> lifeless: ping
<gour> lifeless: can you visit #ghc shortly to explain about loom plugin, pls.
<gour> ...or whoever use it and understand the purpose..
<matkor> Hi ! Afer bzr update I see list of modified (M) files but bzr finishes run with bzr: ERROR: [Errno 13] Permission denied ... with not futher info which file permission are denied ... any hint how to find it out ?
<matkor> ok, question cancelled - I found out ...
<gour> considering http://andrew.puzzling.org/diary/2008/July/29/rebase-criticism i wonder whether rebase is actually needed in bzr?
<thumper> gour: no, it isn't normally needed
 * thumper going to bed now
<LarstiQ> gour: there are usecases for it, but it usually isn't needed.
<gour> LarstiQ: thanks
<gour> thumper: ^^^
 * rocky sniffs and wishes his "bzr commit" to a svn repo didn't make 100 requests and take about 1min
<palango> is there an easy way to find out if a file is under bzr control?
<Peng_> I guess you could use "bzr st" on it.
<Peng_> You could also check for it in "bzr inventory".
<Peng_> I'm sure there's a better way, especially through bzrlib.
<Necoro> bzr unknowns | grep -q $FILE  && echo $FILE is unknown
<Necoro> ;)
<uws> Necoro: that doesn't take ignored files into account
<Necoro> true
<Peng_> "bzr st" does, but it's not very good for a script.
<uws> no
<Peng_> I mean, usable by a script
<uws> "bzr inventory $FILENAME"
<Peng_> Oh, I didn't know you could do that. There you go then.
<uws> bzr inventory $FILENAME 2>/dev/null && echo versioned || echo not versioned
<palango> thanks
<Glenjamin> does anyone have experience setting up tortoisebzr on vista?
<Glenjamin> i'm getting an error about a missing entry point in pywintypes25.dll
<Leefmc> Question: Is there a way to wildcard remove directories? I added a set of directories and my .bzrignore was formatted wrong, so it added a ton of directories and files i dont want.. and removing them by hand would suck
<Leefmc> oo, seems wildcard works
<Leefmc> :)
<gour> how can one delete project on LP?
<jbalint> Hi
<jbalint> how can i debug this problem on windows? http://rafb.net/p/3vsOH366.html ssh.exe/plink.exe to the host works fine, bzr is working fine on the local and remote hosts
<beuno> jbalint, I wonder why you're getting bzr: Command not found.
<beuno> is bzr installed on the remote server?
<jbalint> yes
<LarstiQ> BZR_REMOTE_PATH?
<jbalint>  /usr/bin/bzr
<beuno> jbalint, also, My Documents/.bzr.log   has more debug info
<jbalint> beuno: ah, right. thx, will check it
<LarstiQ> jbalint: and I presume that is also where bzr actually resides?
<jbalint> yes
<jbalint> heres the info from the log http://rafb.net/p/1kzTVr41.html
<LarstiQ> jbalint: hmm, no clue of command not found there.
<LarstiQ> though, maybe, hmm.
<jbalint> i branch its locally on the server, works. i can ssh to the exact from part of the url, and bzr version works fine
<LarstiQ> jbalint: it might be a red herring, but how is ssh/plink setup? Key based login?
<LarstiQ> jbalint: does the server side ssh log provide any insight?
<jbalint> yes, keys, everything is working fine
 * LarstiQ glances at the code
<LarstiQ> jbalint: It comes back to BZR_REMOTE_PATH.
<jbalint> set locally?
<LarstiQ> jbalint: what happens if you set that to, say, /bin/true?
<LarstiQ> jbalint: yes
<jbalint> Dlklemme try
<LarstiQ> jbalint: do I read that correctly to say that you previously hadn't set the env var in Windows?
<jbalint> heh, /bin/true: Command not found.
<LarstiQ> riiight.
<LarstiQ> jbalint: is your ssh server jailing you?
<jbalint> oi, i dont think so
<LarstiQ> if it is a bzr bug, it is a strange one.
<jbalint> i can ssh in and it works fine
<LarstiQ> but right now I'd like some more confirmation on your environment :)
<LarstiQ> rihgt.
<LarstiQ> ugh, typo galore tonight.
<LarstiQ> jbalint: So what is the difference in the two methods?
<jbalint> i dont know
<LarstiQ> jbalint: for openssh, you can add config options for particular hosts to ~/.ssh/config. Does plink have something similar?
<jbalint> kind of, yeah
<LarstiQ> jbalint: can you up the verbosity of the connection?
<LarstiQ> jbalint: if not, does BZR_PDB=1 bzr .... drop you in a pdb prompt? (I'm not sure about connection errors)
<LarstiQ> then again, if the connection is already closed..
<jbalint> it gets into the debugger after the error message
<LarstiQ> ok, good
<jbalint>  http://rafb.net/p/aCkOkR40.html
<LarstiQ> jbalint: while I read more of the code to see what we could do, could you try executing ls or something to discover more about why we get these command not founds?
<LarstiQ> jbalint: and, perhaps you could try with paramiko directly?
<LarstiQ> jbalint: ie, BZR_SSH=paramiko
<LarstiQ> jbalint: btw, which version of bzr is this?
<jbalint> 1.4rc1 on the client and 1.5 on the server
<jbalint> oh, paramiko wont work because of the plink aliases, bzr: ERROR: Unable to connect to SSH host linksys-route-FWD-nt77; (11001, 'getaddrinfo failed')
<jbalint> let me try the ip
<LarstiQ> jbalint: ooh, is that alias something over a forwarded ssh connection?
<LarstiQ> that might be a clue.
<jbalint> http://rafb.net/p/jI6CPD49.html
<LarstiQ> jbalint: without BZR_PDB, does it still print 'command not found'?
<LarstiQ> jbalint: and in pdb, could you 'print dir(self)'?
<jbalint> no, just the bzr: ERROR part
<jbalint>  http://rafb.net/p/8a351019.html
<LarstiQ> jbalint: that to me sounds like an ssh login problem.
 * LarstiQ looks at _request
<LarstiQ> jbalint: the .pyc in the traceback sounds like you use the windows binary installer, and not the bare python based one, is that right? (Thinking of editing .py files instead of doing post-mortem debugging)
<jbalint> yeah, i can install something else
<whitemice> Hi, new (potentially) to bzr.  I am the patch gatekeeper for a large codebase kept in subversion(OpenGroupware).  I'd like to front-end the subverzion repo with bzr so I can allow people to use BZR and push patches, then look at the patches and potentially push them to svn.
<whitemice> I've looked at a couple of pages like <http://blog.tplus1.com/index.php/2008/03/22/use-bazaar-and-subversion-together/> but the examples don't quite work. :(
<uws> whitemice: install bzr-svn and   "bzr branch svn+ssh://....."
<whitemice> Is this a possible setup?
<whitemice> I tried "bzr branch svn+http://developer.opengroupware.org/OpenGroupware.org/trunk" and get "Unsupported protocol for url "svn+http://dev..."
<jbalint> LarstiQ: i just branched from another box on the lan, and it worked fine, so it must be a client issue
<uws> whitemice: do you have bzr-svn?
<uws> whitemice: bzr: ERROR: Invalid http response for http://developer.opengroupware.org/OpenGroupware.org/trunk/.bzr/branch-format: Unable to handle http code 401: Authorization Required
<uws> whitemice: That's what I get
<LarstiQ> jbalint: ok, still would like to find out what is going on
<LarstiQ> jbalint: could you go 'up' in pdb until you hit bzrlib/smart/medium.py:protocol_version
<jbalint> ok
<uws> jelmer: ping
<uws> jelmer: recent bzr and bzr-svn complain about svn+ syntax being depreacted
<LarstiQ> jbalint: and then a dir(self) again, looking for the backing transport
<uws> jelmer: but on the url just mentioned by whitemice it DOES make a difference
<jbalint> LarstiQ: print some specific member of self? or dir is enough?
<LarstiQ> jbalint: dir is enough for now
<LarstiQ> jbalint: what I want to do is call transport.list_dir('.')
<LarstiQ> or '/'
<whitemice> uws: yep, the repo requires auth.  I must (openSUSE 11) be missing something...  I have all the available bzr packages installed.
<LarstiQ> jbalint: but first we have to find the transport
<uws> jelmer: in the svn+http:// case it asks for a password, while the http:// one (recommended by the warning message) gives an error about .bzr/branch-format needing auth
<uws> whitemice: does "bzr plugins" list svN?
<jbalint>  http://rafb.net/p/O1seq080.html
<whitemice> uws: no
<LarstiQ> whitemice: you cn use http://user@../ to force authentication prompt
<uws> whitemice: then you don't have the bzr-svn machinery so bzr won't be able to speak to SVN servers
<uws> LarstiQ: wasn't that supposed to be directed to me instead?
<LarstiQ> jbalint: you can check self._bzr_remote_path but I don't think it will help us much
<jbalint> '/bin/true'
<LarstiQ> uws: ehm, maybe, not paying close attention, trying to debug jbalint's issue
<uws> LarstiQ: no worries
<LarstiQ> jbalint: ah. hmm. Have you tried the combo paramiko//usr/bin/bzr ?
<LarstiQ> jbalint: since paramiko /bin/true doesn't print a command not found
<jbalint> trying
<jbalint> ah, success!!
<LarstiQ> jbalint: ok, so: paramiko works with the ip address, but plink does not with the alias?
<jbalint> right
<LarstiQ> jbalint: how about plink + ip?
<LarstiQ> at least we have isolated the problem somewhat
<jbalint> hrm, yup works with IP
<LarstiQ> next question would be, does it work with other aliases? Or, what makes this one different.
<jbalint> let me try a new/clean alias
<LarstiQ> If it doesn't work with _any_ alias, then we know which bug to file.
<LarstiQ> jbalint: thanks for your patience going through this with me.
 * LarstiQ is also simultaneously trying to translate a text.
<uws> LarstiQ: from klingon to dutch?
<LarstiQ> uws: Finnish to English
<uws> LarstiQ: that's roughly the same for me :)
<LarstiQ> haha :P
<LarstiQ> I admit one of the Finnish 2-seat row athletes had some suspicious crinkles in her forehead.
<uws> heh.
<LarstiQ> but Klingon I don't speak at all.
 * uws afk for a book (in English, not the original ancient greek *phew*)
<whitemice> uws: ran through one-click install (nice!) and now have svn plugin
<whitemice> uws: "bzr branch svn+http://adam:******@developer.opengroupware.org/OpenGroupware.org/" fails with "subversion/libsvn_ra/ra_loader.c:940: svn_ra_get_log2: Assertion `*path != '/'' failed."
<jbalint> LarstiQ: yup same problemw tih a fresh alias :(
<uws> whitemice: ask jelmer about that one. I think it's a Subversion bug
<LarstiQ> jbalint: alias to the same system?
<uws> whitemice: (recompile svn, comment out that assertion might work ;))
<uws> whitemice: (or try upgrading svn to 1.5)
<LarstiQ> jbalint: I have no clue how plink aliases work. But if you can list a set of steps to reproduce this, a bug report would be nice.
<whitemice> uws: I'm using subversion 1.5.0 as is the server (I believe)
<LarstiQ> whitemice: what version of bzr-svn are you using?
<whitemice> uws: bzr-svn-0.4.10-6.2
<LarstiQ> whitemice: svn changed their api in 1.5, but there is a patch for bzr-svn to deal with that.
<uws> whitemice, LarstiQ: https://bugs.launchpad.net/bzr-svn/+bug/234010
<ubottu> Launchpad bug 234010 in bzr-svn "abort: svn_ra_get_log2: Assertion `*path != '/'' failed (dup-of: 229419)" [Undecided,New]
<ubottu> Launchpad bug 229419 in bzr-svn "WorkingSubversionBranch.test_create_checkout fails" [High,Fix released]
<LarstiQ> whitemice: for a big gun approach, you could try to apply http://ftp.de.debian.org/debian/pool/main/b/bzr-svn/bzr-svn_0.4.10-2.diff.gz (but -6.2 seems to imply some local patching)
<jbalint> LarstiQ: add a bug on launchpad?
<LarstiQ> jbalint: yes please.
<jbalint> ok
<LarstiQ> ala "bzr complains about command not found when using plink aliases", listing steps to reproduce and something like your original paste, that would be sweet.
<jbalint> ok
<jbalint> thanks again
<LarstiQ> jbalint: glad to be of help, and thank you for the report.
<LarstiQ> whitemice: how easy is it for you to patch the bzr package you are using?
#bzr 2008-08-17
<lifeless> yay I just got
<lifeless>   File "/home/robertc/source/baz/bzr-test-fixes/bzrlib/transport/ssh.py", line 605, in recv
<lifeless>     return os.read(self.proc.stdout.fileno(), count)
<lifeless> OverflowError: signed integer is greater than maximum
<lifeless> jml: ^ :(
<jonnydee> hi, can anyone tell me how to configure ~/.bazaar/authentication.conf for a sftp account?
<jonnydee> I've alread configured another location which just uses ftp -- and it works.
<jonnydee> but with sftp I'm asked for the password even if I provide one in the config file...
<lifeless> for sftp you should use your ~/.ssh/config file
<jonnydee> and the same way like in the ftp case is not supported?
<lifeless> right
<lifeless> sftp authentication is done outside of bzr
<lifeless> bzr has no access to the protocol
<jonnydee> ah...ok, I see...
<jonnydee> thanks again for your help, lifeless :)
<markh> how do I update my checkout to an earlier revision of the branch?  I was surprised to find no '-r' option to 'bzr up' nor to bind.
<beuno> markh, I don't think you can, since it's bound to the other branch
<beuno> you could branch off of it at that revision
<markh> so update the branch, then up the co?
<pygi> markh, bzr pull --overwrite -r 8214
<pygi> perhaps :p
<pygi> markh, helped? :)
<beuno> markh, you want both branches to be at that revno?  reverted?
<markh> no, just experimenting.  I think I was missing I can still use "pull" on a checkout though - thanks
<markh> ie, want to experiment with how the code behaves at an earlier revno
<beuno> I think generally you'd branch -r off of it
<markh> So what's the difference between "pull" (with no args) and "up" once you have a checkout?
<markh> (I'm working with checkouts on a test machine, with the branches being on the main dev machine)
<pygi> bzr pull is nicer in some cases :)
<markh> heh :)  what's the conceptual difference?
<pygi> well, anyway, they have different use-cases
<pygi> bzr up will do a merge
<pygi> bzr pull won't
<markh> I think I need to experiment a little more with checkouts
<pygi> :)
<markh> I think some of the docs might need to tone down how checkouts are somwhat similar to working with svn :)
<markh> So when I do a checkout, is a "branch" created locally?
<LeoNerd> Yes, except if it's a "lightweight checkout"..
 * fullermd blinks.
<fullermd> Pull changes a branch.  Update updates a working copy.
<fullermd> Using pull in a checkout to adjust your working copy is totally not what you want to do...
<jonnydee> lifeless: sorry to ask again. I can login to my remote server using ssh public key authentication. now how does the authentication.conf have to look like for sftp access...? (btw I need to log in with another user name than I have locally, so would like to make bazaar use the one specified in the authentication.conf)
<jonnydee> with other words: I would like to use "sftp://host/path/to/repo" and and bazaar should use "sftp://remoteuser@host/path/to/repo"
<bob2> sftp happens after the ssh login has occured
<bob2> configure .ssh/config to use the right username
<bob2> (ie add a "Host yourhostname\nUser youruser" section to it)
<jonnydee> ok, it seems like bazaar is not able to insert the username specified in the config into the url. So it's indeed only possible by doing your suggested approach... I see... Thanks a lot :)
<markh> fullermd: right - thanks for the clarification
<markh> so what is the best way to update my co to a specific revision of the branch it is checked out from?
<fullermd> There isn't one.
<fullermd> You can use revert to alter the tree state, but as far as your co is concerned it's still $OLD_HEAD, just with a crapload of changes waiting to be committed.
<markh> right - that will probably do for my purposes.  But it seems an omission - is that by design/restriction, or a feature yet to be implemented?
<jonnydee> markh: maybe you could first branch the requested revision and then do a switch to the newly created branch. but it's not that comfortable -- I know...
<fullermd> bug 45719
<ubottu> Launchpad bug 45719 in bzr "update command cannot take a revision number" [Medium,Fix committed] https://launchpad.net/bugs/45719
<jonnydee> I mean like  so "bzr branch -r REV PATH_OF_NEW_BRANCH" and then "bzr switch ï»¿PATH_OF_NEW_BRANCH"
<fullermd> According to that status, it's set for 0.13   :p
<jonnydee> this should leave you with a branch of the required revision in the current directory... but I've not tried it yet
<markh> jonnydee: yeah, that might work, thanks.  i just wanted to run a quick experiment with an earlier revno, so 'revert -r' worked for me in this case.
<markh> fullermd: sad joke indeed :)
<jonnydee> maybe we shoulg nominate this bug for bzr.dev? or 1.7?
<markh> its not clear from the bug what the "quality issues" John referred to are, and launchpad is helpfully giving "Internal Server Error" trying to view a revision of the branch
<fullermd> Unfortunately, it has to "update -r" to view the branch, see...
<markh> heh :)
<mwhudson> markh: what url?
<markh> mwhudson: what url for what?
<mwhudson> <markh> its not clear from the bug what the "quality issues" John referred to are, and launchpad is helpfully giving "Internal Server Error" trying to view a revision of the branch
<mwhudson> markh: ^ that one
<markh> oh - internal error?  any of the recent revisions shown at https://code.launchpad.net/~jameinel/bzr/update-r
<mwhudson> huh
<markh> eg, http://bazaar.launchpad.net/~jameinel/bzr/update-r/revision/2012
<pickscrape> mwhudson: FYI I pushed up a new version of the breadcrumbs branch today. Added to other pages, moved the code to a shared location etc
<mwhudson> markh: wow, that branch is sure confusing loggerhead
<mwhudson> $ curl http://bazaar.launchpad.net/~jameinel/bzr/update-r/.bzr/branch/last-revision
<mwhudson> 0 null:
<mwhudson> errr
<markh> he
<mwhudson> i _guess_ the branch was mirroring ok
<mwhudson> jam updated all his branches to packs
<mwhudson> and the remirroring failed
<mwhudson> still, loggerhead shouldn't explode so violently
<mwhudson> ah yeah
<mwhudson> http://bazaar.launchpad.net/~jameinel/bzr/update-r/changes
<mwhudson> ^ ok
<mwhudson> http://bazaar.launchpad.net/~jameinel/bzr/update-r/files
<mwhudson> ^ not ok
 * mwhudson files a bug
<markh> bzr tells me the branch is empty
<mwhudson> it is, yes
<mwhudson> we really need to implement useful stacking for mirrored branches to save jam's adsl some abuse :)
<markh> right - its empty as the remirroring failed
<chandlerc> hrm...
<chandlerc> thoughts on this bzr-svn error:
<chandlerc> SubversionException: ("PROPFIND of '/svn/!svn/bc/136/parser/trunk': SSL negotiation failed: SSL error: parse tlsext (https://inc.googlecode.com)", 175002)
<mwhudson> googlecode being a bit random maybe?
<chandlerc> always
<chandlerc> just wondering what this in particular oddity is
<chandlerc> i'm moderately stuck with google code for several projects.
<tacone> chandlerc: I did export from google code.
<chandlerc> this is on a branch
<chandlerc> into a shared repo
<mwhudson> well, if it's a read-only thing
<mwhudson> you can at least do it over http:// and avoid ssl randomness
<chandlerc> nah, trying to do an https branch for future writes
<mwhudson> um
<chandlerc> =/
<chandlerc> yea
<mwhudson> you can do the pull over http
<mwhudson> and push over https
<chandlerc> true
<chandlerc> will try that
<chandlerc> oh fun
<chandlerc> % bzr push svn+https://inc.googlecode.com/svn/parser/trunk
<chandlerc> The svn+ syntax is deprecated, use https://inc.googlecode.com/svn/parser/trunk instead.
<chandlerc> zsh: segmentation fault  bzr push svn+https://inc.googlecode.com/svn/parser/trunk
<percious> anyone home?
<percious> looking for a bzr-svn expert if there is one
<percious> evening
<chandlerc> join the crowd, i'm battling it as wel
<mwhudson> chandlerc: oo
<percious> ehem
<percious> chadmiller: battleing bzr-svn ???
<percious> :q
<percious> chandlerc:  also having issues with bzr-svn?
 * percious compiles svn 1.6....
<tacone> percious: I had
<percious> tacone: mac os leopard?
<tacone> percious: ubuntu hardy.
<percious> maybe this is just a version thing
<tacone> plugin and bzr versions, right ?
<percious> yeah
<percious> svn = 1.6
<percious> bzr = 1.6r3
<percious> *rc3
<tacone> I didnt' tried 1.6, but I was somewhere in the middle, and had to downgrade to use bzr-svn
<tacone> it was a month ago, though, so I guess svn version could work.
<percious> SubversionException: ("Unrecognized URL scheme
<percious> owns me
<percious> downgrade svn?
<percious> i have tried 1.5.1 (universal installer) and 1.5.1 from svn repo
<tacone> percious: no, I just used another version from the repositories
<percious> what version of svn are you using?
<tacone> uhm
<tacone> let me check
<percious> svn --version
<percious> bzr --version
<tacone> wait
<percious> yep
<tacone> svn, version 1.4.6 (r28521)
<percious> wow, that is specific
<percious> thanks :)
<tacone> Bazaar (bzr) 1.3.1
<tacone> bzr-svn version: 0.4.9-1
<percious> you the man
<percious> let me try those
<tacone> uhm, yes. keep in mind bzr 1.3.1 is *old* so you are likely to use that only for exporting your branch to bzr.
<percious> exporting my branch?
<percious> wait, 1.3.1?
<percious> Installed Subversion version does not have updated Python bindings. See the bzr-svn README for details
<tacone> percious: yes
<percious> ug
<percious> the universal for svn sucks...
<percious> building from source...
<tacone> lol
<tacone> percious: this is the readme for that version of bzr-svn http://paste.pocoo.org/show/82441/
<tacone> percious: you need the python bindings, more than svn itself
<percious> yeah
<percious> im working on it
<tacone> lol ok
<percious> i had it going for svn 1.5
<tacone> percious: is you have an ubuntu hardy vm it could work out of the box.
<percious> right, on my mac
<percious> im in love with mac os
<percious> so linux is not happening
<tacone> a virtual machine I mean.
<mwhudson> um
<mwhudson> if you're using a version of bzr-svn that needs the subversion python bindings
<percious> yay :) http://svn.collab.net/repos/svn/tags/1.4.6/
<mwhudson> get a newer bzr-svn
<tacone> mwhudson: he had problems with the recent versions, so he tried to downgrade.
<mwhudson> tacone: oh
<percious> ive tried like 100 different versions at this point :)
<percious> im going with what tacone has
<tacone> mwhudson: I pointed him to the standard hardy versions, that worked for me.
<mwhudson> well, you're pretty unlikely to have _fewer_ problems with older version
<mwhudson> especially building on os x...
<percious> agreed
<percious> but I need to find a baseline to work from
<tacone> mwhudson: I had problem on hardy using bzr repository and bzr-svn because of versions conflicts
<percious> ls
<mwhudson> building the subversion python bindings on os x is seriously hard
<mwhudson> i managed it once a few years ago
<mwhudson> on ppc
<tacone> mwhudson: :(
<percious> intel here
<mwhudson> and had to install a specific micro-version of swig, install a different libtool, etc
<percious> following directions here: http://bazaar-vcs.org/BzrForeignBranches/Subversion
<mwhudson> percious: what problems did you have with the newest versions of bzr-svn and bzr ?
<percious> um
<percious> somethign about it not understanding http in the url
<percious> SubversionException: ("Unrecognized URL scheme for 'http: ... pwns me
<mwhudson> (i had it sort of working today, it broke, but because of problems in the remote repo, not in the software)
<percious> compiling svn for the 10th time :)
<mwhudson> argh!
<percious> at least I am getting paid
<mwhudson> hm, not seen that exception before
<percious> there is a ticket for it
<percious> i put a comment in
<percious> i am evaluating this for my client
<percious> we have some weird development practices
<percious> want to make things better using distributed versioing
<percious> but keep the svn repo
<percious> bzr seems a perfect fit
<percious> i might look at svn-git as well
<mwhudson> mm
<percious> but the commands aren't as nice
<mwhudson> which is the bug?
<percious> hang on, ill look it up for you
<mwhudson> git-svn is a bit different aiui
<percious> https://bugs.launchpad.net/bzr-svn/+bug/80553
<ubottu> Launchpad bug 80553 in bzr-svn "Error with svn get to https repository" [High,Fix released]
<mwhudson> um, that doesn't look very similar to me
<percious> hang on
<percious> thats not it
<percious> https://bugs.launchpad.net/bzr-svn/+bug/211683
<ubottu> Launchpad bug 211683 in bzr-svn "bzr-svn crashes on branch with exception 170000" [Undecided,Fix released]
<mwhudson> percious: oh, you have a checkout?
<mwhudson> i'm not sure bzr-svn supports them
<percious> check out?
<percious> what do you jmean?
<mwhudson> percious: alternative (and probably better) phrasing is a 'bound branch'
<percious> hmm
<percious> i did an svn copy trunk branches/my_new_branch
<mwhudson> a branch where changes you commit go to the central repository
<percious> and then i did a bunch of work in there
<percious> and i cannot commit, because the internet is down
<percious> so i thought... bzr to the rescue
<mwhudson> well
<percious> local commits...
<mwhudson> right
<percious> then push to the server when all happiness
<percious> :)
<percious> bad assumptions?
<mwhudson> that command line shows that you are not doing a local commit though
<percious> :-/
<percious> what should I be typing?
<mwhudson> well, i think
<percious> bzr ci doesnt do a local commit?
<mwhudson> oh hang on
<mwhudson> you're running this in a svn checkout?
<percious> yeah
<mwhudson> aaah
<percious> so, shouldnt bzr-svn do a local commit?
<mwhudson> i don't think you can do a local commit in this situation
<percious> oh :(
<mwhudson> you need to get a bazaar branch before you can do that
<percious> i am confused then
<percious> ok
<mwhudson> so bzr get http://svn/url
<percious> which probably requires me to get at the server, which is inaccessable
<percious> yeah
<mwhudson> yeah :/
<percious> im SOL
<percious> but!
<percious> in the future I can bzr everything and be all happy
<mwhudson> roughly speaking, bzr doesn't have anywhere to store the new commit
<mwhudson> in a svn tree
<percious> (like, tomorrow) when the internet is working at the office 600 miles away
<mwhudson> yes, if you had somehow prepared for the internet going down...
<percious> why doesnt bzr just make their own place?
<percious> big storm in denver this weekend
<percious> affected ABQ too i guess (where my client resides)
<mwhudson> i'm not totally sure
<percious> they only have a dish for the internet :-/
<mwhudson> it may also be the case that bzr needs to have access to the history of the svn repo to be able to commit
<percious> isnt that in the .svn files though?
<mwhudson> jelmer would be the man who would know
<mwhudson> but i guess he's very firmly asleep
<percious> well, im evaluating this technology anyway...
<percious> which will take place tomorrow in the rain as well
<mwhudson> percious: no, the .svn directories only contain data about the current state of the tree, there's no history there
<percious> ok 1.4.6 is in
<percious> and bzr 1.3.1
<percious> and bzr-svn 0.4.9
<mwhudson> very retro :)
<tacone> percious: I fear that those versions could not solve your problem. I didn't tried commit, I just converted my repo to bzr and goodbye svn
<percious> ah
<tacone> mwhudson: that's the current hardy default repositories versions :-(
<percious> wow, fun errors now
<mwhudson> tacone: yeah
<tacone> percious: very sorry, I guess I misunderstood your problem, very sorry. I thought you just wanted to convert your repositories.
<percious> no worries
<percious> i just want to be able to work remotely
<mwhudson> percious: that you get such incomprehensible errors would count as a bug
<percious> i guess...
<percious> i dunno
<percious> i think user error
<percious> im basically a bzr ignoramous, despite wearing a bazaar t-shirt for the last 2 years
<percious> (not continuously)
<mwhudson> :)
<tacone> mwhudson: that could be (old)bzr-svn rather (old)bzr errors. I don't think anyone is going to fix those versions.
<percious> so what versions of things do you recommend
<percious> ?
<percious> so when I get things working tomorrow on the internet side i can actually achieve what I want
<mwhudson> tacone: https://bugs.edge.launchpad.net/bzr-svn/+bug/211683/comments/5 isn't
<ubottu> Launchpad bug 211683 in bzr-svn "bzr-svn crashes on branch with exception 170000" [Undecided,Fix released]
<mwhudson> percious: probably the newest of everything
<tacone> percious: when the bzr tshirt gets dirty just run bzr pull lp:bzr-tshirt
<percious> indeed
<percious> ide like a new t-shirt
<mwhudson> percious: maybe a released version of svn would be a good idea
<percious> and wing is supposed to send me one too...
<percious> well, there are lots of released versions
<percious> 1.5.1 is already checked out on my machine....
<tacone> mwhudson: I guess I misunderstood again :). I thought you were referring to 1.3.1.
<percious> (and compiled)
<percious> im a bad-ass at compiling svn now
<mwhudson> percious: that should be good then
<mwhudson> percious: my commiserations :)
<percious> lemme go get that installed
<percious> ima have to look that word up
<percious> anything over 10 letters is a bit much for me at 2am
<mwhudson> heh
 * mwhudson goes to cook dinner
 * percious might need sleep soon
 * tacone dives into python (and needs sleep too)
<percious> 1.5.1 is hating me
<percious> ok, where does svn install it's binary
<tacone> "which svn" could work.
<percious> i knwo
<tacone> I don't know macosx though.
<tacone> oh
<percious> but there are like 3 svns all over the place now
<percious> and they are seemingly pointing to each other in various ways
<percious> (a tangled web we weave)
<percious> hmm, now I get a different error
<percious> UnsupportedFormatError
<percious> UnsupportedFormatError: This client is too old to work with working copy '/Users/percious/clients/clearwired/mvpdev/src/mvp2_root/branches/coop_resource_ass'; please get a newer Subversion client
<percious> it'd be nice if we knew which version would work
<tacone> percious: is that the path of a repository or a checkout ?
<percious> path of a co
<percious> weirdness though
<tacone> I'd try to checkout again with the version of subversion you have installed now
<percious> yeah, that'd be a great option
<percious> if the network wasn't down
<tacone> oh.
<percious> im somehow thinking bazaar is using the wrong version of svn
<percious> ;-)
<percious> i think i need sleep to function tomorrow.
<percious> this was a fun learning experience though
<tacone> :) see you again
<percious> i have one patch to submit
<tacone> oh, well, I am not a bzr dev, so..
<percious> no worries mate
<percious> that is what launchpad is for :)
<tacone> yes, launchpad's nice.
<percious> ide like to see TG on there
<tacone> tg = ?
<percious> Turbogears
 * percious is a TG dev
<tacone> oh
<tacone> you'd like to make tg hosted on launchpad ?
<percious> ide like to see it happen
<percious> we use SVN/moinmoin/trac
<percious> recently, we started using sphinx for docs
<tacone> launchpad doesn't have a wiki on it's own yet. I filed a bug for that. they're considering.
<percious> but there is no feedback...
<percious> (no feedback on sphinx)
<tacone> lp is great for all the rest. and bzr rocks big time.
<tacone> I love it.
<percious> sphinx is nice for semi-automated api docs: http://showmedo.com/videos/video?name=2910020&fromSeriesID=291
<percious> i want to put a wsgi wrapper on it to create a commenting system
<percious> then it will really work well
<tacone> I am new to python development. I don't know sphinx
<tacone> lol, it's you ?
<percious> :)
<tacone> I saw the username on the terminal :)
<percious> my agile series
<percious> in the back there is longs peak
<percious> ;-)
 * tacone is making his first steps with python unit testing.
<percious> have fun with it
<percious> certainly makes programming less stressful
<percious> nose rocks
<tacone> nose = ?
<percious> check out the video :)
<percious> test discovery
<percious> and more
<tacone> I watching it already
<percious> anyway, i gotta knock off before I wake up with keyboard-face
<percious> see you tomorrow prolly
<tacone> ok, bye
<tacone> see you
<robtaylor> Ok, Say i have a project that's grown large and I want to split in into seperate repos. How would i go about that in bzr?
<radix> robtaylor: one way to do it is to create two branches, and remove one set of files from one branch and the other set of files from the other
<robtaylor> radix: hmm, sounds sensible :)
<radix> of course, that means both branches have all the history of the shared development
<robtaylor> thats really what you want though, isn't it ?
<radix> which, sometimes, isn't what you want (like if you're splitting a chunk off of a proprietary project for release as open source, or if you're trying to prevent the history from growing too large)
<robtaylor> oh ugh yeah
<radix> I guess it's what you want :)
<robtaylor> that's definitly history-rewriting time
<Pieter> or if the other part is really large and you want to keep both repositories of sensible size
<robtaylor> Pieter: is it possible to have a repo that just points to another repo for history before a certain point?
<LarstiQ> robtaylor: s/repo/branch/ and the answer is yes with 1.6
<LarstiQ> but that provides what you want I guess, you didn't actually mean revision garbage collection on repositories?
<Jc2k> robtaylor: 'stacked branches' -> http://jam-bazaar.blogspot.com/2008/05/this-week-in-bazaar_29.html
<robtaylor> Jc2k, LarstiQ: ah, yeah thats what i'm thinking of
<robtaylor> thanks
<luks> hmm
<luks> blackbox.test_check.ChrootedCheckTests.test_check_missing_branch is either way too slow or hangs on my machine
<luks> and blackbox.test_non_ascii diff tests fail :(
<luks> actually, ALL blackbox diff tests fail
<luks> oh
<luks> it doesn't like my pager plugin, never mind
<lifeless> beuno: / mwhudson: does loggerhead 1.6 need bzr 1.6?
<thumper> lifeless: that's what it says (but I doubt it)
<lifeless> thumper: it says 'for 1.6' not 'needs 1.6'
<lifeless> could be either :/
<beuno> lifeless, nope, I added the code for backwards compatibility
<beuno> should work fine with 1.5, maybe even 1.4
<beuno> not sure older than that
<lifeless> did you test 1.4?
<beuno> I was on 1.3.1 for quite a while, and, while I did get deprecation warnings, it still worked
<lifeless> ;P
<lifeless> ok
<beuno> but no, I didn't test with anything other than 1.5 and 1.6  :)
<lifeless> so, did you see my rendering issue yesterday?
<beuno> rendering issue?  no.  The server at my office decided to go to sleep, so I lost my backlog
<lifeless> diff - can't see the edge of lines
<beuno> edge if lines?
<lifeless> foo bar baz quux | foo baz bar quux
<lifeless> but I see up to q
<lifeless> unless I zoom/resize my browser window
<lifeless> theres no scroll bar
<beuno> huh, interesting
<lifeless> http://bazaar.launchpad.net/~jml/subunit/split-right/revision/51
<beuno> do you have font size set to something different than default?
<lifeless> line 218
<lifeless> no
<lifeless> I see 'spli' as the last letters of the left hand size
<lifeless> *side*
<beuno> ah, yes. I can reproduce if I enlarge the font
<sohail> hi, how can I undelete a directory in bzr?
<lifeless> revert -r rev directoryname
<sohail> I deleted it in revision 595
<sohail> that didn't work
<lifeless> oh
<sohail> oh I should have done 594 shouldn't I
<lifeless> yes
<sohail> ok that worked :-)
<sohail> thanks!
<beuno> lifeless, I'll file a bug, thanks
<lifeless> thanks
<lifeless> the README doesn't talk about paste.deploy when behind apache
<lifeless> is that no longer needed?
<beuno> I'm not sure, that's mwhudson's terf really
<lifeless> mwhudson: ping
<lifeless> thumper: unless you know this one
<mwhudson> lifeless: no, you still want paste deploy if you run behind apache
 * mwhudson is not really here today
<lifeless> mwhudson: ok
<lifeless> mwhudson: FWIW the readme says what to do, but doesn't mention that
<mwhudson> lifeless: serve-branches dtrt if paste deploy is importable
<mwhudson> but yes, i guess documentation would be a good thing :)
<percious> is it possible for bzr/svn installs to mess up my setuptools?
<percious> ls
<percious> ok, it is if anyone is wondering
<percious> svn 1.5 breaks setuptools
<percious> here is a thread on the subject: http://www.gossamer-threads.com/lists/trac/users/37446?page=last
<meteoroid> percious: are you serious? that's a problem with svn?
<percious> crazy, huh
<percious> i guess the trunk of setuptools works
<meteoroid> yah i'm having this problem with zc.buildout on a suse box
<meteoroid> lol
<meteoroid> interesting, maybe i can dev-egg it
<percious> but installing the trunk of setuptools doesnt work until you revert to svn 1.4.6
<meteoroid> lol
<percious> of course our svn server is down, so I am SOL anyway...
#bzr 2009-08-10
<lifeless> Noldorin: so, as best as I can see here is whats happening:
<lifeless> bzr asks for lock/held to be renamed
<lifeless> its not renamed
<Noldorin> right
<lifeless> bzr does an rm and rmdir which do not error, so bzr assumes they succeeded(or perhaps we ignore errors at this stage - I'll check in a second)
<lifeless> bzr then tries to take out a new lock, and it fails because the old one is there.
<lifeless> this suggests to me that the FTP server is a) running on windows and b) is keeping a file open within lock/held - either the directory is the cwd for a thread, or the lock/held file still has a read handle open in the ftp server
<lifeless> or
<lifeless> a virus scanner or other async task has opened the lock/held/info file or lock/held directory and thus prevents the ftp server from doing the rena,e
<lifeless> now, I've just checked our code
<lifeless> we do the rename (held, RANDOM) unconditionally, without try:except:
<Noldorin> hmm, what you're saying seems to make sense to me.
<lifeless> so that call isn't returning an FTP error
<Noldorin> right
<lifeless> the delete of the info file is the same, bzr is not receiving an error.
<Noldorin> so the problem is that windows is holding a lock on the file?
<lifeless> we do catch a specific error on the rmdir of the temporary directory, but I can tell from the log that this isn't happening.
<Noldorin> a lock on the lock file, that is
<lifeless> Noldorin: yes, I believe so.
<lifeless> or something like that
<Noldorin> heh
<Noldorin> well i'm glad we're starting to understand the root cause of this now
<Noldorin> i suspected from the start is just wasn't a great FTP server :(
<Noldorin> hrmm
<Noldorin> lifeless: can you consider any simple workaround for this issue, or would i in fact have to change FTP servers to resolve it?
<lifeless> what FTP server is it, if you don't mind me asking?
<Noldorin> lifeless: it's a windows 2003 server hosted by storm internet. more than that, i do not know
<lifeless> ah
<Noldorin> oh lol
<Noldorin> it dos say actually
<Noldorin> when i log in
<Noldorin> Microsoft FTP Service
<Noldorin> so IIS6 i presume
<lifeless> ok
<lifeless> my guess is a virus scanner actually.
<Noldorin> interesting
<lifeless> virus scanners have caused trouble for bzr users in the past, without ftp being involved
<Noldorin> i do succeed with the command *once* in a while
<lifeless> with similar symptoms
<Noldorin> but not often
<Noldorin> would that sound right to you?
<Noldorin> hmm
<lifeless> it does sound plausible
<lifeless> consider that the virus scanner is opening, reading, closing the files that are written, shortly after they are written
<lifeless> if the unlock rename takes place too quickly, it and the virus scanner will be trying to do things concurrently
<lifeless> we can test this
<lifeless> lets add a 2 second delay on unlock
<Noldorin> lifeless: but surely the scanner would only be looking at the files i'm dealing with momentarily?
<lifeless> bzrlib/lockdir.py
<Noldorin> ok
<Noldorin> sure
<lifeless> the unlock() method in that file
<Noldorin> lifeless: i should warn you know, i haven't really coded python before :)
<Noldorin> though i can read it well enough
<Noldorin> ok
<lifeless> at the top of that method, after the docstring.
<lifeless> put
<lifeless> time.sleep(2)
<lifeless> this will make things rather slow :) but if it makes them reliable on ftp, we will have some data.
<Noldorin> ok
<Noldorin> lifeless: right. compiled now
<Noldorin> lifeless: push again? (with -Dtransport?)
<lifeless> yes please
<Noldorin> http://pastebin.ca/1523399
<lifeless> no joy :(
<Noldorin> :(
<Noldorin> so what does that mean, you think?
<Noldorin> virus scanner or not?
<lifeless> I'm not sure
<lifeless> how often has it worked - 1 in 10 ? 1 in 3?
<Noldorin> 1 in 20 maybe
<lifeless> ok
<lifeless> well please try 4 more times
<lifeless> if it has helped we'd expect a significantly better success rate
<Noldorin> lifeless: rubbish. just realised i ran the wronbg bzr.exe
<lifeless> but not necessarily perfect
<Noldorin> sorry, let me try again
<Noldorin> http://pastebin.ca/1523402
<Noldorin> lifeless: that's the actual one :P
<lifeless> doesn't look like a 2 second delay to me
<lifeless> add a
<lifeless> print "waiting two seconds"
<lifeless> line there as well
<Noldorin> ok
<poolie1> hello all
<lifeless> hi poolie1
<Noldorin> lifeless: http://pastebin.ca/1523408
<Noldorin> that should be the onw finally
<Noldorin> one*
<lifeless> it printed out the message to you?
<Noldorin> yep
<Noldorin> lifeless: http://pastebin.ca/1523409
<lifeless> I'm going to get you to move the sleep statement
<Noldorin> ok
<lifeless> can you move it down to right above the line
<lifeless>             self.transport.rename(self._held_dir, tmpname)
<lifeless> (move the print with it)
<lifeless> you'll need to indent, with spaces, to line up.
<lifeless> as python is whitespace sensitive
<Noldorin> yep, i'm aware of that much :)
<lifeless> cool :)
<Noldorin> but thanks
<lifeless> the reason we're moving it i s that the log shows a read right before the rename
<lifeless> and the hypothetical virus scanner could be doing on-demand scanning too
<lifeless> this should give it time to quiesce
<Noldorin> got it
<igc> morning all
<igc> hi poolie1, lifeless
<Noldorin> lifeless: http://pastebin.ca/1523414
<poolie1> hi igc
<lifeless> Noldorin: ok, thats clearly got a 2 second gap. try repeating this 3 or 4 times
<lifeless> just to see if it fails less often than an unmodified bzr
<Noldorin> ok sure
<lifeless> back in a few minutes
<Noldorin> lifeless: no luck
<Noldorin> lifeless: i need to go now unfortunately
<Noldorin> (it's quite late here)
<Noldorin> will talk to you again soon hopefully
<Noldorin> again, thanks for all the help :)
<igc> poolie1: you're intending to release 1.18rc today, yes?
<poolie1> yes
<Noldorin> bye
<igc> poolie1: can you co-ordinate with me before announcing? I'd like to build the docs before then and have them uploaded
<igc> poolie1: I believe that RT request for sphinx is still outstanding so I'll need to do it by hand
<igc> poolie1: also the alldocs website has been translated to Japanese, French and Russian now so it will be cool to roll those out at the same time!
<poolie1> wow, nice one
<spiv> Good morning.
<jelmer> james_w`: what are these "collision" type bug reports about?
<GoStOzInhO> entrem na sala do brasil
<GoStOzInhO> valew
<GoStOzInhO> jklÃ§j
<GoStOzInhO> kfhkf
<GoStOzInhO> kfhkg
<GoStOzInhO> hgk
<GoStOzInhO> kfgk
<GoStOzInhO> gkfgkh
<GoStOzInhO> fgk
<GoStOzInhO> khgfk
<lifeless> poolie1: zing! bug 410745
<ubottu> Launchpad bug 410745 in bzr "PPA GPG key needs more signatures" [Wishlist,Incomplete] https://launchpad.net/bugs/410745
<poolie1> mm?
<lifeless> oh, perhaps you didn't intend the sarcasm in your comment?
<poolie1> oh the last comment?
<lifeless> yah
<poolie1> well, not much
<poolie1> what do you think of it?
<lifeless> I don't think the reporter understands the ppa system
<poolie1> how about comment #5?
<lifeless> as jelmer says, someone that can change a ppa archive signature can suborn the buildds to output different binaries under the original key
<lifeless> hang on, let me start up a browser.
<lifeless> clearer :)
 * igc lunch
<lifeless> EOD
<vila> hi all
<LarstiQ> moin vila
<vila> hey LarstiQ
<LarstiQ> lifeless: did you see my question about what the correct submit branch is for me to submit changes to pqm for 1.17.1?
<poolie1> hello vila
<poolie1> LarstiQ: it should be http://bazaar-vcs.org/bzr/bzr.1.17
<LarstiQ> then maybe I'm just not authorized
<LarstiQ> or should leave the slash off?
<LarstiQ> All lines of log output:Sender not authorised to commit to branch http://bazaar-vcs.org/bzr/bzr.1.17/
 * LarstiQ tries again
<spm> lifeless: spiv: hrm. still no joy. 1. use trash icon in LP UI, remove existing 1.18 2. ~/source/bzr.dev/bzr branch .. to get local 1.18; info -v on this looks fine. 3. ~/source/bzr.dev/bzr push --remember to lp. Have verified it's landing on a different area /00/02/a9/99/ ==> /00/02/a9/9a/ for the new.
<spm> still getting: bzr: ERROR: Server sent an unexpected error: ('error', "KnitPackRepository('lp-45197264:///~bzr-pqm/bzr/1.18/.bzr/repository') has no revision pqm@pqm.ubuntu.com-20090807010459-nw1f0r9y1igi19xf")
<spm> bzr.dev/bzr is 1.17. Halp?
<spiv> spm: huh.
<poolie1> LarstiQ: leave the slash off, it's too picky
<poolie1> because pqm just matches the string, i think it doesn't know anything about the way bzr would interpret that url
<spm> spiv: I'm happy to do the "idiot do exactly this"; it may be pebkac.... :-/
<vila> spm: Are you sure you access the same branch on the super mirror ? I.e. do you have write access in both cases ? Otherwise you may access a different copy in read-only mode
<spiv> spm: I don't see an obvious pebkac in that description.
<spiv> It *is* 5pm, though, which is prime time for overlooking pebkacs!
<spm> spiv: exactly my thinking :-)
<spm> vila: I assume I would have Write access - this is as the pqm user for bzr, so if that has issues.... :-)
<spm> I'll paste the session. one sec.
<spiv> spm: that'd be good.  Hang on -- it's failing on *push*?
<vila> spm: ok, just checking, the write-branch not mirrored on the read-branch in some cases was worth a try, it's a hard one to realize otherwise
<spm> spiv: vila: https://pastebin.canonical.com/20949/
<spm> spiv: no pushed fine, it's an info that barfs
<spiv> Ah, ok.
<spm> if you info locally, you should see it as well; certainly I do.
<spm> vila: ah, right.
<poolie1> any suggestions for stuff to mention in the announcement, beyond what's in NEWS already?
<spiv> Ah, it may just be a bug in server-side HPSS info on a stacked branch?
<spiv> spm: the important question is "does bzr branch via bzr+ssh work?", I'm testing that atm.  It appears the answer is yes.
<spm> spiv: so info may be a red herring of sorts?
<spiv> Yeah.  A bug, not an important one, and not due to a pebkac.  Well, that's my current hypothesis anyway.
<spiv> Not important in this context, obviously it's a fairly important bug for bzr to fix :)
<spm> heh
<spiv> Hmm, I can't trivially reproduce with another stacked branch.  Curious!
<spm> spiv: worth getting me to try and reproduce with eg debugging mode on?
<spm> eg push to bzr-1.18-break-me-if-you-dare ?
<spiv> I wonder if any new stacked branch (i.e. with no data of its own) will trigger...
<LarstiQ> poolie1: hmm, http://pqm.bazaar-vcs.org/ again mentions: Request for non-PQM managed branch.
<spiv> spm: nah, just file a bug
<spm> heh, oki
<spiv> spm: paste/link that session, etc.
<spiv> spm: I think we can figure it out from there without pestering you further :)
 * spm is spoilt for rude choices to respond with, so won't. ;-)
<spiv> :)
<poolie1> LarstiQ: um check with spm?
<spm> LarstiQ: how long ago, and was this against an lp:bzr style branch?
<spiv> spm: FWIW, I can reproduce with a new stacked branch I make myself.
<spm> spiv: cool
<LarstiQ> spm: merge http://bazaar.launchpad.net/~spiv/bzr/bzr-1.17 http://bazaar-vcs.org/bzr/bzr.1.17
<LarstiQ> spm: mail to pqm was at 07:13 UTC
<vila> spm: we still have problems with lp: style branches ? (Trying to keep up without trying myself :-/)
<spm> vila: yeah - hence my question. that &*%^*&$^&^%$(*&^(&^$&^%#$&^&%)(*&^*&^$&*%^$&^%$ing ~/.bazaar/authentication.conf was back again.
<LarstiQ> spm: would you be the one to do the pqm upgrade part of https://bugs.edge.launchpad.net/bzr/+bug/390502 (or is that even what you're doing right now?)
<ubottu> Launchpad bug 390502 in bzr "bzr's development should dogfood format 2a" [High,Confirmed]
<vila> spm: authentication.conf is involved, my word, who would have thought ?
<spm> LarstiQ: I'm one of the losa's; so somewhat yes; and I believe 1.17 is 2a already? I was creating the pqm config setup for 1.18.
<LarstiQ> spm: 1.17 reads 2a, yes
 * spiv heads off for the evening (doing yoga on Monday for a change)
<spm> LarstiQ: "Sender not authorised to commit to branch http://bazaar-vcs.org/bzr/bzr.1.17"
<spm> LarstiQ: recent gpg key change or anything?
<LarstiQ> spm: nope, same key I've used recently to submit to bzr.dev pqm
<LarstiQ> spm: could be that 1.17 has a more restricted list?
<LarstiQ> or, peraps, the mail is not getting signed
<spm> possibly the latter? try again? looking atthe main pqm log, it all looks correct. email from the correct sender and all.
<LarstiQ> --dry-run does show it getting signed
<spm> hmm. well poolies got something in the queue atm, see if that works for him; ie effects all vs just you.
<spm> crap
<LarstiQ> spm: iirc spiv also had trouble submitting for the 1.17 queue
<spm> about 12 hours ago?
<spm> spiv: ^^ ?
<LarstiQ> hmm, longer ago I think
 * LarstiQ checks mail
<spm> gah. he's at yoga.
<spm> 2009-08-09 18:19 - was a fail, same reason
<lifeless> LarstiQ: its on lp now
<lifeless> I thought I sent mail about that?
<LarstiQ> lifeless: ah, that explains it.
<lifeless> spm: none of the bzr branches should be in 2a format yet.
 * lifeless is gone again
<LarstiQ> lifeless: thanks!
<spm> LarstiQ: ah. the one I'm looking at, is one of yours.
<LarstiQ> spm: woops :)
<spm> LarstiQ: which in a way is *some* good news - it's been busted for a while. :-)
<LarstiQ> spm: I've sent another request, this time as lifeless suggested with the submit branch on lp, not bazaar-vcs.org
<spm> boom. same error.
<LarstiQ> ahem, forget the product
<spm> LarstiQ: I've been summonsed to dinner. I'll have a look after, but I suspect it'll have to wait till tomorrow
<LarstiQ> spm: eet smakelijk!
<spm> errr? English? :-)
<LarstiQ> spm: yay, got it going!
<LarstiQ> spm: bon appetit? ;)
<spm> yay!
<spm> and g'night!
<poolie1> spm: now i'm being told i can't commit to 1.18
<poolie1> is it still broken? or was pqm unhappy?
<lifeless> poolie1: what url are you submitting to?
<bialix> igc1: hi
<poolie1> merge http://bazaar.launchpad.net/~mbp/bzr/prepare-1.18 http://bazaar-vcs.org/bzr/bzr.1.18
<poolie1> Command failed!
<igc> hi bialix
<poolie1> All lines of log output:Sender not authorised to commit to branch http://bazaar-vcs.org/bzr/bzr.1.18
<poolie1> hi bialix
<bialix> igc: after 1-2 hours from now I'll start to prepare qbzr release. garyvdm said he will do release today, maybe he'll appear here soon
<bialix> poolie1: hello
<bialix> poolie1: today is release day?
<igc> bialix: that sounds fine. It would have been nice to get qexport in before the 0.13 release but landing it at the start of 0.14 might be better?
<poolie1> yes, i just did it in fact
<poolie1> i didn't announce it yet - we can try to make packages first
<bialix> poolie1: ok
<igc> poolie1: ok, I'll build the docs now then
<bialix> igc: qexport is not ready yet
<lifeless> poolie1: since 1.17 they are on launchpad; I mailed the list at the time
<lifeless> poolie1: I suspect I failed to land a doc update
<poolie1> i suspect you did
<poolie1> actually i know you did
<poolie1> maybe pqm rejected it :-P
<lifeless> [sorry]
<poolie1> np
<bialix> igc1: I've reviewed qexport yesterday, maybe you've missed my mail
<igc> bialix: I did sorry
 * lifeless is really really gone
<lifeless> ring me if you still have trouble
<poolie1> so submit_branch = http://bazaar.launchpad.net/~bzr/bzr/bzr.1.18
<igc> bialix: btw, explorer got preferences support over the weekend
<igc> bialix: does Tools/Options work for you?
<bialix> igc: I saw commit mails, will try it now
<igc> bialix: I've only tested it on Ubuntu at this point
<bialix> igc: http://imagebin.ca/view/yMiG8e7.html
<bialix> Suite has only one option: qbzr
<igc> bialix: that's right. gtk will only appear if bzr-gtk is installed
<bialix> ok
<igc> bialix: do the toolbar preferences work ok on Windows?
<bialix> I believe official plugin name is QBzr, but people usually understand either case
<igc> bialix: and maybe the dialog ought to be called Options on Windows
<bialix> while switching content to expanded I've got traceback
<igc> bialix: as a setting, it's the python package name used for the plugin
<bialix> igc: http://pastebin.com/m348e2c2c
<igc> bialix: I need to i18n all those combo choices as I don't really want to expose the internal values
<bialix> style working ok
<igc> bialix: but my QComboBox foo isn't up to it yet
<bialix> igc: I will be able to look at i18n stuff only tomorrow
<bialix> da you want me to file bug report?
<bialix> *do
<bialix> (something wrong with my keyboard)
<igc> bialix: please
<bialix> hmm
<bialix> it works now
<vila> bialix: blame the gremlins
<bialix> bonjour vila!
<vila> hi bialix :)
<bialix> igc: gremlins here
<bialix> igc: I'm not sure about bug report now
<igc> bialix: try deleting explorer.conf - it will be a one-off init bug
<bialix> igc: gotcha!
<bialix> vila: gremlin name was 'explorer.conf'
<vila> that kind of bug is really annoying especially for *non* devs as they are a royal pain to even understand (there was one in bzr-gtk that remained hidden for months....)
<vila> mabey years even
<bialix> igc: https://bugs.launchpad.net/bzr-explorer/+bug/411304
<ubottu> Launchpad bug 411304 in bzr-explorer "Tools -> Options: changing contents to `expanded` fails if there is no explorer.conf" [Undecided,New]
<bialix> ubottu is really fast!
<ubottu> Sorry, I don't know anything about is really fast!
<bialix> good ubottu, take a cookie
 * bialix bbl
 * igc dinner
<lvh> hi :-)
<ronny> jelmer: aware of any docs for the git http proto? i would implement a wsgi app for dulwich
<ronny> hmm, meh
<ronny> the more i read about it, the more it seems like one doesnt actually want that
<LarstiQ> vila: where can I find the buildbot status page?
<bialix> hi garyvdm
<garyvdm> Hi bialix
<garyvdm> I'm fixing bug 395937, then I'm going to do the release
<ubottu> Launchpad bug 395937 in qbzr "qannotate: Crash when opening qbzr/lib/log.py annotate from qbrowse" [High,Confirmed] https://launchpad.net/bugs/395937
<garyvdm> I'm not sure if I will include the fix or not. I'm worried about lack of testing.
<garyvdm> If not - I will include the fix that we had for 0.12
<bialix> garyvdm: I have problem with proper disabling of UI when operation starte
<bialix> started
<bialix> did you saw it?
<bialix> or this is again Qt 4.4 bug...
<garyvdm> bialix: I do remember seeing something. I did not look in detail, and now I cant find it. Was it in a mail, or a bug?
<bialix> nope
<bialix> no mail no bug
<bialix> I've recently change signal subprocessStarted et al to disableUi
<garyvdm> Ok - That'ss what I saw.
<bialix> and now I see that UI disabled and then enabled once there is incoming data from subprocess
<garyvdm> LarstiQ: The reason why there is no syntax highlighting in unidiff, is it would overwrite the colors for unidiff.
<bialix> actually I see it everytime I do qpull
<garyvdm> ok
<garyvdm> Let me try reproduce.
<bialix> garyvdm: is there some debug utility for qt to trace signals?
<LarstiQ> garyvdm: right, I'd like both  :)
<garyvdm> bialix: Not that I know of. It can be quite frustrating.
<LarstiQ> bialix, garyvdm: there is, QSignalSpy
 * bialix googling
<LarstiQ> last I checked that didn't have PyQt bindings though
<bialix> LarstiQ: it seems it's still none
<garyvdm> LarstiQ: So would the unidiff colors overwrite the syntax colors?
<garyvdm> or the other way arround?
<LarstiQ> garyvdm: I'd go with backgrounds ala side-by-side deletion/addition blocks
<garyvdm> Ok
<garyvdm> Like launchpad
<LarstiQ> euh, possibly :)
 * LarstiQ takes a look
<LarstiQ> garyvdm: I'm coming from vim myself
<bialix> garyvdm: I found!
<garyvdm> LarstiQ: can you send me a screen shot.
<bialix> garyvdm: the problem in on_error method
<garyvdm> bialix: I can reproduce on linux with qt4.5
 * garyvdm looks at on_error
<bialix> it seems some code calling on_error all the time
<bialix> garyvdm: it seems readStderr send it
<bialix> oh
<LarstiQ> garyvdm: hmm, I realize that's actually more of a side-by-side than unidiff thing
<garyvdm> Yes - So something is writing to stderror that should not be?
<bialix> it's never ending discussion: does bzr should emit non-error messages to stderr?
<bialix> well
<bialix> garyvdm: bzr writing to stderr too much data
<bialix> not errors!
<bialix> and this is known intended behavior
<bialix> rats
<LarstiQ> garyvdm: but basically one background color for old and one for new makes sense to me
<bialix> LarstiQ: IIRC unidiff has used bg colors instead of fg
<bialix> but then luks has changed it this way
<bialix> perhaps to avoid height problems
<garyvdm> bialix: no height problems in unidiff.
<garyvdm> may be another reason.
<bialix> perhaps just for estetic reasons
<garyvdm> bialix: We could emit only if a line starts with "bzr: ERROR:"
<bialix> I remeber his comment: if somebody want old behavior -- then make it configurable
<bialix> garyvdm: I think I'm just remove my signal from on_error
<bialix> if I found the case whne it's needed, I'll try to figure out how to deal with this problem
<bialix> so for now (for release) I'll stick with this
<garyvdm> Oh yes - the ui should be enabled on failed/finished.
<bialix> fte
<bialix> (wrong window)
<LarstiQ> bialix: ok, I'll go look for luks change
<bialix> LarstiQ: ?
<jml> hello from Prague
<bialix> jml: hi
<LarstiQ> bialix: and see about what he wanted made configurable
<bialix> LarstiQ: IIUC colors
<bialix> what color should be used for + or -
<bialix> ink and papaer colors pair
<bialix> paper
<LarstiQ> bialix: makes sense
<bialix> LarstiQ: it was changed long ago
<bialix> around end of 2007 - beginning of 2008
<bialix> LarstiQ: revno 186
<bialix> btw, garyvdm , I'd like to measure speed of syntax highlighting
<garyvdm> --lsprof
<bialix> perhaps it's one of major slowdown factor for qdiff I see all the time with big files
<garyvdm> Probably correct.
<bialix> well, I'm thinking about put time.time() in some points here and there and looks at numbers
<bialix> there is another narrow place: detector of NUL bytes
<garyvdm> bialix: --lsprof will give you a good estimate.
<bialix> why --lsprof?
<garyvdm> I wonder if you can run KCachegrind on windows.
<luks> woo, looking at history is cool. nice to see the commit dialog from qbzr r1 still working :)
<ronny> jelmer: how does one propperly set the commit date of a svn rev using subvertpy, passing svn:date as revprop seems to fail
<garyvdm> luks: :-)
<bialix> luks: hi :-)
<luks> hey
<garyvdm> bialix: have you ever use --lsprof[-file]. It gives you the time spent in each method.
<garyvdm> Then I use KCachegrind to browse through the data. Before I used excel on windows to browse.
<bialix> garyvdm: I think I've always used just plain --profile
<garyvdm> Oh
<bialix> garyvdm: I was under impression it does not work here
<garyvdm> bialix: the other way the will give you a more accurate measurement is to time it, and them time it with pygments uninstalled.
<bialix> what is lsprof?
<bialix> I can't find it in standard python docs
<bialix> it's 3rd party lib?
<garyvdm> See bzr help global-options
<LarstiQ> bialix: yes, but it got into 2.5 (or 2.6?) as `profile`
<LarstiQ> bialix: however, it doesn't publically expose some of the lsprof methods we were using
<bialix> --profile calims it uses hotshot std lib
<bialix> hmm
<bialix> cProfile, a module written in C, with a reasonable overhead that makes it suitable for profiling long-running programs. Based on lsprof, contributed by Brett Rosen and Ted Czotter. New in version 2.5.
<bialix> that's one?
<LarstiQ> bialix: yeah
<bialix> I'm using it for my own programs
<bialix> very useful
<LarstiQ> bialix: do you also use the callgrind output it can generate?
<bialix> callgrind?
<luks> imo the main advantage of lsprof is generating the call tree
<luks> messing with kcachegrind was so useful when I was working on the c patiencediff
<garyvdm> bialix: KCachegrind is what I use to look at the .callgrind. I'm not sure if you can run it on windows though.
<garyvdm> bialix: there are 2 things to measure for syntax highlighting: How long pygments takes, and how much extra it takes the QTextBrowser to do the format.
<bialix> http://docs.python.org/library/profile.html#module-pstats
<bialix> I'm using output as in docs
<bialix> QTextBrowser definitely slow to render our diffs with lines
<bialix> it is long standing wish to put every file diff in separate tab
<bialix> I wonder if it helps with scolling slowness
<bialix> *scrolling
<garyvdm> Scrolling slowness?
<garyvdm> Are you maybe trying to scroll before it's finished loading?
<bialix> when you have a big diff in many files then scroll down the entire diff is dead slow
<bialix> does not matter actually
<bialix> it slow even after loading is finished
<garyvdm> That might be our code that is drawing the lines.
<bialix> as good example of slowness we can use any qbzr revno where I did "sync translations with lp"
<bialix> there is a lot changes in many files
<garyvdm> luks: Why did you change annotate from using a QTextBrowser, to using a list controll?
<luks> garyvdm: I wanted columns
<bialix> is it possible to force text selection with mouse here?
<luks> yes, but probably not easily
<garyvdm> But you were using a html table. What was the problem with that? The reason I'm asking is that I think that might be the solution to not been able to select text.
 * bialix mutters: we really needs policy to land new features with corresponding NEWS entry
<luks> you can't resize the columns in a html table
<luks> and names can get quite wide
<garyvdm> bialix: sorry - I'm bad with that.
<garyvdm> luks: ok - I see
<bialix> garyvdm: ok, so I leave NEWS for 0.13 for you
<luks> but it's not that I use qannotate anyway
<luks> I was mostly just copying qannotate :)
<bialix> copying qannotate?
<luks> I mean gannotate
<garyvdm> It would also be nice if when you scroll horizontally in qannotate, it only scrolled the text, not all columns
<bialix> luks: what you think about adding line numbers to qdiff? what QT widget need to be used?
<luks> bialix: I'd like that, but we would have to write that ourselves
<garyvdm> bialix: I see what you say about the scolling in qdiff. Is there a bug loged.
<luks> you can have a margin in QTextBrowser
<luks> but you need to draw it in your code
<luks> the whole diff view should be a c++ widget
<luks> there is too much slow python code
<bialix> when I'm select the text to copy with margin, the numbers will be omiitted?
<luks> no, the margin is totally separate
<bialix> that's nice
<luks> it's intended for line numbers in a text editor, mainly
<bialix> luks: IIRC you has tried to start writing special C++ code for qdiff
<garyvdm> luks: we could probably use that for annotate too.
<luks> garyvdm: yeah, that could be one way to solve it
<luks> garyvdm: but it would need some more code, to handle margin resizing
<garyvdm> luks: oh yes
<garyvdm> luks: What do you think of LarstiQ's idea to have the unidiff colors as background colors, so that we can do syntax highlighting in unidiff?
<luks> garyvdm: we would need a custom painter for unidiff then
<luks> garyvdm: or maybe not, but Qt used to not handle <div style="background-color:#..."> correctly when scrolling
<garyvdm> luks - yes - if we want the background across the whole line
<ronny> jelmer: what is this 1000000 magic factor in the subvertpy timestamp functions about?
<garyvdm> luks: No - it does not have that abiliy afaik
<bialix> is not div element should be resized on full width of window?
<bialix> then it can draw background on full width
<garyvdm> not in QTextBrowse
<bialix> bad
 * bialix bbl
<garyvdm> bialix: On thing that we currently do in qdiff is run the whole file through pygments. You could may be experiment with passing only the part of the file we diapaly through pygments
<garyvdm> *display
<bialix> I need to collect speed statistics first
<bialix> btw, I like how WinMerge shows the diff
<bialix> there is always full file
<bialix> and deletion on each side shown as holes
<luks> I'm not sure if pygments can do that
<bialix> I'd like to accomodate this for qdiff
<luks> higlighting parts of a file is a more complex problem
<jelmer> ronny: hi
<jelmer> ronny: you can't change the commit date during a commit
<jelmer> ronny: the only way you can change the commit time is by changing the revision property afterwards
<jelmer> (which requires the commit hooks to be adjusted to allow that)
<ronny> oh darn
<ronny> jelmer: btw, why that magic timestamp factor?
<jelmer> yes
<jelmer> ronny: magic timestamp facto?
<garyvdm> luks/bialix: When I get around to it, I want to create "qdiffmerge" which will allow 3-way diff, editing, and (this is why I want to write it, not just use meld) the ability to annotate in that window.
<garyvdm> It's a big job, so I keep on putting it off :-~
<ronny> jelmer: the 1000000 you use in time_from/to_ctime
<ronny> jelmer: how do i get the revno a commit created
<ronny> meh, svn is fail :(
<ronny> jelmer: i'll print a warning instead of setting a svn date for now
<garyvdm> ->lunch, bbl
<jelmer> ronny: there's a callback used by commit that will be called with the result author, date and revno
<jelmer> ronny: the 10^6 stuff is used because that seems the times are usually usecs in the svn world
<poolie1> hi vila?
<vila> poolie1: hey !
<ronny> jelmer: how can i use that calback stuff when using a ra editor
<Ng> --help
<garyvdm> Bazaar -- a free distributed version-control tool
<garyvdm> http://bazaar-vcs.org/
<garyvdm> Basic commands:
<garyvdm>   bzr init           makes this directory a versioned branch
<garyvdm> ......
<jelmer> ronny: you can specify a callback to get_commit_editor()
<jelmer> I think it's called "done" or something in the docstring
<ronny>  its called callback
 * SamB wonders why it is *repository formats* that are considered rich-root or not, rather than branches/revisions
<SamB> spiv: so, 1.18 *is* going to have this Repository.insert_stream_1.18 hpss method, yes?
<jelmer> SamB: it's repositories that store revisions, not breanches and not working trees
<SamB> jelmer: yeah, I know
<SamB> but don't only some of the revisions actually use rich-root at all?
<jam> ping vila about kerguelen :)
<vila> jam: goood morning jam :)
<jam> so... you have to delete bzrlib/_chunks_to_lines.pyd before running setup.py, as it loads osutils.py which loads chunks_to_lines
<SamB> evil!
<jam> SamB: evil-ish. Mostly that you can't delete an open file on Windows, which causes difficulties sometimes
<SamB> jam: I meant having the C-ish module import a python module, actually ...
<jam> SamB: it doesn't
<jam> setup.py imports osutils.py imports chunks_to_lines.pyd
<SamB> oh
<jam> just that setup.py also *rebuilds* chunks_to_lines.pyd
<jam> if it is considered out of date
<jam> but it always fails if it already exists...
<SamB> I guess I didn't interpret "it" correctly
<bialix> garyvdm: how it's going?
<garyvdm> Hi bialix
<bialix> hi garyvdm
<garyvdm> hmmmm
<garyvdm> Not on to release yet.
<bialix> is there some blockers for you?
<bialix> jam: hello
<garyvdm> Fixing qdiff perferformance
<garyvdm> Nearly done with that :-)
<jam> hi bialix
<jam> and garyvdm
<bialix> jam: garyvdm working on qbzr release
<jam> bialix: I'm not on as strict timetable for 1.18rc1, so just let me know when you think you're ready
<bialix> what's your plans on bzr installer?
<garyvdm> Hi jam - when do you plan to do the wininstallers for 1.18rc?
<bialix> :-)
<bialix> all windows people looking at jam
<garyvdm> jam - never mind. there was a irc delay
<jam> garyvdm, bialix: I plan to do them.... eventually :)
<garyvdm> jam - I'll let you know when I've done the qbzr release.
<garyvdm> Please will you wait for that before you do 1.18rc1 installers
<bialix> if garyvdm will fall asleep I'll do it
<garyvdm> bialix: I've got qdiff much faster - just some small bug to fix.
<bialix> that's great!
<garyvdm> bialix: Please can you try out the qannotate changes.
<bialix> does they're already in trunk? I did not saw commit mail yet
<bialix> garyvdm: do you remember what's problem with bzr-pipeline? Bug #395817
<ubottu> Launchpad bug 395817 in qbzr "qbzr and bzr-pipeline not compatible." [Medium,New] https://launchpad.net/bugs/395817
<garyvdm> Yes - I know how I think we should fix that - will just take a while.
<garyvdm> I'll explain in a sec
<bialix> if you think we have to fix it on our side, then I'd mark bug as Confirmed
<garyvdm> bialix: It probably involve changes in bzrlib, qbzr and bzr-pipeline
<garyvdm> or just bzrlib, and qbzr
<bialix> should we involve bzr into bug report then?
<garyvdm> Not yet
<bialix> ok, so won't touch it yet
<bialix> so I won't
<Guest65098> ~~~~~~~~/qIRCNICK patrickcd
<garyvdm> bialix: re pipeline problem - I've got a 2 ideas on how to fix. Both are a lot of work :-( I have not decided which is best.
<garyvdm> Idea 1:
<garyvdm> Add --using to merge --preview
<garyvdm> and
<garyvdm> Add a way to hook qdiff into diff --using
<garyvdm> which would be reused by merge --preview
<garyvdm> so you could do merge --preview --using qdiff
<garyvdm> Idea 2:
<garyvdm> Change bzrlib to some how allow for multiple plugins to change a command.
<garyvdm> Not 100% certain how that can be done though.
<garyvdm> bialix: so I have pushed my qdiff improvements if you want to try them out.
<garyvdm> And I'm going to start updating news now.
<bialix> idea #2 require discussion with core devs
<garyvdm> Yes
<bialix> perhaps Aaron or Martin should know better
<luks> Idea 3: monkey patching :)
<garyvdm> luks: what's that?
<luks> modify cmd_merge instead of subclassing it
<luks> you can add an option and overwrite _do_preview
<luks> and now I should hide :)
<bialix> why not?
<bialix> does monkey patching taboo in #bzr?
<garyvdm> luks: Yes - that way one of my ideas, but I'm not sure where one would do that?
<luks> bialix: I guess any bzr dev would complain
<luks> since it's misusing a private API
<bialix> about monkey patching from qbzr plugin?
<luks> from any plugin
<garyvdm> Which we are doing atm....
<bialix> recently there was added some hooks re command loading
<luks> garyvdm: in bzrlib.plugins.qbzr.__init__
<bialix> I wonder if they will be used here
<luks> but of course proper hooks in cmd_merge would be a better solution
<garyvdm> luks: lazly?
<luks> garyvdm: you can overwrite the method by a trivial method that either calls something else or the original _do_preview
<garyvdm> A pro of Idea 1 would get us away from interfacing a private method
<luks> the something else would be lazily loaded
<garyvdm> luks - I see
<luks> not that I suggest using something like this long-term
<luks> but it would work until there are proper hooks in cmd_merge for --using
<bialix> IIUC you mean registry of diff viewers
<garyvdm> Yes - that is what I had in mind for idea 1
<bialix> it's could be complicated because PreviewTree is internal representation of merge results and has not actual mirror on the disk
<garyvdm> bialix: It would be easy to write to disk.
<garyvdm> However, for qdiff, it would not be written to disk.
<bialix> just to throw it after?
<luks> bialix: well, that
<luks> 's what diff --using does
<bialix> right
<bialix> +1 then
<garyvdm> bialix: have you tried qdiff yet?
<bialix> so, we'd need to start supporting `bzr diff --using qbzr` first, I guess
<garyvdm> yea
<bialix> garyvdm: not yet
 * bialix pulls
<garyvdm> bialix, luks: I found that qdiff was spending more time in format_for_ttype than in pygmentstaking longer in
<garyvdm> ^H^H^H^H^H^H^H^H^H^H^H
<garyvdm> So I now cache that.
<garyvdm> And I made the line/block drawing only draw what's on screen.
<garyvdm> much faster now.
<bialix> garyvdm: WOW
<bialix> WOW WOW WOW
<bialix> it flies now
<garyvdm> :-)
<bialix> you're wizard!
 * bialix heads to home now, be back after ~ 1 hour
<fsufitch> hey. who do i complain to about bzr rspush deleting vital files which were part of .bzrignore?
<emmajane> beuno-lunch, I'm just headed out for lunch myself. But I've sent a summary to the mailing list for the wireframes. it would be great if you could take a peek and hopefully pass this along to one of your designers.
<garyvdm> jam: qannotate can now annotate the working tree - so now qannotate can do every that gannotate can do :-)
<garyvdm> *everything
<luks> except for moving between revisions
<garyvdm> luks: It can!
<luks> oh
<luks> cool
<garyvdm> luks: right click on a revision, click on "Annotate this revision."
<luks> UI bug, it should not have a trailing period :)
 * garyvdm fixes
<beuno-lunch> emmajane, will do
 * garyvdm -> dinner
 * SamB wonders why bzr switches packs in mid-transfer
<SamB> (why can't it just write to a temporary pack and then figure out where to really put the the revisions later?)
<luks> hm, I find myself running "bzr branch ../foo ../bar && bzr switch ../bar" too often. has anybody thought about adding a --switch option to branch before?
<SamB> luks: bzr switch -b
<luks> oh?
<SamB> the ../ is sorta implicit, too
<luks> in what version was that included?
<SamB> so you would just do "bzr switch -b bar", if foo was what you had checked out
<SamB> luks: 1.17, maybe?
<luks> I have 1.17 here and no switch -b
<SamB> oh
<SamB> well, whatever's in the PPA then
<luks> hm, but switch -b branches of the current branch, right?
<SamB> I believe you could specify a second arg if you wanted to branch from something else
<SamB> it's inspired by git checkout -b
<luks> oh, so apparently I have 1.17rc here
<luks> and it was added in 1.17
<luks> weird that there was a new feature added after the rc
<SamB> yeah
<luks> I must be blind
<luks> upgraded to 1.17, still don't see the option
<SamB> oh?
<luks> not in builtins.py either
<luks> and not mentioned in NEWS
<luks> but the docs on bazaar-vcs.org mention it
<luks> strange
<luks> last entry in New Features in the tarball is "bzr send now aborts if ..."
<SamB> maybe you're looking at the bzr.dev docs?
<luks> I am, but under the 1.17 section
<SamB> oh?
<luks> it was probably added on the wrong place in bzr.dev
 * LarstiQ annotates
<luks> hm, right, to switch -b is not useful to me
<luks> I'm usually in a situation where I have a feature branch and I want to work on another feature
<luks> this way I'd have to switch to trunk, switch -b to the new branch
<luks> which is not not easier than branch && switch
<LarstiQ> luks: how about cbranch?
<SamB> LarstiQ: doesn't that do something almost entirely different?
<luks> what does it do? the help text is confusing
<LarstiQ> SamB: something witt branches and checkouts? ;)
<luks> I don't want to create a new checkout
<SamB> LarstiQ: but it makes a new checkout, doesn'ty it?
<luks> I want to use the same checkout, but create a new branch
<LarstiQ> SamB: ah hmm, you'd still need to switch, yeah ok, doesn't help
<luks> what do you think about adding "bzr switch -b [SOURCE] TO_LOCATION"?
<luks> would it be acceptable to add a new argument between the existing ones?
<SamB> luks: should be the other way, I think
<SamB> bzr switch -b to_location [source]
<luks> yeah, well, that would be compatible with older switch, but inconsitent with branch
<LarstiQ> bzr switch source -b to_location?
<luks> that's the same as -b source to_location
<LarstiQ> not if -b is an option
<luks> I believe the option parser ignores position of --options
<luks> oh, even more confusing :)
<SamB> the idea is to mimic 'git checkout -b'
<LarstiQ> luks: one of us is confused about argument/option :)
<luks> argument is 'foo', option is '-f' or '--foo'
<luks> right?
<LarstiQ> luks: argument doesn't take an argument, option takes an argument
<luks> well, to_location is not -b's argument
<LarstiQ> d'oh
<SamB> it apparantly should be?
<luks> probably not, because you need it even without -b
<luks> bzr switch to_location is the main use case
<SamB> or maybe checkout is just supposed to treat it's args different depending on whether or not -b was passed
<luks> git indeed uses "checkout -b target source"
<SamB> luks: well, I meant judging by git-checkout(1)
<luks> I'd prefer the argument ordering from branch
<luks> which is the same as for cp/mv
<SamB> it would mess up our finger memory
<luks> well, I'll write the patch and let people on the bazaar ML judge it
<SamB> and having optional arguments at the beginning is quite odd
<luks> it would depend on -b
<luks> "bzr switch foo bar" would raise an error
<SamB> even so
<luks> or, "source" could be -b's argument
<SamB> no, that's an incompatible change
<SamB> or, darn, it's not in a release is it?
<LarstiQ> incompatible changes aren't outruled per se
<SamB> well, anyways, it isn't terribly compatible with my fingers ...
<LarstiQ> and especially when not released :)
<luks> isn't it possible to have an option with has optional argument?
<SamB> I'd want the '-b' short form removed if you're going to do things so different
<luks> so both "-b" and "-b source" are valid?
<SamB> luks: no...
<SamB> well, I hope not, anyway
<luks> oh well, I'll just write it the hacky way and let the patch to be rejected :)
<luks> hm, or I write a plugin
<SamB> dunno how I missed that bzr switch -b bar foo
<SamB> doesn't work yet
<luks> cool, it seems optparse explicitly supports optional arguments in the middle
<luks> I can have takes_args = ['source?', 'to_location'], def run(self, to_location, source=None) and it does the right thing
<SamB> the wrong thing!
<SamB> well, what you meant, sure ;-)
<LarstiQ> interesting :)
<luks> hm, or maybe not
<luks> does anybody know of a bzr command that take arguments in "target source" other?
<LarstiQ> export
<SamB> luks: I think the order to use is "required [optional]", generally
<luks> SamB: I know, but I couldn't live with switch source target
<luks> it seems everything fails, so I'll write a sbranch plugin for myself
<luks> er, sorry, with source target source
<LarstiQ> luks: `bzr export` wasn't helpful?
<luks> (but you can see, it's hard to write the other way :))
<SamB> needs more source
<luks> LarstiQ: I always found it weird
 * SamB pours on some worcestershire source
<luks> LarstiQ: I just wanted to know if there is a precedent
<luks> I wonder why was the option added to switch and not branch though
<luks> since branch has more options for things like revision
<SamB> luks: it's a convenience command
<jam> luks: because at the time I got motivated enough to implement "-b" I was thinking about switch
<jam> there is certainly an argument for "bzr branch --switch"
<jam> nobody has cared enough to do it :)
<jam> in fact, I generally work that way as well, but I wrote 'bzr-start' to handle that for me
<jam> lp:~jameinel/+junk/bzr-start
<jam> uses the 'submit:' branch to decide what the source should be
<jam> so "bzr start ../lp/my-new-feature"
<jam> branches from bzr.dev, and switches to it
<luks> jam: does http://paste.pocoo.org/show/133506/ look sensible?
<luks> (for inclusion in bzr.dev)
<jam> luks: I think if we add the "two location" variant, we should just make "bzr branch --switch" rather than "bzr switch -b target source"
<luks> ok
<jam> luks: though that is *my* opinion
<luks> I'll submit a patch for that
<jam> note there has been some recent discussion
<luks> I like it better, too
<jam> where lifeless and abentley have mentioned wanting "bzr switch --new"
<jam> because they want to use it for bzr-loom and bzr-pipeline
<luks> ah
<jam> and they didn't like "-b" since it would be "new-loom" or "new-pipe"
<jam> or whatever
<jam> so at least think about that briefly
<jam> *I* like "bzr branch --switch ../source ../target"
<luks> me too
<LarstiQ> maybe minus the ../ ?
<luks> in my case it's more often ../branches/source ../branches/target
<luks> or would that relative location handle that as well?
<jam> luks: so "switch" knows about relative locations and "branch" doesn't
<jam> one of the problems about *creating* branches is that it can be unclear
<jam> if you typed "bzr branch source target"
<jam> is source relative to the current tip?
<jam> is target?
<jam> or is target relative to the working dir?
<luks> I generally like using real path, because I can tab-complete on that
<jam> if source is relative to X is target then relative to X ?
<LarstiQ> luks: that's incentive for better tab completion
<luks> LarstiQ: hard to implement as a bash extension if bzr startup time is as it is
<jam> luks, LarstiQ: I think, in general, it is a UI issue that is hodgepodged right now, and nobody has gone through and figured out what it should be
<luks> I really like the way it works in git
<bialix> garyvdm: ping
<jam> switch, IIRC, is the *only* command to support "bzr switch foo" to mean "bzr switch $CURRENT/../foo"
<garyvdm> Hi bialix
<jam> garyvdm: so is it ready yet ?
<jam> :)
<garyvdm> Busy with the release...
<bialix> evening Gary
<garyvdm> not yet
<jam> btw garyvdm, you seem to be doing *far* too much development work on release day
<bialix> garyvdm: I've fixed some typos in NEWs
<jam> take it from the bzr project, that is a very good way to break things :)
<bialix> garyvdm: can you look at them?
<garyvdm> bialix: Yes
<bialix> one sec
<garyvdm> yam: I know it not good. If there are bugs, I'll do 0.13.1 before bzr 1.18(2.0?) final.
<luks> loggerhead should really not annotate files by default
<garyvdm> *jam
<bialix> garyvdm: http://paste.ubuntu.com/250990/
<garyvdm> jam/bialix: do you guys think I should leave the annotate and diff change out the release.
<bialix> diff fixes are superious
<jam> garyvdm: I don't really care. I think they seem like good things
<bialix> jam: we have regressions all the time
<garyvdm> bialix: Please commit and push.
<jam> Just recommending that you do the work right after a release
<jam> rather than right before
<bialix> so even release day is ok
<jam> bialix: "spurious" ?
<bialix> ?
<bialix> WDYM?
<jam> (1:58:54 PM) bialix: diff fixes are superious
<jam> I'm trying to understand what you mean by "superious"
<bialix> SUPER++
<garyvdm> bialix: Normally we catch the regressions before we release.
<bialix> it seems I've construct the word using russian grammar
<jam> bialix: I was concerned you meant :http://www.merriam-webster.com/dictionary/spurious
<jam> " outwardly similar or corresponding to something without having its genuine qualities"
<jam> (often used as, you changed something that didn't really need to be changed, for no real net benefit)
<bialix> jam!
<bialix> you are laughing fromme
<bialix> don;t
<jam> not laughing
<jam> just not sure whether you meant "those are really good"
<jam> versus "those really didn't help anything"
<jam> spurious == don't help
<jam> super++ == help a lot
<bialix> the latter
<bialix> I've just realized
<bialix> Gary perhaps pronounced similar to Harry?
<garyvdm> Yes
<bialix> wizard Gary
<garyvdm> Lol
<bialix> I'm glad 0.13 won't be boring maintenance release
<bialix> pushed
<bialix> wow, paste.ubuntu.com correctly displays russian. kudo for people coding it
<bialix> garyvdm: do you need any other help with release from me?
<garyvdm> I don't think so. Maybe with Inno, but If I get stuck, I'll mail you.
<bialix> I'll build installer tomorrow morning, don't worry about it
<bialix> it seems official bzr rc installer will go first ;-)
<bialix> garyvdm: so, write some optimistic announce mail, this release really deserve it. there is a lot of tasty improvements
<bialix> thanks a lot
<garyvdm> Ok - I'll maybe include some screen shots
<bialix> good idea
<fjalvingh> Sorry for the intrusion, but is there anyone here that can help me with something which looks like a corrupted bzr repository (bug 405251)?
<ubottu> Launchpad bug 405251 in bzr "Huge data transfers/bad performance OVERALL" [Undecided,Incomplete] https://launchpad.net/bugs/405251
<luks> jam: it seems I might take the lazy way and just start using your bzr-start instead of patching branch :) you shouldn't point me to the plugin
<jam> :)
<jam> well, I wrote it because it works well for this mode of operation
<jam> and is *just* special enough
<jam> that i didn't think it was worthy of being a core command
<luks> 99% of cases I branch from trunk, so submit location works fine for me
<jam> I don't really like the name 'start', though it works well for me
<garyvdm> jam: qbzr 0.13 tar uploaded and taged revision pushed.
<jam> of course, I usually also wait for bzrtools 1.18 to be released, so no real pressure from you guys :)
<garyvdm> lol
<garyvdm> luks: There is a command in the .deb building world that automatically downloads the latest source package. I can't remember what it is. I think it starts with "u". Do you know what it is?
<luks> uscan?
<luks> why are you not using bzr builddeb though?
<luks> (or maybe you mean uupdate)
<luks> I used to work with watch files that called uupdate automatically
<luks> but now I only use bzr builddeb, it takes care of the boring work
<garyvdm> luks: Yes - Thats its. I am using bzr bd for some things, Maybe I'm not aware of all of bzr bd features
<luks> well, it can download tarballs for you :)
<LarstiQ> fjalvingh: that bug doesn't seem to mention corruption?
<garyvdm> luks: Ok, how?
<luks> garyvdm: bzr bd :)
<luks> it will download the tarball and build everything
<luks> I think there is a separate command for downloading the tarball too
<garyvdm> Oh wow.
<fjalvingh> LarsiQ: Thanks for answering; at the end of the bug there seems to be the actual problem: the repository grows 170MB for a simple commit,,, And has grown 3x as big in a month
<emmajane> ping beuno
<fjalvingh> So performance is a symptom... I cannot go back to an earlier bzr because the repo itself looks corrupt
<beuno> pong emmajane
<emmajane> beuno, I'm not sure I understand your concern with the front page... do you have some time to go over it before you hand it over?
<beuno> emmajane, sure
<beuno> my main concern is that it's too much content
<beuno> maybe it will not look so much with design slapped on it
<emmajane> too much content, or too many regions?
<beuno> but it seems like a lot to grab your attention
<beuno> I think content
<garyvdm> luks: That did not work. Do I have to update the changelog first? (can't remember the command for that.)
<LarstiQ> fjalvingh: I'm out of my depth there
<luks> garyvdm: yes
<beuno> emmajane, and regions as a result of it
<LarstiQ> garyvdm: dch
<emmajane> beuno, are you trying to include the footer as contnet? It really does not count.
<emmajane> beuno, the footer should be muted and in a small font and out of the way of the main content.
<luks> garyvdm: btw, you can use the scripts from bzr to do ppa packaging
<fjalvingh> LarsiQ: thanks anyway...
<luks> garyvdm: it gets boring to build packages for 3 distros
<emmajane> beuno, people seem to be having a hard time looking past it and I wish I hadn't included it in the design, but it shows how the sections flow into the rest of the site
<garyvdm> Ok - I look at that.
<beuno> emmajane, I think the regions are good, I just think that no matter how you look at it, it's too much
<LarstiQ> fjalvingh: jam might be of more help
<emmajane> beuno, I'm not sure how it's too much though.... it's essentially two regions broken down into smaller areas.
<beuno> emmajane, well, just to show you how much I trust you, I have already sent it off to get a designer on it
<beuno> we can see once it looks more like a web page
<emmajane> beuno, heh. It's not about trust. :) It's about getting it right. ;)
<beuno> and decide based on that
<beuno> emmajane, I jump around a dozen different projects per day, I may be over-siplifying it
<jam> fjalvingh, LarstiQ: Not sure I can be of more help without context :)
<beuno> I don't have my head in this too deeply
<emmajane> beuno, when I gave the examples of simplified home pages (e.g. open atrium someone complained those sites were too bare).
<emmajane> beuno, I'm just tryign to find that post now.
<jam> but if I'm guessing the user correctly
<beuno> emmajane, so if you feel it will fit, we'll see in (hopefully) a few days, and tweak based on that
<jam> he's been talking with me fairly directly for a while now :)
<jam> (well, on the bug page, at least)
<fjalvingh> jam: what do you need? I'm very eager to get this fixed because end of this week I'll be forced to move back to Subversion -  and I hate that 8-(
<fjalvingh> jam: yes, I'm the one on bug 405251 (fjalvingh).
<ubottu> Launchpad bug 405251 in bzr "Huge data transfers/bad performance OVERALL" [Undecided,Incomplete] https://launchpad.net/bugs/405251
<jam> fjalvingh: Unfortunately I don't have great answers for you just yet. I could say "bzr log -n1 -r0..-1" might be helpful
<jam> sorry "bzr log -n1 -r0..-1 -v"
<jam> however, my quick guess
<jam> is just that you change a *lot* of files every commit
<jam> the pull results you showed
<jam> show a lot of files changing on each revision
<fjalvingh> jam: Did you look the last comments where I pulled one by one? Because a growth of 170MB in the repository for a few files seems excessive?
<jam> fjalvingh: can you point to a specific rev
<jam> as I was seeing *lots* of changes for each revision
<jam> but I didn't go one by one
<jam> also, it is just as possible that someone is doing "bzr add big-subdir; bzr commit;  bzr rm subdir; bzr commit"
<fjalvingh> One moment, I'll look in the log to find one.
<jam> and that causes a lot of churn
<jam> that wouldn't show up in the pull
<jam> since it only compares the start and end states
<jam> and not all the intermediate states
<fjalvingh> jam: Yes, I understand but that *would* be visible when doing the log verbose for that revno?
<jam> fjalvingh: not for that revno
<jam> but if you logged *all* revnos
<jam> well, all revisions
<jam> hence -n0 versus -n1
<jam> meh, I typed it wrong again
<garyvdm> luks: bzr.dev/tools/packaging/update-packaging-branches.sh and the other files have strings that a specific to bzr. Should I copy  them to qbzr and modify?
<jam> bzr log --include-merges -r 0..-1 -v
<emmajane> beuno, huh. It was an email from Stephen Turnbull specifically that said the front page was too empty on sites like open atrium. But I can't find it in the archives. the list was CC-d on it, so it should be there?.
<jam> (using the long form for -n0)
<jam> emmajane: though realize that Stephen Turnbull is one person with their own opinions, and not necessarily a well paid home-page designer :)
<emmajane> https://lists.ubuntu.com/archives/bazaar/2009q3/061067.html <--- that's the message but it doesn't have the full text that I have.
<beuno> emmajane, I know what you mean. Let's see it in action, and we'll go from there
<emmajane> jam, correct. But this is a community process so that means I can't flat out ignore people. :)
<beuno> emmajane, you can
<beuno> you shouldn't
<beuno> different things  :)
<emmajane> beuno, bah. I have to at leave throw bones or give reasons. :)
<jam> design-by-committee can often be crap
<jam> especially when the committee is the masses
<jam> rather than experts
<jam> anyway
<emmajane> and it can often reveal really useful information when it's filtered back through experts.
<jam> I've stayed away from the general discussion because of this sort of thing
<jam> I have very little idea ,and I'm willing to say so
<jam> rather than assuming my quick opinion is actually correct
<beuno> emmajane, my comment was just to be prepared to cut content by a significant chunk
<emmajane> jam, but just thought you'd throw your piss into the discussion without being productive. ;)
<fjalvingh> jam: Ok, the revno with the largest increase is from 1321 to 1322, the repo grows from 415MB to 585MB.
<beuno> so when we come back with "it's too crammed", you have idea of what can go
<jam> fjalvingh: so you can do "bzr log -v -r1321..1322 --include-merges"
<fjalvingh> jam: willdo. Will take a while.
<emmajane> beuno, I've kept the word counts low and the link lists can go. That shouldn't be a problem.
<jam> emmajane: I'm being productive in saying that if you significantly disagree with someone, *your* opinion probably matters more than the rest of us
<jam> I can say what I'd like to see, but you aren't going to be putting a pony up on the home page :)
<beuno> emmajane, cool. You can jump into other pages meanwhile I think.
<emmajane> jam, awww. But I thought we were getting a new logo! :)
<jam> and as far as it goes
<jam> I'm pretty sure I would trust beuno's opinon over stephen's
<emmajane> beuno, cool.
<emmajane> jam, :)
<LarstiQ> I sure would.
<fjalvingh> jam: Ok, I did the full log on that revision. It is a merge containing several revisions (rather big). But it does not actually change much data at all and certainly does not add/remove/add/remove huge subdirectories.
<fjalvingh> I can post the log if you want. All in all this commit grew the working space by 1MB while the repo grew 170MB
<jam> fjalvingh: if you could post the log, it would probably be helpfull
<jam> helpful
<jam> in the end, having direct access would be the most helpful
<jam> but at least I could start there
<fjalvingh> jam: I'll add it to the bug report.
<jam> I'll also mention, if you have large binary files being versioned
<jam> they may show up as simply modified
<jam> and not grow by much
<jam> but they may not delta well
<jam> however, the first problem
<jam> is that you have 700k file texts, for only 7k revisions, which seems *really* *really* strange
<fjalvingh> jam: we do not have large binaries and certainly do not change them often. I wondered about those 700K text files but cannot find any way to locate them. Is there some way to dump the repository?
<SamB> fjalvingh: I think he means you have 700K different versions of files
<jam> fjalvingh: well, you can do "for f in .bzr/repository/indices/*.tix; do bzr dump-btree --raw $f; done"
<SamB> meaning that you change an average of 100 files in each revision
<jam> to at least get the list ofthem
<jam> fjalvingh: but in theory "bzr log -v" should be showing a line for each change
<jam> though that may require doing it across all revisions
<jam> to find the ones that are causing this
<fjalvingh> jam: ok; I already did a full history dump (all revisions all merges verbose) and got only about 20K lines - meaning bzr does not see the 700K texts in the log!
<fjalvingh> jam: 50K lines, sorry.
<SamB> fjalvingh: maybe those texts aren't in the history?
<fjalvingh> jam: in addition, a change that *was* very big (changing every source file in the repo) only grew the repo a small bit
<fjalvingh> SamB: Ok, I know little of bzr internals; but where can they be otherwise?
<jam> SamB: if they weren't in the history, then they shouldn't be a factor doing "bzr branch"
<jam> fjalvingh: you can have multiple histories in one repository
<jam> though a thought occurs to me
<jam> what is the size in the target repo after doing "bzr branch shared/branch standalone" ?
<jam> you tested how long it took
<jam> but I don't think we had you determine the number of "text keys" in the standalone repo
<jam> only in the source
<alex-weej> i branched bzr-fastimport and ran setup.py install but it doesn't work. bzr claims fastimport isn't a command
<fjalvingh> jam: Not sure what you mean; the results we are talking about now are in a standalone repo which was branched off the shared one?
<jam> fjalvingh: I'm trying to figure out how many text keys are present in the standalone repository
<jam> so in the repo where you are doing "pull"
<jam> and how that compares to the one you are pulling from
<jam> fjalvingh: we've got several threads going concurrently
<jam> one is about the *size* of the new repo
<jam> which is one concern
<jam> another is about the fetch performance
<jam> fetch performance seems to be primarily impacted by the fact you have 700k texts
<jam> which may or may not be related to why your repo is so big
<fjalvingh> jam: I understand, but related the fetch performance to the delta size in  the repo pulled into; assuming that the 170GB growth also meant a huge fetch.
<jam> fjalvingh: there is also a plugin you could try:
<garyvdm> luks: Do you know what going wrong here: http://paste.ubuntu.com/251025/
<jam> lp:bzr-repodetails
<garyvdm> luks: uscan worked fine.
<jam> fjalvingh: I assume you mean 170MB not Gigabyte
<jam> the plugin provides:
<jam> "bzr repository-details"
<jam> which gives some basic stats about how big various parts of the repository are
<fjalvingh> jam: yes, 170MB sorry. I will do plugin now.
<jam> revision 1310.9.10 seems a bit suspicious
<jam> it claims to be a [merge] but doesn't have any children
<jam> oh wait, I'm reading it backwards
<jam> nm
<jam> (I always log --forward)
<jam> hmm... maybe I'm right
<jam> anyway, it at least looks like you are doing a giant merge that changes lots of files
<jam> but I don't see the revisions that are actually introducing those changes
<jam> 1310.911 seems to be a similar merge, and you can see the list of 0.30.149 stuff that got merged in
<awilkins> Clippy : "Hi, it looks like you are doing a giant merge that changes lots of files. Would you like to install Visual SourceSafe?"   (sorry, couldn't resist)
<fjalvingh> awilkins: ;-)
<Colonel-Rosa> Where does bazaar store plugin information?
<Colonel-Rosa> I've deleted automirror, but bzr is still looking for it
<LarstiQ> Colonel-Rosa: 'looking for it'?
<fjalvingh> jam: I do not understand 1310.9.10?? It certainly does not look like a merge.
<Colonel-Rosa> http://codepad.org/x0wNoO88
<jam> fjalvingh: well:     revno: 1310.9.11 [merge]
<jam> means bzr thinks its a merge
<LarstiQ> Colonel-Rosa: it mentions the path it is loading from
<jam> you could try "bzr log --show-ids -r 1310.9.11"
<jam> to get more info on what it thinks is being merged
<jam> certainly the number of *changes* would usually be caused by a real merge
<jam> ah you know what
<LarstiQ> Colonel-Rosa: so either rename C:/Program Files (x86)/Bazaar/plugins/bzr-automirror, or remove it
<jam> it is probably merging trunk into your dev branch
<Colonel-Rosa> LarstiQ, but nothing is there, that's my problem
<jam> and then that is getting merged back to trunk later
<jam> and that doesn't show anything indented, because they are already in trunk
<Colonel-Rosa> bzr has a reference somewhere, there's no folders in there
<fjalvingh> jam: yes I see bzr thinks it is a merge but I cannot see why. It will be though because I added merge to the commit comment also.
<LarstiQ> Colonel-Rosa: then hava look at the `bzr plugins` and `bzr --version` output
<jam> I should have looked at the commit message
<LarstiQ> Colonel-Rosa: that should tell you where to look for plugins
<Colonel-Rosa> Yeah, I know where to put them, and it says it's installed in that path
<Colonel-Rosa> But as I said, the folder is empty
<fjalvingh> jam: I did the --show-ids but had to add -n0 --verbose; it then shows a merge from __another__ branch that was merged-with-history.
<fjalvingh> Which I cannot do anymore because it triggers another bug now
<jam> fjalvingh: if you just log that one rev, it is possible we will show you the "trunk" revisions
<jam> you might look closely at the "branch nick:" entry
<fjalvingh> jal@mabillon:~/bzr/vp-split/vp$ bzr log --show-ids -r 1310.9.11 -n0 --verbose
<fjalvingh>  
<fjalvingh> ------------------------------------------------------------
<fjalvingh> revno: 1310.9.11 [merge]
<fjalvingh> revision-id: jal@etc.to-20090717172307-qqjfa5fms7p60yxk
<fjalvingh> parent: jal@etc.to-20090717171804-sz02tktpmnalvuzi
<fjalvingh> parent: jal@etc.to-20090717171329-sp6sps0a9l4o7l8w
<fjalvingh> committer: Frits Jalvingh <jal@etc.to>
<fjalvingh> branch nick: vp
<fjalvingh> timestamp: Fri 2009-07-17 19:23:07 +0200
<fjalvingh> message:
<fjalvingh>   Merge with trunk of DomUI; this merges all of the Query Event and new QDataContext code
<LarstiQ> Colonel-Rosa: there are two possible plugin paths
<Colonel-Rosa> Yep, program files and the roaming folder in windows 7
<LarstiQ> Colonel-Rosa: ah, Windows7?
<Colonel-Rosa> Yep
<LarstiQ> possibly that introduces strange and new bugs
<LarstiQ> Colonel-Rosa: does .bzr.log help any/
<Colonel-Rosa> Might hold the answer yes, hold on
<Colonel-Rosa> http://codepad.org/Izu7RfTA
<LarstiQ> Colonel-Rosa: that does seem to imply it thinks that directory is not empty
<Colonel-Rosa> :\
<Colonel-Rosa> I even uninstalled and reinstalled it
<Colonel-Rosa> And removed those folders
<Colonel-Rosa> blergh
<LarstiQ> Colonel-Rosa: what does python -c "import os; print os.listdir('C:/Program Files (x86)/Bazaar/plugins
<LarstiQ> ')"
<LarstiQ> say?
<Colonel-Rosa> gimme a sec
<Colonel-Rosa> ['bzrtools', 'launchpad', 'netrc_credential_store', 'qbzr', 'rebase', 'svn']
<LarstiQ> ho hum
<Colonel-Rosa> Fixed it
<Colonel-Rosa> I had to empty out this folder "C:\Users\Mathew\AppData\Local\VirtualStore\Program Files (x86)\Bazaar\plugins"
<LarstiQ> Colonel-Rosa: oooh boy
<LarstiQ> Colonel-Rosa: so it is sneakily overlaying that over the regular filesystem..
<Colonel-Rosa> Yep, if you do a bzr branch in your program files folder they get written to that path instead
<LarstiQ> wonder what can do about that
<RenatoSilva> Am I connected?
<latexer> can annoyone comment on the status of the EOL content filtering? It seems that branching something over an sftp:// transport is not applying the EOL filters as specified in my rules file.
<fullermd> latexer: Likely the issue is that filtering only happens on a non-default working tree format.
<latexer> fullermd: yeah, i'm *just* noticing that.
<latexer> fullermd: it seems that when I branch, it defaults to working tree format 4.
<latexer> fullermd: how do I control the chosen working tree format?
<latexer> hrm... /me guesses that creating a repository with a new enough format *beforehand* might force it.
 * latexer tries.
<latexer> hrm.. it already was *in* a repository created with a newer format.
<latexer> (note, this is using bzr 1.16.1 on windows)
<jam> latexer: for source repositories with no working trees, you have to use --2a
<jam> it is an open bug
<jam> I don't remember the number offhand
<jam> I believe the person reporting it said they wrote a plugin to set the default WT format
<latexer> jam: ok, so if I'm pushing a branch to a server, and then branching from that remote location, that remote server must have a repository for the branch in the --2a format?
<latexer> right now the server has an older bzr release, so I had figured (wrongly?) that I could simply use the sftp:// transport and not have to have anything special on the server.
<latexer> (i suppose I could create the *repository* locally as well and sftp the whole thing over...)
<jam> latexer: so you can update the local client to change the default WT format
<jam> or yes, have the remote format in a --2a format
<latexer> jam: ok, i'll dig a bit for that plugin, and try both approaches.
<latexer> jam: thanks.
<jam> if you are using sftp:// then you don't even need bzr installed remotely
<jam> though performance is generally much worse
<latexer> jam: I know, this is a legacy system that previously stored branches used only on linux, etc.
<latexer> jam: only now investigating bzr for a windows project, and wanted to do EOL stuff "right"
<lifeless> moin
<beuno> hiya lifeless
<fullermd> latexer: You can use the 1.14 format, that's just a WT change vs. 1.9.  2a changes a lot more.
<latexer> fullermd: ok, so just ensuring that the remote repository is at least 1.14 format should do it?
<latexer> fullermd: I think as I had it, there was no actual repository for the remote push/pull location.
<latexer> I just tested, and ensuring 2a on the remote side seemed to do it.
<latexer> will try with 1.14 on the remote as well.
<fullermd> It may not, because of details of what happens where.
<fullermd> You could use 1.14 locally with 1.9 (or pack-0.92 for that matter) remotely with no trouble; doing that with 2a locally wouldn't work unless the remote were rich-root.
<fullermd> Of course, if you're in a position to just use 2a everywhere, that's the way forward.
<latexer> fullermd: any additional risk by using 2a? Less tested format, etc?
<jam> fullermd: 1.14 == 1.9 without a working tree
<jam> with the main problem that "bzr branch remote" will create 1.9 locally, *not* 1.14
 * fullermd nods at jam.
<jam> latexer: it is expected to become the default format in the next release
<jam> well, 1.18+1
<jam> (likely to be called 2.0 :)
<fullermd> Well, it's naturally less tested, since it's newer.  But going forward it's likely to be the standard (and if it's not, a descendent of it is), so...
<latexer> fair enough.
<fullermd> There may still be some bumpy bits with it.  I think the 'send' fix for it isn't in a release yet, frex.
<fullermd> But that smoothes as we speak.
<fullermd> The main risk you take is not having compatibility with people using older versions of bzr.
<latexer> ok, creating a standalone branch (no parent repo) off a remote 1.14 repo results in a WT 4 (bad). Doing the same off a remote 2a repo results in a WT format 6 (good)
<fullermd> But that may well not be a concern at all in your place, so...
<fullermd> Yah, you'd have to....    uh...
<latexer> i'm not too concerned about older bzr versions, since it's a small team, all installing bzr fresh into windows VMs.
<fullermd> Well, crap, I thought branch had a --format.
<latexer> however, if I do the same branching into existing repos on the client side, what happens?
 * latexer performs that test.
<jam> fullermd: it is in 1.18rc1 which is released-ish as of today
<fullermd> No difference, since the repo format doesn't affect the WT format.
<jam> (windows installers aren't built because I'm waiting on bzrtools 1.18, etc)
<latexer> fullermd: correct.
<latexer> ok, so really, the logical choice here is: go with 2a format everywhere for this new work requiring windows EOL stuff to jive.
<fullermd> It's one of the big strengths of the bzr gestalt, except when it's one of the big annoyances   :)
<latexer> heh.
<poolie> hi jam
<jam> hi poolie
<poolie> want to chat?
<jam> yep
<jam> skype should work fine
<poolie> k
<lifeless> hi poolie
<jam> hi lifeless
<lifeless> hi jam
<jam> do we know if abentley is on vacation or something?
<lifeless> what do you think the priority for 'commit doesn't honour stacking invariants' should be vis-a-vis 2.0
<jam> I haven't seen him around, and he didn't release bzrtools 1.18
<lifeless> check the staff calendar for that question
<jam> lifeless: looks like he is gone until Tuesday *next week* :(
<SamB> lifeless: what are stacking invariants for?
 * SamB wonders if it is safe to change the owner of a launchpad branch mid-push
<lifeless> SamB: data integrity
<poolie> SamB: no
<latexer> fullermd, jam: thanks for the help, standardizing on 2a format has us moving forward again finally.
<SamB> poolie: as I discovered
<SamB> I was wondering that after I already did it
<spiv> SamB: no, the insert_stream_1.18 verb won't be in 1.18; I'll be renaming it to 1.19 before merging I guess (although we hope the next release is 2.0!)
<SamB> spiv: that's not a basis for renaming it, though!
<SamB> the release being 2.0 instead of 1.19, I mean
<fullermd> Well, you could compromise and call it _2.19.  Then everybody would be equally happy   :p
<SamB> fullermd: that's even dumber then "let's compromise and call it ISO"
<SamB> s/then/than/
<fullermd> I aim to excel.
#bzr 2009-08-11
<spiv> SamB: well, even if the release is 2.0, I'm happy for the verb to be 1.19.
<spiv> I don't want the name of the verb to actually mislead, though :)
<SamB> spiv: that's what I'm saying. there's no sense in bumping it from a nonexistant release ;-)
<SamB> indeed
<spiv> (And I'm happy to pay the fairly minimal cost to bump it when it misses the intended release.)
<SamB> you don't want it named for a release before/after the one it debuts in ;-)
 * SamB finds 2a pretty slow for just about anything involving conversion at the moment, actually ...
<SamB> ... though it's extremely pathetic for it to be using more downstream than upstream during a push, which I assume your branch eliminates
<SamB> hard for me to test this, though :-(
<lifeless> SamB: over the network conversions?
<SamB> lifeless: any!
<SamB> over network, local ...
<SamB> if the 2a repository isn't local, that makes it worse, certainly
<lifeless> local should be ok
<poolie> hullo again lifeless
<poolie> did i see you were working on bug 375013?
<ubottu> Launchpad bug 375013 in bzr "Commit doesn't honor stacking invariants" [Critical,Triaged] https://launchpad.net/bugs/375013
<igc> morning
<AfC> Classic. Write a long reply to a bzr mailing list thread, only to realize in the end that if I'm going to pontificate like this, I'd better do it in a blog post instead. Bother.
<AfC> "Save Draft" think about again later
<poolie> which thread, just for curiousity?
<AfC> poolie: GPL licencing
<AfC> poolie: nothing to do with bzr
<AfC> I just liked John's "moral" comment and wanted to add something
<AfC> [battery, back in 60]
<poolie> jam, i think explaining the gpl is good but it's not appropriate to be so flippant in the context of a business inquiry
<lifeless> poolie: yes
<poolie> yes you agree?
<lifeless> poolie: I'm thinking of just untagging it from 2.0
<poolie> oh ok
<lifeless> poolie: [bug 375013?]
<ubottu> Launchpad bug 375013 in bzr "Commit doesn't honor stacking invariants" [Critical,Triaged] https://launchpad.net/bugs/375013
<poolie> right
<lifeless> I heavyweight checkouts will work as they push via streams
<lifeless> lightweight checkouts over the network are a bad idea anyway
<poolie> at least as they currently exist
<lifeless> lightweight checkouts of stacked branches would seem to be a rare case at the best of times
<lifeless> well, indeed.
<poolie> i think we should make them work in future
<poolie> it's a reasonable thing to want
<lifeless> fixing commit to use streams would make them suck less hard
<lifeless> sure
<poolie> it may require tweaking the definitions a bit
<lifeless> at the moment, working content local, all history remote, performs badly
<lifeless> so even with the bug fixed, its not a recommended way to deploy/use bzr today.
<lifeless> which is why I'm thinking of downgrading it to high, or even leaving it critical but untargeting from 2.0.
<lifeless> what do you think?
<poolie> i think it might be right
<lifeless> [and it's not 2a specific, it fails with 1.9 if you have content in the tree]
<poolie> would it be possible to detect the problem cases and just fail cleanly?
<poolie> eg to ban committing in lightweight checkouts of a remote repository?
<poolie> or remote stacked repository
<lifeless> remote isn't part of the equation
<lifeless> we could put a check in commit.py to say if self.branch.repository._fallback_repositories: bail()
<poolie> in general i'm more comfortable downgrading a bug if it causes a traceback rather than a problem in what's recorded
<lifeless> yah
<poolie> want to add that check, including a mention of the bug number near it, and then downgrade/untarget?
<poolie> emmajane: hi, still around?
<emmajane> ping
<emmajane> just eating a cow. or myabe it's a steer. definitely it's beef though.
<lifeless> poolie: yes
<poolie> jam, are you back at all?
<jam> poolie: I'm mostly just heading upstairs, I may be back in another hour or so
<poolie> np
<poolie> i was just thinking about your mail about 2.0
<jam> poolie: about the release schedule, etc?
<jam> I'd be happy to chat with you about that later
<poolie> yes, and whether this should be 2.0b1
<poolie> ok
<poolie> just ping me
<spiv> poolie: ping, mind if I call now?
<poolie> sure
<emmajane> igc, ping. I'll be up for a little bit and thought I'd check to see if you were around?
<igc> hi emmajane
<emmajane> hey :)
<emmajane> Have you had a chance to play with Sphinx any more?
<igc> emmajane: a little
 * emmajane nods
<igc> emmajane: you have pretty fine control over the title page for example
<emmajane> You can apply style sheets to sphinx pages though.
<igc> yes
<emmajane> I can't remember if you've got the source for what you sent me as a branch?
<emmajane> I htink I just remember seeing output?
<igc> emmajane: if it helps, have a look at https://launchpad.net/bzr-alldocs
<emmajane> thanks :)
<igc> emmajane: grab the trunk and see how it hangs together
<igc> the interesting files are en/_templates/index.html and en/_templates/layout.html
<emmajane> excellent.
<igc> emmajane: I'm just building the 1.18rc1 docs as we speak and tweaking that site to reference them
<emmajane> awesome :)
<emmajane> I love automatic builds of documentation.
<emmajane> I recognize that I need better hobbies, but it's right up there with magic tricks and ponies for me.
<igc> emmajane: well the alldocs stuff isn't automated *enough* yet but that can come post 2.0
 * emmajane nods
<igc> emmajane: e.g. still one site per langu rather than something smarter
 * emmajane nods
<AfC> emmajane: we do automatic (ie, live) _screenshots_ for our documentation. http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/TreeView.html :)
<emmajane> igc, do you have people working on translations, or is it mostly beuno jsut working on one language?
<emmajane> \o/ Sovereigns of Canada. :)
<igc> emmajane: no, several people working on different languages
<emmajane> igc, cool
<igc> emmajane: the alldocs website has been translated to French, Japanese and Russian
<emmajane> very nice!
<igc> emmajane: and it's messy right now - if it were done via LP translations, I'm sure we'd get many more
 * emmajane grumbles. the ubuntu package of bzr is old.
<emmajane> igc, tough call. Docs are hard to translate. LP doesn't necessarily make it easier (we deal with this for the ubuntu docs team as well)
<emmajane> LP is optimized for string translation.
<emmajane> the User Guide != strings. :)
<igc> poolie: fwiw, the NEWS in bzr.dev has 2 'In development' headings and no 1.18 heading :-(
<AfC> lifeless: c.f. our conversation at dinner a few weeks ago, see emmajane's comment above.
<igc> emmajane: right, but the wrapper site is really just a few strings. see http://doc.bazaar-vcs.org/en/
<AfC> lifeless: and yes, I realize we're working on the problem.
<emmajane> igc, you're right. that's not bad.
<igc> emmajane: but wrapper site aside, I know at least one person is actively working on translating the bzr docs to Japanese
 * emmajane taps her keyboard and tries to decide the most elegant way of upgrading and ignoring ubuntu.
<AfC> that's easy. Run Gentoo.
 * AfC ducks
<emmajane> HAHAHAHA
<emmajane> you're HilARIOUS. :)
<emmajane> The gentoo cow is the best part about gentoo. :)
<igc> emmajane: the cool thing is, I still haven't announced the alldocs project yet so having those translations being contributed already is awesome
<emmajane> igc, that is cool!!
<lifeless> AfC: which specific comment?
<AfC> emmajane: [but that also explains why I still don't run Ubuntu, and is the gist of my quick aside to Robert a moment ago. As I said, the packaging issue is being addressed. I hope it works out, because then maybe I could run a Debian distro again]
<AfC> lifeless: "grumbles. the ubuntu package of bzr is old."
<emmajane> AfC, APT is made of win.
<emmajane> Gentoo is made of pain.
<AfC> emmajane: [but this is otherwise off topic for #bzr, and I'm not a distro zealot]
<emmajane> lifeless, bzr 1.13.1 on python 2.6.2 (linux2) makes me sad.
<lifeless> emmajane: what release?
<emmajane> lifeless, jaunty. up to date.
<AfC> wow
<lifeless> sounds about right
<lifeless> it was current when released
<lifeless> AfC: old releases of distros stagnating isnt really being worked on; rather we're aiming to have point releases for them, for critical fixes etc
<lifeless> so in this case, emmajane might be seeing 1.13.2 at this point.
<lifeless> OTOH we already do point releases when we think its important enough, so I'm not all that sure that that will change at all.
<emmajane> 2.0 will get packaged though, right?
<lifeless> yes
<lifeless> but getting it into jaunty is about as hard as getting 1.17 into jaunty
<emmajane> I only care because igc's docs are in 2a for which I need 1.16+
<lifeless> which is to say, very.
<lifeless> emmajane: use the PPA :)
<emmajane> lifeless, don't you know people who can do that? ;)
<lifeless> emmajane: yes. The problem is that the delta is huge - 10's of thousands of lines, and SRU policy is to essentially audit that delta.
<lifeless> <pain>
<emmajane> cry
<lifeless> backports have no such policy
<lifeless> and neither do PPA's
 * emmajane nods
<lifeless> thus the answer to 'I /need/ a newer bzr' is - use the PPA.
<lifeless> the major thing that is going to help here, isn't the new release schedule
<AfC> lifeless: without any emotional charge whatsoever, and I do understand the engineering decisions that led the situation being the way it is (after all, inherited from Debian),
<lifeless> its doing less formats.
<AfC> lifeless: I really suggest there is something wrong when Canonical Ltd can't tell it's Linux distro project to backport and include another Canonical project's current version. But you and poolie have heard that enough from me, so I really need to stop bothering you about it.
<emmajane> Yes. Because distros and packages have taught us that progress and change are both bad. :)
<lifeless> so, poolie and I sat down with james_w one time, he was offering to walk bzr through a SRU
<AfC> emmajane: That is also a Debian inheritance.
<lifeless> he spoke to the RM, who vets SRU's
<lifeless> AfC: I think emmajane was being sarcastic :)
<emmajane> SRU is a TLA for "pain"?
<lifeless> I have to say though that I think the SRU (stable release policy) is good, and something many customers depend on.
<emmajane> ah, right.
<lifeless> in our case, we *have* regressions vs 1.13.1 at the moment
<AfC> lifeless: yeah, well, it's the reason (and pretty much the only one) we migrated away from Debian in 2002, and so I'm very alert for it changing, because I'd love to go back [or, forward, if you will, to Ubuntu]
<igc> emmajane: once you get 1.16 or later, grab https://edge.launchpad.net/~ian-clatworthy/+junk/bzr-explorer-docs as well
<emmajane> igc, :)
<lifeless> there are several bugs in the bug database where users are being hurt hugely by changes we've made
<lifeless> corner cases, to be sure
<lifeless> but thats what the SRU aims to prevent.
<lifeless> I think it does a decent job.
<AfC> lifeless: frankly, "we [know we] *have* regressions vs" is actually what's important. That's very responsible, and very cool of you. Most projects aren't that mature.
<lifeless> thanks :)
<AfC> Hm. I need to stop writing about the weather and write about this topic instead.
<AfC> lifeless: (the seed being this, then going to "... but the problem is what happens when customers running a stable release don't upgrade to the next stable release". But again, off topic)
<lifeless> finish your small business accounting package. Please.
<poolie> igc, the 1.18 branch isn't merged back to bzr.dev yet, when we do that it will fix the headings
<AfC> lifeless: got to finish my word processor first, but I'm actually starting to get excited about working on the accounts package again. I think I've figured out a way to make progress.
<emmajane> AfC, you're writing a word processor?!
<lifeless> poolie: is there anything delaying that merge-back? I'm about to be blocked on  it..
<AfC> [and yes, this should be followed by a "what the fuck are you doing writing a word processor"?]
<emmajane> LOL
<emmajane> clearly you were thinking about writing a book but decided that docbook and OOo sucked so much that you'd just write your own word processor first?
<emmajane> Not that I'd know anything about that :)
<lifeless> emmajane: yak shaving FTW!
<AfC> emmajane: s/docbook/LaTeX/, and yes
<emmajane> LOL
<AfC> yummy yummy yak
<poolie> afc, so "why can't Canonical tell X to do Y" has many interesting threads
<emmajane> there's nothing like an author trying to avoid writing a chapter. :)
<poolie> one being that people may object, rightly or wrongly, to canonical making Ubuntu do what Canonical wants
<AfC> poolie: I know. I'm approaching this as a management consultant, not a techie.
<poolie> the short answer is that i think we should meet in the middle
<emmajane> (afc: http://www.amazon.com/Front-End-Drupal-Designing-Developers/dp/0137136692 is me)
<AfC> poolie: (and I don't pretend to know all the factors, so this *is* interesting to me, even if we're all tired of talking about it)
<poolie> if we make bugfix-only updates they should go through SRU without needing a big hammer
<poolie> and if a rubber mallet is needed, canoncial will apply that with discretion
<AfC> emmajane: very nice
<lifeless> poolie: I suspect we'll need further process changes roughly orthogonal to the release schedule changes to help cases like emmajane's.
<AfC> poolie: the fundamental problem is that this isn't Cisco IOS. It's open source, and for essentially every open source project with the possible exceptions of (eg) Linux 2.4 vs 2.6 and (once upon a time) Apache 1.3 vs 2.0
<SamB> docbook is a word processor?
<AfC> SamB: no, XML documentation fomat
<AfC> SamB, emmajane: wait one
 * emmajane finally gets the PPA installed.
<SamB> AfC: you forgot!
<SamB> it's also an SGML documentation format
<emmajane> SamB, that's old skool.
<AfC> poolie: ... and for open source (and commercial software too, but no one admits it), the bug fixes are in the next version, locked up in new features. There's no difference; the new features are the bug fixes; the bug fixes are new features.
<AfC> poolie: (this is one of my keynote themes)
<SamB> though at this point I guess you should probably use XML even if you do want to use it with DSSSL sheets
<igc> hi SamB
<poolie> lifeless: if you mean "but i don't want just bugfixes i want the new black" then yes, that needs - either good ppas or backports or whatever
<emmajane> sometimes I wish error messages had LESS information.
<poolie> afc, i think in some ways open source is just recognizing reality there
<emmajane> Tracebacks scare me.
<poolie> emmajane: yeah that's an interesting question too
<emmajane> +unexpected tracebacks
<igc> SamB: I've put some work into fast-import in recent days to make it more reliable coming up to the 2.0 release
<poolie> possibly we should hide them unless the user actually wants to report a bug
<poolie> afc, at the end of the road is something like tom lord's position that everyone should just maintain their own branch and cherrypick the features they want or need
<SamB> poolie: I loves reporting bugs if I have a clue what bugs I'm reporting
<AfC> poolie: so (and now that it's come up, this is essentially be feedback for the 6-month release thread), I am very wary of such a cycle; for all it's benefits I would suggest that the bzr hacker community will have a hard time mustering much enthusiasm to do anything on 2.stable.x instead of bzr.dev
<poolie> you may be right
<emmajane> From a user perspective it looked like this: bzr: ERROR: exceptions.KeyError: 'Bazaar repository format 2a (needs bzr 1.16 or later)\n' (the slash n is awesome) and the lkjadjkldjlksfadjlksdfljk;asadfjl;sadfjl;sadfljk; for a long time and the error again in English.
<poolie> i think it's worth a try though
<poolie> !!
<igc> SamB: after all, 2.0 will undoubtedly mean more people trying to import into bzr
<poolie> that's a bit poor
<emmajane> That's what tracebacks look like to me. :)
<SamB> igc: mmm hmm
<lifeless> poolie: yes, thats what I mean (and my hunch is thats what most folk are asking for)
<poolie> emmajane: if that's what i think it is should be saying 'unrecognized format' and no traceback
<igc> SamB: so my priorities for fast-import are:
<AfC> poolie: "recognizing reality" yes, exactly. But Debian-esque release freezing and upstream evolving reality just don't seem to jive. I think that's the fundamental problem in the open source sphere currently.
<poolie> i agree they're gibberish
<SamB> igc: you want me to try getting that tarball importer working?
<igc> 1. make importing reliable and bug free
<igc> 2. make exporting from other tools really easy
<lifeless> SamB: are you on Mac OSX ?
<AfC> poolie and lifeless: anyway, sorry to get into that.
<emmajane> poolie, It's plausible that someone tried to help me at some point and turned on tracebacks by default.
<SamB> lifeless: no
<SamB> why?
<AfC> poolie and lifeless: but always a pleasure to talk with (and learn from) you gents.
<igc> 3. fast-export bugs
<lifeless> there is a bug in the python tarball module in some versions of the python Apple ship
<poolie> afc, i think users will never agree 100% on what's worthwhile fixes and what's unwanted churn
<lifeless> they shipped a beta, if I remember the details correctly.
<poolie> anyhow...
<SamB> lifeless: hmm ... iirc, the script in question is written in perl
<igc> SamB: any help you can offer on making import highly reliable would be great
<AfC> poolie: there's also the "corporate sysadmin" vs "developer" vs "end user". All three have radically different needs.
<fullermd> SamB: Pfft.  SGML roolz   :p
<AfC> anyhow
<igc> SamB: that 'tag from ref' bug or whatever it was sounds important if git-fast-export is now producing that more reguarly
<SamB> fullermd: well, I don't know if they've been updating the SGML DTDs and those are kind of important if you're going to use abbreviated forms ...
<igc> SamB: but in general, any help on bug fixing or adding tests is ultra-welcome
<AfC> SamB, emmajane: I'm happy to talk to you about what I'm working on, I _have_ done up a very preliminary web page, but it's not at "I can download it and play with it myself stage" yet so I'm reluctant to talk it up too much.
<fullermd> SamB: Well, I don't either; I don't use Docbook.  I was just making a general trol^Wcomment  ;p
<SamB> igc: actually, that was generated by a slightly-altered form of the tarball import script from git's contrib tree
<igc> SamB: I'll like to release bzr-fastimport 0.9 next Monday say ...
<AfC> SamB, emmajane: but this isn't the place to talk about it further, so after a couple URLs if you want to chat with me about it (please do!) -> #java-gnome on irc.gimp.net
<lifeless> SamB: you know that bzr can import from tarballs itself?
<igc> SamB: to give some time to get it packaged into karmic, etc.
<SamB> lifeless: it's nice to just set it loose on a bunch of 'em, though ...
<AfC> SamB, emmajane: general motivations http://blogs.operationaldynamics.com/andrew/#one-year-and-more and what isn't linked to from there because I'm not promoting it anytime soon is http://research.operationaldynamics.com/projects/quill/
<poolie> afc, that's nice
<poolie> i've always thought the thing about 'a man's reach exceed his grasp' is especially relevant to software or similar creations
<SamB> lifeless: oh, also this fast-import thing gets the datestamps right on the commits, I think ...
<SamB> that is, it takes them from the tarballs
<lifeless> SamB: thats a fairly esoteric definition of 'right' ;)
<SamB> yeah ;-P
<AfC> poolie: it's been a fascinating couple of weeks, because I met a poet who understands (well, almost) what open source is. Really great discussions.
<SamB> igc: so ... if I were going to send you a modified version of a git contrib/ script to include, where should I put it?
<SamB> oh, exporters
<SamB> :-)
<emmajane> poolie, where would the traceback stuff be turned off/on? I don't see anything in bazaar.conf
<SamB> hmm ... is there some easy way to import a single file's history from another branch?
<SamB> a completely unrelated branch?
<poolie> emmajane: ah i might have been talking about what should happen rather than what does happen
<poolie> classic major Australian isp service announcement a while ago "no email should have been lost during the upgrade"
<poolie> yeah :)
<emmajane> poolie, ahhhh
<poolie> emmajane: we could change trace.py to not show them and only log them
<emmajane> poolie, that'd be lovely.
<poolie> there's a flag that does the opposite, -Derror, always shows them
<poolie> want to send an rfc mail?
<emmajane> sure.
<SamB> poolie: it should be easy to configure it to behave like now, I think
<SamB> I prefer not to have to dig too deep for my tracebacks
<poolie> it'd be a small change to trace.py
<SamB> at least, when it's a bug-type traceback
<poolie> oh i see
<emmajane> "the version you want is newer than the version you're using" isn't a bug IMO.
<poolie> we could add another flag or somethnig then you could set in bazaar.conf
 * emmajane nods. Flags work.
<lifeless> we should make unknown formats not traceback, if they are.
<SamB> yeah, that's not a bug per-se
<lifeless> we can render it reasonably well
<SamB> just an absent feature
<emmajane> I'll paste the full message with the RFC.
<emmajane> there are kwargs involved.
<SamB> so ... how would I import a file *with* it's entire history from a branch ... will that thing in that mail I saw recently do it?
<fullermd> Files don't have history; history has files.
<SamB> fullermd: maybe that's true in the soviet union ;-P
<fullermd> It's also true in bzr   :p
<fullermd> And mergitatone, for that matter...
<SamB> well, *I* was speaking english
<SamB> nevermind that the file in question is actually under git ;-P
<emmajane> poolie, RFC sent. I'm not sure that it quite captures things correctly, so feel free to tell me what my opinion is supposed to be if I got it wrong. :)
<SamB> lol
 * emmajane scrolls up and notes the references to oppressive regimes and figures it all fits quite nicely together. :)
<lifeless> poolie: is there a list of failing testids with your plugin?
<poolie> nup, not up to date
<poolie> i can attach it to that bug
<lifeless> please
<poolie> many are now fixed so i'll re-run it
<lifeless> even a larger list would be helpful - massively reduces the window to look at
<poolie> i'm tempted to do subunit-sort first, it woul rock for that kind of thing
<poolie> but i won't
<lifeless> :)
<poolie> merge back to trunk sent
<igc> poolie: new docs built and uploaded - email sent to list
 * igc lunch
<poolie> ok
<poolie> igc my merge will incidentally fix news
 * emmajane shuts down for the night.
<jam> hey poolie, still working?
<jam> night emmajane
<poolie> i am
<poolie> struggling to keep awake at 1:23pm :)
<poolie> more seriously i would like some lunch soon....
<poolie> i was going to work this afternoon but away from email and irc
<Adys> I thought bzr pack was supposed to compress/garbage-collect a repository? After running it on an old one, repo size jumps from 41mb to 54mb
<lifeless> Adys: it consolidates the storage to reduce roundtrips when accessing it over the VFS
<poolie> Adys: there are probably some pack files in obsolete_packs that are retained in case someone's still using them
<poolie> but that will be removed soon
<lifeless> Adys: basically you never need to run it
<poolie> and what he said
<poolie> jam, did you want to talk?
<Adys> um, does that mean I should revert back to the old one or it doesnt matter?
<poolie> it doesn't matter
<lifeless> Adys: its not harmful
<Adys> fair enough
<lifeless> Adys: but its not usually helpful either - bzr will pack behind the scenes when it needs to.
<poolie> see bug 304320 and bug 373539
<ubottu> Launchpad bug 304320 in bzr "bzr pack should (optionally?) delete obsolete packs" [High,Confirmed] https://launchpad.net/bugs/304320
<ubottu> Launchpad bug 373539 in bzr "Add a `clean` command that deletes obsolete packs and uploads" [Medium,Confirmed] https://launchpad.net/bugs/373539
<poolie> i agree it's surprising/confusing
<jam> poolie: I'm happy to chat a bit if you want
<poolie> i was going to ask you about the 1.18rc1 thing
<jam> but if you prefer to head off, that's fine
<poolie> i replied
<poolie> at any rate i don't plan to do anything more on it before i fly so it's not urgent
<poolie> unless you really want to talk
<jam> poolie: no, I just read your reply, and it fits pretty well my understanding
<jam> as far as it goes, I don't really care if we just do a 1.18 and make the big change at 2.0
<lifeless> I'd prefer to make the change at 2.0
<jam> it feels a bit more straightforward, to be honest
<poolie> ok
<lifeless> avoids problems with debian version numbers around the version number
<lifeless> not to mention giving packagers warning
<poolie> therefore we'll do a 1.18 in a week, and then a 2.0beta1 following that?
<poolie> after the default changes
<jam> poolie: sounds ~ right, though a bit of a stepped up schedule when the next release would hit
<jam> are you thinking to get a beta out before 2.0-final?
<poolie> it might be good
<poolie> i think a bit of extra exposure after we change the format could be good
<poolie> even if we don't think every change is finished
<jam> I'll think about it
<jam> I was hoping to see 2.0 be the next release
<poolie> ok
<poolie> me too
<poolie> i wouldn't have a one-month beta
<jam> but we'll have to see how things are shaping up
<poolie> maybe we can just do an rc, or a couple of rcs, and then see
<poolie> let's see when things land
<poolie> biab
<SamB> poolie: 2.0 had better have spiv's branch landed, that's all I can say!
<jam> SamB: stop working cross format, and it won't matter
<jam> if you want 2a, use it
<jam> :)
<SamB> jam: so ... it doesn't use VFS calls over the hpss if you're using just 2a?
<jam> SamB: yep
<jam> well, no more than the current one does, which is only edge cases IIRC
<SamB> but it seems kind of dumb to have it using 95% VFS calls over the hpss like it is ...
<jam> SamB: so I optimize the cross-format conversion to be fast when you have 2 local branches or "bzr upgrade"
<jam> because cross-format over long distances didn't seem that important
<SamB> jam: that's not very fast either!
<jam> if you want to upgrade, then you upgrade
<jam> SamB: it could be a *lot* slower
<SamB> jam: so?
<jam> the primary issue is getting the data out of the old format
<SamB> I should steal some of your RAM
<jam> about 60+% of the time
<SamB> jam: that's not saying much
<SamB> for me, it's at roughly â anyway ...
<SamB> for bzr.dev-sized repos
<SamB> jam: also, you guys haven't upgraded lp:bzr yet
<igc> poolie: I think the bzr-windows team has got off to a good start - we have 22 members now
<igc> poolie: I'd like to do the same for os x
<igc> poolie: do you agree? if so, bzr-mac or bzr-os-x as the name?
<igc> poolie: once again, topic #1 will be packaging/installers, following a similar RFI/call-for-volunteers process as the Windows team
<bialix> igc: I don't quite understand your mail about windows installer changes
<igc> bialix: which bit?
<bialix> maybe I need some coffee first
<bialix> btw, Inno can't build msi, but it definitely build one exe
<bialix> item #2 is unclear for me, WDYM?
<bialix> and you talk about consensus. Does there already consensus reached?
<igc> bialix: Well, if the consensus is that msi is what we want, then we need to look at how we build that
<igc> bialix: there was a fair amount I think, e.g. ...
<bialix> msi is long standing wish with lowest priority as I can say
<igc> one installer is promoted; easy-install for the simple command-line case
<bialix> igc: btw qbzr 0.13 is out, it just lacks announce mail
<igc> bialix: also Explorer & tbzr both in with the latter off by default
<igc> bialix: oh, ok - I'll roll out a new explorer release tonight
<bialix> igc: it seems sidnei want to throw away bzr.exe, but awilkins want it stay.What is consensus here?
<igc> bialix: we keep it I think
<bialix> igc: TBZR today is barely usable buggy alpha software
<bialix> it's shame that nobody works on it, but Mark has put very high bar it seems
<bialix> so I think wil be better to remove it from installer entirely for some time
<bialix> is it too extreme?
<igc> bialix: maybe not. post to bzr-window asking if anyone prefers it to explorer? If no-one says yes, then perhaps we could leave it out altogether
<bialix> well Naoki seems to trying maintain it
<lifeless> it was asked for /a lot/ when it didn't exist
<lifeless> and folk seem to be using it
<igc> bialix: otoh, maybe plenty of silent users are relying on it being there
<igc> bialix: I'd be hestitant to remove it given it's part of our current default install
<bialix> lifeless: in the past there was no alternative. today we have bzr-explorer
<bialix> igc: perhaps I;ve lost the track of user needs, I'm happy with my custom installer, so I think from my egoistical POV
<poolie> bialix: i think at least making it optional would be a good step
<poolie> as i wrote on the list
<poolie> igc, +1 to a mac os list
<bialix> igc: if I'l have some free time at lunch time I'll try to consolidate the feedback
<poolie> the metric i'm really watching is whether more people post
<poolie> but we'll see
<bialix> poolie: it's already optional
<poolie> i think being able to build an installer using only the free compiler would be good
<poolie> oh one more random thought here - i wonder if we can run win32 python under wine well enough to test?
<bialix> I have no experience with COM programming, so I have no idea is mingw could compile this stuff
<bialix> hg guys seems to run windows tests on wine with good success
<bialix> run CLI bzr should be no problem for wine
<bialix> but somebody should just try
<igc> poolie: so preferred list name? bzr-mac or bzr-os-x or bzr-mac-os-x
<poolie> the first is shorter :)
<igc> poolie: I probably prefer it
<lifeless> poolie: bug 375013 fix up for review.
<ubottu> Launchpad bug 375013 in bzr "lightweight checkout commit to a stacked branch does not work" [Critical,Triaged] https://launchpad.net/bugs/375013
<vila> hi all
<igc> hi vila
<lifeless> vila: I wonder if I could get a review from you on my merge for bug-375013
<vila> lifeless: hmm, given the subject, I'm afraid I can't do that dave, but I'lll have a look
<vila> lifeless: merge request URL ?
<lifeless> c.l.n/~lifeless/bzr/bug-375013
<lifeless> is the branch
<lifeless> clickyclicky from there
<vila> got it
<vila> lifeless: err is the 2.0.0 stuff from your or another mad case ?
<lifeless> 2.0.0 ?
<vila> https://code.edge.launchpad.net/~lifeless/bzr/bug-375013/+merge/9967
<vila> bzr and bzrlib/__init__.py
<lifeless> ignore those
<lifeless> its trunk being old
<vila> lifeless: so, if I read that right, this is a one-line fix (in get_commit_builder) and then fixing failing tests ?
<lifeless> yes
<lifeless> and a NEWS entry about it.
<vila> lifeless: but it seems you change some tests to use a checkout instead of a branch ? (I may need to read more deeply, just a quick confirmation)
<lifeless> I got better at the fix later on
<vila> lifeless: right the NEWS entry is important
<lifeless> but they are == in terms of speed so didn't bother to make them all the same
<vila> the feeling I have is that you have hijacked some tests instead of making new ones, am I wrong ?
<lifeless> I think you're wrong
<lifeless> I don't think I changed the intent of any test.
<lifeless> some tests were doing things that they didn't claim to test, so I pruned them back to what they claimed.
<vila> ha, good, not obvious at first read, hence the question
<lifeless> I'm off for a while. ciao.
<vila> lifeless: meh, don't you want an approve ?
<LarstiQ> spm: how did the pqm upgrade go?
<bialix> igc: bzr-explorer 0.6 small issue with bzr.exe
<igc> bialix: namely?
<bialix> About dialog fails with import error: no module named platform
<bialix> bzr.exe lacks std platform module
<igc> bialix: damn I hate how bzr.exe doesn't have all the python libs :-(
<bialix> really? hate?
<bialix> I can package it into installer for bzr-explorer if you wish
<igc> bialix: ok, I guess we can catch the import error in explorer and not report the python version?
<bialix> or into qbzr installer
<igc> into the bzr-explorer installer sounds good to me
<bialix> why not report?
<bialix> sys.version is not good for you?
<igc> bialix: it will do. I was copying some code from a book sample and I just did as it did
<bialix> I can look at the code and tweak it (not yet)
<igc> bialix: please
<bialix> should I push tag then or you prefer 0.6.1
<igc> bialix: 0.6.1
<bialix> ok, so I'll fix the issue and make new release with installer for 0.6.1 only
<bialix> and you can announce it tomorrow
<bialix> ok?
<igc> bialix: yes
<bialix> garyvdm about to announce qbzr 0.13 right now
<bialix> igc: actually I've thought you want to report OS version, like "Windows XP SP3"
<bialix> platform module can provide this sort of info
<bialix> python version available via sys
<igc> bialix: I think that would be good but not for 0.6
<bialix> I'm just trying to understand your intent re platform module
<bialix> I have no chance to look at code yet
 * bialix pulls and looks
<bialix> igc: post 0.6.x I'd like to cleanup tests
<bialix> there is ./tests and ./lib/tests
<bialix> we have to merge them into one
<igc> bialix: go for it. Just ./tests is the best direction I think
<bialix> why not ./lib/tests ?
<bialix> what's the reason to keep in the root of the tree?
<igc> bialix: it just feels more symmetric to me: data, doc, lib, tests, etc,
<igc> bialix: "lib" is effectively "src"
<bialix> ok
<bialix> qbzr question: one man building qbzr .deb for Debian Lenny and Etch
<bialix> where he can publish them?
<bialix> LP PPA can be used?
 * igc dinnner
<bialix> igc: fix for about dialog has pushed
<bialix> LarstiQ, jelmer: hi
<LarstiQ> hey bialix
<bialix> LarstiQ: are you debian dev/maintainer?
<garyvdm> bialix: Just updated http://groups.google.com/group/qbzr/web/screenshots
<bialix> very nice, thanks
<bialix> AfC has mentioned they have auto screenshot updater for the docs in java-gnome. I'm not sure how it could be done, but definitely could
<bialix> especially for new site with user docs
<garyvdm> bialix: It was difficult to choose what to include.  I don't have any thing for qcat.
<LarstiQ> bialix: no, I don't have upload rights.
<LarstiQ> bialix: but I do have some involvement
<bialix> LarstiQ: what is usual practice?
<LarstiQ> bialix: I think I'm missing some context, what do you want to do?
<garyvdm> bialix: is this to get qbzr into debian?
<bialix> LarstiQ: one man from ru_bzr want to build deb package for qbzr for Debian Lenny and Etch, he asking me about advices how to publish his work
<bialix> garyvdm: yep
<bialix> I'll start procedure of buying domain
<garyvdm> bialix: Well I can't see a reason that he could not publish it to the ppa.
<bialix> lp guys said there is no PPA for Debian
<garyvdm> oh
<bialix> you can look at irclogs of #launchpad
<garyvdm> bbl
<LarstiQ> bialix: I'm willing to review the packaging work
<bialix> [11:27]	<wgrant>	bialix: Launchpad can't currently build PPA packages for Debian. However, if qbzr is Python as I assume, Ubuntu packages should work on Debian.
<LarstiQ> bialix: finding someone to sponsor the upload to backports shouldn't be too hard either
<wgrant> Right, no Debian PPA support at this point.
<bialix> LarstiQ: can I give your contact to that man?
<LarstiQ> bialix: sure
<LarstiQ> bialix: hmm
<bialix> so you can provide some hints
<LarstiQ> bialix: qbzr doesn't seem to be in Debian currently?
<bialix> are you asking me about this?
<bialix> I don;t know even where to look to check?
<LarstiQ> bialix: direct him to me, we'll figure it out then :)
<bialix> okay
 * LarstiQ is best contactable on irc btw
 * bialix nods
<bialix> LarstiQ: you talk Serbian?
<LarstiQ> bialix: no, I guess I should remove that, I added that for testing bits of Rosetta
 * LarstiQ does so now
<bialix> np
<jelmer> :-)
<jelmer> bialix: qbzr is indeed not in Debian
<LarstiQ> bialix: I do since speak a little bit of Finnish though ;)
<bialix> :-)
<LarstiQ> updated
 * jelmer speaks 4 words of russian, not sure how to write them though :-)
<bialix> jelmer: there is usual practice on writing them using latin alphabet
 * LarstiQ heads to lunch
<bialix> garyvdm: so, what's our plan for today?
<garyvdm> bialix: http://launchpad.net/qbzr/trunk/0.13.1/+download/qbzr-0.13.1.tar.gz
<bialix> ok
<bialix> do you have a dedicated branch for this?
<bialix> found https://code.launchpad.net/~qbzr-dev/qbzr/0.13
<bialix> garyvdm: does QtTest is used in qbzr now?
<bialix> garyvdm: windows installer has been uploaded
<garyvdm> bialix: I forgot to include in NEWS something that say we now require Qt 4.4. I'll include it in the announcement mail.
<bialix> garyvdm: cool graph on ohloh, indeed!
<jam> morning vila
<jam> fjalvingh: are you around?
<vila> morning jam
<fjalvingh> james_w: Hello, yes; im around
<fjalvingh> jam, I mean 8-(
<jam> garyvdm, bialix: I just say 0.13.1 announced, is that different from the 0.13 you told me about last night?
<bialix> Ð½ÑÑ
<bialix> yes
<bialix> garyvdm has fixed regression introduced before 0.13 release
<igc> night all
<garyvdm> jam: tisk tisk tisk lots of code just before a release...
<jam> :)
<jam> night igc
<fullermd> That's what releases are for, aren't they?  To get people to put in new code?
<bialix> jam: it seems like your comment about new features before release... it was evil eye
<jam> bialix: it was experience
<cody-somerville> I'm having much difficult reverting a single revision
<jam> cody-somerville: Assuming you mean "I'm having trouble removing the changes introduced in a single revision"
<jam> then you probably want
<jam> "bzr merge -r REV..REV-1"
<cody-somerville> But I have no idea what REV-1 is for 625.1.1
<jam> cody-somerville: before:625.1.1 works fine
<jam> so "bzr merge -r 625.1.1..before:625.1.1"
<cody-somerville> thanks
<cody-somerville> that worked
<cody-somerville> but was way too difficult
<garyvdm> bailix: There are lots of bug that I want to change to "wish list", so that I can see the real bug at the top of the page.
<garyvdm> e.g. bug 306688
<ubottu> Launchpad bug 306688 in qbzr "Allow diff style selection to be remembered or configured" [Medium,Confirmed] https://launchpad.net/bugs/306688
<garyvdm> Is that ok>
<LarstiQ> garyvdm: are you using the same bug workflow as bzr?
<garyvdm> LarsitQ: workflow?
<garyvdm> LarstiQ: I was looking for what to work on next. I would like to fix bugs first, before working on new features.
<garyvdm> It would be nice to be able to prioritize Wishlist bugs...
<LarstiQ> garyvdm: doc/developers/bug-handling.txt
<cr3> darn you guys! now I can't type "bar" anymore, it always comes out as "bzr"!
 * awilkins has also noticed that bzr has become a short reflex loop
<Tak> fzo, bzr, bzz
<garyvdm> LarstiQ: Hmm - we are using wishlist for features, bzr doc describes them as very "wishfull thinking buddy...."
<garyvdm> aka very low Importance.
<LarstiQ> garyvdm: right
<garyvdm> Hi bialix
<bialix> evening garyvdm
 * bialix reviewing qexport
<bialix> today I'm thinking about automating screenshot work
<bialix> we can use qbzr trunk to illustrate some interesting dialogs
<bialix> and some dialogs could be created programatically
<bialix> then only printscreen capture need to be automated
<bialix> I hope there is some programmable tools to do this work
<bialix> will be nice to get this functionality directly from qt though
<garyvdm> bialix: That would be cool!
<bialix> garyvdm: do you aware about creating screenshots of qt windows?
<garyvdm> Sorry no
<bialix> I think such feature exists in Tkinter, but I don't remember for sure
<luks> there is something in QDesktopWidget
<luks> hm, maybe not there
<luks> but it's somewhere
<luks> QPixmap::grabWindow
<bialix> luks, garyvdm: http://doc.trolltech.com/4.5/desktop-screenshot.html
<bialix> originalPixmap = QPixmap::grabWindow(QApplication::desktop()->winId());
<bialix> luks: yeah
<luks> TestCaseWithTransport automatically creates a standalone branch in the root of the test directory, is there a clean way to disable that?
<luks> I need to make a failing blackbox test for code that uses WorkingTree.open_containing and with that branch there it will always find something
<LarstiQ> does it really?
<james_w> yeah
<luks> yes
<james_w> it's there for safety
<james_w> and you would be writing a test that would fail on some systems
<bialix> luks: unfortunately you can't
<LarstiQ> james_w: ah, so it doesn't recurse upwards infinitely?
<james_w> perhaps creating a type of bzrdir that says "stop looking here please" for use in tests would help
<james_w> LarstiQ: exactly
<luks> I'm not sure I follow
<Tak> wait, what system allows infinite upward recursion?
<luks> it's hard to believe that no blackbox test in bzr ever needed that
<luks> but I really can't find anything
<luks> I wonder what would happen if I remove the root .bzr directory
<statik> hi bzr hackers! on one of my machines, i'm trying to use bzr and bzr-gtk, both installed from https://edge.launchpad.net/~bzr/+archive/ppa. I get this failure: Unable to load plugin 'gtk'. It requested API version (1, 13, 0) of module <module 'bzrlib' from '/usr/lib/python2.6/dist-packages/bzrlib/__init__.pyc'> but the minimum exported version is (1, 17, 0), and the maximum is (1, 17, 0)
<luks> or perhaps just move it and then move back
<statik> I'm trying to do this on jaunty (9.04), and having some trouble figuring out how to get a usable version of bzr-gtk
<luks> bah, so this means I can't write the test
<bialix> luks: I suppose it's for safety, so your test don't open the branch outside you testing sandbox
<luks> bialix: yeah, I just realized that
<bialix> I've stuck with the same probkem recently
<bialix> problem
<luks> I'll just have to ignore that case
<jam> luks: why don't you just create another dir that is a repository
<jam> without a working tree
<jam> self.make_repository('.')
<jam> that should trap WT.open_containing() so it doesn't find the one in the test root
<luks> oh, that will work?
<jam> luks: try it, but I'm 90% sure it will work
<luks> cool, thanks
<luks> works great
<garyvdm> statik: I'll probable end up trying to convince you to try qbzr, but let me try help with bzr-gtk first. What version of bzr-gtk do you have installed? This can be seen from bzr plugins -v
<jam> vila: are you still around? (not that you should be)
<jam> statik: you need to get the latest bzr-gtk from its ppa, IIRC
<jam> known issue that bzr-gtk had not actually released code for a long time
<statik> garyvdm: thanks for the help. jam: ah, I didn't realize bzr-gtk had it's own ppa, I was confused because I saw bzr-gtk packages in the main bzr ppa
<jam> statik: well, I'm not positive about that
<jam> I'm looking
<jam> it may just be that nobody packaged the latest release
<statik> garyvdm: i had the version from the ~bzr ppa, but i think i might try switching to qbzr or bzr-gtk trunk
<statik> garyvdm: if i'm running bzr 1.17 is it better to use qbzr from trunk or from a ppa somewhere?
<garyvdm> jam: If so, someone should either copy the new ppa to the bzr ppa, or delete the old ones.
<jam> garyvdm: I don't think there is a bzr-gtk ppa after all
<jam> vila was kind enough to force an actual release of bzr-gtk code
<jam> but I don't see any .debs around
<garyvdm> statik: the one in the bzr ppa is 0.12, which is fine for 0.17. The latest release is 0.13.1, which is only in the qbzr ppa
<jam> garyvdm: other than the fact that I just hit "copy" for 0.13.1 => bzr's ppa
<statik> garyvdm: ~qbzr-dev is the qbzr ppa you are referring to?
<jam> I guess Is hould have only copied it to the beta
<garyvdm> jam: Oh - cool
<jam> since 1.18rc1 isn't in the bzr ppa...
<jam> does 0.13.1 work with 1.17?
<jam> statik: I do see: http://bzr.debian.org/pkg-bazaar/bzr-gtk/ubuntu/
<garyvdm> jam: 0.13.1 should be fine with 0.16, and 0.17
<jam> I don't really know what's up with that
<jam> garyvdm: well, hopefully 1.16 and not 0.16
<jam> :)
<jam> though if it still works with 0.16, great
<garyvdm> jam: err- yes - I get so confused.
<jam> garyvdm: yeah, the numbers are "close" but still not in sync
<jam> uh-oh
<jam> it looks like *I* was the last person to upload bzr-gtk
<jam> though that was back in 2008-08-26
<statik> haha, with qbzr 0.12-1 'bzr help qbzr' says "Not finished -- DON'T USE" in the description
<jam> statik: interesting. certainly should be updated. It is the default package on windows for a while now, and is in rather good shape
<garyvdm> statik: bzr qbzr is our main window, which is not finished. All the other command are very useable
<statik> but, yay, qannotate works nicely and I can get back to spelunking through my code reviews :) thanks for the help!
<statik> garyvdm: ah, that makes more sense
<garyvdm> statik: e.g. qlog, qcommit, etc.
<jam> garyvdm: you might want to reconsider the name of your main window, so that you get help on the plugin rather than the command
<garyvdm> jam: yes, I plan to rename it to qmain.
<ryanakca> Is there an equivalent to git add -p, that's to say, only commit parts of the changes in a file?
<LarstiQ> statik: contrast `bzr help plugins/qbzr`
<garyvdm> bialix: ^^^ any objection to doing that now...
<jam> ryanakca: not directly, but you can use "bzr shelve" to back out parts of the change temporarily and then "bzr unshelve" it later
<bialix> one sec
<LarstiQ> ryanakca: on _add_?
<jam> LarstiQ: 'git add' stages things to actually be committed
<jam> (as in 'git add' stores stuff in the repository)
<statik> LarstiQ: ah, thats what i was looking for. thanks!
<jam> but doesn't reference it until 'git commit'
<ryanakca> jam: but to shelve just say, lines 8-12 , but not lines 25-75 ?
<bialix> garyvdm: objection for what?
<jam> ryanakca: bzr shelve is interactive
<garyvdm> bialix rename qbzr to qmain
<ryanakca> jam: Awesome, thanks
<jam> with the main advantage that you can then *test* what you are committing
<bialix> garyvdm: ah, no, of course, it's hidden anyway. But please write NEWS, because some people seems to try using it
<LarstiQ> ryanakca: although it doesn't support hunk splitting atm
<garyvdm> bialix: lots of new users type bzr help qbzr, and get a not so nice message about  not been complete.
<ryanakca> LarstiQ: OK
<bialix> yes, let's do it
<SamB> jam: it would be nice if bzr revert was interactive too ...
<SamB> or could be
<mzz> couldn't you shelve the changes you want to keep, revert everything else, then unshelve?
<mzz> I think I've actually done that
 * SamB wants "bzr vizmissing" 
<LarstiQ> mzz: yes
<jam> SamB: bzr qlog branch1 branch2
<jam> a bit of extra info
<jam> but would show you what is on one branch and not the other
<SamB> jam: I don't think I have enough free disk space to install qbzr
<jam> SamB:  I thought viz may have also been updated to handle multiple branches
<SamB> oh, true
<SamB> too bad I can't do branch1...branch2, though :-(
<jam> SamB: bzr log -r -1:../branch1..-1../branch2 ?
<jam> not sure how that works with viz
<garyvdm> SamB: bzr qlog . branch2
<SamB> "bzr viz ../trunk .&" does something ;-)
<meoblast001> hi, i have a question
<garyvdm> SamB; you can do that with vis if the missing revisions from branch2 are available in branch1's repo
<meoblast001> suppose i have some binary files in my program
<jam> meoblast001: I have a dream :)
<meoblast001> if i modify and push those binary files regularly, does that increase the size of the branch rapidly?
<SamB> garyvdm: they are in the same repo, actually -- are you saying that viz only looks in one repo?
<meoblast001> and make people have to download more
<garyvdm> SamB: I the revisions are not there, it will fail silently :-(.
<SamB> meoblast001: it depends on how much serialization changes when you change the file
<SamB> meoblast001: what sort of binary files?
<meoblast001> .blend files
<meoblast001> it's a game
<garyvdm> SamB: yes, vis only looks at 1 repo, qlog is able to look at multiple.
<SamB> how does .blend work?
<mzz> meoblast001: I'd expect it to depend heavily on the file format (if the file's compressed it'll suck, for example)
<LarstiQ> .blend is not compressed
<LarstiQ> and it's chunk based
<meoblast001> is that good?
<SamB> probably!
<LarstiQ> meoblast001: I think it should work reasonably well, but I haven't tried it in practice yet.
<jam> meoblast001: I would say... It depends
<jam> the latest format (--2a) should do better at producing binary deltas than previous formats which did line-deltas
<meoblast001> is all the data for revisions held in .bzr, i could check
<luks> hm, what do I have to do to resubmit a merge request on LP?
<jam> luks: mark it "resubmit"
<jam> versus Approve/etc
<LarstiQ> meoblast001: in the .bzr of the repository yes (ie, the .bzr with .bzr/repository/)
<meoblast001> yuck
<meoblast001> 27 megabytes
<SamB> meoblast001: does that include obsolete_packs ?
<luks> jam: thanks
<LarstiQ> meoblast001: for what treesize?
<meoblast001> and the entire directory for my game is 28
<meoblast001> actually, that doesn't seem right
<LarstiQ> meoblast001: at how many revisions?
<garyvdm> SamB: I would like to get some feedback, how come you are using bzr-gtk, as appose to qbzr?
<meoblast001> about 50
<LarstiQ> meoblast001: ok
<SamB> garyvdm: qt is too big
<meoblast001> so is that bad?
<jam> garyvdm: hysterical raisins, I imagine
<garyvdm> SamB: ok
<meoblast001> it seems pretty bad
<LarstiQ> meoblast001: a bit hard to tell yet
<SamB> and my /usr is pretty full
<meoblast001> at revision 1000 we'll have several gigs of stuff
<LarstiQ> meoblast001: well, how quick has it been growing?
<meoblast001> slowly
<meoblast001> 50 revisions over the course of a half year
<LarstiQ> meoblast001: no I mean, has it been 27meg from rev1 and stayed the same?
<meoblast001> would you recommend removing all the art and putting that in a seperate location?
<mzz> meoblast001: I don't follow. Does 28 for the "entire directory" include those 27m for .bzr?
<meoblast001> mzz: yes
<mzz> ok, that's odd
<LarstiQ> meoblast001: ah, I thought without .bzr was 28
<meoblast001> wait a second
<meoblast001> this is weird
<jam> meoblast001: just paste the results of "du -ksh .; du -ksh .bzr"
<meoblast001> hm, my tree is 27 MB
<mzz> meoblast001: are you sure the directory wasn't much larger in the past? 27m of .bzr for 50 revisions of a tree that's on average 1m seems a bit larger than usual.
<meoblast001> so let me check .bzr
<mzz> or that.
<meoblast001> it is also 27
<meoblast001> that's weird
<mzz> yeah, that sounds more reasonable.
<garyvdm> SamB: I have spoken to many people that have that reason. So many I often consider creating a gtk port of qbzr. (I think that would be eaiser than porting qbzr's feature to bzr-gtk.)
<mzz> meoblast001: data inside .bzr *is* compressed, so it's possible for it to be a bit smaller than your source tree is, if you don't have many revisions and they compress well.
<LarstiQ> garyvdm: eh, that sounds like a lot of work
<luks> come on, QtGui+QtCore is like 10M or so
<SamB> garyvdm: well, another approach might be to get the python qt bindings split into smaller pieces
<meoblast001> well, 50 revisions, .bzr is about the same size as the rest of the source tree
<luks> I doubt that's the real reason
<meoblast001> does that sound like it's good?
<mzz> meoblast001: that sounds about right to me, yes. But I'm no expert :)
<LarstiQ> meoblast001: that sounds belieavable, yes
<meoblast001> so i should continue the way i'm going?
<SamB> luks: the python bindings are monolithic, though
<mzz> meoblast001: I would, but ymmv
<SamB> luks: in Debian, at least
<meoblast001> ymmv?
<luks> SamB: in debian, they can be built separately
<mzz> meoblast001: your mileage may vary
<garyvdm> luks, SamB: Yes, thats why U loged bug 381409
<meoblast001> ok
<ubottu> Launchpad bug 381409 in python-qt4 "python-qt4 depends on phonon" [Undecided,New] https://launchpad.net/bugs/381409
<garyvdm> *I
<SamB> garyvdm: ah, thanks
<SamB> I was just about to go see if I had gotten around to it ;-)
<garyvdm> lol
<LarstiQ> garyvdm: how does it pull in phonon?
<garyvdm> LarstiQ: I describe it in the bug
<SamB> garyvdm: hmm, is there a debbug for that too?
 * LarstiQ has python-qt4 installed on Lenny, no phonon
<luks> phonon is a part of Qt
<luks> it was added in 4.5, maybe you have something older?
<SamB> I think python-qt4 also pulls in the qitchen sink
<mzz> probably
<LarstiQ> luks: yup, 4.4
<mzz> afaict it's quite possible to split PyQt4 into smaller binary package just like Qt4 itself is
<mzz> packages, even
<bialix> python experts help needed: is it valid to write: def func(self, workdir=None, *args): ?
<jam> bialix: I believe it is "def func(self, *args, workdir=None)"
<mzz> bialix: yes, but it doesn't do what you want.
<jam> not sure, though
<jam> ah right
<bialix> mzz: it's already splitted in Windows package
<mzz> bialix: what jam said is a SyntaxError. What you said works but if you call it with two arguments "workdir" eats the second one, not "args"
<jam> mzz: right, I forgot
<mzz> bialix: you want python 3's keyword-only arguments. Without those the best you can do is take **kwargs and parse them manually.
<jam> which is why we went with "def func(self, *args, **kwargs)" and then inspect kwargs in some of our code
<mzz> exactly
<bialix> I can relax and don't set workdir as None
<mzz> bialix: yeah, making workdir non-optional makes it work as expected too
<bialix> ok
<bialix> thx
<garyvdm> LarstiQ: How knowledgeable are you with debian packaging? Could you have a go at fixing bug 381409 in Debian?
<ubottu> Launchpad bug 381409 in python-qt4 "python-qt4 depends on phonon" [Undecided,New] https://launchpad.net/bugs/381409
<vxnick> is there any plugin docs other than the two pages on the bzr website? Struggling a bit to make a plugin, despite checking things like builtins.py
<SamB> mzz: yeah, and it's presumably not that hard to split libc6-dbg just like libc6 is split ...
<mzz> python 3 lets you write both what you said and what jam said, and they'll behave differently when they get a single positional arg, but you probably can't use that yet.
<mzz> and I have no idea if that feature will be backported.
<LarstiQ> garyvdm: I expect that to be fairly involved
<SamB> mzz: I don't think it will be
<mzz> SamB: oh, I guess it'd be backwards incompatible for things like the inspect module, bleh.
<SamB> mzz: I was just thinking that probably that kind of CODE already means something else in Python2000
<mzz> SamB: no, it's a SyntaxError
<SamB> oh
<garyvdm> LarstiQ: Do you think you could push the bug to Debian's bug db, and nag a dd to work on it for me?
<SamB> in that case I could see it being backported
<LarstiQ> garyvdm: sure
<garyvdm> LarstiQ: Thanks
<mzz> SamB: I'd have to check, but I bet it'd make it impossible for older code to introspect functions making use of the new feature.
<SamB> mzz: it might cause difficulties, true
<SamB> but that's not nearly as bad as breaking everything!
<SamB> (potentially)
<mzz> SamB: fwiw: http://paste.pocoo.org/show/133700/ (python 3.1)
<SamB> I don't suppose anyone here would have any sway on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520680 ?
<ubottu> Debian bug 520680 in libc6-dbg "libc6-dbg: Debug symbols not broken up by runtime package" [Normal,Open]
<SamB> it's marked wontfix
<LarstiQ> SamB: I'm afraid that is not likely to change
<mzz> SamB: his arguments aren't that good imho, but I can't help you there.
<LarstiQ> mzz: not good?
<SamB> hmm, I guess I'll just see if I can get #gdb involved ...
<mzz> SamB: specifically I'm pretty sure those mozilla-related -dbg packages are huge just because the debug info for those packages is, not because there's one debug package per source package
<SamB> some of them work at redhat, which seems to have a nice solution to the "too many -dbg packages" problem ...
<mzz> SamB: and I don't know enough about debian to understand why "increase the number of packages in the archive" is problematic
<SamB> mzz: psh, I don't care about the mozilla ones
<LarstiQ> mzz: the point is, _all_ -dbg packages follow one-per-source
<mzz> SamB: yeah, but that's over half of what he listed in response to your "what other packages are you referring to"
<SamB> I just want libc6-dbg split by architecture like the runtimes are
<mzz> LarstiQ: yes! it should be fixed for all of them :)
<SamB> LarstiQ: surely that can be fixed
<LarstiQ> mzz: eh, no
<SamB> and he never mentioned *that* as an argument, either
<SamB> I would have recognized that as a valid, reasonable, concern!
<LarstiQ> euh, I thought he said that
 * LarstiQ reads again
<SamB> not that I could see
<mzz> "debugging packages in Debian are all using the same layout: one per
<mzz> source package"
<LarstiQ> SamB: he did: Yes, debugging packages in Debian are all using the same layout: one per
<mzz> ugh, linebreak, sorry.
<LarstiQ> source package. A lot of them are a lot bigger than libc6-dbg.
<SamB> oh, he did ?
<LarstiQ> mzz: number of packages in the archive is an ongoing concern.
<mzz> and yes, many others are bigger, but the ones he listed are bigger just because they're bigger, not because they're from a source package that's split into many binary packages.
<SamB> oh, but then he went into that fallacy "other packages are doing the same thing, so it's fine if I do!"
<mzz> SamB: not necessarily. It's entirely possible this is policy, not just convention. I wouldn't know.
<SamB> if he hadn't gone and pointed the finger at irrelevant packages I would have been more well-disposed towards his argument
<bialix> garyvdm: in side-by-side qdiff color lines becomes thickier, it's intended behavior
<bialix> garyvdm: ?
<mzz> SamB: that doesn't matter if it is indeed policy. You'd have to get policy changed.
<LarstiQ> SamB: I think you parsed that wrongly
<bialix> garyvdm: I mean green and red lines
<SamB> LarstiQ: could be!
<SamB> but I don't care about mozilla symbols
<SamB> the way it dies is that I kill it for it's RAM anyway
<garyvdm> bialix: It happens on the side where there is nothing.  The change was not intended, but, I was not too worried about it.
<garyvdm> bialix: Would be easy to fix.
<LarstiQ> SamB: if you can get an ok from a ftpmaster up front about splitting into more packages, you could bring that to the table
<SamB> LarstiQ: I don't see any reason for that, though
<LarstiQ> SamB: for what?
<SamB> why duplicate the same source tarball three times?
<bialix> garyvdm: I don't mind it stay, bt I've noticed because it seems I've used to old behavior
<LarstiQ> no, not source tarball
<mzz> SamB: again, I don't know about debian, but if the concern is about disk usage, not number of packages, I'd expect this kind of split to not hurt significantly
<bialix> garyvdm: it's not big deal
<LarstiQ> SamB: splitting the -dbg package
<SamB> oh, you meant .debs?
<LarstiQ> mzz: the concern is number of packages
<mzz> drat.
<SamB> something about "users"
<SamB> was mentioned
<LarstiQ> SamB: you are argueing with the maintainer about a point that I think will be upheld even if you escalate to a wider audience
<LarstiQ> SamB: how small is your disk anyway?
<mzz> the size of my /usr/ isn't that much of an issue next to the size of my /home if I don't clean it up regularly
<SamB> oh, apparantly I reported the python-qt4 thing as #535759
 * mzz prods ubottu 
<SamB> oh, apparantly I reported the python-qt4 thing as debbug #535759, that is
<SamB> how does this thing work?
 * mzz gives ubottu a friendly pat on the head
<SamB> mzz: I have /home on a bigger disk
<SamB> I might possibly be able to grow /home, I'm not sure
<SamB> er.
<SamB> grow /usr
<mzz> yay lvm
<SamB> for instance, if my old /home is right after it, or my ancient HURD partition ...
<SamB> mzz: hmm, I'm not using that
<SamB> is it easy to start?
<LarstiQ> SamB: parted?
<mzz> too bad! if you were you'd be able to grow your /usr partition onto the other drive.
<fullermd> lvm?  Is that what people use who can't get ZFS?  ;p
<mzz> converting to it is rather a hassle though.
<SamB> mzz: I think I'd be more likely to grow /home on that one ;-)
<garyvdm> SamB: You have to prefix with bug. Bug 535759
<ubottu> Error: Launchpad bug 535759 could not be found
<SamB> garyvdm: doesn't work for debian bugs!
<LarstiQ> fullermd: LVM is much older
<SamB> debian bug 535759
<ubottu> Debian bug 535759 in python-qt4 "python-qt4: package too monolithic -- should be split up to match dependencies" [Normal,Open] http://bugs.debian.org/535759
<SamB> okay, that works
<LarstiQ> fullermd: even the Linux implementation, but I was thinking HP-UX (or maybe AIX)
<fullermd> I know.  That's no good reason not to troll a little though   :p
<SamB> fullermd: I thought it was called "tease"
<fullermd> SamB: You'd have to be a lot better looking before I upgraded you to 'tease'.  Sorry.
<SamB> I'm not even the one using LVM
<SamB> I'm still using IBM/MS partition tables
<fullermd> That's why we're all making fun of you, see   8-}
<SamB> yeah, as well you should
<SamB> that primary/extended/logical thing is *so* stupid!
<fullermd> Pshaw.  It's brilliant; you can run DOS and CP/M on the same machine!  What more do you want?
<SamB> how can you run CP/M on it?
<SamB> and since when does CP/M support fixed disks ?
<fullermd> I dunno.  I can't afford enough drugs to want to try.
<SamB> I thought CP/M was for Z80
<fullermd> It probably wouldn't run bzr anyway...
<SamB> yeah, getting it to work nicely on DOS would be hard enough
<SamB> it's not even worth trying on CP/M
<mzz> I don't think bzr would like the 8.3 filesystem much, even if you managed to find a python that runs on dos.
<garyvdm> http://mail.python.org/pipermail/python-list/2004-December/295818.html
<mzz> I didn't say 16 bit dos (you could run it in an extender)
<SamB> mzz: how about DOS 7, then?
<mzz> http://www.caddit.net/pythond/
<luks> wow, threading?
<LarstiQ> opengl?
 * bialix hopes igc will be glad to see qexport landed; it turned out to be more work than I've expected
<SamB> hmm, the Debian policy manual doesn't have anything obvious about debug packages ...
<bialix> garyvdm: we have 26 public q-commands now, 23 of them are equivalents to bzr CLI
<bialix> woot!
<garyvdm> :-)
<luks> somebody should port qbzr to git
<bialix> gtk lags behind ;-P
<bialix> luks: there is QGit
<bialix> but it's only ~ qlog
<luks> bialix: I don't care much about using Qt, but having sensible UI
<bialix> well, ok
<bialix> so I've misunderstood you
<bialix> what's the sense to port bzr-specific tool then?
<luks> well, I miss the tools I know :)
<bialix> you don't use bzr at all?
<luks> I do
<luks> but I had to deal with git too recently
<garyvdm> luks: use bzr-git
<luks> that would be too slow :)
<garyvdm> bialix: I think one of the things that sets qbzr apart from bzr-gtk this that the ui is very consistent, and consistent with the cli
<bialix> garyvdm: ?
<bialix> oh
<bialix> I've misread
<garyvdm> bialix: bzr-gtk's ui is very inconsistent.
<bialix> I've read bzr-git instead of bzr-gtk
<bialix> yeah, I've got it
<bialix> well, bzr-gtk was collection of different tools at first
<garyvdm> yes
<bialix> or maybe still is
<SamB> bialix: still seems like it
<bialix> so we have a big bonus in our design
<SamB> for instance, why doesn't gmissing look anything like viz?
<bialix> garyvdm: we have several blueprints filed, as I've discovered
<bialix> I'll attach bug reports to them, so we can track it
<garyvdm> bialix: For tag from qlog, I recommend working from lp:~garyvdm/qbzr/logslots . It should merge into trunk soon. The code is much easier to read.
<bialix> garyvdm: I'll wait then
<bialix> garyvdm: I'll start working on saving more commit data, including bugs
<garyvdm> bialix: That will be cool.
<bialix> I've promised to Craig to implement this
<bialix> I should do it finally
<garyvdm> bialix: I did mention this in a mail, but I just want to bump it. It would be cool if the was a api in bzrlib for plugins to provide a default message.
<bialix> there is some hook
<garyvdm> bialix: bzr-builddeb provides a default message (which it pulls from the debian/changelog file.) It would be nice if qcommit could default to that.
 * garyvdm looks at the bzr-builddeb code.
<bialix> I remember there was hook, but documentation does not mention it
<bialix> jelmer: ping
<bialix> james_w, jelmer: someone of you has implemented hook for commit message
<bialix> I don't remember details
<garyvdm> bialix: http://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/annotate/head%3A/__init__.py#L105
<bialix> MessageEditorHooks, it's about providing template for edit it by user
<bialix> yes, it's one
 * bialix bbl
<Noldorin> hi lifeless
<garyvdm> Noldorin: CTCP time reply âWed Aug 12 05:53:21 2009â from lifeless
<Noldorin> garyvdm: heh, fair enough
<Noldorin> forgot he's an aussie :)
<moldy> hi
<moldy> can i get bzr to show relative pathnames in e.g. "bzr st"?
<mneptok> Noldorin: uh oh ...
<mneptok> Noldorin: lifeless is a New Zealander. and quite passionate about that point.
<mneptok> Noldorin: he's going to go all Morgoth on you now
<Noldorin> mneptok: woops, lol
<Noldorin> it's all the antipodes :)
<garyvdm> moldy: I don't think so. Why do you want to do that?
<moldy> garyvdm: because i commonly work from a directory that is not the root of my branch
<Noldorin> mneptok: tolkien fan too, i must presume?
<LarstiQ> moldy: not atm, but you can restrict status output to a subdir
<moldy> garyvdm: having relative pathnames would allow copying and pasting, and possibly make shell completion better
<moldy> my zsh installation does not do bzr completion well :(
<moldy> LarstiQ: ok, thanks
<LarstiQ> moldy: looking up the bug, just a sec
<LarstiQ> moldy: bug 30159
<ubottu> Launchpad bug 30159 in bzr "paths are always from root of branch" [Low,Confirmed] https://launchpad.net/bugs/30159
<garyvdm> mneptok, Noldorin: I think lifeless currently resides in Sydney
<mzz> moldy: yeah, the zsh I have here kinda sucks at it too. I keep typing "bbzr ..." so I get regular filename completion to work around it.
<Noldorin> mneptok: hah, so i was right! :)
<LarstiQ> mzz: compdef -d bzr too radical?
<moldy> mzz: hehe, ya :)
<Noldorin> Noldorin: well, at least an aussie in residence
<mzz> LarstiQ: if that does what it sounds like: perhaps
<mzz> LarstiQ: some of its completions are kinda ok, although frequently slow, like completing new files for "bzr add"
<moldy> LarstiQ: glad to hear that this is going to change eventually
<LarstiQ> moldy: welll
<LarstiQ> moldy: as you see it is a low priority bug
<LarstiQ> moldy: it would be _nice_ to fix
<LarstiQ> moldy: but it's not entirely trivial
<fullermd> And some of us really like root-relative paths  :)
<LarstiQ> moldy: it lacks someone to dedicate time towards it
<moldy> LarstiQ: i understand
<mneptok> garyvdm: he does reside there, but is a New Zealander. if you'd like to dispute his nationality with him, i'll start making your funeral arrangements. :)
<garyvdm> lol
<moldy> i will keep it in the back of my head, maybe i can find the time to come up with a patch
<LarstiQ> moldy: cool. If you do, feel free to bug me
<garyvdm> moldy: you could try the branch linked to that bug.
<garyvdm> lp:~jdobrien/bzr/bug30159
<moldy> i will see. right now, i have other stuff to do (the stuff i am actually using bzr for ;), but i will bookmark it and _maybe_ come back to it ;)
<LarstiQ> garyvdm: I don't think much happened there
<LarstiQ> some tests
<LarstiQ> moldy: sure, cool :)
 * LarstiQ continues preparing for HAR
<fullermd> Well, once you have tests, it's easy.  You just bang up a little code randomizer and run it 'till the tests pass.
<moldy> hehehe
<lifeless> mneptok: thanks ;)
<lifeless> Noldorin: hi
<lifeless> Noldorin: what was the bug number for this problem?
<garyvdm> Hi lifeless :-)
<lifeless> hi garyvdm
<lifeless> hows things?
<garyvdm> Good. You
<garyvdm> ?
<lifeless> pretty good; the weather can't decide if its appalling or sunny though :(
<lifeless> jml: hi; enjoying your self/
<lifeless> ?
<nekohayo> hey there, how is the status/health of the bzr git translation thing?
<mneptok> lifeless: i know the difference between Hobbiton and Alice Springs ;)
<lvh> hi
<nekohayo> I tried to branch pitivi's git repository by installing bzr-git and doing a "bzr branch git://git.pitivi.org/git/pitivi.git pitivi-bazaar", but I just get a huge traceback, including NameError: global name 'name' is not defined
<thumper> jelmer: ping
<thumper> jelmer: I was going to also ask about bzr-git and git://git.pitivi.org/git/pitivi.git
<thumper> jelmer: probably some weird edgecase
<Noldorin> lifeless: hey, you there?
<lifeless> yes
<lifeless> did you see my question?
#bzr 2009-08-12
<Noldorin> lifeless: no, i didn't
<Noldorin> lifeless: i disappeared offline for after my laptop lost power. sorry
<lifeless> Noldorin: whats the bug number for this problem
<Noldorin> lifeless: i still haven't been sure what to submit yet :)
<Noldorin> i've been testing the repo a bit more the past day
<Noldorin> seems init always succeeds
<Noldorin> or almost always
<lifeless> Noldorin: please file a bug.
<lifeless> it lets us gather data.
<Noldorin> lifeless: ok, will do. what should i detail specifically as the cause though?
<lifeless> Don't worry about it being 'right' - bugs are conversations.
<Noldorin> yeah, probably a good idea
<Noldorin> hmm
<Noldorin> fair enough
<lifeless> if we knew the cause, we probably wouldn't need a bug ;)
<Noldorin> lifeless: knowing the cause can often (though not always) still be quite a long way from the fix ;)
<lifeless> thats true too :)
<Noldorin> heh, we've made progress in understanding at least
<Noldorin> lifeless: interestingly, breaking the lock doesn't seem to be a problem now
<lifeless> is that with the delay in it?
<Noldorin> nope
<Noldorin> don't have that available on this comp at the moment, unfortunately
<lifeless> ok
<Noldorin> (the source and dependencies that is)
<lifeless> ok
<Noldorin> ok, submitted now
<Noldorin> #412244
<Noldorin> lifeless: https://bugs.launchpad.net/bugs/412244
<ubottu> Launchpad bug 412244 in bzr "Cannot push to Windows FTP server (Microsoft FTP Service IIS6)" [Undecided,New]
<lifeless> thanks
<Noldorin> no problem
<Noldorin> it's probably still very incomplete at the moment
<Noldorin> but it describes the core of the problem
<Noldorin> i don't have some of the logs i posted you earlier, but i'm sure we can get them again if they're relevant :)
<Noldorin> lifeless: ah, i see your summary already.
<Noldorin> i'll be hear for a while longer, if you care to debug things further with me
<Noldorin> here*
<Noldorin> :P
<lifeless> I'm in the middle of a few other things right now
<Noldorin> alright, sure
<lifeless> When I get a chance I'll brain dump my memory to the bug
<Noldorin> well ping me if you have a miunte :)
<Noldorin> otherwise no worries
<Noldorin> ok cheers
<lifeless> igc: ping
<lifeless> igc: do the docs in trunk suggest in-place upgrade or doing rename dances?
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/374735
<ubottu> Launchpad bug 374735 in bzr "Plan and UI for upgrading multiple stacked branches " [Critical,Fix committed]
<igc> lifeless: http://doc.bazaar-vcs.org/bzr.1.18rc1-html/en/upgrade-guide/index.html
<igc> lifeless: the process is that recommended by thumper wrt stacked branches
<igc> morning all
<lifeless> igc: so, I think this approach is a real problem
<lifeless> igc: should I talk to you or thumper about that
<igc> lifeless: thumper. I'm happy to write up what you agree
<lifeless> thumper: ping
<thumper> whazzup?
<igc> lifeless: but the one thing I do want is a *simple* answer, even if that means more code in bzr or lp
<igc> lifeless, thumper: complex won't cut it imo
<lifeless> igc: my way is real simple: bzr upgrade URL
<lifeless> igc: its a fraction of the way described in your docs; which is why I asked about this in the merge review before it was merged :(
<lifeless> thumper: I think the upgrading docs should just say to upgrade all the branches in place. I'm not sure why they describe uploading new branches, shuffling stuff around, and igc points me at you to discuss this.
<thumper> lifeless: if you can fix the bugs, then sure, upgrade in place
<lifeless> thumper: _what bugs_
<thumper> lifeless: there are bugs filed that it doesn't work
<thumper> lifeless: upgrading stacked branches fails
<lifeless> I've seen one failure, which isn't upgrade relaated, its a fetch failure - being fixed at the moment.
<lifeless> We can't release 2.0 with fetch failures anyway; so I think we should be documenting in-place and *if* we get new bug reports fixing them.
<thumper> lifeless: ok... well if it works, then do it in place
<lifeless> this will use less disk space on launchpad, avoid dead branches, keep bug links and reviews intact etc.
<thumper> sure
<lifeless> igc: ^
<lifeless> vila: ping
<emmajane> igc, I hope I'm dismissed from writing up the summary of the RFC that turned into secretaries and incompetent developers. ;)
<thumper> lifeless: can packs (or later non-rr) be stacked on 2a now?
<lifeless> no, stacking is format locked
<lifeless> you can upgrade something thats invalidly stacked though - upgrade doesn't open the basis branch
<igc> emmajane: yes :-)
<emmajane> igc, *phew* :)
<igc> emmajane: a nice case study though on why reporting bugs is good practice :-)
<emmajane> igc, did y'all know that was going to happen when poolie asked me to write up the RFC?
<igc> emmajane: predicting the future isn't my strong point, so no
<emmajane> heh
<emmajane> as long as it wasn't "trial by fire for the newb" ;)
<fullermd> Oh, no.  Nobody thinks it through that much.  It's more like "trial by fire for somebody other than me"...
<emmajane> hehe
 * igc lunch
<SamB> igc: well, it looks like the git source tree is GPL v2 (only)
<fullermd> Coming out of Linus, I'd be a little surprised to see it otherwise.
<SamB> sometimes he mixes it up a little and says "let's SPL this" ;-P
<SamB> (more or less)
<fullermd> Pfft, spl's are so 1985...
<SamB> even GNU says you might as well use them when your program is shorter than the GPL itself
<SamB> SPLs are my favorite, and I was born in '86 ;-P
<lifeless> special purpose limousine?
<SamB> Simple Permissive Licenses
<fullermd> Alas, my archaic kernel humor is lost on you people   :p
<SamB> like BSD3, BSD2, or better, something which doesn't have <organization> in it ;-P
<SamB> hmm, you know, the latest PPA build has the wrong version number ...
<vila> hi all
<lifeless> hi
<jml> lifeless, yep :)
<lifeless> jml: excellent
 * igc dinner
<vila> lifeless: just noticed your earlier ping :-/
<bialix> hi bzr hackers, what is used in bzrlib internally as revision id of None revision (-r0)? Just Python's None? Or some special string?
<bialix> I suppose it's a NULL_REVISION="null:"
<poolie1> hello all
<poolie1> bialix: yes it is
<bialix> poolie1: hi
<bialix> poolie1: did you receive my mail about qbzr site? (I don't need the answer right now, but in next couple of days will be nice to get some comments from you or I should ask another Canonical person?)
<bialix> rats
<bialix> Elvis left the building
<johnf1> jelmer: you about?
<jelmer> johnf: somewhat
<johnf> jelmer: are you planning to split out bzr-doc in debian like we've done in the PPA?
<jelmer> johnf: it's on my list of things to look into, I just haven't found time to do so yet
<johnf> jelmer: ok no problems
<johnf> I'd offer to help out with the debian packaging but I'm still waiting to become active again. Getting out of emeritus status is painful
<jelmer> johnf: you're welcome to help regardless
<jelmer> johnf: You should be able to join the packaging team on alioth without being a DD, although you'll still need sponsoring to do actual uploads
<jelmer> but commits to the bzr repo shouldn't be a problem
<johnf> ok cool.
<tvainika> about bzr-git, how much is currently missing from bzr checkout git+ssh://repo; $EDITOR LL.po; bzr commit -m 'something' (with bound branch)? I just wonder because I'm reluctant to learn git and I wonder if I could bzr-git for gnome translations :)
<johnf> I figure it makes sense for me to help out with both. I may as well build and upload the debian packages at the same time I do the PPA ones
<jelmer> johnf: yeah, that makes sense
<jelmer> tvainika: I'm not sure how well checkouts work, standalone branches should work
<jelmer> tvainika: they shouldn't be hard to get working in any case. if you find they don't work, please file a bug and I'll look into it.
<jelmer> LarstiQ: do you know what happened to 1.17.1?
<smoser> apologies for newbie-ish question. If I bzr branch from some location, make some changes (bzr commit), how can I see what those changes were ?
<smoser> in git, i'd "git log HEAD..origin/master" or "git diff origin/master"
<luks> bzr diff --old path/to/the/other/branch
<luks> but there is also bzr missing
<luks> or bzr diff -r ancestor:
<LarstiQ> jelmer: got pqm sorted out on monday and submitted some things, did another cherrypick but not submitted yet
<LarstiQ> jelmer: at HAR now, and it's too rainy to pitch a tent
 * LarstiQ sends a pqm request instead
<jelmer> LarstiQ: ah
<jelmer> Let's talk about this at HAR then >-)
<jelmer> I'll be there for the first two days
<LarstiQ> jelmer: ah cool, I thought you wouldn't attend
<LarstiQ> jelmer: you _do_ have a ticket?
<jelmer> yeah
<jelmer> I bought one early but was considering selling it again because I had to miss the last two days
<jelmer> but I decided to go anyway, don't want to wait *another* 4 years
 * LarstiQ nods
<smoser> luks, thanks
<Tak> jelmer: any thoughts? http://paste2.org/p/375184
<Tak> that's on a small commit to a big bzr-svn bound branch
<Tak> got a similar one on update as well; other operation seem to be fine
<Tak> err, from monodevelop-bzr ^^
<igc> night all
<bialix> igc: night
<bialix> vila: bonjour!
<vila> hello bialix
<bialix> I've finally managed to finish commit_data stuff
<bialix> if you want comment on my approach, it will be nice
<bialix> code is here: https://code.launchpad.net/~qbzr-dev/qbzr/commit_data
<bialix> vila: ^
<emmajane> beuno, ping
<emmajane> igc, night :)
<beuno> emmajane, hi
<emmajane> beuno, hey :) Any updates from the designers?
<beuno> emmajane, none. I haven't even managed to get confirmation of the time being booked yet
<beuno> I have a call in 2 hours that gives me hope  :)
<emmajane> beuno, :(
<emmajane> hopefully the call has good news!
<poolie1> hello emmajane, beuno
<emmajane> poolie1, hey :)
<beuno> poolie1, hey!  What are you doing around here at this hour?
<poolie1> i'm in Taipei, going to the COSCUP conference this weekend and to visit canonical here
<beuno> poolie1, ah! that's right
<beuno> how's Taipei?
<poolie1> good
<poolie1> i just got to the hotel
<poolie1> am gaing to bed soon, it's 1130
<emmajane> poolie1, I thought today was a travel day for you. But then all I could remember was, "Wednesday"
<poolie1> it is, i've been travelling all day and then i just arrived
<poolie1> it's the end of my wednesday
<beuno> poolie1, enjoy Taipei
<emmajane> poolie1, :/ sleep will be nice for you then. :)
<vila> hi poolie1 !
<poolie1> hi vila
<bialix> poolie1: do you will be able to comment on my mail during this week?
<poolie1> hi,
<poolie1> any mail in particular?
<poolie1> i am going to be reading some
<bialix> poolie1: about Qbzr site, Gary asking to stay on bazaar-vcs.org
<poolie1> oh ok
<poolie1> i'll look
<bialix> it's not urgent, but I'd like to know how busy you are
<poolie1> i saw the thread but i didn't read all of it
<bialix> check qbzr ML
<poolie1> ok, answered
<poolie1> i hope that helps
<bialix> thanks
<poolie1> did that answer the question?
<bialix> poolie1: what it means: "We could arrange for qbzr to point to some site you like."
<bialix> ?
<poolie1> we can add a dns entry for it
<bialix> i.e. qbzr.bazaar-vcs.org?
<poolie1> right
<bialix> ok
<bialix> I need to catch garyvdm now. But it seems ok for me. (less money for domain)
<bialix> poolie1: we have a big move for last year
<poolie1> ?
<poolie1> a big change since last year?
<bialix> poolie1: we want to release qbzr 1.0 soon
<bialix> yes
<poolie1> cool
<poolie1> it seems to be moving really well
<bialix> so the site will be nice additon for this
<bialix> Gary is really wizard
<bialix> poolie1: it's a shameless, but I can't resist: https://www.ohloh.net/p/compare?metric=Codebase&project_0=QBzr&project_1=Bazaar+GTK%2B+frontends
<jam> poolie1: aren't you up *way* to late?
<jam> or is it a different TZ?
<poolie1> i'm 2 hours earlier, but it's still late and i should sleep
<poolie1> bialix, wow
<poolie1> i'm just going to mail S then sleep
<Tak> doesn't that just show it takes way more LOC to do the same thing using qt? ;-P
<bialix> Tak: :-P
<bialix> :-P :-P
<bialix> :-P :-P :-P
 * Tak moc < bialix 
<bialix> what is "moc <" ?
<Tak> hmm, doesn't qt still use moc?
<Tak> http://doc.trolltech.com/4.0/moc.html
<bialix> Tak: we're using PyQt
<Tak> so pyqt uses some dynamic stuff to avoid all the mocery?
<bialix> I guess so
 * bialix disappear
<luks> Tak: moc is just a way to have meta information about classes in a static language such as C++
<luks> Tak: you can get all that info from Python objects at runtime
 * Tak nod
<jam> luks: well given that moc is a precompiler, is it really even that?
<jam> I thought it was just a way to have nice syntax for slots
<luks> jam: it's not a precompiler
<luks> jam: it extracts info from .h files into _moc.cpp files
<luks> jam: the nice syntax is standard c++
<luks> (#defines)
<jelmer> Tak: sorry, no idea, haven't seen a crash in a while
 * Tak nod
<Tak> and the c#->c->python->c->python roundtrip is nice for debugging anyway ;-)
<jelmer> :-)
<divokz1> Could anyone point me to a resource on storing the current revision number in a file using a commit hook?
<divokz1> I tried making my own pre_commit hook, but it's one revision behind (the commit doesn't send the updated file)
<divokz1> Any ideas?
<andy_> I'm looking for some input on converting projects from svn to bzr.  I'm using nested trees to mimic svn:externals but am not sure which repo format would work best.  Seems like the options that I've tried that work are for me (v1.13.1) are:  rich-root (complains alot tho), i.9-rich-root and development-subtree.  Any recommendations/suggestions as to which format to use?
<divokz1> Google hasn't been helping either...
<Kinnison> divokz1: look for the keywords plugin
<cody-somerville> jam, I don't think lp #412657 is a dup
<ubottu> Launchpad bug 412657 in bzr "update fails when trying to lock master branch (in a readonly checkout) (dup-of: 412244)" [Undecided,New] https://launchpad.net/bugs/412657
<ubottu> Launchpad bug 412244 in bzr "unlock fails to unlock over FTP with Windows FTP server (Microsoft FTP Service IIS6)" [Medium,Confirmed] https://launchpad.net/bugs/412244
<james_w> cody-somerville: it's a dupe of something
<james_w> perhaps just not that one :-)
<james_w> let me find the correct one
<jelmer> andy_: nested trees don't work yet..
<jam> cody-somerville: update fails when updating from master branch
<jam> I'm pretty sure both are a dupe of a third bug
<jam> but perhaps I typed the wrong bug #
<jam> cody-somerville: bug #412223
<ubottu> Launchpad bug 412223 in bzr "bzr up locks master branch" [High,Triaged] https://launchpad.net/bugs/412223
<jam> though ISTR yet another bug
<jam> with this same basic issue
<jam> sorry about the noise of the wrong bug #
<cody-somerville> In this other case, was it working and then stopped?
<jam> cody-somerville: we changed normalization rules somewhere
<cody-somerville> jam, bzr hasn't been updated
<jam> so doing "bzr-old co $PROJECT; bzr-new up" was failing
<jam> cody-somerville: so sometime when it fails for you
<james_w> jam: I remember that other bug as well, but I can't find it either
<jam> try doing "cat .bzr/branch/branch.conf"
<jam> to see what we have recorded as the master branch
<jam> and I'm also 90% sure that all these failures will be found with branches with "~" in them
<jam> which is the bug
<jam> of course, all LP branches have ~ so that isn't a great discriminator
<andy_> jelmer: They've been working for me so far as long as I use rich-root, 1.9-rich-root or development-subtree and don't use the --reference option when doing a join.
<andy_> jelmer: I'm using v 1.13.1
 * Tak can't wait for externals=>nested-trees support in bzr-svn
<andy_> jelmer: so, are you saying that nested trees are unstable/should be avoided?
<andy_> anyone here using nesting successfully?
<cody-somerville> jam, the ones that work have ~ in them too :P
<jelmer> andy_: by-value nested trees should work and are stable
<jelmer> andy_: svn:externals is the equivalent of --reference
<andy_> jelmer: ahh...thanks for clarifying.
<jelmer> andy_: for by-value nested trees, use 1.9-rich-root
<jam> cody-somerville: out of curiosity, does it only break on projects that you don't have commit access to?
<jam> (aka readonly branches)
<jelmer> andy_: or just plain --default-rich-root
<jelmer> andy_: which is an alias for the default rich root format
<andy_> jelmer: thanks.  So, by-value nested trees keep a copy of the branched tree in the containing tree rather than just a pointer to it?
<jelmer> andy_: yes
<andy_> jelmer: any idea of a by-value tree could be converted later on when --reference becomes stable?
<jelmer> andy_: I don't think that would be possible
<cody-somerville> jam, Thus far yes. But its via read/write transport (ie. bzr+ssh and not http).
<andy_> jelmer: very helpful.  thanks.
<jelmer> andy_: of course, you would always be able to remove the by-value tree and add a by-reference nested tree
<andy_> jelmer: that would work fine for me, I think.
<jam> cody-somerville: it is a read-write transport of a readonly location
<jam> and the issue is probably that we are *always* locking the master
<jam> but only when it is a readonly does that fail
<jam> we have code that says "if update_branch.base == self.get_bound_location(): lock_read else: lock_write"
<cody-somerville> Why would it work and then just randomly stop?
<jam> I don't know why it would stop working without changing the bzr client in the meantime
<jam> the fact that unbind + bind fixes it
<jam> hints strongly about the bzr client issue
<jam> are you positive you didn't upgrade?
<cody-somerville> jam, I'll have someone from IS check
<jam> your bug report doesn't include the bzr version
<jam> vila: ping
<jam> in case you are still on
<vila> jam: pong
<jam> Are you still actively connected to Kerguelen?
<jam> (I had a network connection hiccup yesterday, which left Kerguelen thinking someone was connected)
<jam> and since there are 2 active connections
<vila> just connected a few minutes ago to look at the installer failures, did you do anything in the related directories ? (Just checking)
<jam> I can't even get to the login screen
<jam> I've been trying to fix file permissions
<vila> I didn't have any problem to connect
<jam> so that I can get 1.18rc1 built
<jam> are you connected as administrator right now?
<vila> on the shared/builbot/bzr/ directory ?
<jam> if so, can you go to task manager and close my connection?
<jam> vila: on 'shared' in general
<vila> jam: yes connected as admin
<jam> it should all be owned by Users
<jam> and writeable by Users
<jam> vila: should be Task Manager / Users "disconnect" or "logoff"
<vila> jam: you're connected as jameil right ?
<vila> jam: done
<jam> vila: yeah, unfortunately there are "disconnected but still running"
<jam> and there is "your connection died so you are still "connected""
<jam> if there are 2 active connections
<jam> nobody else can even log in
<jam> to kill the connection
<vila> about the access rights, admistrator thinks it has read-only access to the whole shared/buildbot/bzr hierarchy and that's wrong
<vila> jam: regarding the connection, I'm pretty sure I've been able to reconnect with rdesktop once
<jam> vila: I'm not really happy running "make" as Administrator anyway, is there a way we can change that?
<jam> vila: consider if you would run "make" as root?
<jam> vila: if you "close" the connection, the session stays in semi-active state
<jam> if your connection dies it stays in fully-active state (from what I can tell)
<jam> semi-active state lets me connect to the login, and start the session I had running earlier
<vila> jam: I agree about make, but the setup is wrong anyway and I can't find the right way to debug it remotely
<jam> fully active ends up running out of licensed connections and I can't even get to login to logout :)
<vila> jam: yeah, it was semi-active then
<jam> I find it odd that Administrator isn't in Users... but I should be able to set the perms for Admi
<jam> though I think I need to log in as Admin to do s.
<jam> so
<vila> jam: I logged of
<vila> jam: I logged off
<jam> vila: thx
<jam> vila: so where is the start point for buildbot (where does it decide what command to run?)
<jam> is that in 'master.cfg'?
<jam> or one of the slave configs?
<vila> master.cfg on the master host
<jam> vila: what is the lp branch for this stuff?
<vila> bzr info in shared/buildbot/bzr :-)
<vila> lp:~bzr-buildbot-net-dev/bzr-buildbot-net/trunk/
<jam> vila: so effectively, I'm just going to set Full Control to "administrator" and "users" for the whole "shared" and all subfolders
<jam> it will probably take a while
<vila> ok, thanks, I'll add 'not run as root' in the TODO anyway
<jam> vila: so your specific complaint is that "BzrBuildExtensions" is defined in master.cfg across all clients, and clients don't have a chance to customize t
<jam> the fact that PYTHON needs to be set, right?
<vila> my complaint is that I couldn't define such environment variable in the slave Makefile like I was able to do for all other slaves
<vila> I'd also like to define BZR_PLUGIN_PATH there you see..
<vila> I'm referring to the slave Makefile, not the bzr one
<jam> well, both "BzrBuildExtensions" and "BzrTests" are going to fail on kerguelen since
<jam> 1) 'make' will try to build using cygwin's python
<vila> yes
<jam> and
<jam> 2) 'python bzr selftest' ... will likely fail because it uses cygwin python
<vila> yes, that's a slave setup IMHO, that's what I want to debug locally before breaking everything on kerguelen :-D
<vila> s/slave setup/slave setup bug/
<jam> perhaps
<jam> certainly there are a few aspects
<jam> like ideally we would end up running the selftest on windows on py2.5 *and* py2.6
<jam> and possibly other platforms as well
<jam> Mac, certainly
<vila> jam: so far I've handle that at the slave level by saying that a given slave use a given python version
<jam> I don't know wether that is a different salve
<jam> or a different build on a given slave
<vila> both are possible
<jam> vila: so I finished with the perms update, I'll log in as me again
<jam> vila: out of curiosity, is buildbot a push or pull system?
<jam> (does the master connect to the client and tell them what to do, or do the clients connect to master and ask?)
<vila> jam: the client connect and the master ask :)
<vila> and the client use a keepalive mechanism to stay connected
<vila> jam: some perm error apparently :-/
<vila> s/some/same/
<jam> hm... I just gave Administrator Full Control over all subdirs of 'shared'
<vila> I can see that... but yet properties on shared/buildvot/bzr says Read Only :-)
<bpierre> hi
<jam> vila: so run as 'vila' instead of Administrator
<jam> hmm... maybe I only set it to Full Control for "Administrators" the group, not "Administrator" the user
<vila> jam: I'll try that
<jam> though I would have thought Administrator was in Administrators...
<jam> hi bpierre
<vila> or Admistrator is not part of Administrators :)
<bpierre> I think I saw mentioned in the mailing list a script for upgrading to 2a, with support for recursively updating a tree, do you know where I can find it?
<jam> bpierre: beuno or igc are probably the best to ask about that
<bpierre> jam: ok, thanks
<jam> sidnei: ping about buildbot
<beuno> bpierre, http://people.samba.org/bzr/jelmer/bzr-recursive-upgrade/trunk
<bpierre> beuno: thanks
<sidnei> jam: yo
<vila> jam: vila got Read Only too 8-(
<jam> sidnei: I'm getting this failure: http://paste.ubuntu.com/252107/
<jam> which is weird, because if I look in "build-win32/qbzr/" the only thing left in there is ".bzr"
<jam> (note that right now I'm trying again after deleting the whole qbzr dir)
<jam> sidnei: same result... :(
<jam> sidnei: and from what I can see now, there isn't even a qbzr dir around to uninstall from
<jam> hm... maybe it is the staging location?
<sidnei> jam: i suspect so
<jam> sidnei: "find build-win32 -name "qbzr-en.po" returns nothing
<jam> sidnei: same for "find . -name po"
<jam> ahh damn
<jam> I copied this directory
<jam> to save disk space
<jam> and it is probably thinking to re-use the old dirs in another build directory
<jam> I can delete .installed.cfg
<jam> though I'm guessing that means it will download everything again
<jam> which is what I was hoping to avoid
<jam> oh well, I'll start from scratch
<andy_> jelmer: any idea when by-reference nested tree support will be available?  I looked on site, but only could find that the effort started in 2006...
<andy_> jelmer: ... or where I can look to find out?
<jam> so I finally got to the point where I can build the win32 installer for 1.18rc1
<jam> anyone know if there is a new bzr-svn or bzr-rewrite or subvertpy I should watch out for?
<lifeless> no info, sorry.
<jam> yeah, I don't think there is anything, at least quick looks on launchpad don't show anything
<LarstiQ> jam: bzr-svn 0.6.4 is released
<SamB> LarstiQ: dude, wasn't that, like, days ago?
<jam> LarstiQ: thanks for the heads up
<jam> now if we could only get the Launchpad page updated when releases are made...
<jam> :)
<SamB> oh, I guess that's new for *windows* users ...
<SamB> jam: how is launchpad supposed to know there was a release?
<LarstiQ> jam: yeah sorry, still on my todo list
<jam> SamB: in the same way it knows about all the other ones listed here: https://launchpad.net/bzr-svn
<jam> hmm, I see an 0.6.4 there now
<jam> I wonder if somebody got poked into updating it :)
<SamB> I betcha it involves too much manual labour
<jam> lifeless: feel free to file the bug about reconcile on stacked repos, I'm just about at EOD, and trying to get the windows installers built
<jam> so... how should installers be named:
<lifeless> jam: sure, I'll file it so we don't lose it. I dunno if its a 2a blocker or not.
<jam> bzr-1.18rc1-1-setup.exe
<jam> bzr-1.18rc1-setup-1.exe
<jam> bzr-1.18rc1-1.setup.exe
<jam> and to go along with those
<jam> bzr-1.18rc1-1.win32-py2.4.exe
<jam> etc
<jam> I sort of like bzr-1.18rc1-setup-1.exe
<jam> but it doesn't translate well into the python standalone installers
<jam> or python installers I mean
<lifeless> bzr-1.18rc1-setup-1.exe
<lifeless> is what I like
<jam> lifeless: sure, but what about bzr-1.18rc1-1.win32-py2.4.exe
<jam> vrs bzr-1.18rc1win32-1-py2.4.exe
<lifeless> bzr-1.18rc1-setup-1.win32-py2.4.exe
<lifeless> ?
<jam> vs bzr-1.18rc1.win32-py2.4.exe
<jam> bzr-1.18rc1.win32-py2.4-1.exe
<jam> lifeless: so... 'setup' is the installer that installs bzr to Program files
<jam> w/o setup, is the ones that install it into C:\Python2.x
<jam> the "standard" python naming is
<lifeless> bzr-1.18rc1-standalone-1.exe
<lifeless> bzr-1.18rc1-py2.4-1.exe
<jam> bzr-1.18rc1.win32.py2.4.exe
<jam> So 2.4-1 certainly looks like a release of *python*
<jam> and not a version of the binary installer
<lifeless> true
<lifeless> bzr-1.18rc1-py2.4-setup-1.exe
<lifeless> bzr-1.18rc1-standalone-setup-1.exe
<lifeless> I think it would be nice to make the two more comparable to each other, which is what I'm fiddling with here
<jam> so the easiest thing to wedge into distutils is bzr-1.18rc1-1.win32.py2.4.exe
<jam> though you can write your own builder that overrides the naming function
<lifeless> ah, and we can't just rename after?
<lifeless> or, if we do, does that break easy_install magic?
<jam> lifeless: we *can* and to date I do it all manually
<jam> I'd like to have it slightly more automated
<jam> bdist_wininst has a function "get_installer_filename" where it does:
<jam> fullname =
<jam> def get_fullname (self):
<jam>     return "%s-%s" % (self.get_name(), self.get_version())
<jam> and then
<jam> installer_name = os.path.join(self.dist_dir,
<jam>                               "%s.win32-py%s.exe" %
<jam>                                (fullname, self.target_version))
<jam> 'get_version' just returns what was passed in the ARGS of setup()
<jam> so it is easy enough to change that
<jam> and also means that the *installer* will say that this is "bzr 1.18rc1-1"
<mac9416> Hello, how can I overwrite a branch?
<lifeless> push --overwrite ...
<mac9416> lifeless, sorry, wasn't paying attention. Thanks
<mac9416> Worked fine
<Noldorin> lifeless: ping
<Noldorin> lifeless: time not good for you?
#bzr 2009-08-13
 * kfogel is away: Smithwicks w/ Omar
<lifeless> Noldorin: hi
<lifeless> Noldorin: I put some other ideas in the bug
<poolie> emmajane: thanks for the nice update
<lifeless> spiv: ping
<spiv> lifeless: pong
<lifeless> I have an odd failure
<lifeless> which may collide with your patch
<lifeless> branch(Pdb) wt_a.branch
<lifeless> RemoteBranch(bzr-v2://127.0.0.1:59801/extra/a/)
<lifeless> (Pdb) wt_a.branch
<lifeless> RemoteBranch(bzr-v2://127.0.0.1:59801/extra/a/)
<lifeless> -> branch_b = wt_a.branch.bzrdir.sprout('b', revision_id='1').open_branch()
<lifeless> (Pdb) branch_b
<lifeless> BzrBranch7('file:///tmp/testbzr-Hs3ARm.tmp/bzrlib.tests.per_branch.test_branch.TestBranch.test_clone_branch_parent%28RemoteBranchFormat-v2%29/work/b/')
<lifeless> (Pdb) branch_b.repository.chk_bytes.keys()
<lifeless> set([])
<lifeless> wt_a.branch.repository is a 2a repo
<poolie> hi lifeless, spiv
<sque> hello! I am running ubuntu 8.04.3 server with bzr ppa and installed loggerhead
<sque> when I try to view file contents from the webbrowser I get an exception from loggerhead
<sque> An unexpected error occurred whileproccesing the request:
<sque> AttributeError: 'module' object has no attribute 'ProgressBarStack'
<sque> What is the problem?
<lifeless> sque: you either need a newer loggerhead or an older bzr.
<spiv> lifeless: perhaps!  I'm not sure.
<lifeless> spiv: can I call?
<spiv> Sure.
<sque> ii  bzr                                     1.17-1~bazaar1~hardy1                   easy to use distributed version control system
<sque> ii  loggerhead                              1.10-1                                  Web viewer for Bazaar
<sque> those are the version that are currently installed and they both come from this official ppa https://launchpad.net/~bzr/+archive/ppa
<sque> you mean that they are not compatible?
<spiv> Yes; that version of Loggerhead is too old to work that with version of Bazaar.
<lifeless> spiv: found it I think:
<lifeless> 1759 ->         source = repo._get_source(self.to_format)
<lifeless> 1760            if isinstance(source, RemoteStreamSource):
<lifeless> 1761                return repository.StreamSource.get_stream(source, search)
<lifeless> 1762            return source.get_stream(search)
<lifeless> spiv: have you changed that?
<spiv> I don't think so, let me check.
<lifeless> spiv: I've put up a merge proposal
<spiv> No, I didn't change that.  It does seem like an obvious problem, though!
<emmajane> poolie, you're welcome for the update. :)
<sque> beuno: ping
<igc> morning all
<mozmck> on ubuntu 9.04, I installed the latest bzr-gtk from source as described on the website.  but when I try to run olive-gtk is says "ImportError: No module named gtk.ui"
<mozmck> am I missing something?
<AfC> mozmck: a good technique in these cases is to install a -dev package of what you are trying to build first, to make sure you have all the dependencies
<mozmck> I don't see a -dev package for bzr-gtk.  I have the bzr ppa in my repositories list.
<meoblast001> is it hard to set up a bazaar server?
<meoblast001> i'm thinking about doing it on my server for backup of my source files
<igorgue> hi, to install a dependency I use: pip install -e 'bzr+http://bazaar.launchpad.net/~txamqpteam/txamqp/trunk/#egg=txamqp'
<igorgue> do you know how to add that to my setup.py?
<_habnabit> So, I'm not clear exactly what a 'branch' is or how branches can be subdivided. I'm trying to migrate from svn to bzr, and I've created a repository with 'bzr svn-import'. I made a new repository to work in, and I tried to make a branch with just one project from the svn repository, but I get an error saying that its directory is not a branch. I can only make a new branch from the entire svn trunk.
<_habnabit> Should each separate project have its own branch?
<spm> _habnabit: i hit something similar when I first migrated. this may help: http://www.stedee.id.au/2008/11-06/manually_migrating_subversion_repository_launchpadbzr ??
<spm> _habnabit: the key part of that for you would be the: svn2bzr.py --scheme=trunk --exclude=branches --exclude=tags <== to only get what you want
<_habnabit> Well, what's the difference between using svn2bzr and bzr-svn? Aside from that it seems like it's more one-way.
<_habnabit> I'm not sure if it would solve the issue of trying to split my svn trunk into separate bzr branches.
<spm> I tried bzr-svn and it didn't work well for me - then. svn2bzr did. ymmv.
<bob2> branches in bzr and svn are pretty similar in concept, but with the proviso that in bzr you can't check out arbitrary dirs like you can in svn
<_habnabit> So with bzr, I would want separate branches for each project.
<bob2> well, separate branch for each branch of each project
<lifeless> _habnabit: a branch is one line of development for a project
<_habnabit> Right.
<lifeless> _habnabit: and its not subdividable to subdirectories
<_habnabit> Okay.
<_habnabit> How do I deal with this, then? They are in subdirectories at the moment.
<_habnabit> It looks like svn2bzr might help, hm.
<bob2> bzr-svn import lets you explain how the svn repository is layed out, too
<lifeless> spiv: ping
<spiv> lifeless: pon
<spiv> pong, even.
<lifeless> did you do anything along the lines of getting xml inventories from CHK repos?
<lifeless> turns out we have to implement it
<spiv> No, but I believe John did for the bundle code.
<spiv> IMBW.
<lifeless> ah yes, thats what was tickling my memory
<vila> hi all
<lifeless> EODing
<poolie> hey vila
<vila> hi poolie
<poolie> vila, did you mention the existence of the build farm yet?
<poolie> it might be god
<poolie> good*
<poolie> liw just asked about whether we had one
<vila> ok,
<vila> Hey guys, we have a build farm running the test suite on a couple of slaves !
<poolie> :)
<vila> well, the truth is karmic fails and the windows slave setup is broken :-/
<vila> poolie: more seriously, what do you have in mind ? An announce on bazaar@lists.c.c ?
<poolie> yes :)
<poolie> that's no good about karmic
<poolie> liw mentioned that too
<vila> Did you read the discussion with jam about not allowing forcing builds from the public server ? Do you agree with my proposal ?
<poolie> you should file a bug?
<poolie> i did read it
<poolie> um
<vila> the karmic failures may be minor, I just haven't dig them yet
<vila> jelmer: ping, BB is down, care to review my patch for bug #403340 anyway ?
<ubottu> Launchpad bug 403340 in xsane "Sane does not recognize Epson Corp. CX9400Fax out of the box" [Undecided,New] https://launchpad.net/bugs/403340
<vila> cough bug #403430
<ubottu> Launchpad bug 403430 in bzr-gtk "bzr diff fails with traceback and error 'module' object has no attribute 'get_application_name'" [High,Fix committed] https://launchpad.net/bugs/403430
 * igc dinner
<poolie> hm
<lifeless> poolie: how was the conference?
<poolie> hasn't happened yet
<lifeless> ah
<poolie> it's on the weekend
<poolie> am just working from here, mostly on trying to get my presentation to feel more coherent
<lifeless> laserpres!
<poolie> the short story is
<poolie> laserpres?
<poolie> anyhow the short story is: open source development is fun and fulfilling,
<poolie> being done entirely over the net it's very much mediated by and shaped by the tools
<poolie> so the point of our work is to make tools that fit how people work and help them work better
<poolie> specifically: it's pretty amazing when people translate your software or documentation into languages you can't speak yourself
<lifeless> laserpres<- coherent presentation
<lifeless> and that story sounds compelling
<poolie> 2- open source projects are so much more open to bug reporting that it's easy to get swamped, and bugs can be very fragmented
<vila> poolie: regarding bugs: I think it's part of the open thing, in the long term they *will* be fixed, because the underlying assumption is that FOSS *cares* about software without bugs and dislike the tendency to make users think that buggy systems/tools are to be *expected*
<poolie> 3- if you invite people to help, you're obliged to accept that help - don't drop patches but put them through some kind of coordinated merge review
<poolie> mm
<poolie> well
<poolie> neither open nor closed projects fix all their bugs
<poolie> and i'm not convinced closed projects care any less
<poolie> at least, the best projects of either type probably care the same amount
<vila> poolie: not IME, but don't let me disturb you
<poolie> well
<poolie> so the question is, what should i say about either how to handle bugs better, or what launchpad/bazaar do to help you handle bugs better
<lifeless> anecdotally
<lifeless> I just found that a patch I put up for cppunit 4?maybe more years ago - still in the bug tracker. 'postponed'
<vila> lifeless: at least it's there and others can use it
<poolie> well
<poolie> kinda
<vila> lifeless: it's not as good as if it has been integrated, but it's better than not available at all
<poolie> though actually stephane did dig a patch out of the svn bug tracker a while ago
<lifeless> I posted a dup of my patch - it was so long ago I'd forgotten that I'd posted it there ;)
<lifeless> anyhow
<vila> :-D
<lifeless> linking bugs to code, management of the data is Good Stuff
<awilkins> I do like the "proposed for merging" branches thing
<lifeless> code review tied into scm and bugs is good
<awilkins> We have a meeting about dev practices this morning and I fully intend to wave Launchpad around given the opportunity
<awilkins> I just wish the network wasn't so crapulous here or I'd have an instance running by 1100
<lifeless> :)
<awilkins> Have all the sources just need the deps...
<lvh> hi
<lvh> I have two ssh keys, one with password and one without. I'd like to use the one without password as a signing key. Is that a bad idea?
<lvh> also, am I supposed to get ssh to use the different key, or is there some way to get bzr to ask for a different key? (the former is how git does it)
<krisives> How can I branch a repo into a target directroy?
<krisives> I want to do `bzr branch /from/here /into/here` without it creating a new sub directory *inside* "here"
<RAOF> krisives: Is there anything wrong with "bzr branch /from/here /into"?
<krisives> I am branching user directories
<krisives> So what I am trying to do basically is `bzr branch /home/developer /home/me`
<krisives> Get it?
<lifeless> krisives: you can do 'bzr init; bzr pull URL' as an alternative
<krisives> Will it still be a repo?
<krisives> ty, that seems to work well
<vila> jam: ping, what did you do ? windows builds works again 8-/ (and yes, I half expect that you will answer: nothing)
<corporate_cookie> it looks like the default version of bzr in Ubuntu Server LTS 8.04 is 1.3.1; is there a more recent supported version of bzr ?
<beuno> corporate_cookie, you have the official PPAs, yes
<vila> corporate_cookie: https://edge.launchpad.net/~bzr/+archive/ppa ?
 * beuno waves at vila 
<corporate_cookie> are they 'supported' as in can I tell my boss I can call canonical for 'help'  ?
 * vila waves back :)
<vila> corporate_cookie: AIUI yes
<corporate_cookie> thanks : )
<corporate_cookie> hooray : )
<vila> pfew, that one was easy :-)
<corporate_cookie> hehe thanks vila
<lvh_> hm
<Colonel-Rosa> What's the syntax for commit a spefic file?
<Colonel-Rosa> bzr commit -m "message" /file/path
<Colonel-Rosa> right?
<luks> yes
<Colonel-Rosa> Cheers
<davidstrauss> Does anyone know how to take old-format branches that were upgraded to get rich root support to properly support "join"?
<kfogel> I need to convert an older branch to be a branch in a new 2a repository.  Details here; see question at end: http://paste.ubuntu.com/252586/
<kfogel> james_w: (am I on the right track above?)
<james_w> kfogel: yeah
<james_w> but I can't answer your question fully, sorry
<kfogel> james_w: it's that easy, huh?  Great! :-)
<kfogel> james_w: np, thanks for looking.
<james_w> I thought there was a "migration guide" knocking around somewhere or something
<kfogel> let me see
<beuno> kfogel, hold on
<beuno> why aren't you doing bzr upgrade?
<beuno> you should reconcile *before* upgrading
<kfogel> beuno: thank you.  (Er, that's why I'm *asking*.)
<kfogel> beuno: IMNSHO bzr ought to notice and just DTRT, but since it apparently won't, I'll dance the upgrade dance.
<beuno> kfogel, please nag the bzr list about this
<kfogel> beuno: so, reconcile the old tree first; then bzr upgrade it; then branch it into the new shared repository
<beuno> I've been tryingo the the upgrade story straight
<beuno> kfogel, you can just upgrade the repo
<kfogel> beuno: orig tree is not in a shared repo
<kfogel> beuno: I mean, I could put it in one, just for this, but if that step can be avoided, then even better
<beuno> kfogel, https://lists.ubuntu.com/archives/bazaar/2009q3/061057.html
<beuno> kfogel, gotcha
<beuno> yes then
<kfogel> beuno: so if this works, I'll just write a bzr wiki page on it and post that
<kfogel> beuno: thanks for the link!
<beuno> kfogel, also: http://people.canonical.com/~ianc/doc/en/upgrade-guide/
<kfogel> beuno: aaaaah
<beuno> kfogel, also, https://lists.ubuntu.com/archives/bazaar/2009q2/058377.html
<beuno> actually
<beuno> no
<beuno> ignore
<beuno> that
<kfogel> beuno: no, that one does have a section on data migration
<beuno> Peng_ wrote something to the list
<jam> vila: for windows builds working... it may be that I had created a hard link, which I subsequently deleted
<jam> that, at least, is my best guess
<jam> I also submitted some patches to the builder
<vila> jam: k, thks for telling, anyway, I should have an XP setup locally soon (without cygwin) and will see from there
<sque> Hello
<sque> Can someone plz explain the main concept of how to create a multi-user bzr server?
<sque> with different credentials for each user
<kfogel> beuno-afk: I'm thinking maybe this is the page that needs to be updated: http://bazaar-vcs.org/FormatUpgrades  :-).
<Tak> sque: super easy with ssh
<sque> Tak: I have setup bzr+ssh at the moment and have created one user
<sque> Tak: and the repository exists in /bzr. till now I can give this one user to all commiters to commit changes. I thought to create different users but how it will manage the file permissions?
<Tak> it just uses the native file permissions, doesn't it?
<sque> Tak yes it does. But if user A commits changes to repository user B will be unable to change some files. is this normal?
<sque> Tak Or I bazaar repository can work with different file owners?
<Tak> you can set the permissions however you want
<Tak> world-writable, writable only by a developers group, project-specific write permissions, ...
<sque> I think I am missing something here...
<vila> jam: just see revno 4603 (your changes to the builder), the build worked before that (4602 at least, but I doubt that's related), so that hard link you're talking about sounds like a better explanation (which was it by the way ?)
<sque> Tak I created a test branched did many commits from a root user and normal user... to see if it would have permission problems, but as I see bazaar does not change files it creates files for each new commit so alla the commits are readable from any user
<jam> vila: I had hardlinked the build-win32 directory to try to avoid having 10 copies of all the download files everywhere
<jam> but it looks like windows + hard links + acls just doesn't get along very well
<vila> haaa, and you tried to use the one in the buildbot hierachy ?
<sque> Tak I though it was working as svn that the repository should not be written by different user otherwise it would be fucked up.
<jam> vila: something like that, yeah
<vila> jam: right, that matches the fact that I had to delete a couple of files around,
<vila> and why the failure was transient
<vila> jam: by the way, the test farm now run selftest with/without locale so we should be able to remove that for pqm, shouldn't we define an explicit target for pqm by the way...
<jam> vila: you mean something other than "make check" ?
<jam> And yes, we probably could remove the second pass for PQM as long as we update documentation and general workflow
<jam> to make people aware that some tests will be run asynchronously
<jam> i'm guessing we aren't 100% ready to make the switch yet
<jam> but we're probably getting close.
<vila> jam: yeah, something like 'make pqm' with pqm: check to describe today behavior but make it clearer that it's the pqm rule
<jam> vila: just call it "pqm-check"
<vila> right, the missing bit is removing --no-plugins :-) See bug #412930
<ubottu> Launchpad bug 412930 in bzr "BZR_PLUGIN_PATH should be set by distributions" [Medium,Confirmed] https://launchpad.net/bugs/412930
<vila> jam: yup
 * vila EODing
<jam> so... they *should* be running with plugins
<jam> and I'm not sure I agree about bug #412930
<jam> but that is what discussion is for :)
<elmo> how do I turn on http debugging?
<kfogel> elmo: 'bzr help debug-flags' ?
<kfogel> elmo: looks like 'bzr -Dhttp'
<elmo> kfogel: thanks, I id RTFM but it doesn't even mention the word 'debug' :(
<elmo> also -Dhttp doesn't appear to do anything
<kfogel> elmo: Well, I didn't say it worked :-).
<kfogel> elmo: wireshark?
<fullermd> It worked last time I tried it (which admittedly, was a year or two ago, but...)
<vila> elmo: -Dhttp will write all HTTP headers to .bzr.log
<vila> can someone confirms that there are problems with bazaar.launchpad.net since ~1h ?
<kfogel> vila: try in #launchpad too?
<vila> kfogel: was just doing that :-)
<divokz> I have a question about the "Advanced shared repository layouts" (as found in the User Guide).  How are these created on the server?  Do I just init-repo and mkdir directories like "branches", "tags", etc?  I was under the impression that this could be done in a space efficient way, but I'm having a hard time finding anything.  Is there not a command just to pull down the entire tree, including "trunk", "tags", "releases", etc?
<divokz> I've heard of stacked branches, but if I make stacked branches on the server, do they pull down the branch and the stacked-on repository?
<divokz> We have a lot of data, so space can be a concern
<garyvdm> divokz: If you have a shared repository, that will share most of the data amongst different branches (that are in the shared repo.)
<garyvdm> So creating a new branch won't consume alot of space.
 * garyvdm looks at "Advanced shared repository layouts"
<divokz> garyvdm: so if I do `bzr init-repo` and then make branches inside there, I'll get the behavior I'm looking for?
<divokz> `bzr init-repo project_name`
<divokz> `cd project_name`
<garyvdm> bzr branch
<garyvdm> yse
<garyvdm> yes
<divokz> okay
<divokz> and then, if I want a features dir, I just `mkdir features`, `cd features`, `bzr branch ../trunk some_feature` ?
<divokz> Won't I have to check out each branch on a local machine separately?
<LarstiQ> divokz: yes, although I'd start out with less hierarchy and just 'bzr branch trunk some_feature'
<garyvdm> You can just do  bzr branch trunk some_feature project_name
<garyvdm> You can just do  bzr branch trunk some_feature *in* project_name
<LarstiQ> divokz: ehm, I'd do the branching locally
<divokz> LarstiQ: but what if the branches need to be shared?
<garyvdm> divokz: Have a shared repo on both the server and your computer
<LarstiQ> divokz: then you share them when you reach that point. You are right that there is no 'repository cloning'
<divokz> LarstiQ: do you mean without storing them on the server?  (decentralized)
<LarstiQ> divokz: if you feel more comfortable with storing them on the server, then do that :)
<divokz> LarstiQ: :)
<LarstiQ> divokz: but if it is a short lived feature branch only hacked on at a sprint, why bother, it will be merged soon anyway
<divokz> Yeah, I'd use a local branch in that case
<divokz> I'm talking about something longer
<LarstiQ> divokz: sure, then it can make sense
<divokz> But to check them out, I have to get each branch individually, correct?  (what you meant by 'no repository cloning'?)
<LarstiQ> divokz: you have to get each branch you want individually, yes
<divokz> okay, great -- I've been flipping through documentation for too long without finding this stuff out
<LarstiQ> divokz: which is what I mean with no 'repository cloning'
<LarstiQ> divokz: a repository is only a common revision store
<divokz> Thanks, LarstiQ and garyvdm -- very helpful
<garyvdm> divokz: Maybe be you misunderstand the "shared" in "shared repository". The data is shared by the different branches in side the shared repo. A shared repo is not nesserly shared as in accessible by other people.
<divokz> garyvdm: yes, I did misunderstand that
<divokz> garyvdm: so what does `bzr init-repo --no-trees repo_name` do in relation to that?
<garyvdm> A branch normally contains a Working tree, a list of tags, and a pointer to the latest revision.
<garyvdm> You can also have a branch with no working tree.
<garyvdm> if you do bzr init-repo --no-trees, by default branches won't have a working tree
<divokz> so, I would want that if I'm storing branches inside 'repo_name'?
<garyvdm> A working tree is not the same thing as a repository
<garyvdm> A working tree is the copy of the files on the disk, that you can edit, and then commit to the repository.
<divokz> yes...
<divokz> I guess I don't understand why else you wouldn't want to have a working tree in a branch
<garyvdm> A branch with no working tree and be pulled to a branch with a working tree
<garyvdm> cases where it is usefull:
<garyvdm> on a server, we no one will be editing the working tree(wt), only pulling from their branches.
<garyvdm> or
<garyvdm> If you have one branch the you work in, and many other branches that you switch between
<garyvdm> You bind the one that you work in to another on that has no working tree.
<garyvdm> That way, you can have lots of branches, one working tree
<divokz> could you point me to an example of this workflow?
 * garyvdm looks at the docs
<divokz> Or tutorial, etc -- I'm used to using more of the svn-oriented workflow
<divokz> (thanks)
<garyvdm> Can't find something in the docs, let me type up and example
<garyvdm> *an
<garyvdm> divokz:http://paste.ubuntu.com/252737/
<divokz> garyvdm: I just *finally* found http://bazaar-vcs.org/SharedRepositoryTutorial -- it's helpful
<divokz> garyvdm: thanks
<garyvdm> I actual use that example I gave you alot.
<divokz> garyvdm: I think that makes sense
<divokz> I'm saving it at any rate :)
<garyvdm> divokz: If you are not branching from somewhere else, I would recommend using the 2a format. It uses much less space.
<garyvdm> if you are branching from some where else, then stick with the format of the branch you are branching.
<divokz> somewhere else meaning a 3rd party?  Or just a separate machine?
<garyvdm> 3rd party
<divokz> k
<divokz> I'll look into that -- could be helpful for some large datasets
<garyvdm> If it's on a separate machine, you can just upgrade that branch too.
<garyvdm> The reason why I say not to do it from a 3rd party, as that the conversion is one way.
<divokz> makes sense
<garyvdm> s/as/is
<Noldorin> lifeless: pingf
<Noldorin> ping*
<lifeless> moin
<lifeless> hi Noldorin
<Noldorin> hi lifeless
<Noldorin> how are things?
<lifeless> ok
<Noldorin> :)
<Noldorin> you got a few free minutes now?
<lifeless> I will in 20 or so
<Noldorin> ok cool
<Noldorin> i'll message you then
<Noldorin> lifeless: so i noticed your updates to my bug report
<Noldorin> looks like a pretty completely summary now :)
<Noldorin> lifeless: was wondering where you wanted to proceed from here though
<_thumper_> how can I find out which was the last mainline revision that a particular file was modified in?
<jam> _thumper_: I seem to be getting a timeout when accessing http://bazaar.launchpad.net/~jameinel/bzr/1.18-lock-warnings/.bzr/branch/format
<jam> is something going on with LP right now?
<thumper> jam: yes
<thumper> it's minorly fucked
<thumper> we're working on it right now
<jam> k
<Noldorin> lifeless: you there?
<lifeless> Noldorin: hi yes, been doing reviews; more than I expected :)
<lifeless> Noldorin: someone needs to follow through on the tests I've proposed in the bug report
<lifeless> hi jam, thumper
<Noldorin> lifeless: right, ok
<Noldorin> lifeless: so no more suggestions for the moment?
<Noldorin> i have the source on this PC
<Noldorin> if you want to do any more tests
<lifeless> not interactively; got a _lot_ to do to get 2.0 out the door; I'll monitor the bug, and if I can find the time put a patch up to do the read-back test
<lifeless> you could do that yourself fairly easily I suspect
<lifeless> there is a function in that file that the lock object uses to check that its in the right place on disk and has the right nonce
<lifeless> calling that function right after the rename of held to the tmp-for-unlocking would be useful
<lifeless> with a try;
<lifeless>     ...rename...
<lifeless> except errors.BzrError:
<lifeless>     pass
<lifeless> else:
<lifeless>     print "lock still in place after rename-to-unlock"
<Noldorin> lifeless: ok, i'll give that a go.
<Noldorin> thanks
<lifeless> I would like to spend more time myself on fixing this, but - 2.0 calls. Sorry!
<Noldorin> lifeless: that's fair enough. i look forward to trying v2.0 anyway :)
<Noldorin> maybe if we figure this out in time, you can encorperate the fix?
<lifeless> Noldorin: I'd be delighted to
<garyvdm> Is it ok (provided all test pass) to change a public method from returns [] to a generator (yield x)? Or should I create a new method iter_xxx?
<garyvdm> The method in question is Repository.find_branches
<james_w> "bzr: ERROR: Cannot commit from a lightweight checkout to a stacked branch. See https://bugs.launchpad.net/bzr/+bug/375013 for details."
<ubottu> Launchpad bug 375013 in bzr "lightweight checkout commit to a stacked branch does not work" [High,Triaged]
<james_w> but I'm not in a checkout!
<james_w> is that an overzealous check, or is the message unclear?
<lifeless> james_w: its a little unclear. You're in a stacked branch locally, right?
<james_w> stacked against a remote branch
<lifeless> thats been causing corruption for quite some time
<james_w> Standalone tree (format: unnamed)
<james_w> Location:
<james_w>   branch root: .
<james_w> Related branches:
<james_w>   parent branch: bzr+ssh://bazaar.launchpad.net/~dmitrij.ledkov/xiphos/main/
<james_w>      stacked on: bzr+ssh://bazaar.launchpad.net/~dmitrij.ledkov/xiphos/main/
<lifeless> it doesn't work, and will give ACF errors
<james_w> I'm actually testing due to bug 413291
<ubottu> Launchpad bug 413291 in bzr-builder "Fails to merge a stacked-on branch" [Undecided,New] https://launchpad.net/bugs/413291
<james_w> back in a bit
<garyvdm> Never mind about my question. There are test fails, so I'm going to add iter_find_branches
<garyvdm> Or should that be iter_branches?
<igc> morning
<lifeless> hi igc
<igc> hi lifeless
<garyvdm> Hi igc, lifeless
<igc> hi garyvdm
<lifeless> hi garyvdm
<lifeless> need more people to say hi to
#bzr 2009-08-14
 * fullermd didn't get said hi to   :(
<jfroy> Can aliases override commands?
<james_w> yes
<fullermd> For instance, I've aliased 'rm' to 'rm --keep' since the option was added.
<jfroy> mmmm
<thumper> commit to commit --strict :)
<thumper> now...
<jfroy> yes I've just confirmed
<fullermd> 'course, maybe it's a bug that options aren't recursive so that actually works   ;)
<jfroy> I saw some revert backup files in a directory
<thumper> I'm trying to find the revno on trunk that introduced a particular change
<jfroy> and I have revert = revert --no-backup
<jfroy> was wondering if it wasn't working
<jfroy> but I guess they were old
<jfroy> thumper: annotate should be able to get you the revno at which a particular line was last modified
<jfroy> (or a list of revnos?)
<thumper> it gives a dotted revno
<thumper> I want the mainline revno
<jfroy> aaah
<fullermd> You'd have to track forward to where it was merged.
<jfroy> so it was modified in a merge revision and you want the merge revision?
<jfroy> yeah
<fullermd> Though ISTM there was some discussion about a flag to annotate to do just that...
<jfroy> *in a merged revision
<jfroy> is there a way to list merge revisions, incidentally
<lifeless> james_w: hi
<james_w> hey lifeless
<lifeless> james_w: so where/how are you using stacked branches?
<james_w> in bzr-builder
<james_w> using shared-repos is a pain, so stacked branches seemed the obvious choice
<james_w> it's just doing it as it needs the tree at minimum, and then perhaps enough history to do a merge
<james_w> but never full history
<james_w> it's not necessarily the best solution though
<lifeless> there is significant work needed in bzr to fix this bug
<lifeless> we're moving to shared repos or something like it as the main way of working
<lifeless> and downloading all the history should be faster than stacking anyway
<lifeless> actually thats the key point
<lifeless> stacking -> VFS operations -> slow.
<lifeless> stream all history -> fast.
<lifeless> stacking with a local tree requires downloading all the tree data over vfs *anyway*
<lifeless> so ignoring shared repositories, not stacking should be faster in this use case regardless
<AfC> bzr-buildbot-net... a botnet for Bazaar? Cool. Er, um.
<AfC> :)
<poolie> hello all
<lifeless> hi
<poolie> how's stuff?
<poolie> it's hot and humid here
<poolie> more humid than hot though
<lifeless> well
<lifeless> I've been landing lots of little 2a-default fixes
<lifeless> and spivs network delta thing is landable now
<poolie> ah that is good
<lifeless> I spent some time with the u1 folk this morning - they are fsyncing in their dirstate equivalent... and its slow ;)
<poolie> heh
<poolie> i guess at least they know what platform it's running on
<poolie> well, kinda
<lifeless> lynne, stephane and I are doing yum cha & a movie on sunday; the hoyts website is _terrible_
<spiv> Landable, and in PQM's queue!
<poolie> that's nice
<poolie> woo
<lifeless> jam: don't suppose you are still around
<lifeless> jam: WT3.update_basis wants xml inventories from the repo
<poolie> lifeless: generally i think fsync is a poor deal: may not give you much protection and slow with it
<lifeless> yep
<poolie> one property we can rely on is that files written a long time ago and not touched are unlikely to be affected by future writes
<poolie> only by media failure
<poolie> so something like obsolete_packs feels write except
<poolie> - it might be nice not to remove them at all
<lifeless> right? :)
<poolie> heh, thanks freud
<poolie> and s/remove/move
<poolie> - it would be good to automatically detect the latest consistent state, without relying on any fs access
<poolie> blah my fingers are flaky today
<poolie> i meant, without relying on any fs ordering guarantees
<lifeless> yes
<lifeless> thats the tricky bit
<poolie> conceptually if you could read the whole file and compare it to a hash at the end
<poolie> that would get away from assuming that if a file's been renamed, all the data previously written to it made it to disk
<lifeless> oh, complete tangent - http://eu.squid-cache.org:8081/
<poolie> and you wouldn't need to sync
<lifeless> thats the squid hudson instance
<lifeless> what I'd like to get away from is the root node
<lifeless> its the only really fragile bit today
<lifeless> (not that its failed ever as far as we know)
<poolie> meaning the pack names?
<lifeless> .bzr/repository/pack-names, yes
<poolie> mm
<lifeless> I don't mean 'dont have a root node'
<poolie> the other thing that's reasonable to assume is that the fs can keep its own structures coherent, specifically directories
<poolie> but then you get into trouble with places that can't list directories, so it may not help much
<poolie> it's something to think about for wt metadata at least
<lifeless> wt metadata is less of a problem I think
<lifeless> much less at stake, and less likely to be over e.g. http
<fullermd> Corrupted dirstate would be even less of an issue if we had a revert --blat-me-out-a-fresh-dirstate-already...
<lifeless> fullermd: well, there are things that dirstate does today we will definitely fix ;)
<poolie> true
<lifeless> fullermd: but over and above that there are cases repositories [and branches] are expected to handle gracefully that wt's aren't...
<fullermd> I mean, you'd lose add's...   no big deal.  Lose rm's with the file still around...  not too bad.  Lose mv's...  that's the big hiccup.
<lifeless> or aren't-so-much
<fullermd> But when your alternative is to sit around with every op blowing up on the dirstate, or creating a new checkout and manually moving files around to simulate it, as people get told to do...
<poolie> rebooting karmic, biab (i hope)
<poolie> fullermd: i agree that revert op would be good
<poolie> thought it's kind of a kludge
<fullermd> Oh, it totally is.  But I like software that gives me big hammers to power through unpleasant situations once I'm in 'em.
<lifeless> hmm, do you use BSD?
<lifeless> :>
<fullermd> Sure, but that's not powering through; BSD is dying, everybody knows that.
<lifeless> oh
<lifeless> what BSD flavour/version do you use?
<fullermd> (and it's really BAD at it too, 'cuz it's been doing it for more'n a decade, and it's still twitching.  Just can't do ANYTHING right...)
<fullermd> I'm on Free.
<lifeless> (given that macosx has ~= desktop share with linux, its hardly dying)
<lifeless> what version?
<fullermd> FreeBSD 8.0-BETA2 #0: Sat Aug  1 04:27:00 CDT 2009     to be Pacific.
<lifeless> and what arch
<lifeless> care to run a squid buildslave
<fullermd> (RELENG_7 from Feb on another box, an old REL_6 elsewhere....   bunches of 'em)
<lifeless> we have 6.4 under test
<fullermd> Workstation's amd64.
<lifeless> nothing recent
<fullermd> Oh, I can do occasional build/report type things.  Not really in a position to lay out automation, though.
<lifeless> http://wiki.squid-cache.org/BuildFarm
<lifeless> read the 'Activating a slave machine (as the machine owner)' section
<lifeless> if that sounds ok; then woot
<lifeless> and if you want to run it sporadically thats fine too
<fullermd> Hm.  Well, maybe I'll get a chance to look more at it.
<fullermd> It'd be nice to have some ballparks on resource utilization involved on that page.
<lifeless> theres ~ a commit a day
<lifeless> a build can be as short as 30 minutes
<fullermd> What does a run eat, though?  50 megs of disk?  2 gig?  Does it churn the CPU for 10 minutes, or kill the IO subsystem for an hour?
<lifeless> good questions
<lifeless> the build includes make distcheck
<lifeless> and some tests
<fullermd> 3.1.0.13 build takes
<fullermd> 133.100u 40.812s 2:57.68 97.8%  6213+2442k 0+50io 997pf+0w
<lifeless> thats not the autotest :)
<lifeless> which does some more work
<fullermd> Yah, I expect so, seeing ~30+ minute times in some clicking around the buildfarm thing
<lifeless> the 2h one is a nuts slow machine
<lifeless> # du -sh 3.HEAD-i386-FreeBSD-6.4
<lifeless> 119M    3.HEAD-i386-FreeBSD-6.4
<lifeless> we do a minimal build
<lifeless> and a build with everything we can turn on turned on
<jam> lifeless: so I think you're saying that WT3 + 2a is broken... IIRC the WT3 code can handle when the basis inventory is not present, and just fetch it from the repo.
<jam> So can we just have it skip caching the inventory?
<spiv> jam: btw, I'm not sure exactly what you fixed in InterDifferingSerializer recently, but I still see stacking-related test failures with a 2a target if I use IDS.  Your test changes don't notice, but assertCanStreamRevision does.
<spiv> jam: so I suspect something still isn't quite right.
<jam> spiv: I won't say I caught everything, but I certainly made it a lot better
<spiv> Oh, I don't doubt you made it better :)
<jam> given that your change to IDS was causing it to store the current inventory under the name parent_id
<lifeless> jam: we have tests that test that it caches eventually
<jam> lifeless: if self.branch.repository.supports_chks: don't cache
<lifeless> jam: I'm submitting an implementation of _iter_inventory_xmls
<jam> so, given that caching the xml is probably going to end up *slower*, I don't see the benefit
<jam> and it sort of hurts in the long run
<lifeless> its for WT3
<lifeless> its an extremely corner case
<jam> but it leaves a get_inventory_xml lying around
<jam> and now functional
<lifeless> I know, but we use it from two places
<lifeless> bundles and wt3
<lifeless> we use the conceptual functionality, I mean.
<lifeless> honestly, having repository.deserialise_inventory != _serializer.read_inventory_from_string is more of an issue for me
<lifeless> when you say caching the xml is slower, do you mean 'merge etc operations on wt3 will be faster using CHKInventory' ?
<lifeless> because, I'm not entirely sure I buy that, not without profiling/testing.
<jam> lifeless: given how slow it is to build the xml... hard to say for sure
<jam> I suppose if merge has to read the whole inventory anyway
<jam> it would be paying that on each action
<lifeless> jam: so, I don't have a windows machine, which is kindof needed to properly measure this, as win32 is the only place we suggest/encourage wt3
<jam> lifeless: hm... I don't use it there
<lifeless> 'diff', 'status' operations are both full tree
<jam> WT4 works just fine
<lifeless> jam: bialix often says he uses wt3
<jam> I think that is more win98
<jam> but now that isn't even true anymore
<jam> since we switched to CreateFile
<jam> LockFileEx doesn't exist in Win98
<jam> which was how we took the os lock in the past
<lifeless> with that patch, we're down to FAILED (failures=19, errors=17, known_failure_count=22)
<lifeless> on my reduce workflow
<lifeless> when they are fixed, I'll be doing a full run
<lifeless> jam: I think https://bugs.edge.launchpad.net/bzr/+bug/336383 is fixed, do you?
<ubottu> Launchpad bug 336383 in bzr "branching dev6 when ghosts are present fails" [High,Triaged]
<jam> lifeless: given that --2a works with bzr.dev, I'm pretty confident it is fixed
<AfC> Hm. So, if I have a branch that has revisions not on mainline, but there is nothing on mainline since the branch was taken,
<AfC> why would merging that branch back create a mess?
<AfC> (ie, I could pull, but I've been out of that habit)
<lifeless> what sort of mess?
<AfC> I was astonished to see merge conflicts and worse highly incorrect choices on the stuff that didn't conflict.
<AfC> lifeless: ^
<lifeless> did it warn about criss-cross merge?
<AfC> n
<AfC> o
<AfC> (at least, not recently. Few weeks ago)
<lifeless> check the scrollback please; its not very obvious
<AfC> sorry?
<lifeless> in your console?
<AfC> what's a scrollback
<AfC> oh
<AfC> gotcha. Checking
<AfC> _oh_
<AfC> so, I was bad and didn't run `bzr status` in the 'mainline' branch before running the merge.
<AfC> And surprise, it was "Run bzr update"
<AfC> I hate that
<lifeless> I'm confuse - what commands did you run?
<AfC> I would have thought it wouldn't let me merge or something.
<AfC> lifeless:
<AfC> $ bzr merge ../fix-text-replacement
<AfC> lifeless: that's it
<AfC> but then, just now, I ran
<AfC> $ bzr status
<AfC> and saw
<AfC> working tree is out of date, run 'bzr update'
<lifeless> ah
<lifeless> so it got a mangled merge.
<AfC> (there were some revert --no-backups in there)
<AfC> I assume it won't bork now that I've run update
 * AfC tries again
<lifeless> should be fine
<AfC> All changes applied successfully
<AfC> So as noted, I've backed myself into this corner before. Quite frequently, in fact.
<lifeless> you need a flashingblinkinbeepinlight
<AfC> I must admit it's in the category of things I should like to think I couldn't do to myself with bzr
<AfC> lifeless: I need it to say
<AfC> working tree is out of date, run 'bzr update' before you run 'bzr merge', stopping now so you can fix it
<AfC> lifeless: though if you've got a spare blinkenlight, I'll borrow it
<AfC> yeah, it's clean. Build & test passed
<AfC> Hm.
<lifeless> how long does a java-gnome program take to start
<AfC> Not sure if that counts as a bug report, but it sure is a "experienced bzr user managing to screw up, fyi"
<lifeless> yeah
<lifeless> I'd love to make it better
<AfC> lifeless: {shrug} < 1 second?
<AfC> lifeless: but GTK & window manager & X sometimes take a long time to do first presentation of a new GtkWindow. That's not anything I can do anything about; http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/Widget.html#showAll() :)
<AfC> It also takes longer when the person who is supposed to be typing `make test` is typing in an IRC channel instead :)
<lifeless> :>
<johnjosephbachir> what is the bzr "equivalent" to svn's switch (for a branch, not a checkout)-- in terms of appropriateness for upgrading code to a new tagged version
<lifeless> switch
<lifeless> oh, not a checkout
<lifeless> bzr pull --overwrite
<johnjosephbachir> ah okay, i'll experiment with that. thanks
 * igc1 lunch
<spiv> Gar, PQM failed my branch after running about 90% of the tests (test_scenarios).  Oh well, resubmitted...
<lifeless> spiv: :(
<lifeless> spiv: https://code.edge.launchpad.net/bzr/+activereviews - I'm trying to dominate the page :)
<spiv> Heh.
<lifeless> failures=12, errors=16,
<lifeless> the numbers, they are shrinkin
<fullermd> I can resend my log of test failures if that'll help   ;p
<lifeless> of wha
<lifeless> t
<fullermd> Well, bzr.
<fullermd> I presumed you were bemoaning the cursed fate of numeric shrinkage.  I'm all about being helpful   :)
<lifeless> thanks
<overshard> Hello, I have dont a few commits on a system of which I forgot to set whoami on... is there a way to change the commiter name and email on past commits?
<lifeless> you can use uncommit + shelve to pop them off
<lifeless> then commit again
<lifeless> so
<lifeless> uncommit
<lifeless> shelve --all
<lifeless> uncommit
<lifeless> shelve --all
<lifeless> uncommit
<lifeless> commit <new options>
<lifeless> unshelve
<lifeless> commit <new options>
<lifeless> unshelve
<lifeless> commit <new options>
<lifeless> would be how you do it for 3 revisions
<overshard> when doing shelve --all i'm getting an error to where it can't acquire a lock on .bzr/checkout/dirstate etc etc
<overshard> doesn't look like anything has it open
<poolie> lifeless: could https://bugs.edge.launchpad.net/bzr/+bug/377261 be resolved by your delta fixes?
<ubottu> Launchpad bug 377261 in bzr ""AssertionError: name u'COMPILING' already in parent" in _generate_inventory when running "bzr update"" [High,Confirmed]
<lifeless> yes, I expect it wouldn't wedge itself now
<lifeless> EODing
<lifeless> AfC: is libjava-gnome-java on ubuntu your project?
<lifeless> or the other one
<AfC> lifeless: uh,
<AfC> lifeless: http://java-gnome.sourceforge.net/4.0/get/ubuntu.php
<AfC> lifeless: from that PPA, yes
<AfC> (sync from Debian is rather behind, I gather)
<AfC> Guillaume has done a nice job of that package, and I nudged him on the few things that caught my eye with respect to how it was being built. So as far as I know that's good to go.
<AfC> lifeless: I'm going to be on my way out the door shortly, but we can always chat further in #java-gnome on gimpnet should you have project specific questions.
<lifeless> ok
<lifeless> karmic has 4.0.9
<lifeless> debian has 4.0.7 only
<lifeless> so its something else
<AfC> lifeless: I guess I should take an interest in bugging someone about that, then.
<AfC> Where's Peter :)
<lifeless> http://packages.qa.debian.org/j/java-gnome.html
<AfC> Hey look! Zero bugs :)
<lifeless> zaroo!
<poolie> hi lifeless
<poolie> do you want me to do anything more on 2a test failures, or is it all in flight in that branch?
<poolie> i have probably about 3 hours here and am looking for some juicy fruit in small pieces
<lifeless> poolie: hi
<lifeless> I'm down to a small number of failures
<lifeless> there are two conceptual things to do
<lifeless> 1) drive that to zarooo
<lifeless> 2) run the full test suite again to find things missed in the first pass
<lifeless> both of those would be useful
<poolie> i could probably do reviews or finish john's changes for apport
<lifeless> I'll be picking it up again on Monday.
<lifeless> I think getting this branch ready is essentially the most important thing we have; as its critical path for getting feedback from early testers of the impact of the change
<lifeless> theres also 3 or 4 more changes up for review from that branch
<poolie> yep
<lifeless> and after we finish the branch it needs a review
<poolie> i just don't want to churn by investigating or fixing things you've already done
<lifeless> I'd love it if you kept the branch rolling along
<poolie> oh i guess you'll be finishing soon
<lifeless> its all either a) in the branch or b) not investigated
<lifeless> poolie: I finished an hour ago - the perks of starting at 6:15
<poolie> kk
<lifeless> I've been spinning off little branches; if you keep the branch moving I'd encourage you to do that so that the final thing isn't a review headache.
<AfC> lifeless: [I commented the Ubuntu bug about java-gnome 4.0.12]
<poolie> lifeless: yeah that's why i was splitting them off
<lifeless> poolie: right, I just made branches instead:)
<poolie> instead of branches and bugs?
<poolie> mm
<lifeless> if we really need a bug for every change that lands, I know a CMM lvl 3 consultant. :)
<lifeless> though that should be cmmi these days, I guess.
<AfC> lifeless: if you pay me enough, I'll help you convince your boss not to do that :)
<lifeless> :P
<poolie> i'm really thrilled wine was so easy
<lifeless> wine?
<poolie> the win32 implementation
<lifeless> I'm totally lost :)
<AfC> That would be pronounced whine.
<poolie> i just sent mail
<poolie> if you install it and then install win32 python you can run bzr in a win32 environment from within your regular unix workspace
<lifeless> oh right
<AfC> poolie: you should have a chat with Erik de Castro Lopo about his experiences with that & automated builds & automated testing. Quite successful for libsoundfile and secret rabbit code, I gather.
<lifeless> cool
<poolie> mm
<poolie> he might have mentioned it
<poolie> i anticipated it would be more trouble than it has been so far
<poolie> of course that may just mean.... *splat*
<poolie> but for example
<poolie> % winepython ./bzr missing http://bazaar.launchpad.net/~mbp/bzr/doc
<poolie> works
<poolie> running ssh may be hard
<fullermd> Funny.  I was kinda looking forward, when I built this workstation, to seeing how much better stuff through wine performed...  didn't really think it through though.
<acestar> Hello, today when trying to commit my project to LaunchPad I'm getting the following error:  bzrlib.errors.TooManyConcurrentRequests
 * AfC waves g'weekend
<poolie> acestar:  that's probably a followon from something else
<poolie> did you get a previous weekend
<poolie> cheerio afc
<lifeless> fullermd: how so?
<fullermd> Oh, I carefully avoided thinking about wine's stunning capabilities on a 64 bit OS...
<lifeless> lp is down
<lifeless> fullermd: I play WoW on wine on my i7
<fullermd> Well, theoretically it might work if it were built as an i386 binary.
<acestar> Hmmm, when I do a bzr update, I get a notice that says bazaar.launchpad.net has refused the SSH connection.  Any ideas?
<fullermd> But that would take fiddling by itself, never mind that I'd also have to build 32 bit versions of half of X and a bunch of other stuff that it links to...
<poolie> acestar: there's a problem with that system
<poolie> people are working on it
<lifeless> acestar: launchpad has just suffered a problem, and we're fixing it now
<poolie> (i hope)
<acestar> poolie: lifeless: oh ok thanks for the info!  will do local commit :)
<poolie> we really need a system status page
<poolie> lifeless: i'm *this* close to just creating a Launchpad system status page on help
<lifeless> google appserver + N buttons, anyone can click, everyone can see
<lifeless> and have it do a ping on request to the various servers.
<poolie> i thought just on the wiki
<poolie> even being manually updated would be an advance
<lifeless> if auth is down you can't update it
<poolie> interesting point
<poolie> is that common?
<vila> hi all
<poolie> hi vila
<pygi> greetings vila
<vila> power outage here ~4 hours ago, just finished restarting everything :-)
 * fullermd waves at vila.
 * vila waves back
<vila> hey pigy, poolie
<pygi> vila, just you joke about my nick :p
<vila> rats, no, low coffee => typo :)
<vila> wow, ssh: connect to host bazaar.launchpad.net port 22: Connection refused ???
<spm> vila: yeah. (hi btw! :-) ) cherry pick that went sour.  should be good now.
<fullermd> vila: You're only allowed to connect via htpps   ;>
<vila> hi spm ! Great, confirmed, works now
<vila> fullermd: got that wrong ! Should have been hhtps :)
<fullermd> Ah!  No wonder it wasn't working for me...
<vila> anyway, I use a patched /etc/services just in case, so it works for me even with the typo....
<spm> vila: you need: "apt-get install sl" as well then. for those "ls <--> sl" moments
<vila> tsk tsk, sl is aliased to show-loom around here, totally different beast :)
<spm> for shame. having a train scroll across one's screen is entertaining!
<poolie> spiv, how did you go with the delta patch?
<jrydberg> If I merge some specific changes, can I tell my target branch that it is up to date with source somehow?
<jrydberg> I want to merge 1-4, 5-10
<jrydberg> err. 1-3, 5-10
<fullermd> i.e., not bring in 4?
<poolie> but pretend you did?
<poolie> after doing the merges
<poolie> do 'bzr merge source'
<poolie> then 'bzr revert .'
<poolie> this will keep the merge marker but revert the file changes
<spiv> poolie: landed!
<poolie> then commit
<poolie> woo way to go
<poolie> have a weekend on the house
<spiv> Hah.
<jrydberg> fullermd: exactly
<poolie> is it nice and fast?
<fullermd> Well, you could do three merges, doing as poolie said on the middle one.
<spiv> Actually, it's a pretty busy weekend, weddings and things, but I'll be sure to enjoy it :)
<fullermd> Another option is to just merge everything, then make another commit rolling back 4 afterward.  That may be clearer.
<jrydberg> Thank you. Worked like a charm.
<fullermd> Either is appropriate if you don't want the changes in 4; it's still in the history though, so if you want to not have it for reasons like "that version contains my PGP passphrase" or the like, it won't do what you want.
<lifeless> spiv: after some testing, say wed/thur we should ask for a cp to launchpad production
<lifeless> spiv: to get larger scale know-how.
<spiv> lifeless: +1
<vila> spiv: congrats for the wedding and enjoy :-)
<spiv> vila: well, my wedding was a while ago now :)  By I can pass on a your congratulations to my friend if you like ;)
<vila> lol, sorry for the misunderstanding then :-)
 * igc1 dinner
<bialix> I need some advice. I have central bzr server where all finsihed stuff present. I have MANY local branches that either mirrors of branches on central server or they're feature branches merged or not merged yet. Sometimes I feel the need to reduce this burden and clean all mirrors or finished feature branches from the disk. How you deal with this?
<wgrant> bialix: I use the bzr-removable plugin.
<vila> bialix: I just delete (rm -fr) the merged branches when I grow tired of seeing them
<bialix> bzr-removable? I'll check it, perhaps it's what I need
<bialix> vila: it's not easy to do for me.
<vila> bialix: But the biggest picture is that I'd like a tool to help me track all the branches I'm working on.
<bialix> vila: after merge of feature branch I need to test it on real hardware (I'm embedded system engineer) so sometimes I need to fix something after testing
<bialix> this is the problem
<bialix> I can't run buildbot to auto test my firmware ;-)
<vila> bzr-removable is a step in the right direction but doesn't address needs like: are my plugins up-to-date ?
<vila> bialix: in that case it means you're not done with the branch, when I said merged, I abused the term to mean, I'm done with it
<bialix> well, we build the final product as collection of many smaller components. So problem for me is the amount of different branches for different components
<bialix> it begins to out of my control
<vila> I use 'check' with some success on embedded software projects where only the high levels of the application couldn't be tested automatically...
<vila> argh, several uprocs involved or just software components ?
<bialix> several devices involved
<bialix> main PC with Linux with several software components too
<bialix> because main software works with real hardware (via COM-ports or USB) it's not easy to unittest it
<vila> backward/forward compatibility involved or do you deploy on all components at once ?
<bialix> backward compatibility -- yes, very hard
<bialix> for some hardware I have branch for every customer we support
<bialix> just because I have memory restrictions and unable to build universal firmware
<vila> so, your manager knows about the suport costs right ?
<bialix> we very small company. I'm main dev and manager as one man
<vila> bialix: ha ! Of course you have memory restrictions ! Where will be the fun in working in embedded software otherwise !!!!
<bialix> yeah
<vila> well, your *boss* knows about the costs ? Or if it's your own company, *you* know about the support costs :)
<bialix> wgrant, vila: description of bzr-removable is very promising! thansk for the tip
<vila> Automated tests are all about transferring support costs into building and maintaining a test framework :-D
<bialix> vila: I'm not boss, but yes, I'm trying to explain why we need to push our solution to universal side
<bialix> vila: of course, until you need to test some specific GUI or sensors that require specific environment
<bialix> jml: why you put plugin code for bzr-removable into subfolder?
<bialix> jml: it makes hard to install it
<vila> well, the last project I was involved used a specific UI on the device (buttons and LCD display), yet I was able to use pyGtk on *windows* (wink) to emulate the UI and some sensors, the rest of code was common between the PC and the device...
<vila> so most of the work could be done on the PC without the need to flash or debug in the field... they were quite happy about it...
<bialix> I have similar emulator now for our terminals. But I'm using Tkinter and PIL. It works great
<bialix> rats, bzr-removable does not work on windows
<bialix> os.path.samefile?
<vila> :-/
<poolie> hi bialix
<bialix> hi poolie
<poolie> i hoped my mail about wine might please you
<poolie> now i can experience os lock problems more often :)
<bialix> poolie: :-)
<bialix> yes, it is indeed
<bialix> OSLMD!
<poolie> +1
<poolie> the main thing i have at the moment is that i don't have paramiko installed there, so can't do networking
<poolie> but i could either install paramiko or the bzr installer
<bialix> paramiko has not extra dependencies
<bialix> only pycrypto
<bialix> and pycrypto has installer
<bialix> BzrWin32Installer page or WindowsInstall provides the links
<bialix> it's not so hard
<bialix> of course it's not apt-get
<bialix> maybe easy_install will work
<poolie> right
<poolie> i was actually going to use it as a test run for easy_install
<bialix> it will be interesting to hear
<bialix> about easy_install
<bialix> maybe you'll check full round
<vila> bialix: http://docs.python.org/library/os.path.html#os.path.samefile
<bialix> easy_install bzr
<bialix> vila: right, but was is closest equivalent for samefile on Windows? just compare abspaths?
<vila> return path1 == path2
<bialix> ok
<LarstiQ> is that what it does?
<LarstiQ> bialix: you can have links in Windows, right?
<bialix> yes, but not easy
<bialix> hardlinks
<bialix> symlinks only for directories
<LarstiQ> ok
<bialix> and because I have no links on my disks anyway I'll follow vila's advice
<bialix> I don't understand how bzr-removable supposed to work
<awilkins> You can have symlinks in Vista and up
<awilkins> "Junction points" are available in XP and below (folders only)
<bialix> I'm on XP and below
<awilkins> Most people are
 * bialix mutters: something need to be done about branch aliases like :push, :parent. Why people should convert them explicitly?
<bialix> grr
<bialix> about bzr-removable: my sequence of actions now to detect is it safe to delete branch: run bzr st, check for .shelf, run bzr info and see is it pushed, run bzr missing :parent or bzr missing :push
<poolie> bialix: yes the aliases don't seem to work in every place
<poolie> and i agree about the workflow for removing things too
<bialix> perhaps I need write my own removable
<poolie> mm
<poolie> maybe
<poolie> i'd like to consider it as part of the ui 3 thing
<bialix> sorry, I've lost connection
<fullermd> I wish somebody would tell me where I could download an extra 8 hours in the day.  Then maybe I could write out ui 3 thoughts before...   y'know.  3.
<bialix> 3?
<jrydberg> ui 3?
<awilkins> UI 1 : big red off switch
<awilkins> UI 2 : Windows
<awilkins> UI 3 : Something better   ?
<awilkins> Oh, damn, WinXP installs fast in a VM
<awilkins> I guess the host hardware is somewhat meaty
<poolie> jrydberg: http://doc.bazaar-vcs.org/devnotes/bzr-2009-ui-refresh.html
<lifeless> awilkins: also, 'hits disk' isn't well defined in a vm :)
<awilkins> lifeless: Given the amount of RAM this box has I wouldn't be surprised if the entire partition was cached
<poolie> vila did you mention a bug with some failures on karmic?
<poolie> i seem to have a new failure in TestLocale
<awilkins> I think the win32 build page is a bit out of date
<garyvdm> Hi vila
<vila> hi garyvdm
<garyvdm> How are you?
<vila> garyvdm: fine thanks, how about you ? You seem to be pretty active in qbzr these days :)
<igc1> night all
<vila> night Ian
<denys> vila: keys and certs from ssl_certs are not installed by setup.py - shouldn't they be?
<vila> denys: right you are ! There is even a bug filed about it. Feel free to fix :D
<denys> vila: i'll add the fix to my branch
<vila> denys: it's easier if you have a single intent by merge proposal, so if you want to fix bug #392401, it's better to fix only that in a dedicated branch
<ubottu> Launchpad bug 392401 in bzr "Packaging Bug: test SSL certificates missing from 1.16 PPA" [Medium,Confirmed] https://launchpad.net/bugs/392401
<vila> jam: *now* the changes you made to the build config are responsible for the failures :-) At least the bzrtools tag not existing on the public branch that is...
<denys> vila: ok, I push a fix https://code.launchpad.net/~denys.duchier/bzr/bug-392401
<vila> denys: great ! now, just do 'bzr lp-open' in your branch and click the 'Propose for merging' button !
<denys> vila: it's already done I think (but this is my first day using launchpad, so I may have screwed up)
<vila> denys: perfect
<vila> denys: already approved by jam, I'll add a NEWS entry and merge
<denys> vila: thank you
<awilkins> Bah, now I have to install the platform SDK
<awilkins> Or something
<awilkins> I'm missing MSCVRT90.dll
<vila> denys: thank *you* and congrats, your first patch is currently processed for landing in bzr.dev :D
<awilkins> Who's building the Windows installers and how do they get the 2.6 Python installer extensions building?
 * vila whispers jam is building the windows installers
<denys> hmm... I have pushed new revisions to my bzr.ssl branch on lp, but the diff that is shown on the merge review page is still the old one.  is that normal?
<james_w> denys: yeah...unfortunately
<denys> how are people supposed to review the tip of the branch?
 * awilkins woots because he managed to get `make python-installer` to finish
<james_w> by generating the diff themselves apparently
<denys> that's a little bit on the sucky side :-(
<james_w> bug 338002
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/338002/+text)
<vila> denys: you should 'resubmit' aka inform launchpad that your merge-proposal is superseded by a new one
<denys> vila: ah... ok
<vila> denys: the rationale is that the diff represent the difference between the two branches at the time of submission, because people comments refers to that, so the diff itself shouldn't change...
<denys> vila: when you say resubmit, you mean click on the "propose for merging" link again?
<vila> denys: don't know if that will work, no, I meant click the 'Status' near the top of the page of your actual mp: https://code.edge.launchpad.net/~denys.duchier/bzr/bzr.ssl/+merge/10147
<vila> denys: the little pen icon to be precise
<denys> vila: pfff.... that's hard to discover!
<vila> denys: EWRONGCHANNEL :-)
<vila> denys: try https://edge.launchpad.net/launchpad/+filebug instead :)
<vila> denys: but yes, that one is tricky, the UI is still worked on AFAIK
<der|> hi, I'm getting the following error when trying to commit on my project:   bzr: ERROR: 4f7d6b49ca2b8f885b0bd192a5e89b62.rix is not an index of type <class 'bzrlib.index.GraphIndex'>.
<der|> seems like my branch got corrupted :/, I can't uncommit, raises the same error
<vila> denys: hmm, looks like some mail didn't reach you before you resubmit...
<vila> denys: I thought you've seen my mail about wrap_socket but apparently no :-/
<DonDiego> hi everybody
<DonDiego> i'm working on a gnu arch --> bazaar transition
<DonDiego> i had great trouble finding baz-import
<DonDiego> it's no longer part of bzrtools, but the websites do not reflect this
<DonDiego> maybe you could update them
<DonDiego> thx
<vila> DonDiego: it's a wiki, your experience is certainly worth reporting !
<DonDiego> http://bazaar-vcs.org/ is not a wiki afaict
<vila> DonDiego: it is
<vila> DonDiego: look at the small print at the end of the page :)
<DonDiego> saw it..
<DonDiego> i'd prefer if somebody who knew what they were doing edited it instead of me
<vila> DonDiego: damn, there was changes here, how do I logged out ? :)
<DonDiego> ?
<vila> DonDiego: but nobody knows what you did and where you looked, fixing your modifications (if needed !) will be far easier that interviewing you to find what should be chaged
<vila> s/chaged/changed/
<CaMason> hi guys. I've got a project that has a sub-folder that exists as a linked tree (I believe)
<CaMason> I want to move this out into a seperate repo, and occasionally move the libs in manually. Can I just do `bzr split` ?
<CaMason> or is it actually 'join' ?
<kiko> hey
<kiko> does anyone know if 1.18 is due today?
<james_w> kiko: I can't find a metronome that states when it is due
<james_w> I can't even find the mail saying that it will be 1.18 not 2.0 now
<kiko> james_w, I'm a bit surprised because I see a milestone with a bunch of fixed bugs so..
<kiko> https://edge.launchpad.net/bzr/+milestone/1.18
<kiko> the only bug for 1.18 and not rc1 would be 398608
<kiko> I wanted to find somebody to verify https://bugs.edge.launchpad.net/bzr/+bug/393677
<ubottu> Launchpad bug 393677 in bzr "pushing a 1.9 branch stacked on a 2a branch causes problems" [High,Confirmed]
<CaMason> how can I convert a rich-root-pack into a pack-0.92 ?
<CaMason> I've got a project that doesn't need rich root ( no idea why it was made like that). I just want to convert it over to default (pack-0.92) so that I can I can move it into this shared repo
<vila> CaMason: the new format (2a) that will become the default with bzr-2.0 is rich-root, so getting away from rich root now is not a good idea
<CaMason> so I'd be better off upgrading to rich-root?
<CaMason> basically I want to have /home/bzr/projects/myproject/ and be able to have several folders (trunk, branches, releases) that I can checkout individually
<CaMason> not really sure which format I need to use :'(
<CaMason> I'm using bzr 1.13.1 (ubuntu)
<CaMason> I'd prefer to have them all as pack-0.92 at the moment, as that's default
<vila> CaMason: Upgrading to rich-root is a safe bet, you can either use --1.9-rich-root or go straight to --2a
<vila> CaMason: If you prefer, just wait for 2.0 to be released
<CaMason> ok, well I'll wait - but any idea how I can get my project layout sorted for now with pack?
<CaMason> I'm just concerned that I'm going to have problems again in the future if I choose --1.9-rich-root
<vila> you can't get from rich-root to non rich-root
<vila> the single problem is that rich-root and non rich-root are not compatible and that you can't go back,
<CaMason> ok. so what is your recommendation for now?
<CaMason> bzr upgrade --1.9-rich-root?
<vila> CaMason: wait 2.0, --1.9-rich-root, --2a are the options in roughly safest order
<vila> how big are your projects ? # revisions, # files ?
<CaMason> only small really
<CaMason> <100 files each
<vila> no problem then, upgrade to 2a
<CaMason> when will 2.0 be out?
<vila> soon :)
<vila> 1.18 is about to be released and also be the last monthly release befor 2.0
<lvh> does anyone know any distributed issue trackers that dont suck and work nicely with bzr?
<lvh> optimal would be the ability to sync with launchpad but I'm guessing this is mostly impossible
<lvh> or at least doesnt exist yet:-)
<LarstiQ> lvh: which have you tried?
 * kfogel is away: looooooooonch
<lvh> LarstiQ: ditz.
<LarstiQ> lvh: the only (real) distributed one I know is Bugs Everywhere
<lvh> and BE, which is basically ditz but in ruby.
<lvh> err
<lvh> well, ditz but *not* in ruby
<lvh> :-)
<lvh> they have a number of problems, mostly that it's too hard to submit bugs
<lvh> people should not have to do a full checkout
<lvh> I like my bug reporters, I want to make their lives harder
<lvh> there's a "don't" in that sentence somewhere
<denys> vila: I resubmitted with "wrap_socket" mods and cleaned up the tests a bit (but not quite separated out because they are _litterally_ the same tests).  see if you like it better now
<vila> denys: I know they are even *exactly* the same tests, that's why I said you want to parameterize them, look at various load_tests methods, you want a class where you set your 'use_ssl' attribute in load_tests() so that the test is written once but instantiated (and executed) twice
<davidstrauss> Can I configure EOL filters just on the server side, or does it have to be on the client, too?
<LarstiQ> lvh: you could something on the web to feed things into one copy
<lvh> LarstiQ: one copy?
<lvh> web interface with commit access to an incoming-bugs branch?
<LarstiQ> lvh: yeah
<LarstiQ> lvh: ala ikiwiki or hatta
<denys> vila: I used common helper methods with a use_ssl parameter (no attribute anymore)
<lvh> i dont know any of those
<LarstiQ> lvh: dvcs backed wiki(compiler)s
<lvh> oh
<lvh> LarstiQ: so "accepting" bugs could be cherrypicking commits into working branches
<vila> denys: right, but you shouldn't have :-/ You identified some tests that needed to run against the two kind of servers, more will come
<LarstiQ> lvh: yeah
<lvh> does anyone who works on/with bzr a lot think that that would be disgusting?
<LarstiQ> lvh: I think that would be fine
<lvh> okay, how about displaying bugs
<lvh> syncing with launchpad would be mostly impossible without modifying launchpad
<LarstiQ> lvh: use launchpadlib?
<lvh> also im not entire sure that lp would be happy with the extra load that I might generate from generating bug state from repo state :-)
<LarstiQ> gah, out of power, again
<vila> denys: test_osutils.py contains a rather simple load_tests() you can look at in parallel with the TestDirReader class
<vila> in fact the previous version of your tests was closer to the desired result that your actual one
<vila> s/that you/than your/
 * vila EODing
<denys> vila: thanks, I am looking, but all this really clever loading magic takes a while to puzzle out
<lvh> LarstiQ: the biggest problem I can see is that bug state inspection should be easy, and people dont understand bugs-over-time.
<CaMason> I've upgraded my files into --1.9-rich-root, and one of the folders is throwing up an error when using bzr-trac: AttributeError: 'KnitPackRepository' object has no attribute 'get_revision_graph'
<davidstrauss> Is there a way to enforce EOL rules on the server?
<vila> denys: you want something like (untested) http://paste.ubuntu.com/253293/
<vila> denys: and thenos mething like http://paste.ubuntu.com/253297/
<vila> denys: and then something like http://paste.ubuntu.com/253297/
<vila> interesting typo, I should really EOD now :)
<vila> denys: ^ does that help ?
<vila> denys: anyway, if you can't get them right, wait for spiv review, I think he'll ask for some more tweaks/tests
 * vila really gone now
<denys> vila: it's going to, I am sure ;-) but I am going to have to study this carefully (I hate not understanding)
<vila> denys: good, feel free to ask questions when do merge proposals then, we welcome that :)
<CaMason> any thoughts on why I get this in trac? "AttributeError: 'KnitPackRepository' object has no attribute 'get_revision_graph'"
<CaMason> only happens on one particular repo, that was upgraded using `bzr upgrade --1.9-rich-root`
<emmajane> beuno, any predictions for Monday yet? :)
<beuno> emmajane, I've done my part, I now need to get someone assigned
<beuno> we won't have the design by Monday, that I know
 * emmajane nods
<beuno> but, "next week" sounds plausible
<beuno> it's been my #1 urgency for the past 3 days
<emmajane> boo for "next week" and "plausible" but yay for "urgency" :)
<beuno> heh
<beuno> emmajane, I'm trying to get the HTML as well
<beuno> so we iterate over a design
<beuno> and then get the HTML/CSS for the approved design
<emmajane> beuno, oh, cool!
<beuno> emmajane, so maybe that will make up for lost time
<emmajane> :)
<emmajane> beuno, I would be delighted if they used 960.gs or some other CSS framework. it'll make inner pages and applying some of the design to other parts of the site (e.g. docs and wiki) a lot easier.
<emmajane> beuno, I'm most familiar with 960, but I've worked a little with some of the others.
<CaMason> argh bzr-trac is barfed on my install :/
<CaMason> only one of the branches within the shared-repo will show
<CaMason> all others show "AttributeError: 'KnitPackRepository' object has no attribute 'get_revision_graph'"
<beuno> emmajane, I can't promise that, but I can try  :)
<emmajane> beuno, thanks :)
<jwhitley> hi all.  Is there currently (1.17) a way to nest two preexisting trees?  split doesn't appear to handle this, only breaking off a versioned subdir into a tree.
<micahg> hi, is there an easy way to import all of the history from an svn branch to a bzr brach?
<johnjosephbachir> whenever i try to do anything over bzr+ssh (init-repo, push), i get a 'wrong client version' message
<johnjosephbachir> do my local and server clients have to match up? i thought that for modern versions of bzr i only had to worry about the formats
<CaMason> say I have /project, and I also have /project/lib/myplugin, what's the best way to bring the code from an external branch into /project/lib/myplugin ?
<CaMason> ack brb dinner
<micahg> is there a way with bzr to see the history for just one file?
<jderose> micahg: bzr log file-name-1, file-name-2, ...
<micahg> jderose: is it possible with a gui so I can see the revisions as well?
<jderose> micahg: i haven't really played with any of the gui's, so i'm not sure.
<jderose> micahg: seems like you can do it in loggerhead: go to Files, find the file, and then click "view changes to this file"
<jderose> micahg: for example: http://bazaar.launchpad.net/~bzr/bzr/trunk/changes?filter_file_id=setup.py-20050314065409-02f8a0a6e3f9bc70
<alexharrington> Heya. Puzzled about line endings conversion. I know I need to upgrade to --1.14 which I thought I'd done, but it still doesn't seem to work
<alexharrington> Anyone advise on how I should upgrade an entire launchpad project to use the newer format so we don't keep getting problems with mangled line ends?
<micahg> jderose: yeah, but my repo isn't on LP :)
<micahg> that would've been my first choice
<jderose> micahg: then that's all i got.  ;)
<ronny> yo
<ronny> is there a simple way to do what bzr ignore does from the api?
<struberg> hi folks, good evening!
<struberg> I have a quick question about bazaar protocols
<beuno> ronny, have you looked at what the command does?
<struberg> I currently try to fix the maven-scm-provider-bazaar because we don't use authentication for bzr+ssh for example
<struberg> currently the code support the following protocols: FILE, FTP, SFTP, AFTP, HTTP, HTTPS
<struberg> anyone who can tell me what protocols are missing and where I may read more about it?
<ronny> beuno: meh, every time i do that i end up wasting 1-2 hours
<beuno> ronny, there's always a learning curve...  :)
<beuno> that said
<beuno> ronny, http://bazaar-vcs.org/Integrating_with_Bazaar
<beuno> don't know if there's an example there
<beuno> if not, and you do spend those couple of hours
<beuno> please add to that  :)
<ronny> beuno: im writing a lib to abstract the different vcs's
<lifeless> import ignores
<struberg> ronny: in which language?
<lifeless> igores.tree_ignores_add_patterns(tree, ptterns)
<ronny> struberg: python of course
<ronny> lifeless: nice, thanks
<mobodo> if I have a web interface that I'd like listed on the bazaar plugin page, should I send an email or can I just tell somebody here?
<lifeless> ronny: (looking the command :P)
<beuno> mobodo, just add it, it's a wiki
<mobodo> ahhh, just got to login I guess :)
<ronny> lifeless: at some point you guys really should work on killing code-size, im still in fear by the sheer amount of code in bzr
<struberg> I assume the bzr protocol supports authentication in the form bzr://username:password@server... ?
<elmo> hey, possibly a stupid question, but what's the bzr magic for 'show me the changes in the WT relative to rev $foo'?
<lifeless> set -r $foo
<lifeless> bah
<lifeless> bzr st -r $foo
<lifeless> or diff if you want a diff
<lifeless> elmo: ^
<elmo> lifeless: that doesn't seem to DTRT
<lifeless> perhaps I don't know what you mean then.
<elmo> if I do that, it tells me about an added file blah, but blah wasn't in $foo, and bzr cat -r $foo blah, confirms
<elmo> lifeless: I have a tree, with some changes.  and i want to know how my current tree compares to revision 70
<lifeless> ok
<elmo> I could just bzr branch -r 70 and diff, but that seems .. inelegant
<lifeless> and the file blah is in your tree and not in 70
<elmo> blah is neither in my tree, nor 70
<lifeless> orly
<elmo> it got added and removed, somewhere between 70 and now
<lifeless> let me test
<elmo> lifeless: le sigh
<elmo> lifeless: i'm so sorry, apparently I'm on epic levels of crack
<lifeless> ?
<lifeless> elmo: what was going on?
<elmo> lifeless: the file is in my current tree, I'm just a muppet
<lifeless> heh
 * lifeless cancels his test
<elmo> I was utterly convinced I'd rm -fr'ed /etc/apache2 on this box, but apparently not
<lifeless> tricky things those fr's
<fullermd> A fr once bit my sister...
#bzr 2009-08-15
<ronny> sup
<ronny> is there any simple way to get a git diff between 2 bzr revision trees
 * ronny pokes lifeless 
<lifeless> sorry, no
<lifeless> not that I know of anyway; bzr-git might have something
<ronny> i dont think bzr-git will need it
<jelmer> ronny: what is a git diff?
<jelmer> ronny: there's some initial work there in "bzr send --format=git" to behave like git format-patch
<jelmer> is that what you mean?
<ronny> jelmer: i want to get git style diffs betwen 2 revisions (ie the extra lines with rename/add/remove metadata), i never used gits format-patch
<wgrant> 'bzr diff' gives me that information.
<ronny> wgrant: not in the same format as git
<ronny> directory renames are more concise tho
<cellofellow> where might I find the bzrlib.plugins.stats module? I'm assuming it's a plugin? Trying to install bzr-gtk from trunk and it says it needs that module.
<james_w> cellofellow: the bzr-stats plugin
<cellofellow> oh, duh
<cellofellow> :)
<verterok> lifeless: fwiw, looks like there is a eclipse package >= 3.4 in karmic :O
<lifeless> I'm running karmic...
<verterok> lifeless: https://edge.launchpad.net/ubuntu/karmic/+source/eclipse
<lifeless> oh, this is interesting..
<lifeless> Version: 3.4.1-0ubuntu2 yeah
<verterok> lifeless: it's still old, but not "years" old
<lifeless> I was seeing..
<lifeless> Version: 3.2.2-5ubuntu3
<lifeless> must been new in the archive ;)
<lifeless> I haven't updated for a week I think
 * verterok --> dinner
<cellofellow> bzr-gtk nautilus plugin is very slow. :(
<cellofellow> s/plugin/extension/
<JoaoJoao> howdy
<poolie> igc1: hi?
<fullermd> poolie: Aaron's away until after 1.18 is intended to be released, right?
<poolie> i think so
<fullermd> 'k.
<fullermd> Oh, rolled over another ten million on launchpadlibrarian.  Neat.
<alexharrington> Hi everyone. Does someone have a few minutes to help me with upgrading repository formats? I'm working on the Xibo project, which is developed cross-platform, and we keep having issues with line endings getting mixed up. I've upgraded to 1.17 and written a rules file, but I'm not sure how I go about upgrading the whole project (in Launchpad) and associated branches to use the new format.
<alexharrington> I converted one over, and it shows Branch Working Format 5, but when I then branch from that it comes up as format 4?
<alexharrington> I guess what I'm asking is do I have to upgrade the stable/development trunks first, then my branches? Or can I do stuff in any order? And what is it that causes future branches to use the newer format?
<AfC> alexharrington: asking here never hurts, but if you don't get an answer I'd recommend mailing their list.
<alexharrington> yeah - I'm posting on Launchpad Answers now - see if I get any joy there
<alexharrington> thanks
<AfC> alexharrington: actually, I said Bazaar's mailing list.
<james_w> answers is fine
<Noldorin> hello. could anyone please tell me the file in the source in which unlocking is done?
<Noldorin> (including the rename to unlock)
<LarstiQ> Noldorin: bzrlib/lockdir.py ?
<LarstiQ> Noldorin: combined with .unlock() on branch/repository/tre
<Proteuskor> I have a quick question about permissions after an initial branch. If I do the branch locally. bzr branch <dir1> <dir2> the umask is honored
<Proteuskor> however if I do it using the bzr+ssh method bzr branch <dir1> bzr+ssh://user@host/path it doesnt honos the umask
<Proteuskor> s/honos/honor
<Proteuskor> so I have to manually chmod -R g+r /path on the server for every created branch :(
<Proteuskor> chmod -R g+w rather...
<Proteuskor> has no one here ever tried to have a multi-user bazaar server using the bzr+ssh method?
<Proteuskor> well, adding os.umask(002) right after the if __name__ == '__main__': might be a nasty hack but it works for now... bzr should really fix the bzr_ssh method to honor the umask as set in /etc/profile... perhaps its not running the shell in login mode so /etc/profile isn't being executed. This won't work for multi-user environments...
<vila> Proteuskor: please report a bug and your work around, no everybody will read the IRC logs...
<Proteuskor> I wonder if its a misconfig of my system still :) thats why I was asking here first
<Proteuskor> could be my strange ssh server (I use dropbear because of its reduced memory footprint)
<vila> oooh, is that you that plays with tiny servers ? :-D
<vila> s/that/who/ oops
<Proteuskor> indeed
<vila> hmm, well, at least, instead of your "nasty hack" (your words :) you can just define a wrapper and set BZR_REMOTE_SSH
<vila> err, BZR_REMOTE_PATH (see bzr help env-variables)
<Proteuskor> ok, let me look into that real quick :)
<vila> that way you eon't have to patch bzr every time (if it's due to your config)
<Proteuskor> ya, I like that idea better, thank you
<Proteuskor> although I'm not yet sure how to get my windows users to tickle that setting via the tortoise GUI
<vila> and remember that BZR_REMOTE_PATH can also be set in config files (don't remember the config variable name though)
<vila> lol, messages crossed on the wire
<Proteuskor> ok, I can prolly just distribute a config file to all of the users then :D
<Proteuskor> I am actually new to bzr, I used to use perforce, just because thats what the company was using when I joined
<Proteuskor> comming up the learning curve now
<vila> hehe, the pleasure is in learning a little bit every day :-D
<Proteuskor> i think the real fix is to get the ssh transport to use login mode so /etc/profile is processed before calling the specified server. That way the systems configured umask is honored... but there may be a reason they didnt want to use login mode. If the comment at the top of transport/ssh.py is right I could email robey pointer and just ask. I dun want to file a bug if there is a good reason for the current behaviour
<vila> Proteuskor: robey doesn't work on bzr these days, you'd better file a bug, you'll get a far better tracking of the issue, really
<Proteuskor> ok
<AirBender> Hello guys
<AirBender> is there a way to override make AC_PACKAGE_VERSION in autoconf reflect the current revno in a bzr branch?
<AirBender> to make*
<vila> AirBender: hacking around: bzr version-info --custom --template "{revno}"
<AirBender> vila: yeap, but do you know the procedure to make AC_PACKAGE_VERSION read a file with the revno, or execute this bzr command to get the number?
<vila> I know nothing about autoconf except using it :)
<AirBender> because in AC_INIT I can't put a macro I think...
<AirBender> me too lol
<AirBender> but I'm pretty sure there's a simple way to do this... I don't like to change manually the revno every time in configure.ac
<vila> Did you ask Google? :-)
<weigon> http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html#in-development has two bzr 1.18 releases
<vila> weigon: the more the merrier !!
<weigon> please add at least a 3rd :)
<AirBender> vila: yes I have, but may be I'm searching in the wrong way...
<vila> well, most of the time yo found in the last place you search so... keep digging :)
<johnjosephbachir> is there any way to have access control with `bzr serve` ?
<jfroy> is there a known bug with 2a and patch files?
<jfroy> I just tried to apply a merge bundle someone sent me, and bzr died with AttributeError: 'AbsentContentFactory' object has no attribute 'get_bytes_as'
<jfroy> mmm actually no
<jfroy> the branch has the problem
<jfroy> it dies with the same error when doing bzr check
<jfroy> so I branched the bad branch with 1.18rc
<jfroy> and the new branch looks ok (according to check)
<jfroy> however now the merge command is failing with "bzr: ERROR: Bad bzr revision-bundle: "Can't convert to target format"  "
<jfroy> whatever the hell that means
<denys> johnjosephbachir: not at present, but I just started working on it
<johnjosephbachir> denys: cool. so it seems like the only read/write hosting solution with access control that doesn't require making OS users is webdav, yeah?
<denys> johnjosephbachir: and ssh to some extent
<fullermd> No, you could use the smart server over HTTP.
<fullermd> (and of course over ssh doesn't necessarily require system users, since you can putz with how sshd authenticates)
<teolicy> Hi. I'm a git user. A few months ago I wanted to contribute to a project using bzr, and installed some old version of bzr (maybe 1.6?). Today I updated my bzr to 1.18rc1, because I want to contribute to a different project.
<bialix> that's ok
<teolicy> After the upgrade, upon running bzr status in the repository I branched, I get an uncaught TypeError. I read a bit and found this bug to match what happened to me: https://bugs.launchpad.net/bzr/+bug/334202
<ubottu> Ubuntu bug 334202 in bzr "internal error occured on bzr status" [Undecided,Fix released]
<teolicy> The workaround works and indeed I have bzr-loom 1.4dev in the output of bzr plugins.
<teolicy> The question is: I'm not sure how to remove the plugin altogether, and, more importantly, since I'm not well versed in bzr I don't know if bzr-loom is a very important and often used plugin or not.
<teolicy> Recommendations?
<bialix> run `bzr plugins -v`
<bialix> it will tell you where plugin located
<teolicy> And I just rm -fr it?
<bialix> go there and delete loom directory
<bialix> yep
<teolicy> Excellent, very nice.
<bialix> bzr-loom provided special workflow, so in most cases you don't need it
<teolicy> And indeed bzr works now.
<teolicy> OKie, thanks a bunch.
<bialix> :-)
<teolicy> You know what, while I'm here, another question.
<bialix> shoot
<teolicy> I might have my terminology a bit git-ish, I hope you'll understand me. The feature I probably like best in git is 'git rebase -i'.
<bialix> -i means interactive?
<teolicy> After doing a series of local commits on my repo, and before I 'pushed' the changes to the upstream repo, I can see my local changes, edit them, edit their commit messages, reorder them, squash them into one commit, etc, etc.
<teolicy> Yep.
<teolicy> Is there something similar to play with in bzr?
<bialix> no, there is rebase but it has no -i
<teolicy> OK, never mind. I'll do without for now.
<teolicy> Thanks again, see you around bialix.
<bialix> np
<denys> fullermd: is usage of the bzr server over http mentioned/described/explained somewhere?
<awilkins> denys: Windows or Linux?
<denys> awilkins: access control, you mean?
<awilkins> HTTP server
<denys> awilkins: linux
<sinelaw> help! on windows, bzr add on a specific subdir fails with ERROR: "blabla..."  is not a working copy
<Noldorin> lifeless: ping?
<Noldorin> sorry to bother you again :)
<sinelaw> crap. bzr does that because the subdir is versioned by .svn
<sinelaw> but who cares!
<sinelaw> did I ask bzr to give a damn about svn?
<sinelaw> the error is very confusing.
<wgrant> sinelaw: Do you maybe have bzr-svn installed?
#bzr 2009-08-16
* poolie changed the topic of #bzr to: Bazaar version control system | please test 1.18rc1 | try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<gour> morning
<gour> considering there is 1.18rc1 does it mean next bzr release won't be 2.0?
<poolie> gour, it means the one on monday will be 1.18 but we'll shortly follow with 2.0b1 or rc1
<poolie> see the recent 'metronome' mail
<gour> poolie: ohh, thanks
<poolie> np
 * gour is waiting for bzr-2 to see if it could work nicely with bzr-fastimport & darcs repos using LP
<lifeless> gour: there's no need  to wait
<lifeless> gour: just set the repo format to 2a
<lifeless> 2.0's primary difference from the release before it will be to change the default format
<gour> lifeless: hmm, so, 2a is available in 1.17?
<lifeless> yes
<lifeless> and 1.16
<lifeless> but its best to use as recent a release ass possible - we've been bugfixing like made
<gour> to be frank, constant change of repo-formats was the main reason why i went back to darcs :-/
<lifeless> *mad*
<gour> ok. i've 1.17 on arch
<lifeless> gour: we hope 2a to be the last word for quite some time :)
 * gour hopes as well...the old creation of new formats was, imho, disaster
<gour> emacs is going to switch soon?
<lifeless> gour: the thing that caused actual problems AFAICT was rich roots more than anything else; and thats addressed by 2a - everyone has to upgrade to rich roots when they move to 2a
<lifeless> poolie1: did the talk go well?
<poolie1> hasn't happened yet
<poolie1> it's in about an hour
<poolie1> hugh's was good
<poolie1> most of it is in mandarin; aside from that it's a lot like an early lca
<gour> lifeless: i could agree...still, introducing so many formats was, imho, bad PR
<gour> lifeless: what about LP? works with 2a?
<lifeless> yes
<poolie> lifeless: still here? staging seems to be down btw
<poolie> not necessarily an emergency
<Colonel-Rosa> Can bazaar create patch files?
<garyvdm> Colonel-Rosa: bzr bundle or bzr send
<bialix> hi garyvdm
<garyvdm> Hi
<bialix> I've finished rework of commit data save/restore
<garyvdm> Cool
<bialix> I'd like someone (you or vila) will review it
<garyvdm> ok
<pygi> bialix, uh, if garyvdm has to review something that will take years :p
 * pygi hides
 * pygi waves
 * garyvdm waves
<bialix> pygi: this is no problem
<garyvdm> bbl - dinner
<pygi> garyvdm, bon appetit :)
<pygi> bialix, it was a joke :)
<bialix> you are joking about gary all the time
<pygi> ok ok, I'll stop :)
 * pygi stops
<bialix> this looks suspicious
<pygi> why?
<bialix> never mind, it was joke
<pygi> xD
<bialix> I forget adding smilie
 * pygi needs to stop joking with people
<bialix> but this is just my observation
<bialix> never mind
<gsuveg> re
<ronny> i guess im blind, but whats a good way to get all files added on a fresh commit (with no parents)?
<ronny> for all the other cases i can mostly use revisiontree.changes_from(other_revisiontree)
<ronny> hmm, i can just use list_files
<ToyKeeper> D'oh.  I wonder YTF a branch-specific config value would be masked by a generic default from ~/.bazaar/locations.conf .
<ToyKeeper> Seems backward to me.
<ToyKeeper> It looks like locations.conf is even overriding the value I passed on the command line.
<luks> ronny: I guess you can get changes_from against a NULL_REVISION revision tree
<ronny> luks: works fine, thanks
<ronny> \o/ the first diff support unittests for anyvc pass
<garyvdm> pygi: ping?
<garyvdm> bialix: I took a look at commit_data. I'm happy to merge now (so that we get user testing from trunk users.) Feed back from Vincent is important, but we get get that later.
<bialix> garyvdm: thanks. I'll merge it soon (maybe tomorrow).
<bialix> when I worked on bugs.py I thought that we have to use too much private bzrlib config API (with leading underscore)
<bialix> maybe we need to provide some patches for bzrlib/config.py, but later
<bialix> garyvdm: about find_branches/iter_branches: I'd prefer to have new method iter_branches
<garyvdm> Yes - I think lets merge it, and then you can continue to work on improving it in those regards.
<bialix> in this case backward compatibility will be easier for us
 * bialix nods
<garyvdm> I'm working on Bug 412029 and then Bug 412035. Still not sure how I'm going to do the later.
<ubottu> Launchpad bug 412029 in qbzr "qlog: Revision info, and file list should show multiple revisions." [Medium,Confirmed] https://launchpad.net/bugs/412029
<ubottu> Launchpad bug 412035 in qbzr "qlog: Add ui to select parent to diff with." [Medium,Confirmed] https://launchpad.net/bugs/412035
<garyvdm> But it is so important. That bug so often forces me to the command line
<bialix> bug 412029?
<ubottu> Launchpad bug 412029 in qbzr "qlog: Revision info, and file list should show multiple revisions." [Medium,Confirmed] https://launchpad.net/bugs/412029
<bialix> ah yes
<bialix> it's nasty bug
<bialix> garyvdm: about 412035
<bialix> we have context menu for invoking diff, right?
<bialix> why not force user to select parent here
<garyvdm> Yes, but also a button, and the file list.
<bialix> we can force users to select parent all the time
<garyvdm> I hope I can find a way for all 3.
<bialix> it could be nagging
<bialix> and people start crying
<bialix> so we either should provide more options in context menu (as you did to select between different diff tools)
<bialix> or use special dialog
<bialix> garyvdm: what about creating short-cut diff option: default diff tool, left-hand parent always
<bialix> and rich diff option: with all possible options to select
<bialix> something like Advanced search in LP bugs UI
<bialix> garyvdm: ?
<garyvdm> Yes - a combo box would provide that to.
<garyvdm> (default to left hand parent)
<bialix> no, I mean special dialog
<garyvdm> Oh - ok
<bialix> how often you need special options?
<bialix> so with short-cut people will have old behavior
<bialix> and with new rich options dialog they will have to select and run diff
<garyvdm> What I'm really looking for is a way to select the parent, when selecting the revison(s) in the list.
<bialix> in 2 steps: dialog with options -> OK -> launch diff
<bialix> You can show short summary info about parent revisions?
<bialix> e.g. revno + author + summary
<bialix> something like bzr log --line
<bialix> put this into combobox
<bialix> radiobuttons could be unoptimal for octopus merge case
<garyvdm> I'm going to do bug 412029 first - Because I think that that might affect my ideas...
<ubottu> Launchpad bug 412029 in qbzr "qlog: Revision info, and file list should show multiple revisions." [Medium,Confirmed] https://launchpad.net/bugs/412029
<bialix> ok
<bialix> I'm planning to work on Bug #392920 because it beats me on win32 quite regularly
<ubottu> Launchpad bug 392920 in qbzr "can't commit if message has backslashes" [High,In progress] https://launchpad.net/bugs/392920
<bialix> garyvdm: after this I think working on auto screenshots and docs + site
 * bialix mutters: maybe auto screenshots could be used as semi automated tests later
<garyvdm> bialix: I was thinking the same thing...
<bialix> garyvdm: I hope to use qbzr trunk history for generating screenshots
<garyvdm> wow!
<bialix> just need to figure out better places/revisions
<bialix> and maybe your help for programmatically manipulate with twisties in qlog
<bialix> garyvdm: I'm done for tonight. Good night and easy hacking!
<kenichi> "An attempt to access a url outside the server jail was made"  ...  just upgraded the bzr and bzrtools on a host that was serving through apache httpd, and now get this from clients.  can anyone help? (1.10 -> 1.17)
<beuno> kenichi, are both client and server 1.17?
<kenichi> yes
<pygi> garyvdm, pong?
<kenichi> beuno: anything else?
<pygi> garyvdm, once you're around, tell me what you needed :)
<garyvdm> Hi pygi: I think that you were work together with vila on the bzr-gtk, save and restore commit messages.
<pygi> garyvdm, I'm not sure, but I don't think so?
<garyvdm> bialix has been working on and improved version for qbzr. I know that vila is interested in making some of the code common, so I though that you would like to take a look at what bialix has done.
<garyvdm> see: https://code.launchpad.net/~qbzr-dev/qbzr/commit_data/+merge/10040
<pygi> vila, were we working on that? I don't think so. Perhaps Szi?
<lifeless> moin
<igc1> morning
#bzr 2010-08-16
<mgz> and the second is mostly a niggle:
<mgz> if you look at testtools.testcase.TestCase.expectFailure, do you see any way *not* to create a cycle there?
 * mgz heads back up a bit and branches lp:python-fixtures to look at it
<lifeless> mgz: whats the cycle on? the frame contents ?
<lifeless> try: raise _ExpectedFailure(exc_info) finally: del exc_info  again ?
<mgz> yup, puts exc_info in the exception instance it's rerasing
<mgz> ^right, that's not good enough in this case because the reraise keeps the original traceback frames alive
<mgz> that plus _ExpectedFailure((exc_info[0], exc_info[1], None)) works,
<lifeless> mangle the frames ?
<mgz> that's what I'd like, I'm not sure how though.
<lifeless> 'stabbity stabbity'
<mgz> eheheh
<mgz> I'll put up my testtools changes as well now (which are basically just that try/finally/del in a few places)
<mgz> but that method stumped me.
<lifeless> mgz: I'll look in more detail a little layer
<mgz> python-fixtures looks shiny. I'd like to see some harder examples of things like how it'd work with testresources though.
<mgz> ^lifeless: that'd be great.
<lifeless> so I plan to write a decorator for testresources
<lifeless> and deprecate testresources internal fixture-like api
<lifeless> so a resource becomes ReferenceCounter(fixture)
<lifeless> [roughly, mumble]
<mgz> :)
<lifeless> possibly even auto-do that
<mgz> bed for me now. have guests staying and it might be considered impolite to hack late.
<mgz> I'll try and tie up the remaining loose en...cycles this week.
<lifeless> mgz: cool! ciao
<m3ga> poolie: any idea how i might recover from that problem i had on friday?
<m3ga> 'morning btw :-)
<m3ga> poolie: don't worry about it, i managed to branch last_rev - 1
<poolie> hi m3ga, that's just what i would have suggested
<poolie> i think i said it on the bug
<spiv> The divergence of the various stable branches vs. trunk was bugging me so I'm merging them up, but 2.1->2.2 is failing the trivial merge because the test for bug 192859 seems to be tripping over some sort of change in conflict handling in 2.2.
<ubot5> Launchpad bug 192859 in Bazaar 2.2 "AttributeError on parent.children in add when adding a symlink (affected: 4, heat: 78)" [High,In progress] https://launchpad.net/bugs/192859
<spiv> Ah, WorkingTree.list_files seems to need a similar fix.
<poolie> hi spiv
<ciss> hi, i want to temporarily version a directory that contains sub directories already versioned by svn. if i call "add", only one directory gets added (the only one not versioned by svn). if i then call "add a_versioned_directory", bzr imports the svn revisions. how can i prevent that without deleting the svn metadata?
<fullermd> Disable bzr-svn?
<fullermd> (via uninstalling it, or moving it aside, or use of --no-plugins, etc, depending on how drastic you care to be)
<ciss> i have installed bazaar using the osx installer. where can i find the plugin directory?
<fullermd> No idea.
<fullermd> But you can use --no-plugins at any rate.
<ciss> --no-plugins gave me a key error (?) when bazaar encountered a file name containing umlauts
<ciss> i found the directory
<fullermd> That's...   interesting.
<fullermd> I know that OS X does some interesting things with character encoding.  Maybe there's a special plugin included with the installer to deal with that...
<ciss> error and traceback: http://pastebin.com/xi2ySRAG
<ciss> o-kay ... this is not caused by --no-plugins
<ciss> i moved the svn plugin, added again - same error
<ciss> found an explanation and a workaround: https://lists.ubuntu.com/archives/bazaar/2007q2/024773.html
<ciss> so much for the "init --knit" workaround ...
<fullermd> Without the svn plugin, I can't imagine how or why bzr would be doing anything with svn revs.
<fullermd> You'll probably have to wait 'till jelmer is up and about.
<ciss> this has nothing to do with the svn plugin. it's about how osx handles encoding of umlauts in file names
<fullermd> Oh.  Yeah, that's its own little thing.
<lifeless> NKD whatever
<fullermd> I thought we'd handled all that in recent versions though.
<ciss> hm ... only umlauts in directory names seem to be a problem. file names containing umlauts are added without any errors
<fullermd> AIUI, it's not so much the presence of any particular character, but rather that OS X does normalization of the file names.
<fullermd> So if you write a particular file name, then scan the directory, the sequence of bytes defining the file name will be different.
<fullermd> (there being several ways you can encode various characters in Unicode)
<lifeless> ciss: ok, so a bug in a particular code path - please do file a bug
<ciss> lifeless, could you do that for me? i don't have a launchpad account and don't feel like registering just for a bug report
<ciss> again, the stack trace: http://pastebin.com/xi2ySRAG
<ciss> system is osx 10.5.8, using the 2.2 stable installer for osx leopard (python 2.5)
<lifeless> ciss: if we don't have a reproducable test, we need to be able to contact you to work through the details until we do.
<lifeless> so I can file a bug saying you reported the issue, but IME that means we'll eventually close it saying 'cannot reproduce or contact the reporter', which is unsatisfactory.
<ciss> ok, i'll file one myself. might take a while though til i get to it
<sabdfl> hi folks
<sabdfl> http://overbenny.wordpress.com/2010/08/16/daily-builds-rock-but-bzr-imports-suck/ anybody want to lend him a hand?
<sabdfl> are those import problems known issues?
<jelmer> hi sabdfl
<jelmer> sabdfl: Yes, unfortunately. The Audacious and Eclipse ones might not be too hard to fix. The Git submodules ones are harder, since they require nested tree support in bzr.
<sabdfl> thanks jelmer
<poolie> yeah, i think we should try to do them soon
<knittl> hi. i tried to import an svn repository into bzr, but it crashes with a unicodedecodeerror
<jelmer> knittl, hi
<jelmer> knittl, can you paste the traceback?
<knittl> just a sec
<knittl> http://paste2.org/p/952628
 * jelmer tries to reproduce
<knittl> it was only in rev 1600-something
<jelmer> knittl: fixed in bzr-svn trunk
<knittl> that was fast
<knittl> where's the trunk located?
<jelmer> lp:bzr-svn
<knittl> jelmer: thx
<knittl> jelmer: it crashed again. i did bzr co lp:bzr-svn; cd bzr-svn; sudo python setup.py install
<jelmer> knittl: how did it crash exactly?
<jelmer> knittl: Are you sure it's using the bzr-svn you just installed?
<knittl> jelmer: how can i check/select it?
<jelmer> (bzr plugins -v will tell you, it should say "1.0.4dev")
<knittl> it crashed the same way
<knittl> hm no. 1.0.3
<knittl> how can i activate the dev version?
<jelmer> Move the checkout of lp:bzr-svn to ~/.bazaar/plugins/svn
<knittl> i created a symlink ;) shows now the correct version. now for try 3
<knittl> but shouldn't running setup.py install correctly set it up?
<jelmer> knittl: Not necessarily; it picks up the first version of bzr-svn it finds
<jelmer> you already have a system-installed bzr-svn
<knittl> ok
<marienz> I don't think "sudo python setup.py install" is a good idea on a package-managed system (for any python package)
<marienz> if there's an already-installed package-managed version it'll either overwrite it (which may not work reliably if files moved or were removed) or it might install to a different directory (and the newer version might not actually be importable)
<knittl> usually there's usr/local for that
<jelmer> knittl, anyway, I'm off. If you can still reproduce the issue even with 1.0.4dev, please file a bug or drop me an email (jelmer at samba.dot org)
<knittl> jelmer: it did work before. but i accidentally deleted the real folder instead of the backup :x
<knittl> but i should get i t to work now
<knittl> bzr: ERROR: The branch https://svn.neo-layout.org has no revision None.
<jml> I wish WorkingTree, Branch and Repository had consistent attribute names for the base directory.
<jml> I'd like to make a working tree that has another branch (tree?) merged into it, in order to test a script I'm writing. How would I do that most easily using bzrlib?
<knittl> ah man. why do i use clone instead of svn-import? *facepalm*
<lvh> Hi. In a repo with a bunch of branches, is there a bzr command I should be using instead of just rm -r for branches I no longer want to keep?
<marienz> there's some plugin that kills unreachable revisions from the repo
<LeoNerd> Just killing the branch won't recover much disk space, if it's a shared repo. It also wno't make the actual revisions not present any more
<lvh> LeoNerd: I understand both of those things
<lvh> I just dislike having a few hundred branches lying around, 99% I don't care about
<lvh> (Mostly because they were introduced to fix a bug)
<marienz> unfortunately I cannot find it
<marienz> if you don't mind stale revisions still taking up some space and being recoverable if you can find their id "rm" is fine
<lvh> They're mirrored somewhere else anyway
<marienz> and if all those branches were merged there's nothing extra to remove
<lvh> I was just hoping there was a bzr command that could prune a branch and get rid of the repo junk
<marienz> remove-revisions might be it
<marienz> but I thought there was some other thing
<marienz> perhaps it's part of bzrtools
<lvh> meh, it's not a big thing, I'll just rm them
<lvh> once in a while: bzr init-repo foo & get trunk from lp :)
<fullermd> It's probably called gc or something.  I don't think it ever got any significant distance past PoC.
<lvh> fullermd: admittedly since the majority of those branches got merged it's not a big difference
<marienz> yeah
<marienz> it's only a hassle if you have a significant amount of changes that didn't get merged, or if there's something scary in those unmerged changes that you want gone from the repo
<lvh> <- not stalin
<lvh> I don't edit pictures or repositories for mistakes ;-)
<fullermd> Well, it's an important thing to do in nuclear* situations.
<fullermd> But there are plenty of conventional situations where it's more a desire than a requirement  ;p
<rubbs> yeah, a friend of mine had to do some repo editing when his company gave him the go-ahead to open source a log analysis tool he created. Problem was he had it in the same svn repo as some of their private internal stuff. He had to manually pick out the history so he could publish it out.
<SpookyET> Hello. Scratching my head. Is it possible to colour bzr output like hg and git?
<SpookyET> Either through a configuration file or plugin.
<GaryvdM> SpookyET: Which command? diff?
<SpookyET> GaryvdM: Everything: status, diff, log, etc.
<GaryvdM> SpookyET: There is a cdiff command from the bzrtools plugin, which you can alias to diff
<GaryvdM> bzr shelve has color by default
<GaryvdM> but I don't think anything else has color.
 * GaryvdM checks if there is a bug loged
<GaryvdM> *logged
<GaryvdM> SpookyET: Bug 597626
<ubot5> Launchpad bug 597626 in Bazaar "bzrlib should support color (affected: 1, heat: 4)" [Wishlist,Confirmed] https://launchpad.net/bugs/597626
<SpookyET> Thank you.
<poolie> good morning GaryvdM, all
<GaryvdM> Hi poolie.
#bzr 2010-08-17
<poolie> what to do today? reviews maybe?
<AfC> poolie: go for a walk outside. It's sunny. Go figure.
<poolie> it is a lovely day here
<lifeless> its pea soup here
<lifeless> couldn't see across the valley before
<lifeless> couldn't see 20 meters even
 * AfC â coffee
<poolie> hi spiv?
<spiv> poolie: good morning
<spiv> james_w: thanks for releasing bzr-builder 0.4 with the nest-part instruction!
<james_w> spiv: thanks for writing it!
<poolie> spiv, what do you think about merging https://code.edge.launchpad.net/~mbp/bzr/224373-2.2-ftp-response/+merge/32731 into 2.2 vs trunk?
<poolie> perhaps just trunk is better
<spiv> I wonder how long before Launchpad has the new bzr-builder.
<james_w> probably not this week
<spiv> poolie: Hmm, the risk seems pretty smal
<spiv> poolie: especially given that e.g. http://cr.yp.to/ftp/stor.html says "A typical server accepts MKD with code 250 if the directory was successfully created"
<spiv> poolie: so I'd be comfortable with landing that in any/all stable series (after fixing to invoke _setmode for the 250 case, I guess, but even without that it seems to be strictly an improvement)
<poolie> ok
<fullermd> So, what's up with bzrtools?
<poolie> you tell me,
<lifeless> <-|->
<poolie> does trunk pass or fail with 2.2?
<fullermd> What 2.2?
<poolie> does it just need to be packaged?
<fullermd> Latest version is 2.1.0
<poolie> and does that work with bzr 2.2?
<fullermd> I dunno.  'bout the only thing I use is multi-pull, and it seems fine.
<fullermd> (trunk, that is.  2.1 bleats at least, no idea about working)
<poolie> complains about being possibly out of date?
<fullermd> Yah.  Only when you run a bzrtools command at least, so I haven't bothered trying to patch it away in the port build.
<fullermd> It doesn't strike me that the API has moved all that far, so I'd offhand WAG it _works_ OK.  But still.
<poolie> it probably will
<poolie> mkanat: hi?
<mkanat> poolie: Hey hey.
<poolie> hey there
<poolie> spm had an interesting loggerhead bug for you to work on
<poolie> i can't remember if i gave you the number last week
<mkanat> poolie: No, I don't think you did.
 * poolie looks
<poolie> spm: hi?
<poolie> mkanat: bug 617249
<ubot5> Launchpad bug 617249 in Launchpad Bazaar Integration "codebrowse responding to debug requests; 500 erroring on everything else (affected: 1, heat: 6)" [High,New] https://launchpad.net/bugs/617249
<mkanat> I'm almost sure it's going to boil down to some scalability problem, but can't know until I investigate.
<mkanat> One CPU on one machine is never going to scale to Launchpad size.
<poolie> could you investigate? :)
<mkanat> poolie: I can, and I just asked for the data I need, in the bug.
<poolie> ok
<poolie> right it seems very likely to me that we want multiple processes, both for stability and robustness
 * mkanat nods.
<mwhudson> +1
<fullermd> Oh, perforce.  Thank you so much for making fundamental design decisions that make it completely impractical to offer anonymous access...
<spiv> poolie: could I get a quick review of http://bazaar.launchpad.net/~spiv/bzr/merge-2.1-into-2.2/revision/5078?  It's related to your symlink fixes.  Without that fix a merge of 2.1 into 2.2 fails (because 2.2's wt.iter_changes calls self.conflicts calls self.list_files, which is the method that patch changes)
<spiv> I think it would be valid to backport that to 2.1 and 2.0, but I'm not sure that it affects people much.  Maybe a 'bzr ls' would trigger it?
<poolie> hi spiv
<poolie> spiv, that seems reasonable to me
<poolie> biab, rebooting
<vila> hi all !
<lifeless>   hi vila
<poolie> hi vila, welcome back!
<vila> poolie, lifeless : Thanks !
<vila> hmm, babune almost all red expect for gentoo and lucid, quite expected though :)
<poolie> mm
<poolie> even maverick and other ubuntu releases?
<vila> I haven't setup a maverick slave yet, but other releases are red yes, I'm checking why
<poolie> vila, i wouldn't want you to spend a huge amount of time getting it green again
<poolie> it's kinda good but i'm not convinced it's been a really good value for us
<poolie> i'm not quite sure where the cutoff would be
<vila> :)
<vila> Looks like transient failures. Let's see how it goes tomorrow before worrying about it
<poolie> k
<jml> I'd like to make a working tree that has another branch (tree?) merged into it, in order to test a script I'm writing. How would I do that most easily using bzrlib?
<maxb> Wouldn't it be trivial to do it via the command line?
<jelmer> jml: tree.merge_from_branch(other_tree.branch)
<jml> maxb, yes, but I'm not spawning a process for this.
<jml> jelmer, thanks.
<jml> is there a similarly convenient way to clone a branch?
<jml> branch.bzrdir.sprout, it seems
<jelmer> yup
<weigon> hmm, a bzr pull or a
<weigon> hmm, a bzr pull on a stacked-branch doesn't update the workingtree ?
<weigon> I really have to run bzr update to update the working dir ?
<weigon> I created the branch with:
<weigon> src_b.bzrdir.sprout(dst_branch, stacked=True).open_branch()
<weigon> where src_b is a branch.Branch.open(src_branch_url)
<jelmer> weigon, only if the workingtree is colocated
<jelmer> weigon: you're doing a "bzr pull" as command, or using the API?
<weigon> jelmer: using the bzrlib
<jelmer> weigon: in that case, call pull() on workingtree, not branch
<weigon> ah, thx
<weigon> jelmer: *doh* makes sense :)
<RobOakes> Is anyone aware of a step-by-step tutorial for bzr builddeb?  I've configured things as explained here (http://jameswestby.net/bzr/builddeb/user_manual/), but I'm just getting an error.
<RobOakes> Error: Must supply file_id or path.
<james_w> RobOakes: from what command?
<RobOakes> I have no idea what file_id or path it's referring to, though.  (Running in merge mode).
<RobOakes> bzr builddeb
<james_w> RobOakes: please run again with -Derror and pastebin the traceback
<RobOakes> james_w: Here is the pastebin: http://pastebin.com/uD1xnc6V
<james_w> RobOakes: please file a bug at https://bugs.launchpad.net/bzr-builddeb
<james_w> RobOakes: what does an ls of your bzr branch look like? Is it "changelog control copyright rules" etc?
<RobOakes> It just shows the debian packaging files (control, copyright, ...)  Unfortunately, the project is complicated, so there are a lot files.
<james_w> RobOakes: and you have a debian/ directory there too?
<RobOakes> No, just a symlink to the debian directory.  The article I was reading suggested this as a workaround for some packaging systems.
<RobOakes> Should say symlink to the current directory.
<RobOakes> And, removing the symlink fixed the problem.
<james_w> RobOakes: "bzr add" of the symlink should work too
<RobOakes> Okay, that's good to know.
<RobOakes> Thank you very much for the help.
<james_w> RobOakes: please file that bug, as it shouldn't crash in that situation
<RobOakes> I am doing that right now.
<james_w> thanks
<dash> i have a bzr branch that originally used loom; it's at lp:~washort/+junk/modules
<dash> i can't find a way to unloomify it for consumption by people without the plugin
<dash> export-loom doesn't do anything
<dash> is there something i'm missing?
<jam> dash: did you ever run 'bzr record' ? That might be necessary before 'bzr export-loom' works. (I'm just guessing, though)
<dash> jam: well it gets worse, this is branched from somebody else's loom branch
<dash> on which 'bzr record' was never run
<dash> i guess i could go ahead and do it, that might make a difference
<jam> dash: bzr init new-branch; cd new-branch; bzr pull my-loom-branch ?
<dash> worth a shot
<quotemstr1> How do you set a branch's parent branch?
<james_w> quotemstr1: "bzr pull --remember" I think
<quotemstr1> Ah, okay. I was trying to find some git-like configuration entry.
<quotemstr1> Works; thanks.
<GaryvdM> quotemstr1: It's not really recommended, but I often just edit .bzr/branch/branch.conf
<quotemstr1> That was my backup plan.
<jelmer> GaryvdM: hi
<jelmer> GaryvdM: did you see my bug report earlier about test failures in the qbzr testsuite?
<GaryvdM> Hi jelmer
<GaryvdM> jelmer: Yes. I have landed a fix that fixes the bug on new versions of qt, but breaks old versions of qt (<=4.4)
<jelmer> oh
<jelmer> well, that should take care of it for me I guess...
<GaryvdM> And then I discovered that the test is missing a whole bunch of things that It should be testing....
<GaryvdM> So I still need to put some effort in to it.
<GaryvdM> Thanks for the report
<jelmer> np :-)
<jelmer> I'm trying to get 'bzr selftest' to pass on my local machine and that's harder than it should be ...
<poolie> jelmer: urk, what kind of thing is failing? plugins or core?
<jelmer> poolie: various plugins
<jelmer> mainly adapting tests that have never been tried against particular plugin classes
<jelmer> poolie: the recent control dir work I did was inspired by this
<poolie> maybe we can get vila to run some of these plugins in babune, when they're close to being green, and then keep them cleaner
<lifeless> jelmer: thank you for doing this
<lifeless> jelmer: Its what I've been dreaming of :)
<jelmer> lifeless, glad to hear it :-)
#bzr 2010-08-18
<jelmer> maxb: welcome to ~bzr :-)
<maxb> Thanks :-)
<maxb> I vaguely recall some "how to package for the PPA" documentation somewhere?
<lifeless> oh hai there
<maxb> ah, Martin has sent me the link
<poolie> hi maxb
<maxb> hi
<poolie> i might have had the wrong name about /staging
<poolie> or perhaps we only talked of it and didn't actually create it yet
<maxb> I guess that gary was intending to use the beta ppa as a staging area just because it already exists, and isn't currently occupied by later versions
<poolie> it was 2.1-proposed i was thinking of
<poolie> so how about if we create a 2.2-proposed in ~bzr?
<maxb> well, I'd be in favour of a non-versioned name, either proposed or staging
<poolie> ok, so ~bzr/proposed?
<maxb> sounds good to me
<poolie> that's roughly consistent with the meaning of proposed in ubuntu, aiui
<poolie> (it may already be checked for consistency but it's close)
<maxb> close enough, yes
<poolie> ok i'll create that
<maxb> Do you know if there is any standard regarding packaging branches for the plugins?
<poolie> i don't think it's entirely standardized, but it would be good to make it so
<poolie> and/or document what is done now, into that document
<poolie> also we should look at moving the packaging branch names on lp into the package branch namespace, ie
<poolie> lp:ubuntu/hardy/bzr/bzr-ppa
<maxb> That would make them more obvious, yes
<poolie> biab
 * maxb sets a dependency of bzr/proposed -> bzr/ppa
<lifeless> maxb: are you aware of add-apt-archive (IIRC) - adds dependent ppas automatically
<poolie> i didn't know it did that
<lifeless> it should, if it doesn't I have a version I wrote that does
<poolie> maxb in some ways we shouldn't have that dependency
<poolie> we'll get better testing without it
<poolie> if we first copy everything into the proposed ppa
<lifeless> anyhow, for clrity, I'm neither for or against
<lifeless> just adding data to the mix
<maxb> lifeless: Interesting data point, but we can't rely on everyone adding the PPA doing so via add-apt-archive
<poolie> i agree, but what conclusion do you draw from that?
<maxb> option 1 is to build our own subvertpy and dulwich. option 2 is to have jelmer or people he adds to ~subvertpy and ~dulwich build the packages in those PPAs, and copy them into the ~bzr ppas
<maxb> based on jelmer's response, we pick option 1
<maxb> Oh!
<maxb> I've just realized the conversation was about * maxb sets a dependency of bzr/proposed -> bzr/ppa
<maxb> Whereas I was interpreting it as being a response to my email
<maxb> It seems that the lucid version of add-apt-repository does *not* chase PPA build-dependency links
<poolie> no, it doesn't
<maxb> the changelog of the maverick version doesn't mention anything like that either
<poolie> i don't think it should
<poolie> and there's probably no easy way for it to do this
<poolie> on the whole i think we should copy those packages into our ppa
<poolie> i don't think add-apt-archive exists on old ubuntus
<poolie> and people are likely to have the habit of just configuring things manually
<poolie> which will give them dependency errors
<poolie> it may also make it a little easier to check consistency when we promote things from proposed to released
<poolie> we might want a dependency on testtools and subunit too
<poolie> i wonder if you can script the copying through an api?
<poolie> would be nice
<maxb> poolie: Yes, you can. I have a script which I use to promote completed builds from mercurial-ppa/staging-foo to mercurial-ppa/foo
 * maxb removes dependency of bzr/proposed -> bzr/ppa again, since I think I'm convinced that's reasonable
<poolie> ok updating the backport branches now
<poolie> hm so our packaging-dapper, at least, is not related to the current maverick packaging branch...
 * maxb has copied python-testtools into bzr/proposed
<maxb> (for hardy - karmic)
<maxb> Is dapper still worth the effort?
<poolie> maybe not
<poolie> it uses a different python packaging system so it's going to be a bit annoying
<poolie> i'm confused anyhow, because dapper is already EOL
<maxb> poolie: dapper is EOL on the desktop, but not on the server until the release of Nefarious Nundu or whatever
<poolie> natty narwhal fwiw
<poolie> ok, so it may still be supported for server security releases, but perhaps it's not worth doing further non-security updates
<mkanat> All righty, I do believe that it is loggerhead time.
<poolie> spm, meet mkanat
<spm> heh
<spm> heya max! how goes?
<mkanat> spm: Heya! :-)
<mkanat> spm: I seem to have consistently had difficulty getting things simply by requesting them in bugs.
<poolie> getting things?
<poolie> oh asking for debug info
<mkanat> poolie: Data, logs, information.
<mkanat> Yeah.
<poolie> spm may feel he has difficulty getting fixes by requesting them in bugs :)
<mkanat> It seems to me that asking in the bug system ought to be the Right Way....
<spm> mkanat: the logs you were after in the most recent? that'd be a pure timing problem. we've all been in Madrid for the past week - I'm only back at work today myself
<mkanat> spm: Yeah. Okay.
<mkanat> spm: I just want to make sure that the LOSAs are actually seeing my requests when I make them.
<mkanat> spm: In the past I had to ask mwhudson for stuff.
<poolie> i'd like to know that you're unblocked, that you're working on something pretty useful, and that the improvements are actually getting landed into production and data on their success or failure loops back
<spm> but also, bugs aren't wonderful *for us* as a "pls do X" thing. Mainly as we're automatically subscribed to so many across multiple projects; that the sheer volume overwhelms. tehre's no way we can easily filter the noise from real stuff.
<mkanat> poolie: Well, I have other things to work on, on loggerhead, while I wait for that data.
<mkanat> spm: Perhaps Launchpad needs a Requests system.
<poolie> right, i don't mean to to imply you're blocked altogether
<poolie> use Answers
<poolie> assigned to canonical-losas
<mkanat> poolie: Okay, if that works, I can do that.
<spm> that works
<poolie> maxb, since jaunty EOLs in October perhaps we shouldn't update it
 * poolie sees maxb's mail
<maxb> poolie: I suggest we not put particular effort into it if it would be specially difficult, but if it's just one more time around a loop in a script, let's do it
<poolie> agree
<spm> mkanat: part is you're (personally) in a kinda funky space being an external party. So yeah, answers will work per poolie's suggestion; or 'ping losa' in here to get stuff more urgently; or email losas@c.c as an alt/headsup that you've asked for something.
<mkanat> spm: Okay.
<spm> poolie: tho I believe you may have access to the logs on devpad as well? certainly they should be synced there.
<poolie> the loggerhead logs
<poolie> oh ok
 * poolie looks
<SpookyET> Hello. I'm looking for the command that generates a graph like git log --graph.
<rubbs> SpookyET: IIRC there is no command line grapher, you could look at qlog but you'd need qbzr installed.
<rubbs> I could be wrong though
<SpookyET> rubbs: qbzr is a pain to compile on mac.
<rubbs> oh, yes I could see that
<rubbs> is there no installer for bzr explorer for the mac? (sorry i have only tried windows and linux)
<SpookyET> rubbs: To clarify, the dependencies are a pain. I remember trying the HG version, but I don't think it's called qHG. There is, but it looks alien on Mac and not that stable.
<SpookyET> CuteHG. Compiling pyqt, qt4.... it's a pain to get right.
<poolie> rubbs: i thought it was included in the bzr installer? imbw
<poolie> maxb, hardy package sent to the ppa
<poolie> i can never decide if it's less trouble to build locally and faff about with chroots, or to send it straight to the ppa and wonder what will eventually happen
<mkanat> jam: There's no 0.3 branch of meliae...do I just pull from trunk to get 0.3 from bzr?
<poolie> in this case i tried the second, and it was rejected :/
<poolie> due to being in quilt format
<SpookyET> I would like to see one more workflow added to bzr, branching inside the same directory like git/hg. Yeah, I know you can checkout and switch like SVN, but that's not the same thing.
<mkanat> SpookyET: I think that's a design decision difference.
<mkanat> SpookyET: bzr has repos, instead.
<SpookyET> mkanat: The unit of measure is the repo in git/hg. The unit of measure is the branch in bzr. Shared-repos is for space saving, the branches are still separated by physical folders.
<mkanat> SpookyET: Right, but the effect is the same, it's just a different layout.
<mkanat> SpookyET: Perhaps what you want is shelves, which exist.
<SpookyET> mkanat: No quite if have to take paths into account.
<lifeless> so
<mkanat> Sigh. Fedora still ships a debug python. I'm going to have to run Ubuntu in a VM to debug this loggerhead memory problem.
<lifeless> lets shortcut this
<lifeless> we're adding in-workspace branches as an optional core feature eventually
<lifeless> there are already plugins that offer this
<mkanat> Oh, okay.
<lifeless> and that said, you shouldn't need to take paths into account
<SpookyET> mkanat: Why not compile a python in your home dir?
<lifeless> things like 'switch' look in .. appropriately anyway
<mkanat> SpookyET: It will take me just as much time to install Ubuntu as it will for me to compile my own python in a custom location and install every module I need to run both loggerhead and meliae.
<poolie> mkanat: do you know of vm-builder?
<poolie> it's quite nice
<mkanat> poolie: I don't, but the KVM tools in Fedora work really well.
 * mkanat reads up on vm-builder, though.
<SpookyET> lifeless: Think configuration files, virtual hosts.... It's much easier to change the contents of the same folder to test a feature than to configuration files for apps and servers.
<mkanat> SpookyET: I think that shelves will do what you want now.
<mkanat> SpookyET: But I've never used them, so I could be wrong.
<SpookyET> mkanat Shelving is for other things. Let's say you did some changes. But, now you need to fix a bug. You shelve your changes. Fix the bug, commit. Unshelve your changes. It's for a small things. Using shelves as branches is not advisable.
<lifeless> SpookyET: sure. I know some folk find switch just fine for that with branches elsewhere
<lifeless> SpookyET: like I say a) we're going to do it and b) what we have is the basis for it anyhow
<SpookyET> lifeless: I believe you. I understood.
<lifeless> jelmer is a key person doing this stuff
<lifeless> if you want to help out
<SpookyET> Cool
<poolie> maxb: can you tell me where that ppa-copy script lives
<SpookyET> Good night.
<poolie> jelmer (if any) is bzr-git actually in a ppa atm?
<poolie> nm, it's in ~bzr of course, i just misread it
<mkanat> spm: Also, can you tell me whether or not the system was swapping at the time of the hang?
<spm> mkanat: no it wasn't. it was purty much bsns as usual; ~ 1Gb RSS in the process; everything *looked* fine; just wasn't working. :-/
<mkanat> spm: Okay, good to know that we have multiple bugs.
<mkanat> Before, I kept getting various different descriptions of the same bug. :-)
<spm> :-)
<mkanat> Hahaha, I can't debug this memory leak in my VM, because Firefox gets too big.
<lifeless> \o/
<poolie> biab
<poolie> hi spiv, what's new with you?
<spiv> Catching up on old TODOs, mainly.  I started looking at https://bugs.edge.launchpad.net/bzr/+bug/593560, because its tagged UDD, but found the immediate thing to do (disable accel trees by default) had actually already been done for another bug.
<ubot5> Launchpad bug 593560 in Bazaar "Slow performance for many operations on the gcc code import branches (affected: 1, heat: 3)" [High,Confirmed]
<poolie> mm, one of those bugs where it's likely to stay kinda-open
<poolie> perhaps we should either reprofile and identify the next biggest thing, or say that fixing hardlinking fixed it
<poolie> i've been updating ppas
<poolie> it's a bit annoying
<poolie> many possible snags
<spiv> I merged up 2.0->2.1->2.2->trunk, was a bit surprised at how many fixes hadn't made it into trunk yet.
<poolie> thanks for that
<spiv> I kinda wish we could instruct PQM "merge this to 2.x, then merge up to 2.x+1, etc, then trunk"
<spiv> Because as a human I have to wait for PQM to commit the merge to 2.x before I can start the next step.
<poolie> mm
<spiv> But NEWS conflicts and the difficulty in improving PQM would make that annoying to do.
<spiv> (And the news_merge plugin often fails to help with cross-release merges)
<poolie> well, it's not written anywhere that we absolutely have to use pqm
<poolie> but perhaps the pragmatic thing is to just make a bot that merges up every day, or every week, and complains if they fail?
<poolie> lp uses that
<poolie> s/merges/asks pqm to merge
<spiv> I understood :)
<spiv> That would probably be a good start.  Hopefully it would show my concerns about NEWS to be too pessimistic.  I guess the main trouble is when there's a new release on one of the series.
<poolie> we could split out separate news per series
<poolie> then it'll just be an update into NEWS-2.2
 * poolie wonders if it would be too crazy to have a bzr builddeb option that directly uploads into a ppa
<poolie> or maybe there is one
<spiv> Yes, a more machine friendly structure would help a lot.  (And ease implementing policies like "when merging from earlier series, copy new NEWS entries from that series into the latest release of this series")
<vila> hi all !
<spiv> vila: hey!
<poolie> spiv i think i'd rather just have the release say "this includes all changes from bzr 2.0.8, 2.1.x, 2.2.y, etc"
<poolie> but, either way
<poolie> hi vila,
<vila> spiv: hey ! Nice patch for parallel=fork ! I haven't replied yet but while my earlier attempt was different, I think your patch is simpler even if it doesn't address corner cases unlikely to be encountered,
<spiv> vila: I was about to ask if you'd seen it
<poolie> how was your holiday?
<vila> As long as the CPU is/are pegged, I think simplicity beats purity :)
<vila> poolie: just... great
<spiv> vila: there's an interesting side effect too â I don't seem to get "can't start new thread" problems with the new partitioning
<vila> spiv: luck
<vila> spiv: it also depends on how many processes you use
<spiv> vila: possibly because the more even sharing of threads across processes helps stay under the limit we were hitting
<vila> spiv: yes, and spreading the leaking tests
<spiv> (well, "more even" assuming thread-leaking tests occur in clumps, as is the case atm)
<vila> spiv: yup, but I still like to resubmit my fixes on the subject :-D
<spiv> Please do :)
<spiv> This is just avoiding the symptoms a little better, not fixing the problems that cause them :)
<vila> spiv: indeed ! And certainly avoiding them more robustly than just using --parallel=fork
<vila> meh, I meant, just slicing the whole test suite
<spiv> vila: implement --isolate=fork? ;)
<lifeless> spiv: from subunit import donealready
<spiv> lifeless: I know, but there's no CLI glue in the bzr test runner for it :P
<vila> spiv: how many cores do you use ? (More precisely what does python -c 'from bzrlib import osutils ; print osutils.local_concurrency()' says for your PC ?)
<spiv> vila: 4
<vila> spiv: ok, so any bad balancing is impacting you more than me (8). Quick tests shows that your patch is more effective than the previous version but still leaves a single (or two) process running in the end (instead of 8)
<vila> spiv: my patch was avoiding that to the cost of forking more processes, so on the overall, I'm not sure it can beat yours for the total elapsed time
<spiv> I think it's hard to beat my patch if we determine the partitions ahead of time and without any idea of how long each test takes.
<vila> spiv: anyway, as said above, simplicity wins so I'm very happy you addressed the problem :D
<spiv> A more dynamic allocation of tests to the subprocesses could do better.
<vila> spiv: yup, my patch tried to address that by partitioning only some of the tests and as soon as one process ends, started a new one with part of the remaining tests
<vila> spiv: so, more forks with their associated costs
<vila> spiv: your patch is not in 2.2 right ?
<spiv> I don't think so... but see http://pastebin.com/MEbk2TAy ;)
<spiv> In theory you could dynamically allocate tests without more forks if the subprocesses didn't need to know their list of tests in advance.
<spiv> But whatever you do to improve it will be more complex than my patch ;)
<GaryvdM> Hi james_w.
<GaryvdM> james_w: You said I must speak to you to change the qbzr ubuntu branches to pull from the debian branch and/or the upstream branch.
<GaryvdM> I would really like to do that.
<vila> spiv: yup, it wasn't itching enough before your patch, I don't think it will now :)
<spiv> :)
<poolie> spiv/lifeless, what do we normally do to upgrade trunk import branches?
<poolie> create a new import and make that the focus?
<lifeless> hmm?
<lifeless> I like to upgrade in place
<poolie> http://code.edge.launchpad.net/postgresql is all still in 1.19 format
<lifeless> wheee
<poolie> doesn't that disrupt other branches stacked on it?
<lifeless> yes
<lifeless> but recoverably - they can be upgraded independently (unless they are woefully damaged as per bugs spiv has worked on recently)
<poolie> they can be upgraded too separately, or we need to ask people to do them separately?
<lifeless> there's no automatic around those upgrades that I'm aware of
<lifeless> some folk just make a new import
<lifeless> largely its been the consumers of the branches choices, so far.
 * mneptok consumes lifeless and belches erotically
<lifeless> mneptok: I don't think that means what you think it means
<Crovax-31> Hi, I'm trying to create a bzr repository from a git one
<Crovax-31> but I don't find a good way to use git-bzr
<Crovax-31> or bzr-git
<lifeless> jelmer: this ones yours I think :)
<jelmer> heh
<jelmer> Crovax-31, what doesn't work exactly when you try bzr-git?
<Crovax-31> hum, I used easy_install to get it, and "bzr: ERROR: unknown command "git-import""
<jelmer> Crovax-31, easy_install doesn't work for bzr plugins as far as I know
<Crovax-31> I tryed to copy the egge in ~/.bazaar/plugins/git
<jelmer> Crovax-31: can you try putting the branch/directory in ~/.bazaar/plugins/git ?
<jelmer> eggs don't work for bzr plugins (that's the reason easy_install doesn't work, too)
 * Crovax-31 is french what do you mean by  putting the branch/directory in ~/.bazaar/plugins/git, unzip the last tar.gz?
<jelmer> yep
<Crovax-31> bzr: ERROR: exceptions.AttributeError: 'InterLocalGitNonGitRepository' object has no attribute 'fetch_refs'
<Crovax-31> the plugin seems to be installed ^^
<Crovax-31> thanx
<jelmer> Crovax-31: Yeah, unfortunately that's a known issue - "bzr branch" should work though, or a more recent revision of bzr-git
<Crovax-31> I'm using the lastest release
<Crovax-31> ee, how to use bzr branch specifying git for a local repo/folder
<jelmer> Crovax-31: Just specify the URLs as you usually would
<Crovax-31> so if my repo is ./docs I'll put?
<jelmer> Crovax-31: if your bzr repository is at ./docs, e.g. use "bzr branch git://foo/host ./docs/trunk"
<Crovax-31> great, thanx a lot it works
<GaryvdM> poolie: Are you still up? Got some questions about the ppa.
<metaperl> I am trying to get bazaar 2.1 or greater for unbuntu, but dont see a link here - https://launchpad.net/~bzr/+archive/ppa
<jelmer> metaperl, that PPA has bzr 2.1
<metaperl> jelmer I dont see a link though....
<jelmer> metaperl: what sort of link are you looking for?
<metaperl> I want to download a .deb and install via dpkg
<maxb> jelmer: I don't suppose you remember why dulwich Build-depends: python-support (>= 0.90) ?
<metaperl> how would adding something to /etc/sources.list lead to this bzr overriding the one in standard ubuntu?
<metaperl> oh now i've clikcedon the tech details link
<maxb> metaperl: The file is /etc/apt/sources.list. apt will use the highest version of a package available across all configured sources
<jelmer> maxb: Mainly because that's a version of python-support I knew worked.
<maxb> k
<metaperl> maxb thanks I didnt know that
<aj-dneg> i'm using bzr to hack on an svn repository (no branch layout). after some upstream changes have been made i merge them into my local branch with bzr merge and obviously can't push. rebase seems to do nothing even though i have a branch/merge in my history but not on the server. the other option is to merge back in (and lose the individual commits) but i don't want to have to make a separate trunk checkout just to do that. can i do it directly? bzr merge only w
<aj-dneg> orks on the current folder...
<aj-dneg> did that all get through ^^?
<jelmer> aj-dneg: rebase will only rebase your local branch onto new revisions on the server side
<jelmer> aj-dneg: merge and rebase don't mix very well. perhaps try uncommitting the merge and then rebase ?
<aj-dneg> i'd rather not undo several revisions
<aj-dneg> i would be ok to just do a merge, at least my repo keeps the individual commits then
<aj-dneg> is there some way i can do bzr merge --branch svn://whatever/ .
<aj-dneg> or do i really have to make my own local branch of svn://whatever/ first
<jelmer> aj-dneg: You would have to make your own local branch of svn:// first.
<aj-dneg> so i have two branches, upstream and local? :S
<maxb> gah. git on hardy lacks the --bare option to init, scuppering the dulwich testsuite
<jelmer> maxb: I'd ignore the testsuite for hardy in that case
<jelmer> newer revisions of dulwich no longer depend on git-core
<maxb> hrm. actually the suite is broken even on karmic
<maxb> prior to lucid, git init did not take a directory positional argument
 * maxb shelves temporarily to ponder
<aj-dneg> is there some way to generate a list of patches, one per-revision in bzr?
<LeoNerd> I'm not sure I get the question...
<LeoNerd> You mean like  bzr log   ?
<jelmer> aj-dneg: bzr log -p ?
<aj-dneg> jelmer: that's pretty much it -- thanks :)
<aj-dneg> jelmer: actually i just found bzr send, even better!
<thrope> hello - whats the situation with keyword expansion? I would like to have the current revision automatically included in a document like with svn keywords
<jelmer> thrope, see http://launchpad.net/bzr-keywords
<fullermd> Unchanged from some time ago; PoC.
<jelmer> PoC?
<fullermd> Proof of Concept
<fullermd> It's not really usable in any practical sense.
<mars> Hi everyone, I have a question about removing a symlink from a source tree
<jelmer> hi Maris
<mars> Hi jelmer
<mars> the symlink points to ../thefile
<mars> which is obviously not versioned (it is branch parent directory)
<mars> whenever I try to run 'bzr rm thesymlink', bzr says "No WorkingTree exists for "file:///home/mars/launchpad/qa-tagger/.bzr/checkout/"
<mars> file:///home/mars/launchpad/qa-tagger/.bzr/checkout/ is the shared repository full path
<jelmer> and "bzr root" works as expected, printing the root of your working tree?
<mars> yes it does
<jelmer> I think this might be an open bug
<mars> ok
<mars> I may try overwriting the symlink, committing, then removing
<jelmer> is thefile a branch by any chance?
<mars> no, it is not.  It is a regular file.
<jelmer> mars: you might try removing the file before running "bzr rm"
<mars> jelmer, I tried that as well, and it did not work.  I may have had to use 'rm thelink; bzr rm ../thefile' instead of 'rm thelink; bzr rm thelink'
<mars> jelmer, I just overwrote the symlink with a plain old file, committed that, then removed it.  Works.   Thank you for the help.
<metaperl> excuse the amateur question, but when I want to update a bazaar repo that I downloaded via bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk  ... what do I type?
<dash> 'bzr pull'
<metaperl> oh ok thanks
<mkanat> Can a commit have multiple parents?
<dash> mkanat: sure, in the case of merges.
<mkanat> Okay.
<kyan> Hello! I'm a bit of a noob to bzr, but now I'm on a linux box and have it installed. When I type bzr push lp:~info-futuramerlin/futuramerlin.com-calculator/main0.93, I get bzr: ERROR: Invalid url supplied to transport: "lp:~/info-futuramerlin/futuramerlin.com-calculator/main0.93": No such person or team:  . What should I do about that? Thanks!
<dash> hm
<dash> kyan: are you sure what you typed starts with "~info" and not "~/info"?
<marienz> my first guess is actually that your shell did odd things to that ~
<marienz> I'd try quoting the entire url
<dash> oh true.
<kyan> Same error.
<kyan> At https://code.launchpad.net/~info-futuramerlin/futuramerlin.com-calculator/main0.93, it gave what I typed.
<kyan> @dash: Oh, now I get what you're saying.
<kyan> I typoed....
<kyan> Still not working. This exchange was rather wordy, so: http://pastebin.com/rU5sVuv2
<dash> ah.
<dash> launchpad doesn't know about your ssh key.
<kyan> Ok... I added one the other day.
<kyan> https://launchpad.net/~info-futuramerlin/+sshkeys
<kyan> Did I do something incorrectly in adding it?
<kyan> I generated it with a different computer. Should I make another one?
<rubbs> do you have the cooresponding key on this computer?
<kyan> No.
<kyan> (I assume you mean the files in ~/ssh
<kyan> I mean ~/.ssh
<rubbs> correct.
<rubbs> you need the private key in your .ssh dir
<kyan> Ok I guess I'll make a new one.
<rubbs> yeah, probably a good idea. you can have multiple ones on the site
<lifeless> or you can copy it from the other machine
<rubbs> this too ^
<kyan> Done.
<kyan> https://launchpad.net/~info-futuramerlin/+sshkeys
<kyan> I'm 'push'ing that again.
<kyan> elwa@gozog-desktop:~/dev/futuramerlin.com-calculator/main0.93$ bzr push "lp:~info-futuramerlin/futuramerlin.com-calculator/main0.93" Enter passphrase for key '/home/elwa/.ssh/id_rsa':  bzr: ERROR: Target directory lp:~info-futuramerlin/futuramerlin.com-calculator/main0.93 already exists, but does not have a .bzr directory. Supply --use-existing-dir to push there anyway.
<kyan> Should I use --use-exsisting-dir?
<rubbs> if you are just pushing and updated version of the same branch then yes you can do that. keep in mind that if history is different, it will be overwriten IIRC
<lifeless> did you make the branch via the web UI ?
<kyan> Yes.
<lifeless> then yes, use --use-existing-dir
<lifeless> making branch via the web UI causes that
<lifeless> thumper: ^ :)
<kyan> ok
 * thumper sighs
<lifeless> I know you know
<thumper> yes, redoing the register branch page has been on a TODO list for ages
<lifeless> but I'd really love to just remove that field from the form
<thumper> lifeless: that is the plan
<thumper> lifeless: and to have general push instructions isntead
<lifeless> is there anything particularly hard about it ? I mean, could *I* do it ?
<thumper> we should do some proper UI design
<lifeless> that too
<thumper> I'd like to have the same form do foreign mirrors too
<kyan_> It's gotten stuck with Fetching revisions:Inserting stream
<kyan_> What does that mean?
<lifeless> its pushing
<kyan_> Ok ... must be pretty slow since it says '0KB/s'.
<kyan_> Is there a way to see its status?
<kyan_> BTW, in case you're curious, what I'm doing is releasing my calculator program as floss, and uploading old revisions.
<kyan_> http://www.futuramerlin.com/data/2186.html
<lifeless> well, it looks like you're having some internet connection trouble
<lifeless> the push does need to send a fair amount of data the first time
<kyan_> Ah! It says 'created new branch'. I guess that's good.
<kyan_> Seems to have worked!
<kyan_> http://bazaar.launchpad.net/~info-futuramerlin/futuramerlin.com-calculator/main0.93/files
<lifeless> congrats
<kyan_> I'm uploading my oldest version now. Thanks for your help!
<kyan_> Ok... still problems.
<kyan_> When I pushed the previous version 0.91 it seemed to succeed but when I looked at it via the web interface there were no revisions.
<kyan_> http://bazaar.launchpad.net/~info-futuramerlin/futuramerlin.com-calculator/main0.91/files
<kyan_> elwa@gozog-desktop:~/dev/futuramerlin.com-calculator/main0.91$ bzr push "lp:~info-futuramerlin/futuramerlin.com-calculator/main0.91" --overwrite bzr: ERROR: Working tree "/home/elwa/dev/futuramerlin.com-calculator/main0.91/" has uncommitted changes (See bzr status). Use --no-strict to force the push. elwa@gozog-desktop:~/dev/futuramerlin.com-calculator/main0.91$ bzr status added:   Calculator_ALL0_91.zip   Calculator_exe0_91.zip elwa@gozog
<kyan_> fo-futuramerlin/futuramerlin.com-calculator/main0.91" --no-strict Enter passphrase for key '/home/elwa/.ssh/id_rsa':  No new revisions to push. elwa@gozog-desktop:~/dev/futuramerlin.com-calculator/main0.91$
<kyan_> Still, there's nothing there. Any ideas?
<lifeless> bzr st
<kyan_> elwa@gozog-desktop:~/dev/futuramerlin.com-calculator/main0.91$ bzr st "lp:~info-futuramerlin/futuramerlin.com-calculator/main0.91" nonexistent:   lp:~info-futuramerlin/futuramerlin.com-calculator/main0.91 bzr: ERROR: Path(s) do not exist: lp:~info-futuramerlin/futuramerlin.com-calculator/main0.91 elwa@gozog-desktop:~/dev/futuramerlin.com-calculator/main0.91$
<kyan_> elwa@gozog-desktop:~/dev/futuramerlin.com-calculator/main0.91$ bzr st added:   Calculator_ALL0_91.zip   Calculator_exe0_91.zip elwa@gozog-desktop:~/dev/futuramerlin.com-calculator/main0.91$
<kyan_> Hmmm, doesn't seem to be doing much
<lifeless> that says you have added a file
<lifeless> but you haven't committed it
<kyan_> How should I commit it?
<lifeless> bzr commit
<kyan_> 'push' didn't work.
<kyan_> ok.
<lifeless> I note that you're adding zip files
<lifeless> this is a bit unusual
<lifeless> what are you trying to accomplish here?
<rubbs> kyan_: if you are uploading source, best to keep it uncompressed, bzr will compress the history for you.
<kyan_> @rubbs: ok. I was just uploading the old files. Sorry. I'll upload those again.
<rubbs> Just to clarify commit will place the changes you made to the local history, push will then push your history updates to the remote branch. This is why you much commit before pushing ;)
<kyan_> After unzipping them.
<kyan_> Ohhhhh. Thanks. As I said, I'm quite a noob to this :-)
<rubbs> kyan_: that's probabaly better. Bzr will know how to compress that better, most VCSs don't do well with binaries.
<lifeless> if you want to upload old releases
<rubbs> kyan_: np, we all were there at one point.
<lifeless> you can use the releases facility, which works with zip files/tarballs that sort of thing
<rubbs> oh I didn't know about the releases facility.
 * rubbs looks that up
<kyan_> Lifeless: what is the releases facility?
<kyan_> http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=launchpad+releases+facility
<lifeless> in launchpad
<lifeless> you have 'series'
<lifeless> each series has milestones
<lifeless> and milestones can be 'released'
<lifeless> after they are released you can attach changelogs, release notes and downloads to them
<kyan_> what is a series?
<kyan_> what are milestones?
<kyan_> (sorry I'm not more familiar with the terminology)
<lifeless> https://help.launchpad.net/Projects/SeriesMilestonesReleases
<kyan_> Thanks.
<kyan_> Still more problems: elwa@gozog-desktop:~/dev/futuramerlin.com-calculator/main0.91$ bzr commit "lp:~info-futuramerlin/futuramerlin.com-calculator/main0.91" Committing to: /home/elwa/dev/futuramerlin.com-calculator/main0.91/                                   aborting commit write group: PathsNotVersionedError(Path(s) are not versioned: lp:~info-futuramerlin/futuramerlin.com-calculator/main0.91) bzr: ERROR: Path(s) are not versioned: lp:~inf
<kyan_> just running 'bzr' says that 'bzr add' will make them versioned.
<kyan_> I ran bzr add
<kyan_> and then it gave me the same error when I tried to commit it.
<jelmer> kyan_: you can't commit to a remote location
<jelmer> kyan_: You'll have to commit locally and then push your changes.
<kyan_> Um, ok... so just run bzr commit?
<rubbs> right
<kyan_> Thanks...
<rubbs> you do all your changes locally first, the only thing you do to remote branches (usually) is push and pull
<rubbs> there are exceptions of course, but for our purposes now, always do stuff locally, and make the remote a "mirror" of your local branch by pushing to it.
<kyan_> While committing it it opened nano and should I type sthg now?
<kyan_> rubbs: thanks. That makes sense.
<rubbs> np
<rubbs> yes, I believe when it opens nano it's asking for a commit message
<rubbs> I usually commit like this when it's just a short message $ bzr commit -m "My short commit message"
<kyan_> Ok. Thanks.
<rubbs> np
<kyan_> Did that and pushing it.
<rubbs> good, initial pushes take a while, but subsequent ones should be quicker
<kyan_> Is that because subsequent ones just send a diff?
<rubbs> more or less
<rubbs> little more, but it won't send info the remote system already has
<kyan_> BTW, my reason for using zips has something to do with the 22mb vs 3mb filesize difference... :-P
<lifeless> bzr will pack tighter than zips
<lifeless> if you do 10 zips you'll have 30 mb
<lifeless> if you put the original source in bzr without zips, and did 10 commits, you'll have 3mb
<rubbs> exactly bzr will require a larger amount up front but down the road the savings will be quite worth it.
<lifeless> rubbs: it shouldn't require more up front either
<kyan_> Also, is it possible to do this pseudonymously or anonymously?
<rubbs> oh right, I was thinking with a working tree
<rubbs> kyan_: well pushing would require an account on lp, but anyone with bzr could branch from it IIRC
<kyan_> I was just wondering b/c launchpad seems to have used the wrong pseudonym.
<kyan_> (my personal pseudonym rather than my development pseudonym{
<rubbs> of that I'm not sure what happened. I'd help out, but I have to go now sorry.
<rubbs> good luck with everything, and continue to ask questions if you have them. Someone will answer
#bzr 2010-08-19
<kyan> Hello again! Why is it that http://bazaar.launchpad.net/~info-futuramerlin/futuramerlin.com-calculator/main0.96/files shows the content of three of my local directories even though I cded to the right one before 'bzr add' 'bzr commit -m' 'bzr push'?
<Demosthenes> right. i'm using branches for separation of roles and distribution. (prod/test/dev) merging up from one to the next, i'm running into situations where i'm having simple one-line changes labelled as conflicts, which don't show in the conflict output
<Demosthenes> when i'm merging interactively
<maxb> poolie: Hi, if you're around, what's your likely timeline for sorting the failed bzr builds in ~bzr/proposed?
<poolie> hi maxb
<poolie> i'm going to do that pretty much now
<maxb> yay
 * maxb resumes bashing dulwich into shap
<maxb> e
<poolie> hi spiv
<spiv> Morning.
<spiv> Oh good, the socket regression in python2.6 in maverick got fixed.
<jelmer> \o/
<poolie> hi spiv
<poolie> james_w: still around?
<james_w> hi poolie
<poolie> spiv if your plate is empty i was going to suggest bug 619614,
<ubot5> Launchpad bug 619614 in bzr-builddeb "InconsistentDelta during merge-upstream (affected: 1, heat: 6)" [Critical,Triaged] https://launchpad.net/bugs/619614
<poolie> unless james_w is already on it
<james_w> nope, I just wanted to note the pointer today, I was going to come back to it soon
<james_w> getting a small test case should make working out the interaction fairly easy, but unfortunately because of the strategy of building everything up and then applying the transform it can be hard work going from the final state back to the operations that caused it.
<spiv> poolie: ok, I'll do that
<poolie> maxb, i know what broke the earlier uploads
<poolie> hard and jaunty are now ok, and i'll just push rebuilds for karmic..
<poolie> maxb should be all ok now
<poolie> testing them in chroot snapshots...
 * mwhudson had forgotten how slow log -v is with packs
<poolie> maxb: hi; so bzr seems ok in the ppa
<poolie> bzr-svn needs some love, or a backport?
<poolie_> maxb, i'm going to backport bzr-svn now
<poolie_> actually, maybe i'll see if jelmer wants to do that
<poolie_> maxb, around?
<poolie> james_w: should i just s/debian_bundle/debian to fix these deprecation warnings?
<vila> hi all !
<vila> poolie: I caught up with my mail backlog and noticed I was patch pilot this week, sorry for starting so late :-/
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.2-final has gone gold, build those installers
<poolie> np, i was a bit slack last week
<poolie> i'm updating ppa packaging stuff
<poolie> i'd happily swap :/
<poolie> it's a bit tedious
<poolie> otoh it's good practice for getting into making it better
<vila> yeah, learning is always painful :)
<vila> mgz: ping
<poolie> woo spiv :)
<poolie> vila, what's next for you?
<vila> poolie: roughly: pp'ing, re-submitting the mps I've put in WIP before my vacations (leaking tests and locking config files)
<spiv> vila: incidentally, if you want to be a really amazing PP, talk a look at the full list of WIP MPs for lp:bzr at https://code.edge.launchpad.net/~bzr-pqm/bzr/bzr.dev/+activereviews
<vila> then, pursuing config stuff (as we discussed) and/or more conflict resolution and/or UDD bugs
<spiv> Just in case the regular list doesn't keep you busy ;)
<vila> spiv: hehe, I've already looked at that if only to find my own  MPs ;)
<lifeless> spiv: tests needed ;)
<vila> poolie: by the way, I was wrong yesterday, we *have* a maverick slave on babune but it's currently failing because it uses python-2.7 to help mgz
<GaryvdM> Hi vila.
<vila> GaryvdM: hey !
<GaryvdM> Should I maybe merge poolie's branch and mine together with mine, and merge together?
<GaryvdM> Or land poolies, and them merge dev into mine?
<vila> GaryvdM: just land yours :) If a conflict occurs for poolie it will be trivial to fix
<GaryvdM> vila: Ok.
<Crovax-31> Hi, it's me again, if I have two branches, i want to apply 2 commits (and not all of them) from one to the other
<Crovax-31> do I make a patch or it may be applyed directly?
<GaryvdM> Crovax-31: You can do a cherry-pick merge:
<GaryvdM> bzr merge FROM_BRANCH -r x..y
<GaryvdM> Crovax-31: unfortunately, cherry-picks are not yet tracked in the history like other merges.
<Crovax-31> GaryvdM:  which man page talk about this feature?
<GaryvdM> Crovax-31: bzr help merge
<GaryvdM> quote: "When merging a branch, by default the tip will be merged. To pick a different
<GaryvdM>   revision, pass --revision. If you specify two values, the first will be used as
<GaryvdM>   BASE and the second one as OTHER. Merging individual revisions, or a subset of
<GaryvdM>   available revisions, like this is commonly referred to as "cherrypicking"."
<Crovax-31> great, thanx for the help
<Crovax-31> "bzr merge --revision=4761..4762 ../my_repo/" thanx GaryvdM
<fullermd> Note that that's applying 1 commit, not two...
 * jelmer waves
<LeoNerd> Is there anything I ought to know about running bzr as root? E.g I'm using it to version control my DNS zonefiles in /etc/bind, inplace, so I just run   sudo bzr ...
<vila> LeoNerd: you may encounter errors about the log file or some config file in ~/.bazaar owned by root,
<vila> but AFAIK we fixed that in recent versions of bzr
<LeoNerd> OK.. well.. so far I've not seen any errors or problems at all, in fact.. :) Was just wondering if e.g. there might be any security issues involved in it..?
<vila> LeoNerd: well, nothing that I know of, but as usual while running anything as root, be extra careful :D
<LeoNerd> Sure. :)
<LeoNerd> e.g I was just wondering if $malicioususer could plant some file somewhere that bzr as root would execute.. but then if said user can write to /etc/bind I suppose I have bigger problems
<vila> LeoNerd: being paranoid but willing to version control some files that only root can modify, I've setup some scripts to help me *copy* the original files into a versioned controlled tree, but that's just me :) etckeeper requires bzr to be run as root
<vila> LeoNerd: I'm pretty sure bzr doesn't rely on any external exceutable by default (except python itself of course)
<vila> diff was used in the early days but isn't anymore
<LeoNerd> Ya.. was wondering on local plugins and whatnot..
<vila> at least not by default (patch were used too long ago)
<LeoNerd> E.g. I know vim has had issues in the past with modelines and so on...
<LeoNerd> A user could construct a modeline that means vim will execute a command as root, if root even just "view"s the file. :)
<vila> LeoNerd: so, even with sudo, the user plugins will be used
<vila> LeoNerd: you can avoid them if you don't need them with --no-plugins or with a paranoid use of BZR_PLUGIN_PATH, BZR_DISABLE_PLUGINS and BZR_PLUGINS_AT
<LeoNerd> Right.. Well, I think this is good enough
<vila> ok
<vila> mgz: ping
<maxb> I suppose one thing that could be done is for sudo to clear BZR_PLUGIN_PATH and BZR_PLUGINS_AT, much like it clears PYTHONPATH
<vila> maxb: meh, that will forbid the trick I mentioned above :)
<LeoNerd> maxb: Doesn't sudo by default clear most of env anyway?
<maxb> it varies on config
<maxb> mine doesn't because it's too damn paranoid
<maxb> s/it's/that's/
<vila> LeoNerd: you may also consider 'sudo -H' so that ~root is used to better control which plugins are used and avoid the bugs I mentioned above
<mgz> hey vila!
<vila> mgz: heeey !
<LeoNerd> AHyes
<mgz> did you have a nice holiday?
<vila> mgz: just... lovely :)
<vila> mgz: I'm looking at https://code.edge.launchpad.net/~gz/bzr/cleanup_testcases_by_collection_613247/+merge/32711
<mgz> there's some log from a few evening ago that might help as well...
 * mgz goes to find
<vila> and the corresponding one for testtools
<mgz> http://irclogs.ubuntu.com/2010/08/15/%23bzr.html#t23:35
<mgz> http://irclogs.ubuntu.com/2010/08/16/%23bzr.html
<vila> mgz: see my comment on the mp while I read those logs
<mgz> great thanks, I'll go read.
<vila> mgz: hmm, I just realize the ~4000 uncollected test cases I'm seeing may require your testtools patch...
<mgz> ah, yeah, and I needed some feedback on if that'd break --parallel
<vila> mgz: there is that too :)
<mgz> wasn't clear from the code and I didn't want to fiddle around faking more than one cpu here as there weren't any failing test_selftest tests
<vila> mgz: I don't understand how locals can be involved in ref cycles... Aren't they supposed to be freed when leaving a function/method ?
<vila> mgz: cough, lack of test for --parallel ? I can believe it :->
<vila> grrr, I *can't* believe it
<mgz> it works as an expression both ways!
<mgz> just needs different tone of voice imagined.
<vila> looks like holidays is not a cure for my typos ruining jokes disease :)
<mgz> okay, I'll reply to a few points in the mp so they get recorded rather than lost on irc
<vila> mgz: all the babune slaves have 2G not 8 :)
<vila> mgz: works for me
<mgz> I'm unsure, but I think this probably won't help babune,
<mgz> unless some of the thread failures are of the "can't start new thread" variety still.
<vila> mgz: Just mentioning to mitigate your remark about people with 8G PCs (not that I'm concerned here since I have 12G :-D)
<mgz> ehehehe
<mgz> most devs do, it's only me and parth who've reported issues running the whole test suite
<vila> mgz: also, maverick/py27 is still failing if you want to have a look at it on babune
<mgz> great, I will do.
<mgz> hopefully I've got bugs filed on everything, but maverick might turn up a few new ones.
<GaryvdM> I'm sure I read about tool in bzr to help merge changelog files, but I can't find anything about it now.
<GaryvdM> Can anyone advise me where to look?
<mgz> do you just mean the news-merge plugin?
<vila> GaryvdM: james_w will now for sure but I suspect it's part of builddeb and similar to news-merge
<james_w> poolie: no, I prefer to import the new name and catch ImportError to fall back.
<mgz> vila: what's the link for maverick/py27 on babune? (posted mp reply)
<GaryvdM> mgz: oh - maybe that was what I was thinking about.
<vila> mgz: it's just maverick, py27 has been installed for you, I will revert that once you're happy with the results to turn the slave into a "regular" one (revert to py26 until py27 becomes "natuarally" the default for maverick if ever)
<james_w> GaryvdM: yeah, there's one for Debian changelogs in bzr-builddeb thanks to jam
<vila> mgz:  in case you encounter weird problems related to extensions, pyrex is not available so far for py27 so I ran py26 setup.py build_ext -i
<mgz> hm, and I see it ends with:
<mgz> ERROR: Failed to archive test reports
<mgz> hudson.util.IOException2: remote file operation failed: /home/babune/babune/slaves/maverick64.local/workspace/selftest-maverick at hudson.remoting.Channel@3a777ac9:maverick64.local
<mgz> which I presume is not my fault?
<vila> mgz: the last one yes, some previous one went a bit further I think
<vila> mgz: well, it's nobody's fault :) But I thought you fixed enough stuff to make it pass... I was wrong :)
<mgz> yeah, #16 ran the whole suite, but hudson appears to have not managed to record the results
<mgz> Ran 20939 tests in 298.961s
<mgz> FAILED (failures=53, errors=8, skipped=2184, expected failures=25)
<mgz> that's not too bad, and the tail-end ones in the console log all look like things I've got bugs open for
<GaryvdM> james_w: Thanks. I think it's maybe not beening used, as the debian dir is the root of the branch. I change that, and see if it works.
<GaryvdM> mgz: Is that for py2.7?
<mgz> yup.
<mgz> odd, bzrlib.tests.per_repository.test_revision.TestRevProps.test_simple_revprops(RepositoryFormat6) has the same traceback five times,
<mgz> might mean Robert's cleanup reporting is broken on 2.7 somehow
<mgz> ha, yes, each (param) is adding a traceback
<vila> mgz: good, I'm more concerned by the [multi part 0 .... ] stuff still looking like leaks from subunit or something
<mgz> I'm just getting the full log now. continuing stream leaky problems probably explain the java xml parsing error at the end that's breaking the reporting
<mgz> I'll have a look at the subunit code see if I come up with any theories
<GaryvdM> vila: is this a bug? : http://pastebin.org/613865
<vila> GaryvdM: tree transform is malformed is almost always a bug :-/ bzr.dev ?
<GaryvdM> vila: no - 2.2.0
<GaryvdM> vila: Let me try with bzr.dev
<vila> GaryvdM: no need,
<vila> GaryvdM: 2.0 and dev are close enough
<vila> GaryvdM: a bug with a reproducing recipe will be highly appreciated (especially if you encountered it for a common use case (which I suspect))
<GaryvdM> vila: Ok
<nUboon2Age> newbie question: i forgot to add an item in the changelog when i was doing a commit.  is there a way to retroactively alter it to add the item?
<LeoNerd> Only by uncommit/commit, but then you've made a brand-new commit, not altered the original one. If it's a private branch nobody else is looking at, then that should be OK, but if it's been pushed or exists somewhere others can see it then its' a rather disruptive operation, as now everyone else will be out of sync.
<nUboon2Age> LeoNerd: okay thank you for a clear explanation.  That lays out my options fairly straightforwardly.
<nUboon2Age> oh, another related question: i pushed this rev onto LP.  can i somehow delete this branch (so i can do it again correctly?) LeoNerd?
<LeoNerd> Ah well, I don't really know LP much...
<nUboon2Age> i mean the LP version of the branch, not my local version of the branch...
<nUboon2Age> LeoNerd: oh, okay well thank you for your help.  i appreciate it.  anyone else?
<nUboon2Age> okay i found a place to delete the branch, so thanks all. ;-)
<nUboon2Age> on the branch details page.
<rubbs> nUboon2Age: if someone else already branched from that LP branch you could still run into trouble
<nUboon2Age> ah good to know rubbs. thank you.
<rubbs> np
<rubbs> mostly because all their stuff will be referencing that branch. It may be a good idea to just add another commit with your fix.
<nUboon2Age> here's just a thought: it'd be nice to have some kind of admin function where mistakes like that could be fixed. ;-)
<nUboon2Age> i can imagine it would be complicated, but i can envision it being at least possible.
<vila> nUboon2Age: if nobody has yet pull your branch you can do 'push --owerwrite'
<nUboon2Age> vila: oh cool.  thanks!
<vila> nUboon2Age: well, even if some people have pulled, you still can, they will have to either 'pull --overwrite' or merge if they really need
<nUboon2Age> vila: excellante!
<hazmat> with bzrlib how do i get from a branch object to the working tree object?
<hazmat> i'm trying to programatically check if my local branch/checkout has uncommitted changes
<vila> hazmat: you can go from wt to branch (wt.branch) not the other way around, a branch has no idea about which wt is using it and the only the wt can have uncommitted changes
<vila> hazmat: wt.has_changes() should address your need
<hazmat> vila, ic, thanks
<hazmat> using bzrlib.. given a remote branch url like lp:~zebra/foobar/trunk .. how could you open a branch object pointing to it?
<hazmat> i tried Branch.open(url) but it seems to want things from the local fs
<hazmat> ah.. i need to deference lp and use a transport it looks like
<vila> hazmat: b = Branch.open_containing(location)[0]
<vila> hazmat: when searching for such tricks, have a look in bzrlib/builtins.py
 * vila off to bed :)
<hazmat> vila, i'll have a look, i ended up going location = "lp:~/foobar/foobra/ensemble".replace("lp:", "bzr+ssh://bzr.lp.net"); t = get_transport(location); Branch.open_from_transport(t).. doing open_containing with a remote location by default attempted to look at a local directory
<hazmat> at least with the lp  alias
<lifeless> you can get *a* wt for a branch (not the only one, may not be the one being committed from, may not exist), by doing branch.bzrdir.open_workingtree()
#bzr 2010-08-20
<poolie> hi all
<spiv> Good morning.
<poolie> hi there spiv
<poolie> spiv does https://bugs.edge.launchpad.net/bzr/+bug/620684 suggest anything obvious to you?
<ubot5> Launchpad bug 620684 in Bazaar "ERROR file id "None" is not present in the tree when checking the root entry (affected: 1, heat: 6)" [Undecided,New]
<spiv> poolie: huh, no.  Strange upgrade, maybe?
 * poolie is writing up a mail of annoyances in ppa updates
<mwhudson> did i just dream that there was a bzr init --standalone option?
<fullermd> mwhudson: There's a *branch* --standalone.  Maybe that's what you're dreaming of?
<mwhudson> fullermd: ah, probably
<fullermd> Me, I'll stick with dreaming of Cindy Crawford, but...
<poolie> GaryvdM: hi, can you tell me which branches you used for your bzr-gtk packages
<poolie> nm
<vila> hi all !
<fullermd> Wassat?  Morning again already??
<vila> fullermd: yeah, and end of vacations too, wake up NOW :)
<fullermd> Vacations?  Heck, I don't even REMEMBER what those are...
<vila> fullermd: You really should, there are nice places around the world you really should visit while you still can ;)
<fullermd> That would require leaving home.  To say nothing of putting on pants.
<fullermd> Well.  I guess the REALLY nice places don't need the pants...
<vila> fullermd: yup, including the under water world...
<poolie> hi vila
<vila> poolie: heya !
<poolie> i'm going to change tack on the ppa and try to get everything just at least working on maverick
<vila> poolie: what isn't working so far ?
<poolie> a bunch of litle annoyances
<poolie> one being that in the debian bzr packaging, they've cut out python-configobj
<poolie> because of a sensible policy that packages should not ship their own copies of libraries
<poolie> but that's not packaged on hardy, and it's a little hard to make it work there
<poolie> it could all be fixed but it just seems like a time sink
<vila> well, not shipping copies of libraries shouldn't apply if the said libraries aren't available methinks...
<vila> hm, restart required bbib
<fullermd> Yeah, if we shipped testtools, I could run selftest  ;>
<poolie> it's completely fixable it's just one thing after another
<poolie> separated by long pauses for soyuz to decide
 * fullermd is unpleasantly familiar with such tasks...
<poolie> anyhow istm the main thing is to get it all working on lucid
<poolie> you might think it would make sense to start with the oldest one and work forward
<poolie> but i now think this is probably wrong
<vila> poolie: waitaminute, I thought we modified configobj lightly but enough to not be able to use the stock version no ?
<poolie> oh, really?
<poolie> that's such a bad idea
<poolie> i hadn't heard of that
<vila> IMBW or the changes may just be cosmetic...
<GaryvdM> Hi poolie
<GaryvdM> poolie: lp:~bzr/bzr-gtk/packaging-$DISTRO
<GaryvdM> I may not have push up all my changes yet, as I've not finished the hardy build. Let me push up the rest.
<GaryvdM> poolie: I've also merged them with the debian unstable branch :-)
<GaryvdM> That's why hardy is failing...
<poolie> GaryvdM: got it now
<vila> poolie: hmm, scratch that, if we used a modified version and debian deleted it, we would have heard about bugs
<poolie> vila, that's what i thought too
<poolie> i don't feel like going to look for trouble there; i have enough already
<vila> poolie: ok, but may be we should file a bug about using our own copy only if none is available
<spiv> There is at least one bzr-local change to ours, to improve import speed :/
<spiv> (It imports the 'compiler' module for a feature we never use)
<poolie> hm, that's just the kind of thing we wouldn't get bugs about too
<poolie> hello spiv, btw, you've been a quiet mouse :)
<vila> hi spiv, I was just seeing your comment in configobj.py :D
<poolie> spiv, i we should file a bug against bzr, debian, and ubunut
<poolie> and maybe try to send the patch upstream to configobj
<spiv> AFAIK we'd run ok with stock configobj, I think most of the other changes that bzr log reports are cosmetic.
<spiv> poolie: I've been chipping away at old todo items before they go entirely stale... I'm currently looking at a draft of a LEP about logging (and contemplating how e.g. 'bzr serve' could change to do it better).
<vila> poolie, spiv: even comparing with actual configobj-4.7 (we have a copy of 4.6) I see nothing worth worrying. As spiv said, there is the compiler loading and then 4.7 differs slightly for some errors handling
<spiv> vila: that's a relief :)
 * bialix waves at GaryvdM
<GaryvdM> Hi bialix.
<poolie> hi bialix
<poolie> ppas should be all ok once the packager finishes updating
<poolie> well, by that i mean the lucid proposed ppa
<bialix> hi poolie
<bialix> does anybody know which version of bzr-explorer is packaged in ppa and lucid?
<poolie> https://edge.launchpad.net/~bzr/+archive/proposed?field.series_filter=lucid has 1.1.0~beta1
<poolie> and lucid itself has
<poolie> 1.0.1-0ubuntu1
<bialix> why not 1.0.2...?
<poolie> and maverick also has 1.1.0~beta1
<poolie> i don't know
<bialix> rhetorical question
<poolie> i would guess that nobody updated it
<poolie> if it's only bugfixes, it still could go in
<bialix> sorry, I've meant maverick
<bialix> 1.0.2 has released after lucid
<poolie> maverick of course is the one that's coming out in october
<bialix> yep
<GaryvdM> bialix: https://wiki.ubuntu.com/StableReleaseUpdates
<bialix> that's fine then
 * bialix notes
<GaryvdM> bialix: It's quite a process to get it updated in an existing release.
<poolie> we should do something about the sru policy
<bialix> yes, I understand
<poolie> spiv it would be nice if you could do that next week
<bialix> I'm not ready to force SRU right now
<poolie> we'll try to keep the ppa up to date
<GaryvdM> bialix: The ppa will have 1.1.0~beta soon.
<bialix> GaryvdM: thank you!
<GaryvdM> poolie: the latest bzr-explorer, and qbzr are compatible with bzr 2.1.0, so I may as well copy them to the main ppa now.
<poolie> ok
<poolie> so i think we're now all done
<GaryvdM> poolie: what about git, svn loggerhead?
<GaryvdM> git has new version for lucid, but not other distros.
<GaryvdM> Same for dulwich
<GaryvdM> Same for svn
<GaryvdM> poolie: I think we still have some way to go.
<poolie> GaryvdM: i was wondering if we should have some enlightened lazyness about builds on old distros
<GaryvdM> :-)
<poolie> i found i was bogging down a lot
<poolie> trying to get them all through, and once i focussed on just lucid it was much easier
<GaryvdM> I know the feeling.
<poolie> it ought to be mechanical but there are proportionally more snags across the old ones
<poolie> i'm going to try to get some data on how much people actually use them, or want upgrades there
<poolie> both from the download logs, and perhaps we'll see if anyone objects on the list
<GaryvdM> poolie: Lets copy for lucid now, and not copy for the others...
<poolie> my sense is that people mostly do not stick with old ubuntu releases for a long time (except for lts)
<poolie> unless they specifically want the machine not to move very much
<poolie> but this is ... wishful thinking :)
<GaryvdM> poolie: How come your uploads show as no signer?
<vila> poolie: the reasoning sounds fine, if I want a newer bzr I'm likely already tracking a newer Ubuntu. But even if I track an older Ubuntu *and* I've subscribed to the bzr ppa, I still prefer stability over new features so I may accept fewer updates on the bzr ppa. I.e. we can start proposing an up-to-date ppa for lucid and maverick and update hardy/jaunty/whatever when time permits (including when our process become more automatic)
<bialix> I can't remember the name of the plugin to run test suite on each commit, aka poor-man pqm. anyone?
<bialix> testrunner
<poolie> GaryvdM: i copied the binaries from the main archive; i guess that's why
<GaryvdM> poolie: Ah - ok
<GaryvdM> poolie: I just read your mail.
<poolie> vila, are you talking about maybe having a 2.1, 2.2,  etc ppa?
<GaryvdM> poolie: This was the frustration I was trying to describe at uds - You described it much better than I could...
<vila> hmm, no I was thinking about just the stable and proposed ones
<poolie> i'm just glad it's done; the combination of lags plus tiny failures is so annoying y
<poolie> you can't concentrate and just get it done but you can't concentrate on anything else
<poolie> or at any rate i can't
<poolie> vila: oh you're saying people on hardy may be happy to just stay on 2.0 or whatever?
<poolie> i agree
<poolie> i agree they may
<GaryvdM> I upload, play a game of solitaire, and then go and check if it succeeded. :-0
<poolie> exactly
<poolie> nice for 20m, not a good way to spend two days :-{
<poolie> or more :{
<vila> poolie: yes, they may accept to upgrade to 2.2 later
<vila> err, they may accept that the upgrade is delayed
<GaryvdM> poolie: I'm going keep at it though. Next up - for me: bzr-builddeb
<poolie> ?
<poolie> i think they're all done
<poolie> assuming the publisher runns...
<lifeless> awesome
<GaryvdM> poolie: For all distros
<poolie> oh, ok
<poolie> if you really want to
<poolie> wow, launchpadlib pulls in a bunch of stuff
<poolie> i think it's used by builddeb
<poolie> including a mail server
<poolie> strace
<GaryvdM> poolie: The other thing is that merging the debian unstable packaging branches as caused more complication, but I think it will make it easier in the long term. Packages for which I did this when I did 2.1 were easier this time round.
<bialix> poolie: q about pad.lv: why you've used .lv domain for it?
<poolie> it's cheap, and it sounds like "pad love"
<poolie> i'm not latvian
<poolie> i think spiv is Â½ latvian though, or lithuanian
<bialix> funny
<poolie> good night and good luck!
<GaryvdM> Good night
<bialix> :-)
<GaryvdM> i386 ppa build queue > 4hrs :-(
<jelmer> vila: Thanks for the review, very much appreciated!
<vila> jelmer: as is your work in this area, you're definitely on something here and I was just wondering if the factory idea shouldn't be pushed even more to clearly define how one create repo/branch/wt for a given format
<vila> jelmer: they are all created from the format or its associated dir so far and without looking into the details, I wonder if we have inherited that from the early days of bzr...
<vila> jelmer: I was quite surprised that you were able to produce such a clean patch there, I would have swear that things were too mixed-up for that... So, well done ! ;)
<jelmer> vila: Thanks :-)
<jelmer> vila: History shows there indeed, although I think it's a slightly disconnected problem.
<jelmer> I'll followup to the branch tonight and see if I can get some of the plugins working with this new API then :-)
<vila> great !
<GaryvdM> jelmer: My I ask you some debian packaging questions?
<jelmer> GaryvdM, yeah, sure
<GaryvdM> jelmer: I would like to submit a patch to the packaging config for qbzr. Should I submit a branch with just the change, or should I also merge the upstream, and update the changelog?
<GaryvdM> Making the change, and updating the changelog with out merging upstream feels odd.
<jelmer> GaryvdM: You should definitely update the changelog to mention what you've fixed
<jelmer> merging upstream isn't necessary, but you might as well while you're there
<GaryvdM> Also one of the changes I want to make is specific to the upstream version (minimum bzr version)
<GaryvdM> jelmer: And then push to lp, and send mail to pkg-bazaar-maint@lists.alioth.debian.org ?
<jelmer> GaryvdM: yep
<GaryvdM> Ok :-)
<starenka__> hi, sorry for noob question but is there a way how to show all modified files since rev x?
<vila> starenka__: bzr status -r x
<starenka__> neat
<starenka__> thanks
<mgz> garyvdm: re your pretty html table of package versions on the mailing list
<GaryvdM> Yhea - sorry about the html.
<mgz> I think testtools really wants to be at either 0.9.2 or 0.9.5
<mgz> we probably can't do much about debian unstable, but who would need bugging about maverick?
<mgz> ^needing to do a table is a good reason for html email, the mess people make trying to do them is plain text is worse
<GaryvdM> mgz: Why not do any thing about debian unstable. We have 2 dd's amongst us!
<mgz> well, they're deeper in freeze than ubuntu is I believe
<mgz> but sure, jelmer/lifeless, if you can find a way to get the release managers to take the next testtools version, that'd be great
<GaryvdM> mgz: I don't think that would be required for sid, only for squeeze.
<mgz> yup.
<GaryvdM> mgz: Ok - so we should try get sid/mavrick updated to 0.9.5 before updating the others in the ppa.
<GaryvdM> Thats ok, because I want to get the more user facing packages updated first.
<mgz> great, thanks.
<mgz> my busy week is over now so I should be around if you need help with anything
<jelmer> hi Gary, Martin
<jelmer> mgz, GaryvdM: Rob is the person to talk to, he's the only maintainer of testtools in Debian.
<mgz> thanks jelmer, I'll bug him later.
<zyga> hello
<zyga> is 2.2 officially released ?
<jelmer> yeah
<zyga> jelmer, then why does the website state that 2.1 is stable release?
<jelmer> zyga: That's a good point..
<jelmer> jam, vila: ^
 * zyga-afk needs to go away for a few hours :/
<vila> jelmer: I think we wait for the installers before releasing officially
<vila> jelmer: and also an updated ppa but this should be good now thanks to poolie and garyvdm
<vila> zyga-afk: so 2.2 is really *close* to be officially released
<MTecknology> I tried doing this --> bzr pull lp:pressflow --remember  and got this --> bzr: ERROR: Cannot lock LockDir(lp-70598736:///~pressflow/pressflow/6/.bzr/branchlock): Transport operation not possible: readonly transport
<MTecknology> why?
<vila> MTecknology: bzr info ?
<vila> MTecknology: may be your branch is bound to lp:pressflow ?
<MTecknology> vila: that'd explain it :D
<MTecknology> thanks
<rocky> jelmer, what's the latest version of bzr-rebase/rewrite i should use with bzr 2.2.x ?
<jelmer> rocky, the latest version f bzr-rewrite (not sure off the top of my head what that is)
<rocky> well baseically i need rebase that works with bzr-svn and bzr 2.2.0
<rocky> so what do i get? :)
<rocky> jelmer, ^^
<jelmer> rocky: as I said, the latest version of bzr-rewrite
<rocky> jelmer, oh sorry i misunderstood... the reason i'm asking is because the latest download on http://wiki.bazaar.canonical.com/Rewrite?action=show&redirect=Rebase says it's for bzr 1.13 and higher... hwich makes it seem old
<MTecknology> Is there any easy way to take one branch abd run bzr pull lp:newbranch --remember --ignore-conflicts ?
<MTecknology> The only way I can think of is to move the directory, then grab a fresh copy - but not ideal
<jelmer> rocky: the APIs it uses haven't changed, so there's no reason to change the minimum bzr version
<rocky> k
<MarcWeber> I dowloaded two blender branches. How can I visualize when one was forked off and how many commits are different?
<dash> MarcWeber: 'bzr missing' will tell you the differences between the branches.
<dash> 'bzr vis' or 'bzr qlog' can show you a pretty view of the history, if you have the gtk or qt extensions installed
<MarcWeber> dash: I prever pretty views :) Are those extensions included in the main source ?
<dash> they're plugins.
<MarcWeber> Does bazaar store multiple branches in one directory as git does?
<MarcWeber> I have a blender branch on lp I'd like to compare with current unstable.
<dash> MarcWeber: no, it doesn't
<dash> you can use a shared repo so that branches don't have duplicate copies of the revs they have in common
<MarcWeber> So I checkout twice and then use diff ../other-dir or such ? or diff lp-url ?
<dash> MarcWeber: sure
<MarcWeber> or missing ../other-dir etc?
<dash> yep
<dash> if you start with 'bzr init-repo .' then it'll create a repo in the current directory
<dash> and so checking out a second branch in that dir will only fetch the extra revs
<MarcWeber> branch 'lp:~diresu/blender/blender-command-port-002'
<MarcWeber> and branch lp:blender
<MarcWeber> Can I make a shared repo out of a checked out one?
<dash> MarcWeber: to do that you do init-repo as above, then clone your existing branch into it
<dash> so 'bzr init-repo .; bzr branch mybranch mybranch_new' will do it.
<MarcWeber> ( --trees) ?
<dash> if you like :)
<eydaimon> if I do a bzr up -r 123 and then a bzr revno, it shows the head revno, not the one the repo is at. How can I get the revision the repo is at?
<maxb> eydaimon: You don't mean repo, you mean tree. Use bzr revno --tree
#bzr 2010-08-21
<eydaimon> maxb: yes, tree. I mean tree :)
<eydaimon> thanks
<eydaimon> hmm, how come it doens't work to do that on a remote branch?
<maxb> do what?
 * maxb uploads lots to the proposed PPA
 * maxb looks confused about the bzrtools in the ppa having odd differences compared to the one in sid
 * eydaimon wonders what PPA is
<maxb> PPA == Personal Package Archive, a Launchpad facility to allow people or teams to have their own Ubuntu package building and distribution facility
<eydaimon> "do that" was to do bzr revno --tree
<maxb> Most likely the remote branch has no tree
<eydaimon>  it does. I went to the branch and ran it
<eydaimon> i'm stupid, but not *that* stupid :P
<Kamping_Kaiser> aw, no jelmer
<Kamping_Kaiser> i still have a diff of his in my bzr-svn branch :/
<Kamping_Kaiser> ...
<Kamping_Kaiser> speaking of which
<Kamping_Kaiser> jelmer: got a moment?
<jelmer> Kamping_Kaiser, hi
<Kamping_Kaiser> jelmer: hello. http://paste.debian.net/84733/ is a change you left in my bzr branch, is it something you need(ed?) to commit?
<jelmer> Kamping_Kaiser: ah, that was the workaround
<jelmer> Kamping_Kaiser: that should no longer be necessary, lp:bzr-svn should now cope with that branch
<jelmer> Kamping_Kaiser: thanks for checking though
<Kamping_Kaiser> jelmer: ah, no problem. i'll revert it out . thanks for looking :)
<parthm> hello. i am trying to create a branch on my office system but am getting a weird transport error http://pastebin.com/JC2e6JQJ ... i suspect the windata dir is a mount. does anyone know what might be happening? the message is quite generic.
<mkanat> Okay, let's say that I have a file path. What's the fastest way to find out which revision it was modified in last before a certain revision?
<mkanat> Or, more specifically, I have some log -v output, and I can see that a file was moved from one place to another.
<mkanat> I'd also like to know what the revid of the file was at that time, using the CLI.
<alkisg> Hi, I've lost 5 "pack" files from a repository: .bzr/repository/obsolete_packs/26c250e9eacd0e32253aee09ed6ea15f.pack .bzr/repository/obsolete_packs/3e0684636f1b84bd93b726886ac33ac8.pack .bzr/repository/obsolete_packs/bdde9237d718da297ea1819ea955695f.pack .bzr/repository/obsolete_packs/ee3c02de21d2ea6dfc116bbbb4d48694.pack .bzr/repository/packs/aabdba7905e54e65ce719f97876569a4.pack
<alkisg> No actual data files were lost, and bzr seems to be working fine. Should I be worried about those "pack" files?
<fullermd> What do you mean, "lost"?
<alkisg> Some hard disk problems, and I was able to copy all the files except for those.
<alkisg> Ugh yeah `bzr diff` works but `bzr log` complains about missing files
<fullermd> Well, the stuff in obsolete_packs won't matter.  But you're missing one active one, so...
<jelmer> alkisg, files under obsolete_packs being lost should usually not be a problem; the one file under packs/ would be an issue
<alkisg> Any way to fix it with minimal loss? I don't mind much about the history, it's a personal project...
<mkanat> alkisg: You could export the files and create a new project.
<mkanat> alkisg: Although somebody else might have a better idea.
<mkanat> I mean, create a new branch.
<mkanat> alkisg: You don't have any other checkout or branch of that project?
<mkanat> (This is one reason why I often use bound branches.)
<alkisg> Got it. No, unfortunately, it was somewhat new, I didn't get a chance to back up the bzr data yet
<alkisg> But I do have all the project files, so all I'm losing is the changes history...
<alkisg> Hmm I'll try to use one of the obsolete packs instead of the lost one, maybe I'll get half of the history back
<alkisg> Is there a "bzr unpack" command that would allow me to revert to one of the obsolete_packs ?
<alkisg> (file renaming didn't work :))
<jelmer> alkisg: No, although you may be able to get it to pick up the obsolete pack files by editing .bzr/repository/pack-names
<alkisg> That looks like a binary file to me, I don't know how I could edit it...
<jelmer> ah, hmm
<alkisg> I tried renaming an older pack to that missing pack, but I got a bzr panic :)
<alkisg> OK guys thank you all, I'll just recreate the branch
<fullermd> Well, renaming a pack that doesn't have the same stuff would certainly not help anything   :p
<alkisg> I tried renaming both the pack + its indices, hoping that all of them would hold a previous state
<alkisg> I.e. what are the obsolete-packs for, if there's no way to restore them?
<fullermd> Potentially restoring if the new packs are bad in some way.  But changing their name would never be meaningful; if two packs have the same content, they'd already have the same name.
<alkisg> "Potentially restoring if the new packs are bad in some way" ==> and how would that restoration be accomplished?
<fullermd> Much what jelmer said.
<fullermd> But of course the reason they're in obsolete is that things have happened since then, presumably including new commits.  And if those are in the pack file you lost, restoring obsoletes wouldn't be any help.
<alkisg> Well, I tried editing pack-names, but it was a binary file, so the only thing I could do was to rename the files instead of changing pack-names :)
<alkisg> Anyway, thanks again guys, it's not worth any more time, it wasn't a very big history.
<GaryvdM> maxb: Wow - The ppas is looking good. Nice work!
<Noldorin> does bzr on windows come with its own distribution of python 2.5.4?
<Noldorin> it's not seeming to use my 2.6.5 installation
<maxb> GaryvdM: Hi - what's the story regarding qbzr/bzr-explorer on hardy? Dependency hell?
<GaryvdM> maxb: They are no longer with compatible with the hardy version of qt
<Noldorin> anyone here got bzr-tfs workign?
<GaryvdM> maxb: The old versions *should* still work with the latest version of bzr (we only check for a minimum version,) but I've not tested this.
<maxb> I think my builds of dulwich on hardy have hung :-(
<jelmer> maxb, whoa, a build time of 2.5 hours!?
<maxb> jelmer: what, dulwich?
<maxb> The tests hung, somehow :-(
<jelmer> maxb: I've seen that happen before in the compat tests
<maxb> Any hints, or does it remain a myster?
<maxb> y
<jelmer> All I know is that those particular issues were caused by a bug in dulwich that didn't make it respond as it was expected to.
<jelmer> You might want to just skip running the compat tests.
<maxb> I was contemplating that.
<maxb> It feels like cheating, though
<jelmer> Well, the alternative is to check what version of git-core dulwich relies on and backporting that as well..
<jelmer> at least, that's my guess
<maxb> jelmer: btw, at the moment we have subvertpy 0.7.3 for karmic+lucid, but 0.6.9 for hardy+jaunty, because subvertpy 0.7.3 is broken with Subversion << 1.6 - that's ok for now, from a bzr perspective, right?
<maxb> I'll file a proper subvertpy bug later
<jelmer> maxb: yes
<jelmer> maxb, 0.7.3.1 fixes that
<maxb> ah, great
<GaryvdM> maxb: There is a newer version of bzr-pipeline that I would like to upload to the ppa. I'm not sure what to do about the missing packaging branches. Should I just create them?
 * GaryvdM is aware of ~bzr/bzr-pipeline/lucid-packaging thanks due to your wiki page.
<GaryvdM> maxb: It would be great if you were to push what you had for the versions you uploaded to new branches, so that history is not lost.
<jared> how can I download code from launchpad without creating a ssh key?
<jared> I don't want to upload, just download.
<dash> you only need an ssh key to upload, i believe.
<dash> so bzr get lp:whatever should work
<jared> Permission denied (publickey).
<jared> I'm doing "bzr get lp:jade"
<jared> I'm trying to get this: https://launchpad.net/jade
<jared> sorry I'm a noob, just switched from git
<dash> hm. that url should work
<dash> do you get an error?
<jared> dash: yeah,-> Permission denied (publickey).
<dash> hum
<jared> I tried cleaning out my known hosts, but no success.
<dash> try just 'bzr get lp:jade'
<jared> thats what I did
<dash> very odd
<dash> OTOH i've had my ssh key on launchpad since i started using it
<dash> does 'bzr get https://launchpad.net/jade' fail the same way?
<jared> that seems to be working...
<jared> thank you... that's a bit strange though...
<GaryvdM> jared: lp:whatever will map to a bzr+ssh url if bzr launchpad-login is set, and to a http url if it is not.
<GaryvdM> the http urls don't require the ssh key.
<maxb> GaryvdM: I know there are well-established bzr-svn packaging branches, which I'm looking into updating now. For the rest, I wasn't planning on creating new branches where my changes were nothing more than changelog bumps and scripted reversion to source format 1.0
 * jelmer is looking forward to build-by-push
<maxb> ugh. bzr-builddeb's changelog merge hook is a menace when working with ppa branches
<jelmer> maxb: how so?
#bzr 2010-08-22
<Kamping_Kaiser> gah. i just broke bzr-svn again
 * Kamping_Kaiser slaps his wrist
<jelmer> Kamping_Kaiser, hello
<Kamping_Kaiser> jelmer: hi. seems 'OperationalError: database is locked' isn't caught. (i filed a bug, fwiw).
<Kamping_Kaiser> and i admit the user deserves a screen full of backtrace if htey are silly enough to try and branch twice :p
<jelmer> Kamping_Kaiser: to work around that, you can install python-tdb. the default cache is based on sqlite, which doesn't allow concurrent writers
<Kamping_Kaiser> jelmer: ok, thanks :)
<boybzr> hi guys
<boybzr> i am wondering, i have a shared repository with multiple branches below
<boybzr> i am making a new directory in it in which i just want to merge ALL the branches into (suppose we have no conflicts)
<boybzr> in git, i do an octomerge
<boybzr> in bzr, must i do this for every branch ? isn't that a LOT of extra commit msges ?
<lifeless> boybzr: bzr merge --force will let you do octomerges
<boybzr> lifeless: an example?
<lifeless> bzr merge b1
<lifeless> bzr merge --force b2
<lifeless> bzr commit -m 'commit a merge of b1 and b2'
<boybzr> i can also do this:
<boybzr> bzr merge b3
<boybzr> eek
<boybzr> bzr merge --force b3
<lifeless> yes
<boybzr> bzr merge --force b4
<boybzr> THEN commit yes?
<lifeless> yes
<boybzr> ok
<boybzr> is there any way to do all of this together
<boybzr> in one line
<lifeless> you could write a wrapper, or a plugin
<lifeless> there isn't a builtin way
<boybzr> ok
<boybzr> another question now
<boybzr> say i play with my branches in my shared repository
<boybzr> and i want to push to launchpad
<boybzr> will pushing from branches residing in a shared repository pose a problem?
<boybzr> aka, how launchpad gets correct history?
<lifeless> no problem
<boybzr> reading on stacked branches now
<lifeless> that should be transparent to you; just make sure your trunk is marked as such on the series page in launchpad
<boybzr> yeah noticing
<boybzr> the gui tools look awesome as well
<boybzr> alright, another question guys, if you can
<boybzr> suppose i have to unrelated in ancestry repositories that at some point have to be merged into a new project, and i want to keep the history of both without starting from zero
<boybzr> will such a merge happen cleanly and if not, will it bust future merges that are similar?
<lifeless> generally works ok
<boybzr> ok, how so
<mgz> I'm about to go out for the day, but quick request lifeless
<mgz> could you look at uploading testtools 0.9.5 for debian?
<mgz> it fixes a few things I'd messed up in 0.9.4
<lifeless> mgz: sure; was going to wait for the next release
<lifeless> boybzr: what do you mean?
<parthm> Hello. I am trying to branch into a certain directory on RHEL and its generating a TransportError EPERM. I am not sure what to make of it. I have permission and copy etc. works. http://pastebin.com/5tYFwhX7
<parthm> The /data/dev in the paste is a mount.
<maxb> jel
<maxb> oops
<ddaa> hey jelmer
<ddaa> I just noticed "bzr init --subversion"
<ddaa> I see that creates a local subversion repo
<ddaa> What's the use case for that?
<jelmer> ddaa: hi
<jelmer> ddaa: Nothing in particular, it's just something that we get automatically if we hook in a new format
<jelmer> and I guess it gives you the ability to avoid the svn command-line altogether
<ddaa> I don't see a lot of point in creating a local repo and not hooking it into an actual subversion server.
<jelmer> ddaa: I use a local svn repo quite often for testing, but you can also e.g. create a repo for the svn apache module
<jelmer> What I mean to say is, just creating a svn repo somewhere can mean it's picked up by the svn apache module
<ddaa> I see. Still, if could configure apache in this way, one needed enough knowledge of svn to know "svnadmin create"...
<ddaa> Anyway, I understand it is not a designed feature. And I think it is possibly confusing.
<ddaa> To try putting it out more clearly.
<ddaa> "bzr init" is user operation, but "svnadmin create" is an administrative operation
<ddaa> Most of the time, a svn repo is provided by a hosting service, or a sysadmin.
<ddaa> Unless people start using local svn repos over network shares, but I shudder at the thought of it.
<fullermd> Well, dunno about svn, but a fair number of my CVS repos were primarily accessed locally.  And the rest were all over ssh anyway, so...
<ddaa> fullermd: thinking about it, local or ssh is just better than pserver
<ddaa> but it's only becaus pserver is such a POS
<fullermd> Yeah.  But had I gone down the svn garden path, I can't think why I'd have done anything differently.  So, no real server-admin type stuff necessarily involved in creating repos.
<ddaa> I see.
<ddaa> I remain unconvinced that "bzr init --subversion" is a good tradeoff between convenience and possible confusion.
<ddaa> It looks to me like a feature that would be documented as "You don't really need to use that ever, but its presence is a side effect of the bzrlib architecture."
<jelmer> While I can see the points both ways, I haven't come across any users who have actually used this option and confused by what it did.
<jelmer> s/points/arguments/
 * fullermd waits for `bzr init --rcs`...
<ddaa> fullermd: is bzr turning into emacs? :-)
<fullermd> I think it has to grow "bzr checkout INBOX" capability before that.
<ddaa> jelmer: I'd bet the format options to init are almost unused in the real word. That does reduces the likelihood of this option causing confusion.
<ddaa> fullermd: checkout, I don't know, but "bzr merge INBOX" would make some sense: as a complement to "bzr send".
 * ddaa considers the question settled
<ddaa> thank you jelmer
<jelmer> ddaa: Thanks for your thoughts. I won't take action on this now, but I'll keep it in mind while we make more changes to the control directory infrastructure in Bazaar.
 * maxb ponders syncing ~bzr/proposed into ~bzr-beta-ppa/ppa
<anthony__> I was looking to get some help with a little ubuntu problem Im having
#bzr 2011-08-15
<poolie> hi all
<thomi> Is there a script somewhere I can use to generate a large bzr branch for testing things?
<poolie> yes, there is
<poolie> um
<thomi> I guess I could also just branch a big project from launchpad....
<poolie> that could be good
<poolie> there's a plugin that makes arbitrary-sized history
<poolie> it depends what you want to do with it
<poolie> i can't recall the name at the moment though
<thomi> ok, no worries.
<thomi> I guess Bazaar itself, or launchpad would be reasonable candidates
<poolie> yep, depending on what size you want
<poolie> and linaro-gcc and emacs are bigger again
<poolie> hi jam
<jam> morning all
<jam> hi poolie
<poolie> hi there
<Riddell> morning
<poolie> hi riddell, how are you?
<Riddell> funny, I feel hungover but I didn't drink any alcohol yesterday
<Riddell> rather I did a 6 hour paddle and a 2 hour climb.  I think I must have got dehydrated without noticing
<AuroraBorealis> so
<Riddell> anyway, I'm going to see if I can finish off this KDE Bazaar integration today
<AuroraBorealis> is anyone here familiar on how...bzr packages its installers?
<AuroraBorealis> since its the only program i know that is written in python / pyqt
<Riddell> AuroraBorealis: it entirely depends on the platform
<Riddell> for ubuntu it's a normal .deb package using the normal debhelper python scripts
<AuroraBorealis> well mostly mac / windows
<AuroraBorealis> since linux is easy
<AuroraBorealis> like windows has a exe that runs python
<AuroraBorealis> and mac os x has an installer but no nice app bundle
<Riddell> I believe there's some well known process that turns python into a .exe on windows but I don't know any more than that
<poolie> hi AuroraBorealis, jam has worked on the windows installers at least
<poolie> there's a tool called py2exe
<AuroraBorealis> and im assuming that works with pyqt
<jam> AuroraBorealis: we use py2exe to create a .exe program
<jam> Then innosetup (IIRC) to build the setup.exe
<AuroraBorealis> which includes python and pyqt in it?
<gour> if the bug has low priority @LP it means one cannot expect anything within next 6 months?
<jam> AuroraBorealis: py2exe bundles up a python script with pythonXY.dll
<jam> and creates a library.zip containing the python code
<jam> and pulls in needed libraries, etc.
<AuroraBorealis> ah, thanks for the info =)
<poolie> gour: some low priority bugs are fixed but generally only when the developer has some other reason to fix them
<poolie> eg it's on the way to fixing something else or it personally annoys them
<gour> poolie: i'm thinking about bug #240067
<ubot5> Launchpad bug 240067 in Launchpad itself "Launchpad projects need wikis" [Low,In progress] https://launchpad.net/bugs/240067
<poolie> heh
<gour> we're on the point to decide between bzr/hg & LP/bitbucket
<poolie> well, apparently geoff is working on it
<gour> just asked about it at SO
<AuroraBorealis> wikis dont seem like a trivial thing to implement
<AuroraBorealis> but i feel they are really needed cause they are super useful
<gour> poolie: i cannot understand that LP team is dragging this for more than 3 years...SF,Google, Github,BB...everyone has it
<gour> people were even blogging about moving from bzr/Lp due to it (http://www.artima.com/weblogs/viewpost.jsp?thread=242653)
<poolie> you'll probably get more traction in #launchpad
<AuroraBorealis> its just that there are no other websites for bzr other then launchpad
<AuroraBorealis> there was one that was starting up but its not even functional
<gour> i must admit i never got much response there
 * gour has asked question about it - http://stackoverflow.com/questions/7063145/bzr-launchpad-vs-hg-mercurial
<poolie> so the big thing that launchpad has been working on for the last year or so is speed
<poolie> both application speed and development speed
<poolie> i mention this because it's actually first on the list of that blog post from 2008
<gour> poolie: it's a pity that LP & bzr are losing 'customers' because of that
<gour> iow, hard work of bzr devs is wasted due to missing features in LP
<gour> actually, not wasted, but you get the point...
<AuroraBorealis> it doesn't seem THAT hard to just use markdown files like github does. of course i'm not the one working on it so yeah =P
<poolie> gour, so, xaav was making fairly fast progress on some of these bugs
<gour> AuroraBorealis: problem is that LP people have other priorities...it seems that they even didn't get spec...although it seems it's not rocket science considering so many hostings have it
<poolie> perhaps he will get this one up
<AuroraBorealis> a wiki would be very nice to have.
<AuroraBorealis> integrated.
<AuroraBorealis> at least the start of one :3
<gour> AuroraBorealis: the bug is over 3yrs, old :-(
<poolie> so, basically, you're saying
<ccxCZ> I plan to just use ikiwiki/sphinx/whatever can generate static html for a wiki
<poolie> launchpad ought to do this next, as an official feature, because it's the single most important thing?
<poolie> i'd like to at least show branch content formatted as rest/markdown
<poolie> even if it's not editable in the first cut
 * gour nods
<AuroraBorealis> that would be acceptable ^
<AuroraBorealis> thats kinda what github does anyway
<AuroraBorealis> and is easily editable through the source anyway
<gour> it would be cool to have e.g. sphinx reST docs rendered
<gour> ..but having nothing as 'project page' really sucks
<ccxCZ> gour: I think there's an independent service for that already
<AuroraBorealis> id offer to help but i doubt my skillz are that good =P
<gour> ccxCZ: there is, but its not the same
<ccxCZ> yeah
<gour> there is readthedocs.org
<ccxCZ> tbh I decided to go fully decentralized and build simple stack of project management tools anyone can install (unlike launchpad)
<AuroraBorealis> looks cool, but i still think bazaar should have something integrated to the website itself
<ccxCZ> roundup, buildbot and probably sphinx will be the building blocks for that
<jam> poolie, jelmer, vila: anyone up for a teddy-bear chat about the get_parent_map stuff I'm working on? I think I've got it, but it would be nice to work through it with someone
<poolie> hi jam
<poolie> i might be, but not tonight
<poolie> hm, not right now anyhow
<jam> np
<jam> side point, we were talking about backporting bug #609187 to 2.1 for Lucid, right?
<ubot5> Launchpad bug 609187 in Bazaar 2.1 "users are not warned when branching ubuntu:foo (or lp:ubuntu/foo) and the package import of foo is out of date" [High,In progress] https://launchpad.net/bugs/609187
<jam> wow, backporting to bzr-2.1 means NEWS instead of doc/en/release-notes...
<jelmer> jam: sure
<poolie> jam oh if you get the chance could you read https://code.launchpad.net/~spiv/bzr/faster-stacked-tree-build/+merge/70381
<poolie> jam, yes, ideally for 2.1/lucid, but i wouldn't pay an unlimited price if there's something that makes it hard
<poolie> beyond the location of the news file ;)
<poolie> blah
<poolie> poolie: jam oh if you get the chance could you read https://code.launchpad.net/~spiv/bzr/faster-stacked-tree-build/+merge/70381
<jam> pidgin just died... very weird
<poolie> 19:45
<poolie> poolie: jam, yes, ideally for 2.1/lucid, but i wouldn't pay an unlimited price if there's something that makes it hard
<jam> poolie: I feel like faster-stacked-tree just needs someone to become its new mascot/driver
<jam> I've sort of avoided poking at it, but if you want I can move it to the DOTO queue
<jam> TODO
<jam> (Do Too?)
<poolie> distcc has a 'DOTO' protocol unit for a .o file :)
<poolie> well, if you don't mind
<poolie> spiv is still around a bit
<poolie> i'd better go
<jam> k
<gour1> poolie: thank you for the hint @SO...wasn't aware of it
<gour> poolie: i've added --append_revisions_only to my 'upstream' repo, added a 'feature' into upstream and added a feature to 'feat1' branch. tried to merge upstream into feature and then pushed backe feat1 to upstream and got 'bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch 'upstream'...so it looks as that setting for
<gour> 'init' prevents one to do the 'mistake' and forces one to use 'correct' (for bzr) workflow?
<lelit> hi, is there any specific reason why the cmd_merge builtin does not honor a --verbose flag (even if "bzr merge -h" says so?) like cmd_pull for example?
<lifeless> jam: hi; did you see the loggerhead issue when we rolled it out ? with dictionary size changed during iteration
<jam> lifeless: sorry I missed your ping. I did not see the loggerhead issue. do you have a link? I don't think I even saw a loggerhead bug report.
<jam> ugh, looks like in all the revamping, I lost my subscription to loggerhead bugs...
<jam> why do I lose subscriptions I want, and still get email about every lp-oops-tool that I don't care about... :(
<jam> lifeless: https://bugs.launchpad.net/loggerhead/+bug/826136 this looks more like a launchpad codebase issue.
<ubot5> Ubuntu bug 826136 in loggerhead "dictionary changed size during iteration" [Critical,Triaged]
<jam> At least https://lp-oops.canonical.com/oops.py/?oopsid=2051CBA110 does
<jam> it appears to be failing in "lp.codehosting" not in bzrlib or loggerhead code.
<jam> jelmer, Riddell, poolie, vila: I just updated http://wiki.bazaar.canonical.com/PatchPilot for the next few weeks. I just copied the rotation for the last few weeks. Double check if anything won't actually work. I tried to look at the calendar
<jam> but that might not be complete.
<jelmer> jam:thanks
<jelmer> reminds me, I should send a report for last week
<jam> jelmer: also, we wanted to pair on the quilt stuff. I wasn't sure, but it looks like I'll be available whenever.
<jam> I think I'd like to chat with Martin tomorrow after the standup (if he's available), and you said Wed was no good.
<jam> But I could do later on Tues, or Thurs
<jelmer> jam: Thursday?
<jam> jelmer: works-for-me
* Riddell changed the topic of #bzr to: current topic is: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: Riddell
<Riddell> oh aye
<jam> hey Riddell, how was your conference?
<Riddell> nice to catch up with desktopy people
<Riddell> I got some ideas and requests for bzr
<jelmer> hah, switching between colocated branches works
<jml> mgz: hey, had a chance to look at the assertThat bug yet?
<mgz> hey jml.
<mgz> I have a branch, need to make a few choices about output changes
<mgz> I think the simplest option is adding a Python 3 style repr for Python 2,
<mgz> for anywhere %s is currently used in matcher stringifying and describe methods
<mgz> the regexp case is a bit funky, I wonder if we could make up r"" style strings
<mgz> I'll put up some suggestions based on your branch shortly.
<jml> mgz: cool. thanks.
<jml> mgz: The main thing with regexes is to avoid the double slashes.
<jml> mgz: not sure there's any other special handling worth doing for them.
<jml> mgz: I wonder if we could somehow add some more automated tests guaranteeing that matchers have proper unicode behaviour.
<mgz> I've added a few tests for Mismatch describe behaviours
<jml> mgz: that's good. thanks.
<DerNalia> how do I fix this: bzr: ERROR: Couldn't import bzrlib and dependencies.
<DerNalia> I just tried checking out a repo
<DerNalia> told me to Please check the directory containing bzrlib is on your PYTHONPATH.
<jhtran> if i'm in trunk, how do i 'checkout' an old revision based on date?
<jhtran> such as using git, i just do git checkout <date>
<kkrev> how do you undo 'bzr resolve somefile' so you can redo the merge for just that file?
<kkrev> I guess 'remerge' works
<kkrev> even after you marked resolved
<wilx> Hi.
<wilx> Does anybody have experience with using Bazaar for disconnected development against Subversion?
<wilx> It seems that once I make revisions graph non-linear by a merge, I cannot push to Subversion anymore.
<jelmer> hi wilx
<jelmer> wilx, you have to set "append_revisions_only = False" to push changes that change the branch mainline
<lifeless> or use dpush
<jelmer> lifeless, that will still try to change the mainline, it just won't push extra metadata
<lifeless> oh
<lifeless> I thought it rebased locally as needed
<jelmer> it will discard the local bzr revisions and replace them with revisions fetched from svn after pushing
<jelmer> (effectively rewriting the local revisions that were pushed to no longer include data that can't be represented in svn)
<jelmer> 'evening Riddell
<Riddell> hi jelmer, I'm afraid I'm not too well and spent today in bed, so if I don't make it to the meeting in the morning it means I'm not better
<jelmer> Riddell, Sorry to hear that
<jelmer> Riddell: I'll mention it in case when you're  not around tomorrow
<jelmer> Riddell: get well soon
<mwhudson> jelmer: hi
<jelmer> mwhudson, hello
<mwhudson> jelmer: i was wondering why we still have the ~launchpad-pqm/bzr-svn/devel branches
<jelmer> mwhudson: survived the flight back to .nz?
<mwhudson> jelmer: rather than referring to particular revisions of lp:bzr-svn
<mwhudson> (& so on for bzr-git etc)
<mwhudson> jelmer: apparently!
<jelmer> mwhudson: Why not go one step further.. perhaps we could just use by-value nested trees for the various sourcecode branches
<jelmer> mwhudson, lp-pqm's bzr-git still has a patch to allow deregistration
<mwhudson> jelmer: oh right, that hack
<jelmer> mwhudson: I guess we could get that landed upstream if we'd really have to
<mwhudson> jelmer: well carrying changes in general is a good reason for a separate branch
<mwhudson> i'd forgotten we were doing that
<mwhudson> i also forget a bit _why_ we do that
<mwhudson> jelmer: do by-value nested trees actually work yet?
<jelmer> mwhudson: by-value nested trees have worked well for years :)
<mwhudson> oh right, i think i'd gotten the kinds of tree messed up
<jelmer> by-reference nested trees are not yet supported
<dOxxx> howdy
<dOxxx> jelmer: is there going to be a stable release of bzr-svn for bzr 2.4.0? The last official release was August last year.
<lifeless> jelmer: ah! it was your patch - 826136 :)
<lifeless> jam: thanks for the analysis, thats excellent.
<hazmat> is it possible with the bzr plugin api to alter existing commands, or is it only  for the addition of new commands? i'd prefer to avoid monkey patching the existing commands, so i'm looking for a replace option
<hazmat> hmm.. found this http://doc.bazaar.canonical.com/plugins/en/plugin-development.html#extending-an-existing-command which is effectively empty
<hazmat> ah.. ic the decorate param looks like it does the trick
<jelmer> dOxxx, hi
<jelmer> dOxxx, There is another release planned
#bzr 2011-08-16
<dOxxx> before tuesday?
<dOxxx> jelmer: I'm building the Mac OS X installer now so it can be ready in time for tuesday's 2.4.0 release
<jelmer> dOxxx: given it's already tuesday, not likely
<jelmer> dOxxx, :)
<jelmer> dOxxx, it should be a couple of days, I've been putting it off for way too long.
<dOxxx> jelmer:  is it likely that you'll be making any changes or can I just package the current tip?
<jelmer> dOxxx, there are probably going to be a few more changes
<dOxxx> jelmer: ok. I guess I'll wait to package it then.
<poolie> hi doxxx, jelmer
<dOxxx> hey poolie
<statik> poolie, I'm doing my part to celebrate the 2.4 release, submitted a pull request to upgrade the version shipping in homebrew :) https://github.com/mxcl/homebrew/pull/7031
<poolie> hi statik
<vila> hello guys
<poolie> hello vila
<vila> poolie: hi there
<poolie> vila, can you help with https://answers.launchpad.net/bzr-explorer/+question/168113
<poolie> i guess it's not on his patch or something
<vila> poolie: funnily enough, I already replied to that ;)
<vila> (6 minutes ago according to lp ;-p)
<poolie> :) good for you
<poolie> must be just stuck in mail
<vila> poolie: any progress on the HTTPError on package importer ?
<vila> jelmer: don't forget your pp report ;)
<poolie> vila, hi, not yet :/
<poolie> may go back to it tonight
<jam> poolie: are we doing standup now? mumble or voip?
<vila> poolie: no pressure, was just wondering
<jam> (morning all, btw)
<poolie> let's mumble!
<bignose> aaaare yoooou readyyyy toooo MUMBLLLLE
<jam> bignose: yes
<jam> or maybe that should be mhmhmh yes mhmhmh
<bignose> heh
<bignose> so how is Mumble working for you folks? I'm glad you found a free-software teleconference app
<jam> bignose: noise cancelation is worse than skype
<jam> but overall it works ok
<jam> we're also looking at Skype
<poolie> vila, jelmer, hi?
<vila> grr, can't connect to mumble anymore :-( Probably related to my recent change on lp for my preferred email...
<poolie> vila, so what are the odds you'll get it up in a few minutes?
<jam> vila: It is SSO, I believe, so whatever your Launchpad login is, should be your mumble email
<poolie> i've seen some bug traffic about it getting confused by some email changes
<poolie> some interfaces key off email address or something, which is obviously not stable
 * jelmer is on his way
<vila> jelmer: \o/
<poolie> jam, bug 819910
<ubot5> Launchpad bug 819910 in Ubuntu Distributed Development "many packages fail to import due to HTTPError talking to Launchpad (eg ubuntu:transmission)" [Critical,In progress] https://launchpad.net/bugs/819910
<poolie> still with me
<poolie> also helped fix bug 815190
<ubot5> Launchpad bug 815190 in gnupg2 (Ubuntu) "gpg2: pkglue.c:41: mpi_from_sexp: Assertion `data' failed." [High,In progress] https://launchpad.net/bugs/815190
<poolie> from the moderation queue
<poolie> Answer please the following questions:
<poolie> Do you have a possibility to send packages to Russia?
<poolie> What should be the maximum sum of money (in dollars) for buying a package in order to escape problems at custom?
<bignose> poolie: reminds me of <URL:http://download.ted.com/talks/ZeFrank_2004.mp4>
<vila> https://bugs.launchpad.net/bzr/+bug/712474
<ubot5> Ubuntu bug 712474 in Bazaar "ModuleAvailableFeature broken for modules with side-effects" [Undecided,Confirmed]
<poolie> bignose, what is that?
<nigelb> poolie: is that moderation queue for bzr mailing list or something?
<bignose> poolie: Ze Frank's TED talk, which (once he's actually on stage) begins with a pretty funny rendition of â well, something that you'll find familiar :-)
<nigelb> bignose: Speaking of Ze Frank, head of Klout? Klout marks him as expert on cupcakes. :)
<lifeless> mgz: hi
<lifeless> jam: thanks for analysing that bug
<jam> lifeless: yeah, np
<jam> In the big subscription switchover, I lost my subscription to Loggerhead bugs. But that should be sorted out now
<lifeless> cool
<spiv> jam: thanks for picking up my branch --stacked work
<jam> spiv, np
<poolie> hi spiv
<poolie> jam, are you still mumbling?
<jam> poolie: yep
<poolie> i probably should have muted my mike
<poolie> was futzing with audio
<jam> yeah, you had some buzzing feedback
<jam> nothing terrible, thoug
<jelmer> jam: Robin is one of the Ohloh hackers, and they call the command-line bzr utility from their ror app I think. Which is why they're calling bzr on ancient revisions.
<poolie> right
<Sweetshark> "bzr: ERROR: Tree transform is malformed [('duplicate', 'new-2', 'new-25', u'debian_gaupol_library_path')]" when trying to merge translate-toolkit from debian with bzr. any hints?
<Sweetshark> (that is not on the merge itself, which just spawns bazillion of conflicts, but on the attempted resolve of conflicts)
<jelmer> Sweetshark, hi
<jelmer> Sweetshark, it sounds like you're trying to merge two unrelated branches, which is usually a bad idea
<jelmer> Sweetshark, though of course we shouldn't error out like that during conflict resolution
<jelmer> vila: ^
<Sweetshark> well, Im trying to merge lp:/ubuntu/oneiric/translate-toolkit and lp:/debian/sid/translate-toolkit
<Sweetshark> I had hopes that those where related ;)
<jelmer> hmm, they should be
<poolie> hm, i also get the traceback of http://package-import.ubuntu.com/status/exult.html#2011-08-04 14:38:28.971355 on some packages locally
<ccxCZ> is there easy way to perform some actions on server after I push changes to it?
<ccxCZ> like generating ikiwiki/sphinx doc/whatever and publishing that
<poolie> you can write a post-tip-change hook that runs on the server
<Sweetshark> jelmer: hmmm, the debian changelog talks about moving to v3. Maybe: a) it was not imported before because it was not v3 b) we had out own repo still (of course unrelated to the not yet imported/existing debian-repo) c) now the debian import works
<ccxCZ> poolie: I think I tried that before but it failed on bzr sandboxing code it runs
<ccxCZ> well, gonna try again then
<ccxCZ> any obvious errors in this? http://paste.pocoo.org/show/459275/
<poolie> looks good
<poolie> there's also a bzr push-and-update plugin that can be installed on all clients, and it then doesn't need server support
<ccxCZ> yeah, but that need double login (I don't mind in this case, but sometimes it is problematic)
<vila> Sweetshark: which bzr version are you using ?
<vila> Sweetshark: 'Tree transform is malformed' is unambiguously a bug, but there is no bugs currently known. So either upgrading will fix your issue or you should file a bug with a reproducing recipe
<Sweetshark> vila: bzr 2.4.0
<Sweetshark> but it is likely just 12:24 < jelmer> Sweetshark, it sounds like you're trying to merge two unrelated branches, which is usually a bad idea
<vila> Sweetshark: oh, yeah, I agree, quite a bad idea ;) Still we shouldn't crash, so bug welcome ;)
<vila> Sweetshark: by the way, what command did you use ?
<poolie> jam, i'm going to stop for tonight
<poolie> i think i cracked one of the errors but not the top one
<jam> poolie: ok, have a good evening
<poolie> bloody yaks
<jam> HTTP stuff?
<jam> sure
<poolie> yeah https://bugs.launchpad.net/udd/+bug/827263 is fixed
<ubot5> Ubuntu bug 827263 in Ubuntu Distributed Development "KeyError: 'debian' in get_debian_versions (dup-of: 626960)" [High,Confirmed]
<ubot5> Ubuntu bug 626960 in Ubuntu Distributed Development "Collection dictionary access incorrectly folds all HTTP errors to KeyError" [High,In progress]
<jam> you know, when they start bleeding, you've probably shaved too much :)
<poolie> which i ran in to on the way to fixing the main wrong-url thing
<poolie> :)
<poolie> will try to get back to it first thing tomorrow
<jelmer> poolie, *bloody* yaks? What are you doing to them ? :P
<jelmer> argh, GMTA, John already said that..
<ccxCZ> hmm, branch I get in hook has .base in form of "filtered-363286476:///home/ccx/bzr/wobsite/", should I just de-urlize it to get unix path, or is there simpler way?
<ccxCZ> also O_o filtered
<jelmer> ccxCZ, hi
<ccxCZ> hello jelmer
<jelmer> ccxCZ, you'd presumably have to ask the transport for the proper path
<jelmer> ccxCZ, where are you getting that URL?
<ccxCZ> post_change_branch_tip hook
<ccxCZ> when I push to the server via ssh
<vila> maxb: 2.4.0 is now in sid and oneiric, what's your plan for the ppas ?
<sidnei> jelmer or jam around?
<sidnei> bug #827631 fyi
<ubot5> Launchpad bug 827631 in Bazaar Hg Plugin "Got list instead of iterator, causes import failure" [Undecided,New] https://launchpad.net/bugs/827631
<jelmer> sidnei, hey
<sidnei> hi jelmer
<sidnei> jelmer, seems like a simple fix? ^^
<jelmer> sidnei: I saw that problem earlier, but I had problems reproducing it locally
<jelmer> sidnei: bzr-hg needs some more work in general, unfortunately. hopefully I'll have some time to look into it soon.
<sidnei> jelmer, awesome, thanks!
#bzr 2011-08-17
<poolie> hi riddell
<vila> hey poolie and others !
<poolie> hi there
<poolie> i'm giving udd config options to talk to staging lp to make it easier to debug/test stuff
<vila> poolie: great !
<vila> poolie: don't worry too much about using the stacked-based configs, I intend to upgrade udd when 2.4.x is deployed on jubany anyway
<poolie> vila, so how about https://code.launchpad.net/~mbp/udd/configure/+merge/71822
<poolie> oh also, while i'm here, can you see if you can get into the blog?
 * vila looking
<vila> poolie: this won't work until 2.4x is deployed I think
<vila> poolie: meh, I'm out-of-date about iconfig
<vila> gee, I didn't remember introducing a forward-compatible layer there...
<poolie> ah, are you saying iconfig's present but can't be used?
<vila> no no no, you're doing fine, my bad
<poolie> thanks for thinking of it though
<Riddell> hola
<poolie> hi thar
<jam> morning all
<poolie> hi jam
<vila> poolie: reviewed
<vila> poolie: BB:tweak
<poolie> thankss
<poolie> i'll roll that out then
<poolie> actually i might try to actually fix the httperrors first
<jimis> I did a bzr switch, and an unexpected conflict happened
<jimis> Can I undo and go back to previous branch to commit?
<poolie> hi jimis
<poolie> you can go back but i think that will carry back the conflicts
<poolie> sorry
<poolie> there ought to be a way to say 'i wish i never switched (or, merged, or whatever)' but there isn't yet
<jimis> I was afraid of that :-(
<jimis> anyway I understand that this workflow is not considered as mainstream for bzr
 * jelmer waves
<poolie> hi jelmer
<jelmer> g'evening poolie
<jimis> imho it should ask before switching, saying that a conflict has occured
<vila> jimis: out of curiosity, what kind of unexpected conflict did you get ?
<jimis> vila: I had changed a file but forgot to commit
<jimis> so when I did "bzr switch other-branch" a conflict happened
<jimis> and now I have to resolve it
<vila> oh, so you wanted to commit it, not switch to the other branch carrying the change ?
<jimis> wow, switching back created a double conflict :-o
<vila> yeah, never a good idea to leave unresolved conflict
<jimis> vila: no I wanted to switch, but I had forgotten to commit this particular file
<vila> right, that what I meant, you wanted to commit *before* switching
<jimis> that's what I should have done, yeah
<vila> there are cases when you want to switch but still want to carry the change over
<jimis> but bzr should have reminded me because I forgot
<jimis> I intend to file a bug when I find some time, about missing functionality when working with checkouts
<vila> yeah, kind of the --strict option on pull/push and... I forgot the other one send ?
<jimis> I understand it is not a mainstream workflow, but it is the *only* possibility when working with branches sized as big as lp:gcc
<jimis> multiple dirs is not an option then
<Riddell> vila: where is baboun again?
<jelmer> Riddell, under vila's desk :)
 * Riddell books a trip on the eurostar to test his branch
<jelmer> jam: did you have more comments on my transport-segments branch?
<vila> Riddell: http://babune.ladeuil.net:24842
<vila> jelmer: :)
<jelmer> Riddell: :)
<jam> jelmer: no, just the display thing, Riddell had already approved the branch
<Riddell> vila: hmm, how do I build a branch again?
<Riddell> oh, helps if I log in
<vila> yeah, a lot ;)
<jelmer> jam: thanks :)
<jam> vila: do you have python-2.4 on babune?
<Riddell> vila: I scheduled selftest-subset-natty but it says "pending - natty64.local is offline"
<vila> Riddell: yup, the slave needs to be started, just wait a bit
<vila> jam: probably, depends on the slave
<jam> when did FF go to 6.0?
<vila> jam: why would you care, we don't support anymore ?
<jam> did they just decide to stop doing minor versions
<jam> vila: I'm backporting something to bzr-2.1 for Lucide
<jam> Lucid
<jam> so we *do* care there
<vila> then it should be available on the lucid slave
<vila> jam: note that installing a local lucid chroot will probably be more convenient for you
<vila> unless you just want a final test run that is
<maxb>   
<jam> vila: yeah, pretty much
<jam> I think everything is ok
<jam> I just want to make sure before I submit it, and it goes boom when we release
<vila> but.. doesn't python defaults to 2.5 on lucid already ?
<vila>    python | 2.6.5-0ubuntu1 |         lucid | all
<vila> yeah, 2.6 even
<jam> vila: sure, but we are still backporting to a 2.1 series, which *is* 2.4 compatible
<vila> I'm not even sure 2.4 is supported on lucid (imbw)
<jam> even backporting to bzr-2.3 we should be verifying python-2.4 compatibility
<vila> right, but I'm not sure you can use lucid to test 2.4 you may need to dig deeper
<jam> I thought you had that set up on babune
<jam> (since it at least are excuse for why it was ok to upgrade PQM)
<poolie> ok this time for sure
<jam> poolie: ? (this time you're gone for sure?)
<poolie> this time i think i fixed bug 819910
<jam> or this time httperror is fixed
<ubot5> Launchpad bug 819910 in Ubuntu Distributed Development "many packages fail to import due to HTTPError talking to Launchpad (eg ubuntu:transmission)" [Critical,In progress] https://launchpad.net/bugs/819910
<poolie> it took kind of a silly long time
<vila> poolie: \o/
<poolie> we'll see
<poolie> i have something a bit more realistic working locally though
<poolie> which is a good step
<poolie> not my best day ever
<poolie> https://code.launchpad.net/~mbp/udd/819910-service-root/+merge/71832
<poolie> quick review anyone?
<jam> poolie: looking
<vila> not at lot to look at ;) can't you add a test for that, even against a live lp ?
<jam> poolie: str() is worrying for me, though it may be correct. And it certainly looks like something that Launchpadlib is likely to break
<jam> since you're poking at private attributes
<poolie> the object itself is a URI class
<vila> and yeah, why the str() ?
<poolie> and it defines a str as apparently the right way to get an actual string
<jam> poolie: ok, that part works for me.
<poolie> other launchpad client infrastructure won't accept the URI
<poolie> as far as using the underscoe
<poolie> there's no public equivalent
<poolie> maybe i'll ask in #launchpad
<jam> poolie: there's no way to ask for a branch's LP URL?
<jam> or is it that you have to go via a round-trip that you are trying to avoid
<jam> like lp.branches['~user/project/branch'].url seems like it should work
<jam> but that is a round trip you might be trying to avoid
<poolie> does that work?
<poolie> it would be cleaner
<poolie> i don't think this will be a performance problem
<poolie> it's not hit all that much compared to the amount of other work this program does
<jam> poolie: https://launchpad.net/+apidoc/beta.html#branches
<jam> I'm thinking
<vila> yeah, make it work, make it right, make it fast... and it doesn't work yet ;)
<poolie> that doesn't work; it seems to expect an integer index
<poolie> but there might bbe something similar
<jam> poolie: so probably lp.branches.getByUniqueName(short_form).self_link
<poolie> yep
<poolie> or no
<lifeless> jam: I wonder if you could have a look at https://code.launchpad.net/~lifeless/python-oops-wsgi/extraction/+merge/71839
<lifeless> jam: its a replacement for the oops middleware we use in launchpadloggerhead
<jam> lifeless: no diff yet, but I'll give it a minute
<lifeless> yeah, no panic
<lifeless> bedtime for me, 7am meeting tomorrow ;)
<jam> lifeless: maybe you have a hint. Trying to get the LP API reference for a branch known by its short name
<jam> (~user/project/branch)
<poolie> yep, that's it
<jam> trying to get something like api/1.0/...
<poolie> thanks
<jam> poolie: getByUniqueName is correct?
<lifeless> jam: you want the devel api, not beta
<jam> lifeless: this is for the udd package importer
<lifeless> yes
<jam> I think we found it, though.
<lifeless> beta is -deprecated-
<lifeless> dead dead dead
<lifeless> for a live service under maintenance, I would definitely be using the devel version of the API
<poolie> where is he using beta?
<poolie> oh in the doc api
<poolie> i don't think that's a problem unless we still have an lplib that defaults to beta
<jam> poolie, lifeless: sure, it was just what firefox quick-linked for me when typing "apidoc"
<poolie> oh actually if we're going to call we can just use getByUrls and simplify this a bit more
<jam> poolie: or getByUrl, just depends what you actually have.
<lifeless> poolie: its a problem to the extent that there is stuff in 'beta' that no longer exists, and conversely not stuff in beta that now exists.
<lifeless> best to read the docs for the api being used.
<poolie> i am looking at the 1.0 docs
<poolie> i mean i don't think there's a practical problem for the importer
<lifeless> sure
<lifeless> I get that; I'm just trying to ensure you don't do what I've seen others do which is try a gone api and be confused when its not there but is on the web page.
<poolie> oh it is actually gone?
<lifeless> that particular one isn't.
<poolie> perhaps the beta api doc pages should be removed
<lifeless> but, in beta particularly, a great many have been deprecated and are now gone
<lifeless> and there is a great deal in 1.0 that won't be listed on the beta page
<lifeless> so you might miss out on just the right api for the job
<lifeless> anyhow
<lifeless> jam: that diff is up; I realise I haven't glued the url inclusion in the report in yet, I'll do that as a separate landing I think
<poolie> so, jam needs to just update his bookmark or browser history
<lifeless> more or less ;)
<lifeless> gnight
<poolie> jelmer: hooray
<jelmer> poolie: glad that finally seems to be taking shape :)
<jam> vila: so, do you have a test runner on babune that can run older versions of bzr against python-2.4?
<vila> jam: not sure, do you know which ubuntu release supported 2.4 in the end ?
<jam> hardy?
<vila> hardy is 2.5 by default iirc
<jam> vila: probably default, but still supported
<jam> vs you can't even install python-2.4 on Lucid
<vila> after a quick check, babune always use the default python so there is no existing job to test 2.4 explicitly, but you can probably create one pretty easily
<vila> the hardy slave has python-2.4 installed
<poolie> jam, ok, how about https://code.launchpad.net/~mbp/udd/819910-service-root/+merge/71832 then
<jam> poolie: lp_call is really how you have to spell that? ugh
<jam> but otherwise, approve
<jam> poolie: you have a comment "Sripo of the scheme, and hostname" that should go
<poolie> lp_call is a wrapper that handles retrying the operation etc
<poolie> it really ought to be in lplib
<poolie> also, for that matter, it would be nice if you could declare special forms in python for things like this
<jam> sure
<poolie> thanks
<poolie> ok, i'll merge it and try it
<jam> poolie: care to chat about my patch?
<poolie> i'm just trying to roll this onto jubany and it seems to be breaking
<poolie> after that sure
<jam> sure
<poolie> this is your get_parent_map patch?
<jam> yes
<poolie> jam, ok that _seems_ to be working
<poolie> bit hard because of bug 827935
<ubot5> Launchpad bug 827935 in Launchpad itself "consistent timeout on user branch listing page" [Undecided,New] https://launchpad.net/bugs/827935
<poolie> jam i might have some dinner now, i'll try to ping you later
<jam> sure
<jam> I should have lunch as well
<jelmer> hmm, it's kindof worrying that PQM is now so slow that we can keep it busy overnight :-/
<vila> jelmer: ... and still has a queue of 5 :-(
<Riddell> so it this my fault or baboun's? http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-natty/12/console
<jam> Riddell: isn't everything your fault? You're the new guy, after all.
<Riddell> it might be less my fault if I learnt to spell babune
<vila> FATAL: Unable to delete script file /tmp/hudson2041655501694922969.sh
<vila> shudder, long time not seen
<vila> slave died for mysterious reason, try again, using a smaller subset may help
<vila> making chroots real nodes and switching the old jobs to these new nodes will also address the issue but I'm not there yet...
<vila> I've made some progress on upgrading the gentoo slave (which I couldn't do for.. months), currently rebuilding 12/258 packages...
<vila> maxb: ping
<vila> jam: are you planning to build th windows installers for 2.4.0 ?
<jam> vila: at some point, though I was still dragging my feet based on what Jelmer has stated about bzr-svn (critical bug still remaining)
<vila> huh ? Where ? When ? jelmer ?
<vila> crap, just found the mail
<vila> jelmer: is there a bug # for that ?
<jam> vila: https://bugs.launchpad.net/bzr-svn/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed ?
<jam> 3 critical bugs
<vila> hmpf
<vila> madness
<vila> jelmer: are all these bugs relevant for 2.4.0 or only for prior versions ?
<vila> jelmer: also, are they regressions and do they affect the majority of users ?
<jam> vila: I think you scared him away
<vila> hehe
<vila> *I* am the one who is scared, I know nothing scares jelmer ;)
<jelmer> I'm lunchin' :)
<jelmer> 826946 is the one that's worrying me
<jelmer> 704716 is fixed so no longer an issue
<jelmer> 485601 is fixed I think but doesn't have tests yet
<vila> pfew, good to know (bon appÃ©tit by the way)
<vila> jelmer: should bug #826946 block the 2.4.0 release (or even the 1.1.1 ? bzr-svn release) though ?
<ubot5> Launchpad bug 826946 in Bazaar Subversion Plugin "Commit to svn repo completes, but repo is not updated" [Critical,Triaged] https://launchpad.net/bugs/826946
<vila> HMPF (no space left on device, gentoo I hate you)
<jelmer> vila: if it is as serious as it appears to be, it's a serious regression
<vila> k
<vila> jelmer: let me know how it goes
<poolie> jam, are you back?
<jam> poolie: yep
<poolie> vila, is enospace connected or something else?
<poolie> jam do you have an mp up already?
<jam> poolie: yeah, I posted it while you were dining
<vila> poolie: I went to /etc/fstab and found the comment I left ages ago when the same problem happened: don't use tmpfs for /var/tmp if more space is needed for emerge
<jam> poolie: if you want to read through the merge proposal, I think I've captured everything I had to say about it. The only other bit that would-have-been-nice is to have you run some tests from Sydney
<jam> but they take a while, and I didn't work up a script to automate all of it
<poolie> i might do that tomorrow
<poolie> vila, just add more swap
<vila> poolie: or more memory or just comment out the fstab line which I did. After a reboot, the emerge is going on now
<poolie> jam, i'm reading it
<poolie> or tell emerge to use a different tmpfs
<poolie> what a nice analysis
<poolie> and what a long commit message :)
<poolie> jam, hi
<jam> hey
<poolie> so the reasoning and the code make sense to me
<poolie> i can't see any actual bugs (other than a couple of tweaks)
<poolie> i'm not super confident that i would catch any bugs that actually were there though, cause it's moderately large
<jam> yeah
<poolie> so, perhaps i should just try it out a bit tomorrow
<jam> I did manually test it against launchpad a fair amount
<jam> Not that it exhaustively tests all possible edge cases.
<poolie> i think landing into trunk first makes sense
<poolie> it's really nice it doesn't need a server change
<poolie> is there anything in particular we should talk about?
<jam> poolie: I think I've worked through it. I mostly wanted to do the summary live-on-the-phone, but it has been done
<poolie> weeee
<poolie> the flood of mp mail indicates the lpapi connection is unjammed
<poolie> i wonder if people will feel spammed
<poolie> i guess it's a good chance to consider how much they are useful
<jam> poolie: when don't people feel spammed by lp?
<poolie> i don't know
<poolie> i certainly do
<poolie> i'd like to do built-in non-email notifications some time
<poolie> https://bugs.launchpad.net/launchpad/+bug/827935/comments/1 might amuse
<ubot5> Ubuntu bug 827935 in Launchpad itself "consistent timeout on user branch listing page" [Critical,Triaged]
<poolie> i should sleep
<jam> poolie: real quick, what time would be reasonable to load the global config to check the value?
<jam> poolie: OFFSET 313000 seems particularly telling
<jam> (sort all 500,000 entries, and give me the middle 48)
<poolie> yeah that offset looks to me like it's either loading them all (i'm not sure if that's what the oops means) or slicing a big collection
<poolie> i haven't dug into it
<poolie> how do you mean 'what time'?
<poolie> as in, where in the code, or how long do i think it would take?
<jam> poolie: where in the code
<poolie> perhaps when the remotebranch or similar is constructed, make an instance and hold it?
<jam> I don't think we want to check the config on every _get_parent_map_rpc call
<poolie> that should make sure it's read just once
<jam> this is in RemoteRepository
<poolie> ok, remoterepository then
<poolie> vila may have a more evolved idea, but putting it there should mean it's not loaded too many times in normal use, and we can move it later
<jam> poolie: but you're thinking to cache the GlobalStack object, not just the config value
<poolie> yes
<jam> vila: ^^ thoughts?
<poolie> is even reading out of that expensive?
<poolie> it may be
<jam> poolie: I don't think it is expensive as in, will show up in real-user-time branching all of history
<jam> maybe in shorter term. But for all of bzr it only does 600 or so RPCs
<jam> because of the preloading behavior
<vila> jam,poolie: is there a global config on lp ?
<poolie> ok, good night then
<jam> vila: a config for all branches on lp? no
<poolie> jam, if it's nontrivial to change i wouldn't block on it
<jam> though you could do a locations.conf thing
<poolie> we can always add it if it's wanted
<vila> I suspect not (today)
<poolie> another option would be to go off a debug flag which we know should be cheap
<poolie> good night all
<vila> jam: if you're talking about *local* config then the plan is that checking an option will be a bit more than checking an in-memory dict (or thrice) i.e. far lower than reading a file
<vila> poolie: g'night
<vila> jam: or doing an rpc call
<jam> sure, but "plan" and what will "land in 2.4" is pretty different
<jelmer> g'night poolie
<vila> jam: well, stop worrying about a bug that has been there since the beginning then
<vila> jam: *all* options requires reading one or several config files so far
<jam> vila: which is why I've generally *avoided* having things in config files so far
<vila> jam: then keep doing so until we get a better config or join the effort to get there ;)
 * jelmer is generally also not too fond of adding configuration options
<jelmer> it's often the easy answer, deferring to the user instead of thinking about what the right thing to do is
<vila> yup, I know the trap
<bigjools> as a KDE user, I say moar config!
<vila> that doesn't mean nothing should be configurable
<jelmer> bigjools: ((-:
<vila> jelmer: the other extreme example is OSX (or more generally Apple) where you *can't* configure what you want because *they* know better
<jelmer> vila: yeah
 * jelmer takes a quick break
<vila> jelmer: back ?
<jelmer> vila: yep
<vila> jelmer: you mentioned a fallout about my last patch around BZR_HOME, I can't find the thread anymore :-/
<vila> jelmer: but from memory you mentioned bzr-svn tests failing because of it. I was wondering if these tests should be put into core instead
<jelmer> vila: basically, if BZR_HOME is set then bzrlib.config.config_dir() returns unicode strings
<vila> yeah, I remembered that
<jelmer> vila: GMTA. lp:~jelmer/bzr/cachedir was an attempt to do just that :)
<vila> oooh
<vila> I don't clearly see the connection though :)
<vila> or was it just a first step ?
<jelmer> vila: bzr-svn falls back to storing its cache in ${config_dir()}/cache/svn if it can't find a cache directory
<vila> ha, that's the connection, pfew, but... where does cache_dir calls config_dir ?
<jam> jelmer: so it looks like PQM is still chewing through stuff you submitted yesterday. Not a good sign.
<jam> http://webnumbr.com/bzr-pqm-queue-length.from%282011-08-01%29
<jam> I do wish we had some stats on time-to-run-the-test-suite
<jam> anyway, I'm off for now. Have a good night y'all
<vila> g'night jam, the issues you mentioned have been briefly discussed here ;)
<jelmer> jam: g'night
<jelmer> jam: it does indeed look worrying :_/
<jelmer> vila: it doesn't, but the bzr-svn equivalent of it does
<vila> ....finally :)
<vila> sooo, no need to search how to avoid return unicode right ? Better spend my time on reviewing your branch instead ? Or are you already addressing jam's review ?
<vila> jelmer: ^
<jelmer> vila: Yeah, I'm addressing jam's concerns at the moment.
<vila> k
<jelmer> have a good evening
<wilx> Hi, I am having problems installing/running bzr-fastimport: http://codepad.org/Uz43PkP4
<wilx> This is the selfcheck fastimport as suggested by the README.txt output.
<wilx> I run setup.py build and then I have copied the directory to ~/.bazaar/plugins/fastimport
<fullermd> That's happening in bzr-git, not fastimport...
<fullermd> Riddell: ping   (if'n you're around still)
<wilx> fullermd: Oh, so it is not a problem with my installation steps of bzr-fastimport?
<wilx> Shall I report it as a bug as suggested?
<maxb> Perhaps, but not on fastimport, because the problem is an version incompatibility between bzr-git and dulwich
<hexsprite> I _think_ i'm using a checkout, why do I get this? ERROR: Cannot switch a branch, only a checkout.
<maxb> wilx: Actually the problem is simply: If you install dulwich 0.8.0, you must also install bzr git >= 0.6.2
<maxb> hexsprite: Try "bzr info", see if it is as you expect. Pastebin it for more help.
<lifeless> mgz: hi
<hexsprite> Maybe that's not even the right command for what I want to do.  Which is to switch my working copy to be based on a new repository located in my homedir
<mgz> hey lifeless
<hexsprite> eg. i just merged all my changes from my feature checkout in ~/feature into ~/trunk repo. now i want to update ~/feature to be based on ~/trunk
<lifeless> mgz: I can meet anytime, if now would be more convenient for you
<lifeless> mgz: I just need 5 minutes to feed cats n stuff (I"ll be right back after that - let me know :P)
<maxb> hexsprite: Please pastebin the output of "bzr info ~/feature" and "bzr info ~/trunk" - it will help explain the details of your situation
<hexsprite> bzr info for both: http://pastebin.com/eMF1iiVD  -- note ~/main a checkout of trunk and 1079_dojo is where I'm actively working on new features
<mgz> lifeless: I'm ready when you're back
<hexsprite> to get 1079_dojo up to date so should i be doing: bzr switch ~/main
<lifeless> mgz: kk
<lifeless> mgz: do you have skype ?
<mgz> I don't have a decent mic to connect to the computer unfortunately
<lifeless> kk
<lifeless> ringing in  a sec
<jxself> http://doc.bazaar.canonical.com/latest/en/whats-new/whats-new-in-2.4.html
<jxself> Says 2.4 was released August 8?
<jxself> http://bazaar.canonical.com/en/ disagrees
<meme> hi im trying to use bzr to push source code to a launchpad project but i have no idea what im doing i think im doing it right but i get bzr: ERROR: Not a branch: "/home/jadon/airscripts/.bzr/branch/": location is a repository.
<meme>  
<meme> anyone able to help?
<meme> anyone?
<jxself> Relax. Be patient, young grasshopper. :)
<beuno> meme, you're not in a branch, you're in a repostiry
<meme> so i need to cd deeper tell im in a branch?
<hexsprite> seems like bzr pull ~/main was what i needed
<meme> well i did something that happend and now it does other stuff and it seems to work
<Riddell> fullermd: pong
<fullermd> Ohai.  Um.  Why was I pinging you?
 * fullermd scratches his elbow.
<fullermd> Oyah.  Are you doing much actively on qbzr?  I noticed you popping up in the commit logs somewhat lately...
<wilx> maxb: Thanks, that's probably it. I have only bzr-git 0.6.1 installed.
<controversial> hi
<controversial> i've tried svn, git, and hg, and i'm using hg right now.  i'm curious about bzr though.  how does that compare against hg
#bzr 2011-08-18
<controversial> bzr versus hg fight -- who wins?
<spiv> clearly bzr, because it has more letters.
<fullermd> No way, hg has that underhanded hook to sneak up.
<lifeless> its a noshow, they both get distracted by git on the way to the arena
<fullermd> How monotoneous.
<bairui> hi, guys. Is this a place to ask about workspace layout, workflow, releases, etc...?
<bairui> i have read the user guide and the advanced workspaces section, but i am still a bit vague on some of the mechanics
<lifeless> fullermd: :P
<lifeless> bairui: sure it, though I'm running out; I'm sure other folk here will help when you have questions
<bairui> heh, ok. thanks :)
<bairui> no. i don't even know enough to ask good questions. :-/ Is there an additional resource I could read? The User Guide feels a bit... sparse to me.
<bairui> say I have a   release target   layout (taken from the shared_repository_layouts section of the UG). It has the main   trunk/   branch and containers   releases/   0.1/   0.2/   etc (all in the root of the project repo dir)
<bairui> the term   container for foo branch   in the UG means what? Just a regular old directory in the filesystem, right?
<bairui> well, for eg:   "container for release branches"
<fullermd> bairui: I think so, yes.
<fullermd> bairui: Don't forget (well, or "don't fail to learn", depending ;) that you can rearrange the branches around inside the repo any time, now or later (just watch out for other branches that might look for their old path).
<bairui> ok. thanks, fullermd. I have to cook breakfast atm, so I'll be back. :) apologies for the monotony ;)
<bairui> right - rearranging - that was on the Q list :)
<fullermd> The only important thing is "stays under the repo's dir".
<fullermd> The repo doesn't know where the branches are, or vice versa.  bzr just looks at the branch and says "is there a repo here?  No?  How about at $BRANCH/../?  No?  $BRANCH/../../?  ../../../?  [etc]"
<fullermd> So if you mv one of the branches 'outside' the repo, the world will end and fire will rain from the sky (not necessarily in that order).
<fullermd> But as long as you stay 'inside', it doesn't matter to the branch or repo where it is.
<bairui> ok, fullermd... that's reassuring. Avoiding fire rain is good. So, if I could now move onto the topic of   creating releases...   Let's say it's a fresh project with nothing in production yet. Dev away, test and ready to release (small cycle with small changesets). What now? Do I tag it? Do I branch a copy as 1.0 and do I need to somehow "freeze" that branch so it can't get altered? Is that even close to the
<bairui>  right path or am I wandering, lost in the scrub?
<bairui> apologies again for the "now you see me; now you don't" - breakfast. bbl
<fullermd> bairui: Well, that ends up being a question of your flow as much (or more) than a VCS thing.
<fullermd> At one extreme you have "OK, I'm releasing this as 1.0 now", in which case you Obviously(tm) just tag it.
<fullermd> At the other you have "OK, let's settle this down toward a 1.0 release in the next couple weeks, while we continue to let speculative stuff go on in head", in which case you Equally Obviously(tm) make a 1.0 branch.
<fullermd> (or do you have a '1.x' branch, that you then tag 1.0 and 1.1 and ... on?  Or do you have a 1.x branch that you branch 1.0 from, work toward 1.0 on that branch, let 1.x keep working toward 1.next, and meanwhile still have the separate trunk moving toward 2.x?)
<fullermd> There's no in-bzr way to 'freeze' a branch (though of course you could mess with FS permissions or the like to make it require increasingly heroic measures to commit on)
<jimis> a "freeze" or "lock" feature would be good though
<jimis> besides releases I've needed it for feauture-branches
<jimis> let's say one week I hack on 15 different features, each on a separate branch
<jimis> the *finished* features, I'd like to lock them somehow, to warn me against further changes
<jimis> and also to be seen as status: locked, so that I know that this feauture is merged and I should not work anymore on this branch
<jimis> At present I do it with all caps files at root dir, like branchname_IS_LOCKED
<bairui> thanks, fullermd. That makes sense... I just have to choose a path. I'll experiment to make sure my understanding matches reality.
<bairui> and yes... a lock would be nice and I'll consider an approach like IS_LOCKED, jimis, cheers.
<bairui> let's talk feature branches...   say I have a main (shared) repo at   bzr+ssh://server/repos/project   with a /trunk/ under that. If I    bzr branch bzr+ssh://server/project/trunk bzr+ssh://server/project/0.1   to create a 0.1 pool   and then I   bzr branch bzr+ssh://server/project/0.1   to get a local working copy (into, say, another local shared repo structure). Would I then (locally)   bzr branch 0.1
<bairui> 0.1-dev   (to keep the local 0.1 'pristine')?   Or am I now playing with the fairies again?
<bairui> ok - something in there was not right... after doing   bzr branch bzr+ssh://server/project/trunk bzr+ssh://server/project/0.1   and then   bzr branch bzr+ssh://server/project/0.1   to create a local branch, going into the   0.1   dir and issuing the command   bzr status   gives me the error: bzr: ERROR: No WorkingTree exists for that one, mate.
<spiv> bairui: what does 'bzr info' say?
<bairui> that it's a repo branch (2a).  The shared repo, repo branch and parent branch look sane... the push branch is .
<bairui> repo branch is . (which I assume is sane)
<bairui> so, something that has been confusing me is:   Do I create a shared repo on both the server AND on each of my local dev boxes?
<bairui> meh - newbie mistake - I didn't read the FAQ. It said to just do    bzr checkout   in my local branch (the one that was complaining about   bzr status   ).
<bairui> however... now my local branch 'seems' to behave better, but it's not updating its parent when I do   bzr push
<bairui> it says   Nothing to do.   My local says it's at revision 1 and the remote says revision 0
<vila> hi all !
<vila> haaa, pqm queue empty, finally !
<maxb> Morning vila. 2.4.0 PPA uploads in progress.
 * vila thanks maxb !
<vila> \o/ o// \\o
<maxb> Hmm. bzr-builddeb 2.7.7 FTBFS on <= maverick
<jimis> How come some commands accept branches without full path, but others require it?
<jimis> for example I can do "bzr switch branch1"
<jimis> but I have to do "bzr log -rbranch:../root-dir/branch1"
<vila> jimis: switch has some DWIM magic (iirc)
<jimis> vila: DWIM?
<vila> Do What I Mean
<jimis> :-)
<jimis> I love that kind of magic
<vila> http://www.catb.org/jargon/html/D/DWIM.html
<jimis> Can't -rbranch use that magic?
<vila> -r uses some DWIM magic too :) So it can conceivably borrow some from switch... I don't know the details well enough
<jimis> allright, thanks vila
<vila> jimis: don't hesitate to file bugs when you encounter issues, that's the best way to bring feedback and attention to them
<jimis> ok, will do
<jimis> together with some other stuff, I've put it on my TODO list :-)
<vila> great ;)
<bairui> oops: bzr: ERROR: exceptions.ValueError: WorkingTree.set_root_id with fileid=None
<vila> bairui: bzr version ?
<bairui> 2.3.4
<jimis> hmmm, log needs full path too, like "bzr log ../proj-dir/branch1"
<vila> there was a bug with this kind of symptom, fixed in 2.4x, triggered when merging to an empty tree or empty branch
<vila> jimis: log will be harder as you can specify a file/dir path
<bairui> i am trying to learn how to manage distributed workflow with branches. I had made changes to a branch and merged it back into my trunk. Then it said trunk is out of date with respect to its parent; update. On the update I got that error. I did a commit successfully, and then update was a (successful) no-op.
<bairui> vila: I did exactly that
<bairui> pacman says 2.3.4-1 is the best I've got for now :-/ what's latest stable?
<bairui> but on the *bright* side... I *think* I finally get DVCS and bzr's implementation (for small values of 'get')
<vila> 2.3.4, but 2.4.0 is *just* around the corner (I'm waiting for a bit more available packages/installers before doing the official announce)
<vila> bairui: what OS are you using ?
<bairui> arch
<bairui> er, well, i guess that's a distro, but it answers your q too :)
<vila> pardon my ignorance, what package manager is used there and who package bzr (and when ?)
<bairui> i dunno who and when, but the package manager is called   pacman
<vila> oohhh
<vila> bairui: well, in the meant time, the workaround is to avoid merging to empty branch/trees ;)
<vila> mean
<jimis> vila: arch is famous for packaging the latest stable really on-time
<bairui> heh, thanks, vila :p
<jimis> vila: if there is a bug in 2.3, proper solution would be to do a small 2.3.5 fix release
<poolie> hi vila, jimis, maxb
<vila> jimis: ok, thanks for teaching me ;)
<jimis> :-)
<vila> jimis: in theory, yes, in practice, 2.4 *is* the new stable series
<vila> bah, not therory/practice, sorry, bad english
<jimis> I'm sure that 2.4 will be packaged by arch very soon after released then
<vila> jimis: right
<jimis> vila: Nevertheless if there is a bug on 2.3, remember that many RHEL users will not be able to use that one
<vila> jimis, bairui : feedback on when 2.4 is available in arch welcome !
<vila> jimis: 2.4 ?
<vila> jimis: because we drop support for python2.4 ?
<vila> ghaa
<jimis> vila: yes
<poolie> vila what's a control.conf?
<vila> so, the consensus was that getting python-2.5 on redhat/fedora was easy enough
<jimis> I went through a lot to be able to run, as we were discussing some other time
<jimis> vila: *only* if you have root access
<vila> poolie: the most unknown config file used by bzr
<jimis> if not, it's pretty hard
<jimis> and RHEL users tend to have an admin over their heads :-)
<vila> jimis: ghaaa, are you subscribed to the bazaar ml ?
<poolie> vila "you're in a balloon!"
<vila> poolie: ??? :D
<jimis> vila: no, but I read it casually (have also posted once)
<vila> poolie: control.conf is mainly used by launchpad to provide default_stacked_on
<poolie> google it
<vila> jimis: there was a long thread about dropping support for python-2.4
<vila> poolie: oh, you mean my first answer was useless ?
<poolie> a bit
<poolie> i thought that was it but the cover letter might have been more clear with a reminder
<vila> yeah, I know, but it took me so long to learn about this file and it's so well hidden, I feel *a bit* relieved that I'm not alone there
<poolie> ok
<poolie> perhaps a comment or two would be good
<vila> in the stack types ?
<vila> to explain how they are built ?
<vila> the rationale and so on ?
<poolie> something like that
<poolie> yes, in the stack classes
<vila> right, my next submission will probably be to introduce a stack registry and that's where I intended to explain that but I can as well start here
<vila> poolie: roughly the idea is that you call the registry with a stack ID and a context, for example:
<vila> poolie: stack_registry.get('bazaar') # no context
<vila> poolie: stack_registry.get('branch', branch)
<poolie> hm
<vila> poolie: stack_registry.get('locations', url)
<vila> and you get the right stack for the context
<vila> branch should chose the appropriate stack depending on 'branch', remote or local
<vila> or may be the registry gives bask a factory and *then* you provide the context
<vila> back
<poolie> so that sounds about right
<poolie> i do wonder if having a factory function is a bit redundant with also having classes per stack?
<poolie> also i wonder if it's more a matter of giving it a dict of relevant things
<poolie> or even a set/list of relevant things
<poolie> like stack_registry(a_branch, a_transport, etc)
<vila> yes, the factory is redundant, the classes were an intermediate step
<vila> ghaa
<vila> yes, the classes are redundant, they were an intermediate step and the registry will replace them
<Riddell> hi all
<vila> Riddell: hey !
<vila> Riddell: I'm not sure I was clear yesterday about your babune failure, you encountered a *transient* failure (cause not well understood, workaround: try again)
<Riddell> vila: got that thanks, the change got merged in
<vila> ok
<jimis> Is there a way in launchpad to see a list of bugs I have subscribed to, or marked as affecting me?
<vila> jimis: https://bugs.launchpad.net/~
<vila> jimis: top right corner gives several links
<jimis> perfect, thanks vila
<jam> hi all
<poolie> jimis: no link for bugs affecting you yet
<poolie> hi jam
<poolie> bad news on your hpss branch i'm afraid
<jam> poolie: what's that?
<poolie> it's still doing the initial pull of gcc-linaro after several hours and it's running one step at atime
<nigelb> I wanted to try out an easy bzr bug, but not of the "easy" bugs seemed easy
<nigelb> I :)
<poolie> hi nigelb
<nigelb> hey poolie :)
<jam> poolie: I don't quite understand what you mean by "one step at a time"
<jam> My fix was about initial discovery of revisions.
<jam> If it has passed about 2MB transferred, it should have gotten the revs.
<poolie> it's doing many, individually small, get_parent_map calls
<poolie> with 19MB transferred
<poolie> nigelb: https://bugs.launchpad.net/bzr/+bug/328910 should be genuinely easy and useful
<ubot5> Ubuntu bug 328910 in Bazaar "ugly traceback when sftp server drops connection" [Medium,Confirmed]
<poolie> it has a note about where to start but you're super welcome to ask more about it here, or on the bug
<jam> poolie: so I just tested my branch as of right now, and things look fine, it got to "Using fetch locgic" in 79s
<nigelb> poolie: hehe, thanks :)
<poolie> so i did init-repo, then bzr branch lp:gcc-linaro/4.6 into there
<jam> poolie: do you have the .bzr.log for me to look at?
<jam> poolie: well, I'm doing "lp:gcc-linaro" just trunk, not a stacked branch. That may be the difference
<nigelb> heh, there's something magical about doing bzr branch lp:bzr :)
<jam> Try that first, see if it helps, and we may need to do more work w/ stacking
<jam> but yes, trying /4.6 I see that I'm already at 4MB @ 50s
<poolie> jam: in chinstrap:~mbp
<jam> poolie: so I see similar behavior from a stacked branch, so I do think there is something we need to look at, but I think that is *in addition to* what I fixed
<poolie> ok
<jam> can you try lp:gcc-linaro directly?
<jam> (I'm at 206s ,and a huge number of round trips)
<jam> my guess is that the caching provider isn't triggering at the right layer
<poolie> yes, starting it now
<jam> so we make a request against StackedRepo find it isn't there, then fallback to StackedOnRepo and find it in the cache
<poolie> good example of the value of having someone else test i suppose
<jam> and we do that *for every step*
<poolie> michaelh just reported a dupe of this today, and his was with /4.6
<jam> sure
<poolie> woo
<poolie> that looks a lot better
<poolie> got to 'using fetch logic' in 94s
<jam> poolie: right, and compare that with bzr.dev
<jam> so I think my fix is still practical and good, we just need to also fix the "stacked repo gets queried before we check in cache" sort of bug.
<jam> I could be wrong, but that is what it looks like to me
<poolie> i think you're right
<poolie> i'm glad i avoided saying "it's fixed" to them prematurely though
<jam> poolie: agreed.
<jam> poolie: So I think I remember spiv poking in this area. Where he realized we were double caching, and moved to expose the cache to the higher levels.
<jam> It is pretty vague, though.
<jam> poolie: but yeah, I'm seeing 500s 10MB transferred, and still discovering for a stacked branch.
<poolie> i'll comment on the bug
<vila> poolie: I now get mails for list moderation but I'm not able to connect, I suspect it's because you used vila@c.c instead of vila_bzr@c.c, can you try to change that ?
<vila> grr vila+bzr@c.c
<vila> It's a bit strange that the login ask only for a password and not for an email, but it probably tries all passwords for all admins...
<poolie> jam as a workaround we could unstack their 4.6 branch
<jam> poolie: because they are branching from it a lot?
<jam> poolie: certainly that will give them an immediate boost if it is something they are active on.
<jam> (should it be the dev focus if it is the active branch?)
<poolie> yes
<poolie> i don't know about that
<jam> poolie: so the *big* win is that unstacking it will mean they get immediate benefit regardless of what bzr client they are using
<jam> poolie: so I would recommend for that because it helps them *today*, though I still want to fix this
<vila> jam: but won't they run into issues when *pushing* if 4.6 is unstacked ?
<vila> or is that the opposite ?
<jam> vila: The main issue is that it will have all the history there, but if we do that part then it doesn't matter for them
<jam> so *if* they bring in a lot of new data from trunk into 4.6
<jam> that will get copied when they push to 4.6
<vila> 'that part' == unstacking ?
<jam> vila: yes
<vila> k
<jam> it will have to transfer, say 500MB, of history
<jam> (not sure on the exact amount)
<jam> but if we get someone close to the datacenter to do it, it should be pretty fast.
<vila> and how about keeping it stacked but still add the missing revisions ?
<poolie> vila i doubt they will be regularly merging such large amounts from trunk to 4.6 to outweigh the existing history
<poolie> jam, ok, it completed in 27m
<jam> poolie: well, you could stack it and leave the history, it would be a bit odd. And I think I'd just unstack it
<nigelb> poolie: hm, unsure how to get the right info to raise ShortReadvError.
<nigelb> Actually, unsure how to get the parameters for it.
<poolie> biab
<vila> nigelb: identify one file that is read, remove its content (or part of it, may the first few bytes needs to be there so the file can be identified properly)
<vila> nigelb: a pack or a an index file will do
<nigelb> heh, didn't understand that. let me grep where its used and try to decipher what you wwant
<vila> ShortReadvError occurs when a file is truncated (it should never happen under normal circumstances)
<nigelb> ah, so when the ftp does get disconnected, that's what would happen.
<nigelb> *stfp
<vila> nigelb: sry, didn't notice your reply
<vila> nigelb: hmm, so, if you're working on ssh disconnections, that's a bit different
<vila> nigelb: truncating the file may not be the right way to trigger the problem
<vila> nigelb: reading bug report
<vila> right, so what you really want is a test server that will drop the connection, catch that on the client side and (as spiv suggested) turn it into a ShortReadvError (I don't fully understand why spiv suggested that though)
<vila> ShortReadvError are really serious, when we encounter them it has always been linked to hardware issues (or bad crashes), raising them for network issues seem a but weird
<spiv> vila: we're talking about FTP?
<spiv> vila: FTP doesn't have any standard way to tell you how many bytes to expect on your data channel
<spiv> vila: and it's a separate connection to the control channel
<vila> spiv: sftp, see bug above
<vila> https://bugs.launchpad.net/bzr/+bug/328910
<ubot5> Ubuntu bug 328910 in Bazaar "ugly traceback when sftp server drops connection" [Medium,Confirmed]
<spiv> vila: in that case probably a ConnectionError of some sort is probably a better match
<vila> spiv: why did you suggest to turn a network error into a ShortReadvError ?
<vila> ha right
<vila> k
<vila> I agree
<vila> nigelb: ^
<jimis> Can I write a message for some changes I just shelved, but forgot -m?
<vila> jimis: unshelve/reshelve :-/
<vila> jimis: not ideal
<fullermd> vi .bzr/....    ;)
<fullermd> bairui: Hey, I snuck off to sleep while you were eating.  Hope you got on the right track.
<vila> fullermd: you... what ?
<fullermd> It's not my fault!  I'm sick!
<fullermd> I mean, physically, this time.
<vila> ha, ok
<jml> mgz: hi. how's things?
<Riddell> how comes there's no  bzr qremove command ?
<jelmer> Riddell: what would it use qt for?
<Riddell> well same as bzr qadd I would think
<jelmer> I wasn't aware there was a qadd either :)
 * jelmer gives it a try
<bairui> fullermd: heh... yes, I did, thanks mate. I read dozens of bzr articles and wiki entries and whatnot... I grok it! Thanks for your pointers this morning - good start to digging further. :)
<bairui> I'm doing up a dev & mig workflow doc & diag now
<fullermd> bairui: Oh good.
<fullermd> If you haven't come across them, some of the SpotDocs I wrote up a little while back may be useful.
<fullermd> http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs
<bairui> sweet :)
<fullermd> Particularly the PiecesInBrief section.
<fullermd> They're all totally useless as tutorials or introductions.  They're made to more fully explain the conceptual models of what happens, once you get used to basically using the system.
<bairui> nice. i've added them to my read queue. cheers. :)
<fullermd> (they're pretty rough; haven't had time to do much editing etc  :( )
<bairui> that's cool... I know where you live if I need to clear anything up ;)
<poolie> jam, so, anything else you need?
<poolie> otherwise i might poke at some more jubany failures and then stop
<jam> poolie: I think I'm good for now, probably time for you to take a break :)
<jam> vila: ping
<jam> jelmer_: do you still think you're going to be releasing bzr-svn ?
<vila> jam: pong
<jelmer_> jam: Yep, working on that at the moment. It's way overdue :-/
<jam> jelmer_: k, I won't spin up ec2 yet.
<jam> vila: Thoughts about get_parent_map and caching
<jam> have some time to chat?
<vila> always for you :)
<jam> vila: mumble/voip/skype? I'm thinking it will be faster than trying to type it all
<briandealwis> jelmer_: does bzr-git support accessing a repo over http?  I'm having problems branching from Eclipse's git repositories: trying 'bzr branch http://git.eclipse.org/c/platform/eclipse.platform.ui.git' results in HTML being spat out, and they don't seem to be running a git smart server
<jelmer_> briandealwis, I can't clone that URL with git either, it just hangs
<briandealwis> oh!  It works for meâ¦ or at least it was
<briandealwis> just checked again: it's working from here
<briandealwis> jelmer_: is there a way to force bzr to look at the URL for bzr-git?  There's no git+http scheme
<briandealwis> (I vaguely recall there being some "+xxx" addition to do something different)
<jelmer_> briandealwis: the problem is that that site doesn't return 404 for files that are not found :-/
<briandealwis> oh!  that's not useful
<jelmer_> briandealwis, bzr-git doesn't support smart server access over http to git repositories
<briandealwis> jelmer_: and it doesn't support dumb access either? :)
<jelmer_> briandealwis, it does support dumb access, but I'm not sure if that's enabled on the server
<briandealwis> jelmer_: they're supposed to be running a smart server (their examples show using the 'git:' protocol too), so I'll bug them about that.
<jelmer_> briandealwis, the main problem is the missing 404 though
<briandealwis> I'll file a bug with them about that.  There's no +xxx I can append to force bzr-git to continue on?
<jelmer_> briandealwis: no
<briandealwis> ok. Thanks for the help, jelmer_
<briandealwis> jelmer_: sorry to bug you again: would you happen to know what file is being probed for â the file that's returning 200?  (In case I'm asked)
<jelmer_> briandealwis, *any* file that doesn't exist
<jelmer_> briandealwis, e.g. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/.git/foo
<briandealwis> jelmer_: I understand that â they likely have done that to make things 'easier' for people.  They may be loathe to disable that.  But they might be willing for a particular file nameâ¦
<jelmer_> briandealwis: I'm not sure if it's actually worth reporting this just yet
<jelmer_> briandealwis: it'll be slow as hell until there is support for the smart server over http in dulwich/bzr-git
<jelmer_> briandealwis, any reaosn you're not cloning over git:// ?
<briandealwis> It's not working.  I've reported that to them too :)
<jelmer_> briandealwis, seems to be working fine here
<briandealwis> huh, weird.  I get an error.  I'll check that I'm running the latest dulwich and bzr-git
<briandealwis> jelmer_: You mentioned that you were able to clone over git:// from the Eclipse server?  I'm now up to dulwich 0.8.0 and tip of bzr-git on bzr 2.4b4, but I'm unable to branch from http://git.eclipse.org/c/platform/eclipse.platform.ui.git/.  I get an 'bzr: ERROR: The remote server unexpectedly closed the connection.'  -Dtransport doesn't reveal anything in the log
<jelmer_> briandealwis, does git:// work for you with git itself?
<briandealwis> jelmer_: I can pull from github. Though I get a NotImplementedError exception when I try 'missing'
<briandealwis> jelmer_: sorry â I misread.  No, git doesn't work with the URL either.  Weird.  But it works for you?  Maybe I should move to Europe.
<jelmer_> briandealwis: "bzr missing" should "work" now (just pushed a fix to lp:bzr-git)
<briandealwis> great!
<briandealwis> ah right, now it doesn't error :)
<briandealwis> jelmer_: the Eclipse sysadmins note that the 200 behaviour is part of cgit, the web front-end to git that they're using, and it isn't configurable.  They do run the git smart-server over http.  And I realize I had the wrong URL for the git:// smart server â not sure where I got it from.
<jelmer_> briandealwis: ah, cool
<jelmer_> briandealwis: so, bzr-git only supports "dumb" http access, but even if that works it'll be pretty slow for projects the size of eclipse
<briandealwis> jelmer_: they do have working smart servers â it still feels slow as molasses, so I shudder to think of what it would be like to use the dumb access.
<briandealwis> jelmer_: and thanks for your work with the ",branch=" work. Is this supported in bzr-git?  Out of curiosity, is there some more work required for that still?
<jelmer_> briandealwis: yeah, should work with current tip of bzr-git and bzr
<briandealwis> cool!  I'll give it a shot.
<briandealwis> Is there some way to disable or prevent a particular plugin from being loaded from the CLI?
<cody-somerville> Is there any way to make bzr update atomic?
<briandealwis> Not sure how I missed it, but BZR_DISABLE_PLUGINS is what I was looking for
<jelmer_> cody-somerville: what do you mean by atomic exactly?
<cody-somerville> jelmer_, ie. if the operation fails (ie. conflicts, etc.) that nothing changes
<jelmer_> cody-somerville: it is atomic, there just isn't any support for rollback if the transaction contains conflicts :)
<jelmer_> cody-somerville: I agree it makes sense to have an option which can abort and not touch the tree if there are conflicts
<cody-somerville> yea, I'm basically looking for it to be an atomic transaction
<thumper> hi people
<thumper> I have a weird merge problem
<thumper> I've done a bunch of work in a branch
<thumper> which ends up being branched from the packaging branch (with distro patches et al)
<thumper> instead of the upstream mirror
<thumper> now I want to make another branch
<thumper> and merge in particular changes to particular files
<thumper> is there a way to say "merge the changes to this file from that branch"
<thumper> but not get the revisions?
<jelmer_> thumper!
<jelmer_> thumper: Do you perhaps just mean "bzr merge" followed by "bzr revert --forget-merges" and reverts of the other changes you don't want?
<thumper> hi jelmer_
<thumper> ah...
<thumper> that should work
<thumper> although I'm going to have to revert a bucket load of changes I don't care about
<thumper> I did "bzr revert .", but it did the opposite of what I wanted and I couldn't remember the syntax
<thumper> can I just merge changes from a particular file?
<jelmer_> thumper: you can, just specify that specific file
<thumper> kk
 * thumper tries
<thumper> nope
<thumper> can't specify a file in merge
<jelmer_> thumper: "bzr merge ../path/to/branch/file.txt" works here
<thumper> ah... I was doing two parts
<thumper> jelmer_: it also appears that just merging a file doesn't have pending revisions to merge
<jelmer_> thumper: yep
<jelmer_> we don't properly track cherrypick merges of individual files or individual revisions yet
<thumper> yep
<thumper> that works for me
<thumper> ta
<maxb> jelmer_: Do you have any plans to release subvertpy 0.8.4 soon?
<maxb> I had been intending to not obsolete karmic from the ~bzr PPA until after bzr 2.4.0 happened, but there's no bzr-svn/karmic compatible with bzr 2.4, and there won't be unless subvertpy 0.8.4 happens, or I backport that. Which I was hoping to avoid :-)
<jelmer_> maxb, sure, I guess I could do a release
<maxb> If it's not too much effort, great
<maxb> Otherwise, we can just obsolete karmic now, before bzr 2.4 hits ~bzr/ppa
<maxb> Which, come to think of it, might be the sensible thing to do anyway
<maxb> it is over 3 months EOLed
<idnar> does bzr have anything like mercurial queues?
<idnar> I guess loom is the thing I need to look at?
<lifeless> pipelines are closer to queues
<lifeless> loom versions the stack of patches as a unit, which is useful for distro / collaboration-around-the-queue
<idnar> ah
<idnar> I'm not yet sure which approach I want here
<idnar> (some background: I'm trying to find out what changes I need to make this code run on pypy, so I'm just hacking stuff willy-nilly to get it working; later I want to clean things up and eventually break changes out as separate branches to hopefully be merged into upstream)
<idnar> I think pipelines may be the easiest way
<idnar> I guess I can't sync-pipeline to Launchpad
<lifeless> idnar: pipelines fit that use case
<lifeless> idnar: sure you can
<idnar> bzr: ERROR: Permission denied: "~divmod-dev/divmod.org/divmod-on-pypy/.bzr/branches/divmod-on-pypy/": : Cannot create branch at '/~divmod-dev/divmod.org/divmod-on-pypy/.bzr/branches/divmod-on-pypy'
<idnar> er, the line before that was: Creating new pipe at bzr+ssh://bazaar.launchpad.net/~divmod-dev/divmod.org/divmod-on-pypy/.bzr/branches/divmod-on-pypy
<lifeless> hmm, where is abentley when you need him :)
<lifeless> idnar: oh
<lifeless> idnar: so, what you do is have the pipeline local
<lifeless> and publish all the pipes to lp as separate branches
<lifeless> this is a bit different to loom
<idnar> yeah
<lifeless> pipelines is a less intrusive plugin :)
<lifeless> poolie has a plan to merge various bits of guts and make them separate policy layers on a common substrate.
<lifeless> I'm not sure that the substrate is enough for loom without being in the way of pipeline, but I guess we'll see ;)
<idnar> I should have looked at pipelines again before now; I read about them a while back, then forgot about them
<idnar> I did a think the other week that would have been much easier
<idnar> *a thing
<poolie> hi all
 * idnar waves to poolie
<poolie> hi idnar
<poolie> some parts of that unification are now landing
<poolie> for example 'bzr branches' will tell you about colo branches
<poolie> it's not connected to pipelines or looms yet though
#bzr 2011-08-19
<idnar> -r ancestor::submit..
<idnar> there's something visually fun about that
<lifeless> :)
<lifeless> almost perl in its elegance :P
<idnar> although I think I actually just want bzr missing
<fullermd> It really needs a pair of top-aligned dots at the beginning though.  Isn't that in Unicode somewhere?
<idnar> haha
<idnar> Â¨::..
<idnar> hmm, no
<idnar> ÎÎ::..
<idnar> someone else can write the patch to add it to the revisionspec syntax :P
<fullermd> Alternate interpretation: "ancestor::submit.." would be a good title for a prog metal album.
<bairui> hey, guys... on evaluating my repository layout needs for website development, a question arose regarding releases. We have a staging area (called XPT) from which successfully (accepted) builds become releases. What is a better strategy (repository-wise) with dealing with these releases? Should I have a single XPT branch from the trunk (created either way back when or at the first release) and as new
<bairui> releases come, just merge them into XPT and tag the successful ones?   Or...   Create a new branch for each release?
<mwhudson> fullermd: i like "Alternate interpretation: ancestor::submit.." actually
<lifeless> bairui: both are fine
<bairui> cool
<fullermd> mwhudson: Could be a totally genre crossover.  Tracks include "Criss-cross merging the streams" and "-rdate:All Our Yesterdays".
<bairui> tagging it is then, methinks
<bairui> thanks, lifeless
<mwhudson> fullermd: i like "Alternate interpretation: ancestor::submit.." actually
<mwhudson> bah!
<mwhudson> fullermd: :-p
<fullermd> Maybe I should take that back.  It almost makes me look like some kinda nerd.
<james_w> poolie, hi, did you change the crontab on jubany to send to canonical-bazaar?
<james_w> poolie, if you did, it's bouncing
<james_w> in fact, that's not conditional :-)
<james_w> it is bouncing
<james_w> "Relay access denied" from smtp.external
<poolie> hi james_w; i did
<poolie> shall i set it back to you?
<poolie> i've donethat
<vila> hi all !
<vila> good evening poolie
<vila> compiz: I don't what you're doing but t 2.5GB (3.7GB virtual), you're overdoing it
<vila> I almost rebooted...
<blackarchon> this wouldn't happen with KDE!
<vila> :)
<vila> famous last words ?
<blackarchon> I call it the eternal truth!
<AfC> KDE or GNOME3, works for me!
<AfC> [I can't believe I just wrote that]
 * gour stays with xfce
<bairui> i just switched to xfce about a week or so ago
<bairui> from awesome. I *liked* awesome... I just wanted to play with something shiny for a while.
<jam> vila: unity --replace &;  Should fix it, I think.
<jam> There are some memory leaks in compiz wrt app indicators
<jam> bug #779717
<ubot5> Launchpad bug 779717 in unity (Ubuntu Natty) "indicator-multiload causes a memory leak in compiz when run under unity" [Undecided,Triaged] https://launchpad.net/bugs/779717
<gour> i'm just not sure i will be able to stay on freebsd seeing that DEs are becoming more & more linux-only
<vila> jam: yeah, thanks, I've seen some earlier bugs and thought the issue was fixed...
<vila> fullermd: ^ Imminent death of FreeBSD predicted ;)
<vila> vila: stop it ! Enough noise already !
<AfC> Replace Unity. Yes, that's an excellent idea.
<zzz> Hi, is there any possibility to see the actual branches? Like git branch -a in git?
<blackarchon> 'bzr branches' has just made it into trunk
<vila> zzz: a bit more context may help answer your question
<vila> zzz: branches map to directories by default
<AfC> zzz: ie http://research.operationaldynamics.com/bzr/quill/ ; lots of Branches there; 'mainline' only one with a Working Tree in it.
<gour> i like that hg doen't have 'main' line...but, well
<gour> for me, greater problem is lp' lack of wiki & private repos (in comparison with bb)
<vila> jelmer_: what's the status of bzr-svn with respect to bzr-2.4.0 ?
<vila> jelmer_: no pressure intended et al, but, you know.. ;)
<vila> jam: regarding bug #614713, you said 'reasonable to backport', how far should I target ? 2.0 ?
<ubot5> Launchpad bug 614713 in Bazaar "selftests fail assertActivitiesMatch for pycurl compiled against openssl" [Medium,In progress] https://launchpad.net/bugs/614713
<poolie> hi there vila, all
<vila> jml: I've got a magic guesser but you won't be able to use it :) Good one ! (Joke aside, kudos for the neat pkgme-binary, that's the kind of magic I *love* !)
<vila> hey poolie !
<vila> poolie: I've run selftest -Econfig_stats | subunit-sum on bzr.dev.revnos[5982:6082] and your fdatasync raise interesting numbers
<vila> s/sync/& stuff/
<poolie> oh?
<vila> since you cache the config we get a preview of what read/write once will achieve
<vila> https://launchpad.net/bzr/+milestones
<vila> list all the planned dates for the releases
<jml> vila: thanks :)
<poolie> jam, hi?
<poolie> jml, hi
<vila> Riddell: hey PP, can I ask for some reviews ? :D
<vila> jam, jelmer, Riddell : ping
<jelmer> vila!
<vila> ha ! Someone ! :D
<jelmer> uhoh, what did I volunteer for ? ;-)
<vila> jelmer: how's going :)
<vila> oh, nothing, just wanted to know are you were going on with bzr-svn and if you needed help there
<jelmer> vila: alright so far, still working on tests
<vila> \\o o// rock&roll !
<jelmer> vila: :)
<vila> If our beloved PP can shime in now... that would be so great ;)
<vila> wow, almost felt into the 'pqm-is-broken' trap :) The progress does *not* work for 2.0 ...
<vila> ohhh, and we run the test suite twice with [ascii] :)
<vila> Riddell: Ping
<briandealwis> jelmer: I have a local git repo.  With latest bzr.dev and bzr-git at tip, should I be able to use file:.../git-repo,branch=XXX to reference a particular git branch?
<jelmer> briandealwis, yep
<briandealwis> jelmer: I'm getting an error: "Not a branch: "/Users/bsd/Manumitting/Projects/e4/platform-ui-git": location is a repository.
<briandealwis> jelmer: but branching without ",branch=XXX" works fine
<jelmer> briandealwis, what does "BZR_DISABLE_PLUGINS=bzrtools bzr branches ../git-repo" say?
<briandealwis> jelmer: no change
<briandealwis> jelmer: sorry â I didn't fully read your message
<briandealwis> jelmer: it just spits out 'master'
<jelmer> briandealwis: does that match the output of "git branch" in that repo?
<briandealwis> jelmer: yes â good catch.  Sorry for the confusion.
<briandealwis> jelmer: do you think specifying 'origin/XXX' will work?  (There's a pile of origin/ branches listed with 'git branch -a'
<jelmer> briandealwis, that should work, but you have to urlescape the / to prevent it from being interpreted as a path separator
<jelmer> ,branch=origin%2Ffoo
<jelmer> I realize that's not a very nice syntax, but it's a start
<briandealwis> it makes complete sense
<briandealwis> â¦though unfortunately origin%2Fxxx doesn't work â same location-is-a-repository
<jelmer> actually, it needs to be
<jelmer> ,ref=refs%2Fremotes%2Forigin%2Ffoo
<briandealwis> nifty â but now I get a "ValueError: unable to map ref refs/remotes/origin/R4_development back to branch name".  Strangely there's only HEAD under .git/refs/remotes/origin/
<briandealwis> I wodner where 'git branch -a' gets its info from then?
<jelmer> briandealwis: ah, argh
<jelmer> briandealwis: yeah, remotes are still problematic - can you file a bug?
<briandealwis> ok
<jelmer> briandealwis, git branch -a gets them from the packed refs file, which bzr-git will also be looking in
<briandealwis> This is all great stuff, jelmer.
<jelmer> briandealwis: now if only it actually worked.. :)
<briandealwis> jelmer:  filed as bug 829481
<ubot5> Launchpad bug 829481 in Bazaar Git Plugin "cannot reference a remote branch" [Undecided,New] https://launchpad.net/bugs/829481
<jelmer> briandealwis, thanks!
<briandealwis> jelmer: it's working great once I establish a local tracking branch
<briandealwis> jelmer: the fix to bzr-git for avoiding rebuilding the git-map cache no longer triggers a rebuild.  thanks for that too!
<vila> jelmer: thanks for the review !
<vila> everybody: just thanks jelmer will you, it's just this time of day ;)
<jelmer> briandealwis: great, thanks for confirming :)
<jelmer> vila: hehe :)
<vila> jelmer: any news from Riddell ?
<jelmer> vila, haven't heard from him
<vila> la la la, finally a trick to use pdb for blackbox tests \o/
<jelmer> vila: ooh?
<vila> http://paste.ubuntu.com/670131/
<vila> I thought it was possible for... a long time, never tried. Stupid vila
<vila> jelmer: and now https://code.launchpad.net/~vila/bzr/debug-blackbox-tests/+merge/72195
<ubot5> Ubuntu bug 72195 in linux-source-2.6.17 (Ubuntu) "Ubuntu Edgy don't power off after shutdown" [Undecided,Won't fix]
<vila> great, merge proposals and bug numbers overlap... endless fun
<jelmer> vila: it'd be great if BZR_TEST_PDB could support that too
<fullermd> vila: Onoes!  BSD is dying again??   :(
<vila> fullermd: hehe, wow, you've been away for long ;)
 * vila just can't remember about BZR_TEST_PDB... time for some grepping
<jelmer> fullermd, it's true, netcraft confirms it!
<fullermd> Oh, I was worried for a second.  It's not REALLY official 'till it's on Wikipedia.
<vila> jelmer: doesn't it work already ?
 * vila tests
<jelmer> vila: I'm not sure actually.. I just figured it wouldn't
<vila> it seems to work but I'm not that familiar with post-mortem debug
<vila> and before fullermd jumps his gun, yes, I prefer live debug ;)
<fullermd> Ew.  Live bugs are creepy.
<jelmer> fullermd: You have entomophobia and still manage to be a programmer?
<vila> jelmer: right, looking at the implementation it's called far after stdin/stdout have been restored so N/A ?
<fullermd> Well, it would be a problem if I were a _bad_ programmer.  Just gives me another reason to maintain my wonted perfection, see.
<vila> fullermd: it's an acquired taste, I love bugs at breakfast
<jelmer> heh, fair enough
<jelmer> vila: that's a good point; so this means I should be using "from bzrlib import debug; debug.set_trace()" rather than importing from pdb?
<vila> jelmer: yes
<vila> well, at least with the proposed patch
<vila> there may be a way to override the pdb.Pdb class directly, but I went with the simplest dirst
<vila> first
<jelmer> vila: this seems reasonable too
<vila> thinking about it, may be I should just define set_trace in bzrlib including the pdb import... so we can just say bzrlib.debug()
<vila> errr
<vila> bzrlib.set_trace()
<vila> jelmer: love/hate ?
<jelmer> vila: in debug makes more sense to me
<jelmer> and easier to find
<jelmer> if we really care about not having to type that many characters, we should have ./bzr override pdb.Pdb
<jelmer> IMO
<vila> k
<vila> on the other hand overiiding pdb.Pdb may be seen dev-hostile in same cases, bah, let's see what reviewers think, thanks for your feedback
<lamalex> hi bzr, i'm trying to set up daily builds for the unity team. working on nux and when i run my recipe i get an error i dont understand, bzr: ERROR: No such tag: upstream-1.2.0t hooks - Stage 5/5
<jelmer> lamalex, hi
<vila> I like the existing ability to do self.debug() in tests (which triggered my typo above: bzrlib.debug())
<lamalex> hello jelmer
<jelmer> lamalex, it sounds like you're trying to build a non-native package but do not have a tag for the upstream tarball
<jelmer> lamalex, since launchpad itself does not (yet) support non-native packages in recipes, I would recommend building with --allow-fallback-to-native
<fullermd> Sounds like a double error actually, with it not clearing the line before giving the error.
<lamalex> jelmer, what's a native vs non-native package? (i'm not a packager..)
<lamalex> it's all C++ code..
<jelmer> lamalex: http://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a_native_Debian_package_and_a_non-native_package.3F
<lamalex> :)
<jelmer> lamalex, in contrast to the answer on that FAQ, native packages often make more sense for daily builds
<jelmer> lamalex: as upstream is going to change for each new upload, so there isn't much benefit in trying to reuse tarballs
<lamalex> makes sense
 * lamalex tries that flag
<jml> mgz: I'm probably going to have some time for testtools hacking on the weekend. Am looking forward to seeing your stuff on assertThat.
<jml> mgz: I don't want to nag. I very, very much appreciate your contributions. But I also want to release.
 * jml goes
<jelmer> maxb, btw, I did a subvertpy release
<jelmer> jml: have a good weekend :)
<etenil> Hi there
<jelmer> hi
<etenil> I'm working with the bzrlib, and I'm trying to make a formatter that turns a log into HTML, but the formatters seem to only be able to output to files (from the API anyway) and I'd need the output into a variable. Could someone help me?
<mgz> blast, missed jml
<Riddell> good evening
<Riddell> sorry vila, I had a day off today
<Riddell> are reviews still needed?
<jelmer> 'evening Riddell
<jelmer> I think there's still two open MPs
<GRiD> hi Riddell  and/or jelmer, i'm waiting for proposal 70691. here if you want to talk about it.
<Riddell> GRiD: got the full URL?
<GRiD> https://code.launchpad.net/~weyrick/bzr/54624-warn-on-large-files/+merge/70691
<GRiD> actually, i'm here as long as the approaching thunderstorm doesn't take out my power.
<jelmer> g'evening GRiD
<GRiD> howdy :)
<GRiD> re: this proposal, i was thinking that if my final comment makes sense, i should probably make that functionality more explicit in the docs, and add a test for it
<Riddell> GRiD: yes, I was just going to say that
<GRiD> ok i'll add that, shouldn't take long.
<Riddell> "add.maximum_file_size" why the dot in there?  bzr config options mostly don't use dots but some do and I'm not sure why
<GRiD> if you look up in the comments a bit, that was one of the original suggestions from martin
<GRiD> it seems that's a convention that's trying to be adopted
<jelmer> yeah
<jelmer> GRiD: I think this all looks ready to land
<GRiD> awesome. let me just push these final doc changes and test
<jelmer> GRiD, can you also add another newline above AddWithSkipLargeAction ?
<GRiD> well now you're asking for a lot
<jelmer> :D
<GRiD> :) ok just pushed
<jelmer> cool
<Riddell> GRiD: lovely, approved, shall I sent it to PQM?
<GRiD> very cool. uh, i don't know the next step, this is my first patch :)
<Riddell> a good first patch :)
<Riddell> next step is to ask the patch pilot (moi) to send it to PQM which is the programme that runs the test suite then merges it if it all works
<Riddell> unfortunately pqm doesn't seem to want to work tonight "httplib2.ServerNotFoundError: Unable to find the server at api.launchpad.net"
<Riddell> ah here we go
<Riddell> GRiD: actually, could you add a release note too?
<Riddell> needs an entry in doc/en/release-notes/bzr-2.5.txt
<teratorn> hi, I'm trying to 'bzr merge', but bzr is failing to work because it complains about outstanding changes in the working directory. Which there are none, only the mistaken perception of changes; a bunch of files that have modes +x instead of -x presumably because this is on a Windows file system... how can I get unstuck?
<Riddell> teratorn: does running bzr commit help ?
<jelmer> teratorn: bzr revert should reset the entire tree, including the permission bits
<Riddell> that's a better idea
<teratorn> lets see
<teratorn> I guess that works.... but how would it have gotten screwed up in the first place?
<jelmer> teratorn: was there perhaps another branch you pulled in (and then reverted?) that touched the permissions bits?
<teratorn> jelmer: I don't think so *shrug*
<teratorn> btw, is there a fast-export/fast-import tool for bzr?
<jelmer> teratorn, yep, there is a fastimport plugin
<teratorn> yeah - I'm just checking it out now
<jelmer> teratorn, I'm not sure what else could have caused the permission bits, I don't have a lot of experience using bzr on windows
<GRiD> Riddell, ok thanks. I'll add the note
<GRiD> Riddell, pushed, please take a look. tried to follow the existing format.
<Riddell> GRiD: lovely, sent, it's in the queue at http://pqm.bazaar-vcs.org/
<GRiD> great thanks :)
<GRiD> i guess i should close the associated bug
<GRiD> Riddell, shows a conflict in the release notes. do I have to do something?
<Riddell> uh oh
<Riddell> GRiD: merge in trunk and I'll send it again
<elmo> does no one else find the bzr completions in zsh slow to the point of unusability ?
<Riddell> they're slow to the point of unusability on bash too
<elmo> Riddell: really?  bash works ok for me
<elmo> I finally got annoyed enough to try bash
<elmo> and was horrified to find it works there
<mgz> elmo: have you seen contrib/zsh/README ?
<mgz> my understanding is the new bash-completion plugin uses a more sensible method
<mgz> it's certainly fast on my ancient laptop
<GRiD> Riddell, ok i think i've merged ok
<elmo> mgz: hmm, I hadn't thanks
<mgz> GRiD: about your earlier question, unexpected merge conflicts are one reason I superstitiously wait for the pqm run to complete successfully before marking the bug fixed :)
<mgz> so, elmo, I think `bzr shell-complete` is just slow, and zsh uses it while bash-completion doesn't.
<GRiD> mgz, agreed, i actually did wait ... :)
<bairui> elmo: did you find the problem? I think my bzr zsh setup is woeful too. :-(
<elmo> bairui: I'm sure what mgz said is likely the problem - unfortunately I don't know enough zsh to be able to use the information to fix it
<bairui> ok, but I don't even understand what he said - where is contrib/zsh/README ? whose contrib is that? bzr's? where is that? I did a locate and came up dry... :-?
<bairui> oops... I didn't read his final word on the matter. :)
<fullermd> Yes, it's right in the bzr tree.
<bairui> you guys *have* a bzr tree :)
<fullermd> We what?  Of course not.  What kind of nerds do you take us for?
<bairui> heh - it's just that at this party... I'm a lesser nerd :-/
<fullermd> In my youth, I tried that once.  It was an embarassing failure.
<bairui> lol
<fullermd> Now I just strive instead to be _massively_ more nerdy than anyone else.  That way, any references or jokes I make are so far out nobody even notices that I tried, so the end result is that I seem more normal.
<fullermd> ...  that's my theory, anyway.
<bairui> good blending strategy - at nerd parties
<fullermd> There's...  some other kind?
<bairui> heh - no. not fun ones, anyway.
<bairui> so, without being able to read said README, what are my zsh bzr completion options? suck it up and wait? or is there a super-magic fix? or... use bash? :-(
<fullermd> You can just read the README online y'know   ;p
<fullermd> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/view/head:/contrib/zsh/README
<bairui> thanks, fullermd :D
<fullermd> It's even more fun that way too, 'cuz it looks like loggerhead is trying to syntax highlight the README as if it were python...
<bairui> yes... a bit unfortunate.
<fullermd> Of course, the Right Answer is obviously to just use tcsh, like all smart attractive people do.
<bairui> so, fullermd, you're on zsh too, eh?
 * fullermd looks around for a stick.
<bairui> heh :D
<fullermd> I had a professor once who kept a 2x4 by his desk, with "Board Of Education" stenciled on it.
<fullermd> He threatened to use it with some regularity.
<bairui> the Clue Stick!
<bairui> we had a senior at uni with a wiffle (sp?) bat that he'd wield in the labs. It was his Clue Stick
<idnar> hmm
<idnar> is there an easy way to reorder pipes?
#bzr 2011-08-20
<fullermd> bairui: So how did your designing-layouts/workflows stuff turn out?
<bairui> so far, so good... methinks. I have a workflow doc and I'm creating some images to go along with it now.
<fullermd> Cool.
<fullermd> 's long as it doesn't end up in a Powerpoint or something, anyway...
<bairui> I am just putting it in pastebin if you'd like to cast your critical eye over it, fullermd?
<fullermd> Well, it'd be a pretty cursory glance.  I'm evaluating and collating incomplete and outdated information for a pointless meeting on Monday about a doomed project.
<bairui> fullermd: http://pastebin.com/88sNi5Wv
<bairui> and thanks for even glancing at it :)
<bairui> hate meetings... especially pointless ones, and so many are. :-(
<fullermd> I would suggest using a checkout rather than a branch for trunk.  Then you can just merge/commit, and it also makes it harder to accidentally go the other way and swap around the mainline accidentally.
<fullermd> And you're already using checkouts for the feature branches anyway, so might as well be consistent.
 * bairui is taking notes
<bairui> ok. good to know.
<fullermd> I'm not sure why you have the "merge --pull" stuff in youe trunk branch notes here either.
<fullermd> I suspect you really meant just 'bzr pull'.
<bairui> i think we were originally doing a   bzr pull   and saw someone use   merge --pull   and thought, well that saves a command if we had to merge... wrong?
<fullermd> Well, for one thing, after a merge you'd have to commit the merge.
<bairui> ah. ok.
<fullermd> But also, if pull failed on trunk, I'd think that's a red flag to stop and go "whoah, wait, wtf".  Not something to gloss over.
<bairui> so - we'll go back to    bzr pull   and be explicit about the merge if that was necessary
<bairui> agreed
<fullermd> That would mean that somehow your local 'trunk' ended up with something the upstream trunk doesn't have.  That shouldn't happen.
<bairui> like a local commit
<fullermd> And if it did and you merge, you get into the mainline-swapping situation.
<bairui> ok. to be avoided. noted :)
<fullermd> Is it necessary to have the feature branches on the server?  I mean, sure, it's nice for longer lived stuff, but it may be overkill for simpler.
<bairui> i was originally not putting them there - just keeping them on our local dev machines, but someone raised the concern that these are not on the server...
<fullermd> Well, if a feature branch is taking weeks, or being worked on by multiple people, you definitely want it central there.  If it's lasting hours or a day or two, for just one person, though...
<bairui> i guess after they get merged into trunk then they're 'available'... I think there was concern over being able to easily go back to that piece of work if rework was necessary
<fullermd> Maybe you want to avoid people thinking case-by-case like that, which is valid.
<fullermd> Oh, yes.  Once it's merged into trunk, it can be recreated trivially.
<bairui> ok...
<fullermd> If you do "bzr branch -r123.4.5 trunk newbranch" (assuming that rev is the head of the branch you had, that got merged in), you've [almost] recreated it exactly as it was before you merged.
<fullermd> The only stuff you miss is transient branch config (the nick, saved parent/push/etc branches, and so on).
<bairui> nick?
<bairui> the local branch name?
<fullermd> So any time a branch is "completed" and merged, if you don't expect to pick it back up as-is, it can be rm'd away.
<fullermd> Branches have nicknames, which are recorded in the revs created in them.  The default is just the dir name, but you can set it manually.
<bairui> right - and it was that rm'ing that freaked a team member (and I didn't know bzr well enough to assuage their fears)
<fullermd> It shows up in `log`, for instance.  Just cosmetic, but helps keep straight what you think you were doing.
<bairui> ah - we've just been using dir name as branch name
<bairui> ok - so for small dev work and bug fixes, you'd say: branch locally, hack, commit, merge, rm   ?
<bairui> for collab stuff, branch on server
<bairui> or longer living / huge stuff
<fullermd> I usually always branch locally, then also push the branch up to the server if it winds up being long-lived or needing collab.
<bairui> ok. i saw that flow sometime yesterday - was nice to know one could always push a local branch at a later date
<fullermd> `bzr branch bzr+ssh://some/thing bzr+ssh://some/thing/else` is kinda wacky, since you copy all the data across the network twice.
<fullermd> My work tends to go something like
<bairui> good to know
<fullermd> cd ~/work/projfoo; bzr co bzr+ssh://central/trunk   # pretty much always a central trunk, just make local checkout.
<bairui> ok
<fullermd> For utterly trivial stuff, I often just do and commit right on trunk.  If it's 5 minutes of work, and just one commit, why bother with the overhead of branches, I say.
<bairui> ok
<fullermd> If it's going to be more than one rev, especially if half-broken in the middle, or take longer, I make a local branch
<fullermd> cd ~/work/projfoo ; bzr branch trunk featfoo
<fullermd> Then I can work in featfoo.  If I decide to put it central for some reason, I can just `bzr push bzr+ssh://central/featfoo` then.
<bairui> right. cool.
<fullermd> And either remember to 'push' my changes Every So Often(tm), or convert the branch into a checkout at that point.
<bairui> so that each commit effectively pushes, right?
<fullermd> (see `bzr reconfigure`; you can turn a checkout into a branch, a branch into a checkout, a standalone [non-repo-using] branch into one using a shared repo, a shared repo branch into a standalone, blah blah blah)
<bairui> nice. awesome
<bairui> scary :)
<fullermd> Correct in essence [auto-pushes].  That gets into philosophical issues.
<bairui> heh, let's keep this pragmatic for now - my bzr-fu is not ready for philosophy :)
<fullermd> Now, you may want to just fiat declare "all branches are always on the server", for either political reasons or to avoid asking people to make judgements.  That's down to your situation.
<fullermd> So anyway, over time, I can always `cd ~/work/projfoo/trunk ; bzr up` to have my trunk copy up to date.  Merge changes from it into featfoo if/as necessary.
<fullermd> And when featfoo is done, I can just rm -rf it.
<fullermd> (for various external reasons, I often don't exactly, but that's another matter)
<bairui> mmm... I smell pancakes cooking... *drool*
<fullermd> Oh, I notice you mention a 'settings.php'.  Here's a trick I use a lot in webdev: we want separate configs in testing vs live (actually run credit cards vs. fake, different databases, all sorts of things)
<bairui> ok, fullermd... that's cool. I'm logging this, so I will show it to the other team members.
<bairui> yep
<fullermd> So what I do is I have a 'live.conf.php' and 'dev.conf.php' versioned.  The includes look for "conf.php", which I make an [unversioned and ignored] symlink to whichever one is appropriate.
<bairui> drupal, as I'm sure you've guessed
<fullermd> Or in some special cases, a hand-crafted one.  That way we don't worry about versioning local changes, but we still have standard configs versioned and ready.
<bairui> I keep a config.yml file and generate the appropriate settings.php from the current env
<fullermd> (actualy deployment happens via Makefile, which creates the proper symlinks in the destination)
<bairui> config.yml gets versioned and the settings.php is always re-created
<bairui> I don't have the luxury of running a Makefile on some of my deployment hosts - cheap :)
<fullermd> If I don't admin the system, it's not a deployment host; it's something I complain to the client about and bill triple time for any interaction with  :p
<bairui> heh... that will be a glorious future, but for now, we suck it up. :-/
<fullermd> As far as the testing/XPT/later stuff, it sounds like something particular to your process, so I don't have much of an opinion.
<bairui> i will compare your settings.php approach with our current way and reconsider our choice.
<bairui> fair
<fullermd> Is //todd/ on the LAN?
<bairui> the XPT is now a single branch that we merge releases into and tag if happy
<bairui> yep
<fullermd> 'k.  I'd avoid using lightweight checkouts across anything slower than a very fast LAN.  They work great on local disk; on an uncongested LAN it's not too bad.  But I wouldn't try it farther than that.
<bairui> wow. really? why?
<fullermd> They're really made for use on local disk, so they move a lot of data and a lot of round trips.
<bairui> ah... didn't know that. ok - so, what? branch or checkout as necessary?
<bairui> instead
<fullermd> With a gigabit of bandwidth and sub-millisecond latency, that's ignorable.  With a couple megabit and dozens or hundreds of ms, not so much   :)
<fullermd> Using a [regular, 'heavy'] checkout in their place would be fine.
<bairui> oh - so it's merely a speed issue? not a lost-data one?
<bairui> ok
<fullermd> Oh, yes.  No data safety; just speed.  But a lot of speed.
<bairui> cool - good to know. if we notice lag, heavy she is.
<fullermd> A heavy checkout is basically the same as a light one, except it keeps a local cache of the whole history (like a branch).
<bairui> ironic - i thought light would move less - no history, after all... what am I missing?
<fullermd> If you can spare the space, it can be worth doing heavy just because it gives you an extra 'free' backup on another box, too.
<bairui> that is a good point
<bairui> space is easy to spare
<fullermd> Well, on the one hand, because it has no history, it has to go to the server to even find out what the pristine state of the _current_ files are.
<bairui> ah... which reminds me... I haven't read about bzr backup yet... it's on the todo list
<bairui> that makes sense (light)
<fullermd> So doing e.g. 'bzr diff' has to go grab the originals of all the changed files from the server, every time.
<bairui> yuck
<bairui> ok - sold.
<fullermd> And it does the internal lookups in very network-unoptimized ways.
<fullermd> There are cases where somebody has done light checkouts of couple-meg trees, and foudn that an 'update' moves hundreds of megs across the network.
<fullermd> (due to egregious bugs, rather than the suboptimal-for-usecase design, but still)
<bairui> *shudder*
<bairui> ok - we'll go heavy - space is not a concern.
<bairui> so, any other nasties in our proposed workflow, mate?
<fullermd> Well, all your uses of "--remember bzr+ssh://...." are a bit of an eyesore.
<fullermd> If you're --remember'ing, why specify each time?  ;)
<bairui> ok... i think the designer had assumed that these were previously non-existing dirs - recreated as necessary.
<bairui> we'll look at that.
<bairui> thank you very much, fullermd, for your time and advice on all that. <3
<fullermd> I'm somewhat curious about the "rm -rf web ; bzr co [...]" bit at the end of the XPT migration thing.
 * bairui smells pancakes, honey and maple syrup...
<fullermd> Surely you don't want to do that every time?  Maybe that's just meant to be a "first time" instruction block...
<bairui> /var/www/xpt/web held the last (view into) a site in xpt
<fullermd> Yah, but wouldn't it already be the existing branch/checkout from last time you do it?  So why rm ; re-checkout instead of just 'update'?
<bairui> we would do that *if* we didn't care for the previous view
<bairui> right - so it it's the same view (site), we'd update
<bairui> if it's a different website then we'd rm
<fullermd> Ah.  So it's a single location potentially used by different things.
<bairui> we were just being lazy - keeping a single xpt site
<bairui> yep
<fullermd> Speaking of some of my unfavorite things about webdev...
<bairui> heh
<fullermd> (this is why I often don't rm my feature branches when I'm done with them; instead I rename them to a new feature branch, because webdev means there's always extra setup to do when creating a new workspace   :|  )
<bairui> ah, yes... we generate code for that reason
<fullermd> Can people just use userdirs on todd?
<bairui> userdirs? like  /home/user/public_html  ?
 * fullermd nods.
<bairui> um... i haven't set that up... why? what would that give me?
<bairui> gack! pancake call! :-o
<bairui> can we pick this up again in a bit, fullermd? :-D
<fullermd> Well, maybe it's usable instead of xpt; that way you don't worry about stomping on each other so much.
<fullermd> Or maybe it fit your flow; I'm just spitballing.
<bairui> we can create multiple xpt sites (with our generator scripts) very easily - we were just documenting the lazy case :)
<fullermd> Ah.  Laziness is next to godliness.
<fullermd> But both are far removed from pancakes, so I dunno why you're wasting time talking about them when the latter are in offing   :p
<bairui> agreed! thanks, mate. later! :-#
<fullermd> Oh, [when you get back] have you worked out in-repo perms on todd so things keep working for everyone?
<bairui> back... delicious pancakes.  And oh, my gosh, yes... permissions. A colleague has threatened nasty things with pliers if I don't sort out the permissions thing pretty soon. What's the good oil there, fullermd?
<fullermd> I dunno.  Break-Free maybe?  That should make the pliers run smoothly.
<bairui> keeping my bits away from pliers is the goal here, fullermd...
 * bairui suspects fullermd's still looking for that stick   ;)
<fullermd> Oh, I'm supposed to be helping YOU in this instance, then?
<fullermd> That's way less entertaining.  Hold oh, I'll go cancel the popcorn then...
 * bairui needs to invest more in team management skills...
<fullermd> Team management is tough sometimes.  Depending on the floor plan, it can be difficult to get enough voltage to everyone's chair.
<bairui> lol
<fullermd> What OS it the server running?
<bairui> linux
<fullermd> Wow, people still use that thing?  Amazing...
<bairui> oi!
<fullermd> OK, so you've got SysV filesystem semantics.  Presumably you're using a shared group with everyone in it?
<bairui> yep
<fullermd> 'k.  So you'll need g+s on all the dirs under the repos, to keep the group ownership.
<fullermd> And g+w of course.
<bairui> out of curiosity, what OS are you on? BSD?
<bairui> got that
<fullermd> bzr will preserve that in existing bzrdirs.  The tricky thing is new branches; they'll get set based on umask.
<fullermd> Yah.
<bairui> my current umask is g-w
<bairui> which sucks
<fullermd> As it probably should be.  And anyway, you couldn't make them g+s with umask anyway.
<bairui> oh
<bairui> i haven't even *tried* looking into solving this yet
<fullermd> So, any time a new branch is created (or a new repo, though that would be way less often), its perms will wind up wrong.
<bairui> correct
<bairui> so, bsd then... also in the curiosity realm... editor preference?
<fullermd> The cheap easy ugly solution is to brute force the living crap out of it, and setup a cron job to `chgrp -R ; chmod g+ws -R` on /mnt/repos/websites every {hour,day,whatever}.
<bairui> ah - I was thinking of a script to do the same - manually atm, cronned probably later
<bairui> i was wondering if a hook might work
<fullermd> Then anything new will be "correct" soon enough as to hopefully not matter.
<bairui> right - is that my *best* approach?
<fullermd> vi, of course.  Is there another choice somehow?
<bairui> it certainly is... easy
<bairui> vim
<fullermd> That falls under the rubric.  Shoot, I've even used elvis.
<bairui> as long as it has a v and an i in there somewhere, we're cool
<fullermd> It may be your best approach.  The other option is for people to do it manually (and that means logging into todd directly and doing stuff).
<bairui> nope
<fullermd> It's possible you could create a third option by hacking bzr on the server.
<bairui> nope
<bairui> ok - so, scripts it is
<bairui> good to know
<fullermd> Squirreling with the VFS stack to auto-force perms on the filesystem is another outstanding choice.  I kinda like it, personally.
<fullermd> It's a sorta-bug (call it a misfeature, maybe) that bzr won't propogate the repo's permission to newly created branches.  If that got fixed, it would take care of most of your situation.
<bairui> and there's no harm in   chmod -R g+ws   on a repo, eh? I mean, don't waste time cherry-picking dirs for that treatment - just smack the lot.
<fullermd> You'd still need manual intervention on creating new repos though, whenever you started a new project.
<bairui> i have a repo-making script that does that atm
<bairui> it's not remotely callable yet
<fullermd> Not as far as bzr is concerned, no.  So as long as it's the same group for everything, and everyone gets equal access to everything, should be OK.
<bairui> that is the case. cool.
<fullermd> Never try to be clever when brute force will solve them problem   :)
<fullermd> (and when it won't, redefine the problem!)
<bairui> heh - never underestimate the power of force
<bairui> we share quite a few aphorisms, fullermd. Chances are we have a common ancestor, at least academically :p
<bairui> well, thanks again, fullermd for your advice. That clears up quite a few todos on my bzr/server plate. yay. :)
<fullermd> I just think of it as "sharing good sense"   ;)
<bairui> fair
<bairui> i tend to do much the same on #vim
<bairui> what goes around comes around
<bairui> and as long as the pliers *never* come around, all's good
<fullermd> Oh, them coming around is fine, as long as they don't close first...
<bairui> closing after would be uncomfortable too...
<bairui> especially were they to encompass *bits* between arrival and said closing oO
<fullermd> Anyway, glad to be of help.  Now I have to go find a way to explain to people why their plans are impossible and their project is hopeless, without continual profanity...
<bairui> well, you just had some good warm-up training with me :)
<bairui> thanks again, mate. enjoy. later.
<fullermd> Though I'm not sure why I'm bothering.  I've been doing that to date, and the project still won't die.  Maybe I should stop censoring...
<bairui> start supporting it
<bairui> amazing how that kills a project, I've found ;)
<maxb> Hmm
<maxb> criss-cross merges are annoying
<maxb> And bzr doesn't seem to be being as smart as I'd have hoped about not generating conflicts
<maxb> Oh, no, I was wrong to blame bzr
 * jelmer waves to maxb
<maxb> jelmer: Your latest merge into ~bzr/bzr/daily-ppa seems to have gone rather wrong, and included text changes from bzr.dev, without recording their ancestry
<maxb> hence the conflicts
<jelmer> that's something that often happens during criss crosses
<jelmer> as there isn't an obvious common base
<maxb> uhm
<maxb> Why would bzr even be considering any text versions that happened in the future, with respect to all of the tips being merged?
<maxb> I'm inclined to just push --overwrite the daily-ppa branch with the Debian unstable-2.5 one
<jelmer> maxb: I'm not sure what you mean
<jelmer> maxb: +1 on overwriting with unstable-2.5
<maxb> The current daily-ppa branch contains text changes from bzr.dev r6038
<maxb> However, it does not include bzr.dev's r6038 in its ancestry
<vila> jelmer: lp:~jelmer/bzr/more-get-transport-from => 5878 lines ? You're overdoing it ;-p
<maxb> This seems rather WTF-worthy
<vila> jelmer: something went wrong with test_controldir.py, can you check ?
<mgz> looked like a line ending change to me.
<vila> mgz: I thought that at first, but unlikely from jelmer, instead a looks like including 2 copies of itself or something
<mgz> I nearly commented but was reading mail in a hurry and didn't have time to check if it was
<vila> s/a looks/it looks/
<vila> mgz: hello by the way :)
<jelmer> vila: looking
 * mgz waves
<jelmer> maxb: what lines are in daily-build from bzr.dev r6038?
<jelmer> maxb: r6038 was manually backported to lp:bzr/2.4
<vila> one should always merge up asap after backporting so *others* don't wtf'ed on further merges
<vila> just saying
<jelmer> vila: well, the debian packaging wasn't updated for bzr.dev until recently
<jelmer> so there wasn't much to merge up to
<maxb> ahhh
<maxb> right, I think I understand
<vila> jelmer: I was talking about upstream backport, packaging is a totally different beast (but merges not done upstream are likely to impact packaging too)
<maxb> So really the problem is that bzr doesn't track backports, so it's necessary to ensure backports get merged back up into their source branch ASAP to avoid surprises
<vila> maxb: exactly
<vila> maxb: err, sorry, we're talking about two different kind of backports, your point is similar to mine though
<jelmer> vila: I've updated the more-get-transport-from branch
<james_w> hello all
<jelmer> Hey James
 * maxb wonders which is the lesser evil - forking the bzr-daily recipe into three, or backporting python-meliae-dbg and python-configobj
#bzr 2011-08-21
<idnar> is it possible to use bzr missing on two remote branches? or does the one have to be local?
<AuroraBorealis> so, is bazaar supposed to freak out if it can't create a symlink on windows and just ...not branch a repo?
<AuroraBorealis> cause that seems like a very stupid reason to just abort and not be able to branch something
<wilx> What handling would you propose?
<AuroraBorealis> windows has ntfs junctions
<AuroraBorealis> or just...not check out symlinks or something
<AuroraBorealis> cause now i can't work on this code on windows.
<spiv> AuroraBorealis: yeah, it's not so good
<spiv> AuroraBorealis: patches would be welcome, there's a bug about it.  I think just omitting the symlinks as you say would be a big improvement over the status quo
<spiv> AuroraBorealis: (so long as doing commits in the wt wouldn't accidentally delete them, etc, which is what makes it a little bit fiddly)
<AuroraBorealis> while i know python, i know nothing of the bazaar code base, and it bothers me that this bug is nearing 5 years old :<
<AuroraBorealis> but i'm not opposed to giving it a shot i guess...
<spiv> AuroraBorealis: a good start might be suggesting a specific strategy on the mailing list and seeing if anyone can offer advice (or reasons why it might be a bad/difficult idea)
<AuroraBorealis> http://stackoverflow.com/questions/1967973/mercurial-symlinks-on-windows
<spiv> It's https://bugs.launchpad.net/bzr/+bug/81689, in case you didn't know that already
<ubot5> Ubuntu bug 81689 in Bazaar "Branches with symlinks can't be checked out on Windows" [High,Confirmed]
<AuroraBorealis> according to that, it says that hg just puts them as a file with the path
<AuroraBorealis> which is another solution..
<spiv> Yeah, that sounds reasonable to me.
<AuroraBorealis> but then won't it get commited and overwrite the sym link?
<spiv> Ideally perhaps we'd allow plugins to control how they are represented, but getting it working at all is more important.
<AuroraBorealis> i feel bazaar should just store the fact that it is a symlink or a ntfs junction, then convert it to wahtever the OS implements.
<AuroraBorealis> no idea if thats possible or not.
<spiv> In the most naÃ¯ve implementation, yes
<AuroraBorealis> why is that?
<spiv> But I think it'd be possible to arrange for the code to do something like "if platform == 'win32' and dirstate_kind == 'symlink' and disk_kind == 'file': pretend disk kind is symlink"
<AuroraBorealis> yeah
<spiv> Why?  Because 'bzr status' etc looks at what's on disk (with os.stat, basically) and reports 'file', 'directory', 'symlink'.
<AuroraBorealis> subversion does this: Details: the Subversion repository has no internal concept of a symlink. It stores a "versioned symlink" as an ordinary file with an 'svn:special' property attached. The svn client (on unix) sees the property and translates the file into a symlink in the working copy. Win32 has no symlinks, so a win32 client won't do any such translation: the object appears as a normal file.
<AuroraBorealis> and git doesn't have to since it has to be compiled against cygwin which supports symlinks
<spiv> Well, you can use bzr under cygwin too.
<AuroraBorealis> yes, but thats silly since its python
<AuroraBorealis> as far as i know, git can't be compiled natively for windows, but i might be wrong.
<AuroraBorealis> or at least i haven't seen it
<AuroraBorealis> and according to that bug report, they say that "adding os.symlink() and os.path.islink() support for windows" as been added, but only for python versions 3.2 and greater
<nigelb> I've used git in windows. I don't think I had cygwin.
<AuroraBorealis> since i keep seeing that you need admin privs to actually create a symlink (windows y u so bad??) unless you do something convulted, i feel that it should just create a file with the path inside of it for nw
<AuroraBorealis> so people can actually check out the repository...
<spiv> AuroraBorealis: yeah, I think waiting for bzr to support python 3.2 would be an unfortunate answer
<AuroraBorealis> well the python bug page says versions effected: 2.7
<spiv> Although it's nice to know it's a problem that will solve itself *eventually*, but still.
<AuroraBorealis> i have no idea how to tell where the fixed code actually got commited
<AuroraBorealis> versus what version
<spiv> And if it needs admin privs it's still a pretty bad workaround
<AuroraBorealis> well the thing is it doesn't need admin privs, its just by DEFAULT only the administrator has that priv
<spiv> (and suggests that the underlying semantics might not map so well to symlinks?)
<spiv> Anyway, time for a late dinner for me.
<AuroraBorealis> i guess i'll post to the mailing list i guess
<AuroraBorealis> i sent a message to the mailing list, although i don't know exactly how they work so i have no idea if i actually sent it or not o.o
<mgz> It arrived.
<AuroraBorealis> no idea why i haven't gotten the email though o.o
<mgz> thanks for sending that. it's one of several really frustrating platform specific bugs that haven't been addressed.
<AuroraBorealis> you are welcome.
<AuroraBorealis> it seems all of the version control systems have problems with this
<AuroraBorealis> cause the REAL problem is windows =P
<R33D3M33R> hello, i just installed qbzr and bzr-explorer and was hoping to receive a GUI management tool for bzr, but unfortunately, there are no binaries in bin/sbin ... so how does this work then?
<R33D3M33R> http://people.canonical.com/~jriddell/blog/qbzr.png
<jelmer> R33D3M33R: bzr explorer is a subcommand of bzr
<jelmer> R33D3M33R: running "bzr explorer" should work
<jelmer> brb
<R33D3M33R> oh...
<R33D3M33R> thanks
<R33D3M33R> it works :)
<ls3> hello... just wonder if there is a command to show the location that will be pushed to
<fullermd> bzr info
<ls3> if i just created a branch from trunk, will it push to the branch be default?
<ls3> just trying to confirm before i mess something up :)\
<fullermd> No, push is unset by default; it won't push anywhere.
<fullermd> You could use "bzr push :parent" to push to the parent location (and set is as the default for future pushes, if there isn't already one)
<ls3> ahh ok
<ls3> fullermd, thanks..much appreciated
<ls3> time to go experiment on a test repo..
 * maxb crosses fingers and hopes for some successful bzr builds in the daily ppa now
<maxb> argh, except bzr-svn is now a new failure because it declares a requirement on bzr << 2.5
<Daviey> maxb: it's a genuine depends.. jelmer is aware.
<maxb> ah
<maxb> keeping the bzr daily ppa green sometimes feels a bit sisyphean
<jelmer> hah, there is my dictionary word of the day
<jelmer> ah, sisyfusarbeid..
 * maxb wonders where the gtk.gdk module has gone in oneiric
 * jelmer wonders what the status of the gtk3 port is
<maxb> The current bzr-builddeb failures are because URL-encoded filenames are leaking through to local fs access
<jelmer> I figured it was something like that, but I didn't have time to look into it yet.
<jelmer> hey Noldorin
<maxb> There really is a huge variance in the speed at which different PPA buildds can get through the bzr testsuite
 * maxb is waiting on some slow ones :-(
<jelmer> hmm, the next bzr-svn release is going to fix 50 of the almost 100 open bugs
<jelmer> I guess I should've done a release earlier...
<dOxxx> howdy...
<dOxxx> vila: I'm having trouble with bzrlib config's automatic quoting
<mgz> he's likely not around till tomorrow, you'll probably have more luck on the mailing list
<dOxxx> thanks
<maxb> Argh
<maxb> alioth anonymous http is presenting an older version of users/jelmer/dulwich/unstable than alioth ssh
<lifeless> win
<lifeless> how much older ?
<jelmer> maxb: perhaps something that broken during the server migration?
<maxb> likely
<maxb> In fact, I dimly recall something about personal branches not being fixed
<maxb> Also, they seem to have done something silly with their URLs, as http://bzr.debian.org/bzr/users/jelmer/dulwich/unstable/ is permanently redirected to http+urllib://anonscm.debian.org/bzr/bzr/users/jelmer/dulwich/unstable/
<maxb> Or just for fun, http://anonscm.debian.org/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/bzr/users/jelmer/dulwich/unstable/ gets you the same branch :-)
<lifeless> maxb: ><
<jelmer> maxb: Yeah, there was some talk about that on debian-devel@
#bzr 2012-08-13
<mgz> morning!
<jml> hello,
<jml> could we please get a review on https://code.launchpad.net/~james-w/udd/binary-scanning-series/+merge/119248
<jml> would still really appreciate that review.
<fayaz> how do i set up pqm?
#bzr 2012-08-14
<mgz> morning all!
<nabz> hi
<Lasall> hi http://wiki.bazaar.canonical.com/BzrPlugins <- the rebase plugin link is dead
<nabz> noob question: i'm missing some revision in my local repo, bzr tells me I can reconcile the branches using merge... but merge don't allow me to do it because of changes made in my repo
<nabz> what's the good way to solve this ?
<AfC> nabz: commit your local changes first, then merge, then continue
<nabz> AfC: the problem is that when i try to merge my local changes, bzr adds all the file in missing revisions
<nabz> AfC: *to commit my local changes, sorry
<AfC> um
<AfC> I'm not sure what you did. You could always `bzr revert` those adds
<AfC> nabz: bzr is absolutely doing the right thing. The problem is you've asked it to do something in a strange order
<AfC> nabz: I'd go back to figuring out how you got "missing revisions" and then not do that again
<AfC> But in general, if you're doing an operation that results in things you don't want, bzr revert those changes.
<AfC> then commit
<nabz> don't revert erases all the changes in the local repo ?
<AfC> for the listed files, yes
<AfC> you just said you didn't want the changes
<AfC> whatever
<AfC> Sorry, some one else is going to have to help you. I'm not sure how you've boxed yourself into this corner. You're doing something strange. Did you do `uncommit` perhaps? Or a pull --overwrite maybe?
<AfC> Regardless
<nabz> i don't want the changes coming from the trunk, but i want to keep what i've changed so i can commit them
<nabz> don't know
<nabz> i think i'll make another clean branch and set my changes in it...
<nabz> thanks for you help
#bzr 2012-08-15
<jlf> hi #bzr, i'm trying to populate a local emacs repo as described at https://savannah.gnu.org/bzr/?group=emacs -- after rsyncing from the savannah repo, doing `bzr checkout' in the branch directory results in `bzr: ERROR: A control directory already exists: "file:///Users/jlf/emacs-bzr/trunk/".'.  does anyone have insight?
<lifeless> you may want --lightweight ?
<lifeless> I think thats special cased.
<jlf> same result -- [jlf@bix] ~/emacs-bzr/trunk [1428]$ bzr checkout --lightweight -> bzr: ERROR: A control directory already exists: "file:///Users/jlf/emacs-bzr/trunk/".
<AfC> I just had someone tell me Bazaar isn't a proper distributed version control system.
<AfC> {sigh}
<AfC> Not that I'm usually inclined to argue in comment streams, but where do you even start replying to something like https://plus.google.com/113426423446646532879/posts/eAfWc7q6Zgu
<spiv> AfC: I see what you mean.
<spiv> I'm not sure an argument would be productive there either, but you can go at least one more round under Charles' Rules of Argument if you really want ;)
<bob2> after using hg for 3 months, oh man :(
<bob2> holy confused model batman
<spm> AfC: http://xkcd.com/386/ lol, and walk away. not even worth the pain of trying to correct that.
<lifeless> wow, they don't understand what distributed means do they
<AfC> spm: yeah, but this was an otherwise smart guy. I'm getting annoyed to see him harshing on bzr so much
<spm> heh
<AfC> spm: this is like the third or fourth post.
<AfC> spm: I figure it's time people pointed out to him he's a bit off-base
<AfC> spm: guy's an experienced GTK hacker, and admittedly they were some of the first git adopters, but, still
<spm> masking his true irritation(s) with bzr via these messages perhaps? - in that, it's fine to dislike, even for irrational reasons.
<AfC> I guess. But the "I hate branches because they're not real branches" thing shows the usual impedance mismatch
<spm> heh, yes.
<AfC> (which has been going on ever since Bazaar used the word "repository" to mean something other than what everyone else thought it meant)
<spm> I'd blame lifeless for doing that, myself. rightly or not. it's always his fault.
<AfC> spm: oh, I did, don't you worry
<spm> haha
<lifeless> AfC: what does everyone else think it should mean?
<mgz> morning
<AfC> lifeless: it *does* mean "central repository" for everyone else. We talked about this at code con many years ago.
<AfC> He's at it again https://plus.google.com/113426423446646532879/posts/1BP8YtuiUjC
<gmarkall> AfC: I just get a "post not found" message
<AfC> gmarkall: hm, maybe you need to be in his extended circles. I'll follow you on g+
<gmarkall> I was curious to see what he's saying, but got the same with your earlier link and assumed it had been deleted
<AfC> gmarkall: what's your g+ page?
<gmarkall> AfC: thanks - its https://plus.google.com/u/0/103909627907661974392/posts (i think)
<AfC> That git has become the dominant system, fine; that bzr has various corner cases that it breaks down, fine. But constantly bagging it for fun makes me angry
<AfC> gmarkall: [curious if you can see it now, or whether you have to circle me back]
<gmarkall> AfC: I can't see it yet, and I can't see your page because you only recently circled me, I think - which page is yours?
<mgz> sometimes people just want to gripe, not get solutions :)
<AfC> gmarkall: https://plus.google.com/u/0/104216419012637157644/posts maybe?
<AfC> mgz: yeah, but this sort of thing shouldn't be unchallenged. If we won't stand up for bzr, we might as well pack it in
<mgz> (that post worked for me once I'd logged in, as I seem to have someone who has AfC who has the guy circled)
<AfC> mgz: you won't win *him* over, but there are LOTS of people who will be reading his posts, and they should benefit from someone sticking up for Bazaar.
<mgz> I do agree, but it also becomes feeding the troll at a certain point...
<AfC> mgz: well, as it stands now, Bazaar is a "serious junk tool". Hope that's ok with everyone.
<gmarkall> still can't seem to see it... ah well
<AfC> What amazes me is pondering what on earth Matthias could have done to get himself backed into such a corner.
<lifeless> AfC: so this guy is an ass apparently ?
<AfC> I mean, sure, if you're hacking on emacs, there are a few things you need to be wary of, but for 98% of projects, Bazaar just works.
<AfC> lifeless: he didn't used to be :(
<AfC> lifeless: sorry
<lifeless> AfC: his reply to me is /nearly/ an ad-hominen
<AfC> yeah
<AfC> I'm going to have a word with his boss
<mgz> I await the followup g+ post where he says 'whoops, sorry everyone, I tyoped the branch name' or something
<AfC> mgz: heh
<AfC> mgz: if he'd tell us what actual branch he was aiming at, we could see the history, and pretty rapidly get a sense of what class of roadblock he's run afoul of.
<AfC> mgz: but you're right, clearly he doesn't want any help
<lifeless> its probably private
<AfC> lifeless: point
<AfC> Usually it's something like monster binary files committed or not using a shared repository at .. or (as you said) not committing merges or reverting after uncommit or...
<lifeless> ah, someone had a word with him.
<lifeless> not quite sure he understands, but has toned down.
<tbf> sorry if i already asked and forgot again, but how do tell "bzr shelve" to show the magic "e" option for splitting chunks?
<tbf> (using bzr 2.5.1)
<tbf> ok: https://bugs.launchpad.net/bzr/+bug/708716
<ubot5> Ubuntu bug 708716 in Bazaar "config change_editor is undiscoverable" [Low,Confirmed]
<tbf> now only need to figure out what "config change_editor" is
<tbf> ok. just "vim" doesn't seem to be a good setting
<mgz> tbf: I have "change_editor = vimdiff -of @new_path @old_path"
<tbf> mgz, thank you. let's see if that works for me
<tbf> hmm. also different from "git add -p" or "git commit -i".
<tbf> well. guess i'll just resurrect my old svn habit, something like: bzr diff > patch; bzr revert; vim patch
<mgz> right, but you can stick other things in there instead, I'm not sure what's closest to just editing the diff directly
<Lelak> Hi!
<Lelak> Is there someone who could help with a smart server problem?
<Lelak> I already asked on https://answers.launchpad.net/bzr/+question/205362 but no answers till now.
<Lelak> Actually I know the cause, but I donÂ´t know how to resolve
<Lelak> =(
<Lelak> is anyone there?
<mgz> Lelak: there's no simple answer, basically you need to not commit large binary files
<mgz> the problem you'll have is that was done a while back, which now makes normal commits break
<Lelak> mgz: thank you very mutch for your interaction!
<Lelak> :)
<Lelak> much
<mgz> so, one way forwards is to create a new shared repo (without trees), branch all non-borked branches using the repo into it, and then branch the last good rev of the borked branch
<mgz> then replay the newer changes sans giant binary files
<Lelak> mgz: if I understood well, I will need to create a new shared repo and rebranch all 'good' branches from theold repo?
<Lelak> I was trying to tweak the .bzr/reposity folder (15GB) to make it smaller
<Lelak> do you think this is a good Ideas and less work?
<mgz> poking around inside .bzr/repostory isn't safe, and won't fix your OOM issue
<mgz> you need to excise the revisions that included big binary files, but not damage history you care about
<mgz> the easiest way to do that is by starting from a new shared repo
<Lelak> thanks mgz. I see. Do you know a way to find on wich branches are located this big binary files?
<Lelak> so I can exclude them on the new repo?
<mgz> hm...
<jlf> good morning #bzr, is it possible to generate changelog entries for as-yet-uncommitted changes?  i see that `bzr log' has a --gnu-changelog option, but `bzr status' does not.
<mgz> I'm not sure we have a tool that makes it easy, but basically anything that if you try to branch to a temporary location makes a giant repo. really you want the specific rev too so you can rewrite it
<mgz> jlf: uncommit! :)
<Lelak> ok. I was taking a look on the .bzr/repository/uploads folder (12GB) and there are packs with regular sizes some with 1gb.
<jlf> mgz: will that entirely remove the temporary commit from the history or just apply a second commit that undoes the first?
<mgz> it removes it from the branch, but keeps it in the repo in case you want to un-uncommit
<mgz> Lelak: the issue is the packs are not segmented by branch, so some bzrlib scripting is needed to work out what changes are stored in which packs
<Lelak> understood.
<jlf> mgz: i see, thank you
<Lelak> mgz: so will start to create a new repository. I have now about a 100 branches. Do you recommend any proceedure to make the migration to the new repo easyear?
<Lelak> easier
<mgz> hm, that probably does want scripting
<Lelak> mgz: please, can you indicate to me any documentation where I can start understanding how bazaar scritpting works?
<mgz> Lelak: I suggest you start by just doing a couple of branches manually
<mgz> and I'll try and see if we've got some existing code that finds bloated branches/revisions
<Lelak> thank you mgz!
<Lelak> I will be back in 1hour.
<quotemstr> bzr branch from a git repository (using git+ssh) is very slow. Is there any way to speed it up?
<bob2> clone with git then clone with bzr?
<quotemstr> bob2: It's CPU-bound, not network bound.
<bob2> i'd still be surprised if git wasn't faster but ok
<jelmer> bob2: cloning locally first basically has the same effect; either way you end up receiving a git pack first, storing that on local disk and then processing it
#bzr 2012-08-16
<quotemstr> Dammit, why does bzr fast-export -r date:2012-01-01-revno:-1 onlyexport one revision?
<quotemstr> Oh. ...
<jimis> bzr log -l N -rbranch:../repo/branch
<jimis> no matter how big N is I always get only last log message
<jimis> should I report a bug?
<fullermd> Isn't that exactly what you'd expect?
<fullermd> (well, I mean, obviously not, or you wouldn't bring it up.  But it's what _I_'d expect  :)
<fullermd> I'd always expect `bzr log -r X` to show exactly one thing; the log message for whatever revision 'X' evaluates to.
<fullermd> And for X == 'branch:/where/ever', that would be the head rev of the branch at /where/ever.
<jimis> fullermd: oh, and how to get the log from another branch?
<jimis> I 'm used to using -rbranch for that
<jimis> (for everything else besides log that is)
<fullermd> Mmm, it's probably not meaning exactly what you think it's meaning on those cases either.  But anyway.
<fullermd> Log takes a path, so just `bzr log /where/ever` would be what you'd want.
<jimis> fullermd: perfect! thanks :-)
<mgz> morning
<TJ-> Using bzr 2.5.1 on Ubuntu 12.0 amd64. Branched an Ubuntu project (bzr branch lp:ubuntu/precise-updates/gnome-control-center), wrote a patch, push it to my own LP account (bzr push lp:~tj/gnome-control-center/fix-979959).. The entire local repo is being pushed, but I thought - when branching from LP - my push should only contain my diff (assumed the LP server clones the original branch locally). Am I misunderstanding 'push' in this scenario?
<TJ-> *Ubuntu 12.04
<mgz> TJ-: if you're basing off the ubuntu branch, you need to push to that project, not the base one
<TJ-> mgz: Ahhhh OK! I somehow had got the impression even for a clone it'd do a lightweight branch on the server to save bandwidth and storage.
<mgz> so, lp:~tj/ubuntu/precise-updates/gnome-control-center/fix-979959
<mgz> otherwise you stack on the wrong thing, which means you push all the ubuntu related revs along with your change
<TJ-> mgz: Unfortunately using the same path to push to my own account fails. I'll just have to live with pushing the entire repo I guess.
<mgz> TJ-: did you try the location I just gave? if so, can you paste the error in here?
<TJ-> mgz: bzr: ERROR: Permission denied: "~tj/ubuntu/precise-updates/gnome-control-center/fix-979959/": : No such distribution series: 'precise-updates'.
<TJ-> mgz: I also tried it with "precise" and without "ubuntu" and so on
<mgz> TJ-: try just precise rather than with -updates
<mgz> darn.
<TJ-> mgz: hold that!...
<mgz> I think precise should work, I'm not sure how they arrange the updates bits generally.
<TJ-> mgz: that appears to be working... but it is still sucking out all the bandwidth.. says "Fetching revisions" would that be expected?
<TJ-> mgz: I need to check my bash history I must have typoed when I tried just "precise" earlier :O
<mgz> ideally not, but there may still be a large delta
<TJ-> mgz: OK *blush* here's why it failed earlier: "bzr push lp:~tj/precise/gnome-control-center"
<mgz> :)
<TJ-> mgz: by 'delta' you mean my changes versus the origin? One 60 line diff.
<mgz> but we're basing it on the precise branch, there may also be other changes in precise-updates
<TJ-> mgz: OK, that was why I asked the question, so the delta is precise > precise-updates -> my patch
<TJ-> mgz: thank-you so much. I'm a hardcore git user and bazaar still confuses me especially with the launchpad integrations
<quotemstr> Why does "bzr branches" come up with "* (default)"?
<mgz> because you're on a branch without colocated branches underneath I guess
<mgz> what do you expect it to print?
<quotemstr> git-bzr uses bzr branches to get a list of branches.
<quotemstr> When it feeds '*' to the shell, Bad Things happen.
<mgz> * denotes active in `git branch` output no?
<quotemstr> Did the format change recently?
<mgz> probably with the colocated things for 2.5, or perhaps in a more recent 2.6 change
<quotemstr> Are you guys planning on fixing https://bugs.launchpad.net/bzr/+bug/541626 ?
<ubot5> Ubuntu bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Confirmed]
<Noldorin> back
#bzr 2012-08-17
<quotemstr> Say I have a loom. What's the best way of merging the loom into the parent branch while erasing all the history, making each thread in the loom a single commit?
<quotemstr> I could just generate patches and apply them manually.
<mgz> morning
<quotemstr> Why would anyone want to use loom instead of pipeline?
<thumper> looms came first...
<quotemstr> Neither allows you to associate a thread/pipe/patch with a message, though.
<quotemstr> Is it possible to convert a branch to an init-repo branch without cloning all over again?
<mgz> quotemstr: depending on what you mean by that, yes, see `bzr help reconfigure`
 * thumper wants a command to turn a stand-alone branch into a shared repo and move the branch to a named directory
<thumper> don't suppose that exists yet?
<quotemstr> Ah, I see.
<quotemstr> What's the difference between bzr branch in a shared repository, then, and bzr checkout?
<mgz> read http://doc.bazaar.canonical.com/latest/en/user-guide/core_concepts.html
<mgz> thumper: it's not hard to do that, just in a couple of steps
<mgz> `mv branch name; bzr init-repo branch; mv name branch/name; bzr reconfigure --use-shared branch/name`
<thumper> mgz: similar to what I do now :)
<thumper> mgz: I was hoping for one command :)
<mgz> feel free to submit one for merging :)
<mgz> you'd need to be a bit careful over checking that the location really is just a plain branch, moving repos around is one of the easier ways to lost revision history
<quotemstr> Okay, so I had two branches in a shared repo, trunk and test.
<jml> any lp:udd devs around?
<quotemstr> I deleted test with rm -rf, and now most bzr operations complain that the directory that used to contain test is no longer a branch.
<quotemstr> But test was a branch of trunk. Why should trunk know about test or care that test's been deleted?
<quotemstr> Huh. trunk is now a checkout of test? When did that happen?
<mgz> jml: who are those mysterious creatures?
<mgz> quotemstr: check back through your .bzr.log to see if you like
<jml> mgz: anyone who can tell me how to land https://code.launchpad.net/~james-w/udd/binary-scanning-series/+merge/119248
<mgz> jml: it's changed recently, poke vila
<mgz> (if by merge you also mean deploy, otherwise it's just push to the branch, no?)
<quotemstr> mgz: Ah, I didn't know about that file. Thanks.
<jml> mgz: so there's no gatekeeper ala pqm?
<mgz> jml: nope, just merge locally, run tests (hah) and push
<mgz> really needs to be deployed at the same time though, otherwise the skew from what's actually being used vs trunk becomes painful
<mgz> and because the test aren't great, so breaking sooner while people still remember the mp is best.
<mgz> quotemstr: you know how to change trunk back to a normal branch, right?
<jml> mgz: I'm sorry, but I don't think I can take responsibility for that.
<mgz> jml: I see vila did update README_DEPLOYMENT after doing the quantal chroot stuff
<mgz> jml: well, I'm not really sure who should. I can do it, but if things blow up you and james will still be the ones we coming crying to.
<jml> mgz: that's fine by me.
<mgz> okay. want me to merge and push to, or have you done that?
<quotemstr> mgz: Too late. I just puled again.
<quotemstr> mgz: pulled, even.
<quotemstr> Is it possible to tell bzr to use hard links _by default_? Some commands that branch internally don't provide a top-level hardlink option.
<mgz> quotemstr: that works fine too, shared repo so apart from constructing tree again doesn't really hurt
<mgz> hardlinks aren't a win when using a shared repo.
<jml> mgz: I'm still trying to figure out how to run the tests.
<jml> mgz: lot of dependencies, no obvious list of them or means of acquiring them.
<quotemstr> mgz:For me they are. A branch with hard links takes 4.4 seconds. A branch without hard links in a shared repo takes 10.4 seconds.
<mgz> jml: that is a good point
<jml> mgz: 'ImportError: cannot import name LAUNCHPAD_API_URLS'
<jml>     from bzrlib.plugins.launchpad.lp_api import LAUNCHPAD_API_URLS
<jml> mystery meat bzr.
<mgz> heh, that's a recent change on trunk, aaron updated the launchpad plugin to expect a newer launchpadlib version
<mgz> and apparently udd is getting vars from launchpadlib via the bzr plugin...
<jml> \o/
<mgz> ah, it does have a comment so is for (semi) sensible reasons (launchpadlib had the api stability of a not very stable thing), wants updating though
<jml> mgz: cool. you right to do that?
<mgz> yeah, I'll take that one.
<jml> mgz: thank you
<mgz> ...is there any reason to support any older launchpadlib anyway? we control the versions...
<vila> jml: apart from lp, james_w introduced other tests dependencies which I don't remember from the top of my head and that are not installed (nor easy to install on jubany), caveat emptor
<vila> jml: i.e. test cannot be run on jubany
<jml> vila: what makes them hard to install on jubany?
<mgz> have 1.9.12 on jubany, will making 1.6 the minimum break anything for you jml?
<jml> mgz: pretty sure not.
 * jml checks
<jml> launchpadlib = 1.10.2
<jml> we're laughing.
<vila> jml: usual china wall
<jml> vila: oh. hmm.
<jml> vila: what are your thoughts on buildout?
<vila> jml: no first hand experience, almost only bad reports though :-/
<jml> vila: heh.
<jml> vila: my thesis is that Python packaging is terrible in pretty much every way.
<jml> vila: so it's simply a matter of choosing your means of execution.
<jelmer> jml: debian packaging of python stuff, or the wide range of packging available for python?
<vila> jml: oh, also, I'm now part of jfunk's team (since monday)
<jml> jelmer: deploying Python services with dependencies
<vila> jml: regarding test deps, the consensus was that the bzr-package-importer package should add them as build deps
<jelmer> jml: ah, ack on that
<jml> jelmer: so, every available option, including Debian packaging
<jml> which is great until you want to have more than one service on a machine, or want to be able to update a dependency without a week-long lead time.
<jml> vila: is lp:udd deployed as a package on jubany?
<vila> nope, as a branch
<jml> vila: what's the bzr-package-importer package used for?
<vila> track the other dependencies :)
<vila> lp:udd is not packaged to the best of my knowledge
<vila> I needed *something* to keep track of the deps and install test setups
<jml> vila: so b-p-i is installed on jubany?
<jml> vila: or is it just for dev envs?
<vila> jml: installed in the quantal chroot, I don't think it's installed on jubany (precise) itself
<jml> vila: and the actual service runs from the chroot?
<vila> jml: all jobs running in the chroot are started from the crontab (see lp:udd), that lefts the apache web server running on precise
<vila> and the tmp reapers
<jml> vila: thanks
<jml> vila: so, will you no longer be maintaining lp:udd once you move to jfunk's team?
<vila> and that's not that bad to be able to say that in 3 IRC msgs ;) Far from an automated deployment, but...
<vila> jml: yes, I moved last Monday
<jml> vila: yeah, definite improvement in deployment :)
<jml> vila: I asked that question with a negative, so your answer confused me :)
 * jml tries the positive construction
<vila> argh :)
<jml> vila: Are you still maintaining lp:udd?
<vila> jml: no
<jml> check.
<jml> vila: who is?
<vila> jml: lp  maintenance team
<jml> vila: thanks.
 * vila wonders if he should have answered 'no' to the negative...
<vila> Do you still beat your wife ?
<mgz> yes!
<vila> ha ! Said the single ! :)
<jml> vila: at chess? quite comprehensively
<vila> hehe
<jml> "Have you stopped beating your wife?" is the traditional formulation.
<vila> ha right
<jml> Hmm. I guess lifeless is the person to talk to re longer term udd maintenance plans then.
<vila> jml: jam has a kanban card about moving jubany to wepobs
<jml> vila: ah cool. I might approach him, since we have quite a lot of friction with our udd deployment that's currently maintained by them.
<vila> jml: hopefully I addressed a lot of the pre-requisites, apart may be pushing my b-i-p branch but the history there is pretty boring anyway ;)
<jml> vila: yeah. the main issues are that packages are a really error-prone way of managing dependencies. (there's a long lag with updates, it's difficult to get the exact versions used on prod, upgrades bypass the regular automated testing process, if your machine is shared then things can randomly break because someone else upgraded a version, etc.)
<jml> vila: and that lp:udd (well, our deployment especially), doesn't give a whole heap of visibility as to what it's doing through the web
<jml> which doesn't matter so much when you've got shell access
<vila> "really error-prone way", not sure, in the lp:udd case, the only strictly required branch is lp:udd, everything else can use the quantal packages (see my last mail in the udd ML)
<jml> today
<vila> jml: on jubany, installing from sources wasn't an option for xz-utils for example as this isn't a dev machines and the dev packages are not installed...
<vila> jml: but yeah, lack of visibility is an issue as is the need to issue commands on jubany
<vila> to fix imports
<vila> deploying new versions is another story
<jml> vila: we still use packages for non-Python dependencies.
<vila> for lp:udd ?
<jml> no, for pkgme-service, txpkgme and libdep-service
<vila> ha
<jml> we're in the middle of migrating to buildout.
<vila> oh
<vila> why not juju ?
<jml> we don't like it very much, but we like everything else less
<jml> vila: why juju?
<vila> way of the future ? Allows a single story for dev/test/prod ?
<jml> vila: That would only solve the 'many services, one machine' issue if IS were willing to have one archive per service. It would still mean that developers would have to use different packages to the ones in production, since people aren't given general access to the 'cat' archives.
<vila> jml: I found a way: chroot with a dedicated PPA ;)
<jml> vila: and it wouldn't address the multi-day -- sometimes multi-week -- lag that we get when updating package dependencies.
<jml> vila: not allowed to deploy from PPAs in production.
<vila> jml: allowed in the jubany chroot
<vila> jml: don't get me wrong, I'm not arguing *against* you,
<vila> but either juju is the preferred way and each service runs in its own isolated machine where a PPA is allowed or it's far less interesting
<jml> vila: I still see juju as very interesting, even when using something like buildout or virtualenv for dependency management
<vila> right, my point is more about: if it's isolated devs should be able to deploy specific packages
<vila> and get rid of the delays
<vila> it's a bit ironic to run end-to-end tests and then wait for deployment...
<vila> may be ironic is not the right word...
<jml> vila: quite possibly.
<jml> vila: "silly"? "pointless"? :P
<vila> and having isolated machines (1 service by machine) addresses the issues of package compatibility
<mgz> okay, stopped fiddling and did that udd/launchpadlib change: <https://code.launchpad.net/~gz/udd/require_launchpadlib_1.9.0/+merge/120132>
<jml> mgz: LGTM
<vila> of course devs are supposed to submit their patches upstream or to ubuntu and converge as fast as possible to the standard packages (which is what I had in mind with the pristine-tar issue)
<jml> vila: I always find such patches more convincing when they have been deployed and been known to work :)
<vila> jml: isn't it ?
<vila> That's one more reason to allow devs to deploy them to demonstrate their patch is working no ?
<jml> yes.
 * vila feels better :)
<vila> lunch break
<jml> :)
<jave> hello
<jave> I have a bzr project where files mysteriously seems to have vanished
<jave> how can I figure out what happened?
<jave> heres the project: http://bzr.savannah.gnu.org/lh/emacs/xwidget/files/head:/leim/quail/
<jave> and a missing file is latin-post.el
<mgz> jave: looks like it exists in the branch <http://bzr.savannah.gnu.org/lh/emacs/xwidget/annotate/head:/leim/quail/latin-post.el>
<mgz> do you mean your local branch doesn't have the file?
<mgz> try looking in your .bzr.log (see `bzr version` for the location) for 'latin-post.el' to see what's happened to it recently
<jave> mgz: yes, it doesnt exist in my local copy
<mgz> so, `bzr status` should tell you the current state vs the last committed revision, but the .bzr.log output may be more useful (if it was bzr that touched the file rather than say, a mistake in the make clean or something)
<jave> I get:
<jave> [11406] 2012-08-17 00:01:14.716 INFO: missing leim/quail/latin-post.el
<jave> [11406] 2012-08-17 00:01:14.717 INFO: deleted leim/quail/latin-post.el
<jave>  
<mgz> and that's under a 'commit' command?
<jave> [11406] 2012-08-17 00:01:14.607 INFO: Committing to: /home/joakim/current/build_myprojs/emacsnew/allbranch/my-working-copy/xwidget-bigmerge2/
<jave> 0.182  Selecting files for commit with filter None
<jave>  
<jave> If I understand the log format at all
<mgz> right
<mgz> so, something (not bzr) removed the file, then you committed the change without noticing
<jave> okay
<jave> hmm
<jave> how can I get out of this mess?
<mgz> can fix by bringing the file back and committing
<jave> should I just checkout again from my upstream?
<mgz> or if it's a change you haven't pushed anywhere and don't care about, just uncommitting
<jave> recently ive only merged from upstream trunk
<jave> anh probably not pushed to the public branch
<jave> the files arent touched by build command afaics, so something more serious must have happened like a disk failure during copy or something. so, ill probably just checkout from the savannah branch and discard this broken branch
<jave> anyway, thanks.
<mgz> jave: so, the simple fix is `bzr revert -rbranch::parent leim/quail/latin-post.el && bzr commit -m "Restore accidentially deleted latin-post.el file"`
<mgz> which is always safe
<mgz> but if you're not sure whether you might have other broken changes, and don't have any important changes you've not pushed back yet, then just restoring the branch to the trunk state is fine too
<jave> mgz: theres a large number of files mising
<jave> so I would like to revert to a known sane state
<mgz> right, that does sound like the best option
<jave> and just hand pick any relevant local changes
<mgz> you can cherrypick merge from your broken branch to a fresh one
<jave> yes
<mgz> hm... qt4-x11 was the last thing out of the queue and it's in again... thought the issues over pending packages were fixed
#bzr 2012-08-18
<ScottK> I have a local bzr branch that has a number of files and directories in it.  I would like to export a single file (which has been renamed, if it matters) with the history of just that file into a new bzr repository.  Is that possible/how do I do it?
<bob2> split, I guess
<bob2> or bzr-rewrite
<bob2> (or not bother, and just put the file in a new repo)
<fullermd> split is just a shortcut to rm'ing everything else and committing.
<fullermd> You can't move just one file's history, because there isn't any such thing.  Files don't have history; history has files.
<fullermd> With something like rewrite, you could in concept create a new history with just that one file in it that looks a lot like the existing one; whether the tool makes that practical, I have no idea.
<ScottK> OK, put it differently, can I rewrite the history to remove everything else?
<ScottK> Keeping the history is important because bzr blame has saved my behind more than once already.
<fullermd> Yeah, that's what you'd have to do; create a new history that looks pretty much like the existing history of the file.
<fullermd> Sorta a (foreach `bzr log $FILE`; set contents ; commit with same log/committer/date) process.
<fullermd> Which is conceptually in rewrite's domain.  Whether such a thing is actually implemented there, I don't know.
<mnn> hi... it seems that there's a bug in bzr log
<mnn> I merged stable branch into trunk, and the tag on the last revision in stable branch is not shown in bzr log -r <rev_with_merge> -n0
<mnn> however when I want to add it in Bazaar Explorer, it says that the tag already exists and asks me if I want to move it
<mnn> * I run bzr log -r <rev_with_merge> -n0 in trunk of course
<mnn> oh no... I wasn't able to reproduce it on new branch :(
<mnn> does anybody know what could cause this behaviour?
#bzr 2012-08-19
<nigelb> Anyone know what's the cause/possible fix for http://hastebin.com/wiyimolabi.vhdl
<lifeless> nigelb: bzr launchpad-log
<lifeless> bah
<lifeless> launchpad-login
#bzr 2013-08-12
<vexo> ll
<Andy80> hi guys
<Andy80> do you know if it's possible to trigger a jenkins build with a "bzr push" ? I've read that is possible with git and found some tutorials, but I don't understand if it's supported also with bzr
<Andy80> I've found this http://wiki.bazaar.canonical.com/BzrHooks
<Andy80> but I don't understand if it's already available or if it's a feature request
<jelmer> Andy80: bzr hooks are available
<Andy80> jelmer, yes, but I was just reading the docs here http://doc.bazaar.canonical.com/development/en/user-reference/hooks-help.html in the "post_push" section it says "post_push is called with a bzrlib.branch.BranchPushResult object and only runs in the bzr client". There is no way to implement the hook on server instead of each client?
<jelmer> Andy80: no, because the server might be a dumb server (e.g. sftp)
<Andy80> jelmer, well... that's not a good reason imho. I mean... I could understand if this feature was missin on a "dumb server", but on a normal one it whould exist...
<jelmer> Andy80: there is something that gets run on the server side in a smart server, though I'm not sure of the details there.
<LarstiQ> Andy80: post_change_branch_tip is perhaps more suited to your purpose
<Andy80> LarstiQ, let me give a look..
<spundun> hi all, is there a bzr equivalent of git notes? http://git-scm.com/2010/08/25/notes.html
<cyberkilla> <3
#bzr 2013-08-13
<justdave> are there any tools other than loggerhead for viewing/searching contents of a bzr repo?
<justdave> trying to ween our remaining users off of cvs and I have a couple still refusing to go because loggerhead doesn't do everything that bonsai does
<justdave> wondering if there's anything fancier than loggerhead out there
<jelmer> hi justdave
<jelmer> justdave: There isn't anything fancier than loggerhead out there for Bazaar as far as I'm aware.
<beuno> well
<beuno> loggerhead is a web viewer
<beuno> the local viewers are much fancier
<beuno> qbzr and bzr-gtk
<beuno> right?
<justdave> passed those along, I'll see how convincing it is. :)
<justdave> makes sense since you have a local copy of the repo when you branch
<Jayden> Hi.  After a bzr checkout of a head, I drop back to a specific revision with `bzr revert -r###`, which I think is correct.  I notice that `bzr log` on the "reverted" tree STILL gives me log entries from ALL/newer revisions.  This is different than git, so suche wan't to ask -- is it expected for bzr?
#bzr 2013-08-14
<MeaCulpa> How can I bzr add a file deep in a directory while leaving that whole dir tree not versioned?
<bob2> well, you'd obviously have to version the dirs, but you don't have to add everything in them
<MeaCulpa> bob2: I haven't control of the ext file name pattern, say there are 100 different kinds of files, I only want 1 file under control
<MeaCulpa> I don't want to regex match all the other files, I want no bzrignore involvement
<bob2> ?
<bob2> bzr add -N who/cares/blah.txt
<bob2> bzr add --dry-run -N who/cares/blah.txt
<MeaCulpa> no, this will still add the dir, who
<bob2> of course
<MeaCulpa> and all it's files
<bob2> it won't add all the things in who/, though
<bob2> doesn't for me
<MeaCulpa> hmm oh, I got it
<MeaCulpa> after I add this I ran bzr stat, and I didn't noticed that it listed all the IGNORED file :)
<MeaCulpa> bob2: Thank you
<tigrang> whats the equivalent of git reset --hard HEAD~1
<vila> tigrang: I don't know git ;) But that's probably 'bzr revert'
<tigrang> vila: when I do that and look at bzr log, there's still the latest commit, is that normal, how do I know which revision I'm currently on
<vila> bzr revno
<vila> bzr revert brings you back to the latest committed revision indeed, if you want a different one, use 'bzr revert -r<rev spec>'
<fullermd> Mmm.  reset screws with the branch.  --hard makes it screw with the WT files and meta.
<fullermd> So the equivalent would probably be more like a pull --overwrite.
<fullermd> --soft is more closely related to uncommit.  The rest of the --options get more esoteric in WT-vs-index stuff, so probably don't have particularly close equivalents.
<maxb> For the specific case of tigrang's command I guess it would be 'bzr pull --overwrite -r -2 .'
<maxb> Or 'bzr uncommit --force && bzr revert' to arrive at the same position via another path
<nopf> hm the web is not conclusive... what is the best quick way to remove some accidentally commited large files from the repo completely?
<jelmer> nopf: create a new repository, clone all history except the history with the acidentally commited files into it
<nopf> jelmer: well thanks, first. shall i use 'bzr clone', which is deprcated? and if so (or 'branch'), how do i 'keep out' the files? do i have to redo the other changes in the commit where they went in? (added some smaller files in the same commit...)
<karlis> I ask because I'm relatively new to Linux and I don't know exactly what to search for. When someone commits something to our server its drwxr-xr-x  user:user. But i need it to be drwxrwxr-x root:developers. Where to set this or what do I search for?.
<LeoNerd> Personally I'd branch at the commit that added the file, uncommit, remove the file, recommit, then replay over the rest of the commits. If there's any that try to modify it they'll conflict, so you'll just have to ignore that change and continue
<nopf> LeoNerd: oki. this seems like a bit of work but managable. i'll try
<kolbe> i'm trying "bzr branch 5.5 5.5.29 -r 3654" and it shows me "- Fetching revisions:Get stream source" and hangs ... any pointers?
<kolbe> looks like 5.5.29 is actually growing in size, so i guess it's doing something... but what? can it do this branch locally, or is it trying to do something over the network?
<kolbe> maybe i want bzr export anway
<jelmer> kolbe: what's your question?
<kolbe> when i do "bzr branch 5.5 5.5.29 -r 3654" it appears to hang with "- Fetching revisions:Get stream source", is that normal?
#bzr 2013-08-15
<jelmer> kolbe: it depends - is 5.5 a lightweight checkout? are you branching in the same shared repository
<jelmer> ?
<kolbe> no, there's no shared repository, 5.5 is a standalone thing that i got with bzr branch lp:maria/5.5
<jelmer> kolbe: in that case, it's copying all of the revisions; that could be correct
<kolbe> alright, thanks
<kolbe> jelmer: i suppose if i just want one revision, in this case maybe bzr export would be a more reasonable choice?
<jelmer> kolbe: yes
<nopf> LeoNerd: hi again. im trying to follow your strategy to get rid of some big accidentally commited files. i branch. uncommit. recommit. then how to 'replay' the other commits? using 'merge'? the big files keep creeping in then! seems i'm not very good at this :/ anyone else maybe a hint?
<LeoNerd> nopf: bzr replay
<nopf> LeoNerd: oh which seems to be an extension that i don't have... checking
<LeoNerd> Ahh
<LeoNerd> Ooohyes. it's from the "rewrite" plugin
<LeoNerd> I sometimes forget what isn't core ;)
<nopf> LeoNerd: yeah, succes, thanks!! ... now that i understand that right: this is in a shared repo. i need to branch all other projects in the shared repo and then replace the whole shared thing with the new thing, yes?
<LeoNerd> Hmm?
<nopf> ... to remove the 'big files' from the .bzr directory -- that was the main goal
<nopf> ... i have to recreate the shared repo, not?
<LeoNerd> Oh.. most likely, yes...
<bob2> also everyone needs to rebranch
<bob2> and throw away their existing branches
#bzr 2013-08-16
<lduros> thought I'd ask here: is there documentation on meliae somewhere?
<lduros> isn't it a software used by bzr devs?
<jelmer> lduros: I think all of the documentation for meliae is included in the main branch
<lduros> ah, ok
<lduros> jelmer: do you know where the repo is?
<jelmer> lduros: lp:meliae
<lduros> kewl, thanks
#bzr 2014-08-11
<sidi> Is it possible to use bzr fast-import to keep syncing the master branch of a bzr repo with that of a git repo?
<sidi> (I'm asking because I want to copy a git repo with one branch and a handful of release tags, then I want to make branches for some of those tags and apply my patches, but want to be able to create new branches for the git repo's future release tags and keep applying my patches all within Launchpad, so it can be packaged automatically)
<stbatduke> Hello!
<stbatduke> Quick question (hopefully):
<stbatduke> "Conflict adding id to <filename>.  Unverseioned existing file <filename>."
<stbatduke> Scenario:  Programmers my company hired does not know how to properly name files, so I had to change the names of a bunch of config files and csv files.
<stbatduke> They updated one of these files this time around after I am forcing the file changes , and now one of the files I changed has been updated by the programmers
<stbatduke> I need to add the file to the bzr repo however I am seeing this conflict in the bzr status, and I'm not sure how to just add this file to the repo, or how to merege the files updates into the renamed version of the file.
<stbatduke> any ideas?
#bzr 2014-08-14
<ciampix> hello. bzr newbie here. Why "bzr add" may be silent? Even with --verbose?
<jelmer_> ciampix: not sure I follow? It should print names of all files it's adding
<ciampix> jelmer_, yes I though so but I do "bzr add" and it output nothing...
<jelmer_> ciampix: are there actually files that haven't been versioned already?
<ciampix> jelmer_, these files are versioned, I would like to add my modifications...
<jelmer_> ciampix: there is no need to add your modifications, there is no staging area like in git
<jelmer_> ciampix: bzr commit will pick up those changes
<ciampix> jelmer_, ahhh ok! I am from git...
<ciampix> jelmer_, many thanks!
<ciampix> jelmer_, bzr: ERROR: Cannot lock LockDir([...cutted...]) Transport operation not possible: http does not support mkdir()
<jelmer_> ciampix: you can't push over http
<jelmer_> you'll need ssh
<ciampix> jelmer_, I do not understand ... I was doing a commit, not a push...
<jelmer_> ciampix: how did you create your local branch?
<jelmer_> ciampix: using "bzr checkout" or "bzr branch" ?
<ciampix> jelmer_, I've used a script so I do not know the method used but I imagine that it is only for "read-only" local mirrors (kicad build script) so I imagine I have to do some local repo manually and by ssh ...
<jelmer_> ciampix: to "unbind" it from the remote branch, use "bzr unbind"
<ciampix> jelmer_, ah with bind-ed local branches every commit do automatically a push? I am right?
<jelmer_> yes
<ciampix> thanks that clears up many things in my mind...
<ciampix> jelmer_, I am always amazed by the level of help that free project groups deliver...
<ciampix> ;-)
<ciampix> jelmer, many many thanks! Done my first commit+push!
#bzr 2014-08-15
<thrustcore> I'm now completely out of disk space, so I can't pack with bazaar anymore, is it safe to just move the folder that contains the repository to a different volume?
<fullermd> Long as you move the repository and any branches using it together, yes.
<fullermd> With a light-to-moderate (depending on your particulars) risk of external stuff referencing the old locations (parent/push locations, checkouts against them, etc), but you could mostly mask over those with symlinks if necessary.
<thrustcore> fullermd: I don't know of any such external "dependencies"
<fullermd> Well, assuming this is "my workspace" rather than "a central server that arbitrary people might look at", you'd presumably know if there were, so you should be fine.
#bzr 2016-08-16
<rindolf> Hi all. How can I resolve the bzr status conflicts ? http://paste.debian.net/789884/
#bzr 2016-08-17
<catern> Hey, how would I use bzr over HTTP?
<catern> I would like to checkout http://bzr.savannah.gnu.org/r/gsrc/
<catern> and I can't use bzr:// because ports other than 80/443 are blocked...
<catern> and if I do "bzr checkout http://bzr.savannah.gnu.org/r/gsrc/ gsrc" I get "Not a branch"
<fullermd> You probably want .../trunk
<catern> er yeah i have that
<catern> and it still does not work, should it?
<fullermd> into works, so I presume branch would.
<fullermd> Or checkout, though of course you won't be able to commit.
<catern> it says not a branch :/
<catern> not at a shell atm tho
<fullermd> If you're looking at /r/gsrc, yes.  If you're looking at /r/gsrc/trunk, it should be OK.
<catern> ugh... yes now that I'm back at my shell I realize I guess I omitted the /r/
<catern> but now I get some invalid http response thing, ugh
<catern> might be the corporate proxy...
<catern> invalid http response: bad status line received
<fullermd> Seems to work here
<fullermd> % time dbzr branch http://bzr.savannah.gnu.org/r/gsrc/trunk
<fullermd> Branched 3851 revisions.
<fullermd> 10.178u 0.410s 0:40.19 26.3%    5+167k 51+294io 3pf+0w
<fullermd> Wouldn't be too surprising I guess if a proxy expected web browsers loading web pages choked itself on an app expecting fine-grained file access  :)
#bzr 2017-08-15
<durin42> Hey, anyone around that can help me report a security bug in bzr?
<durin42> (got someone via another channel, so I'm set)
#bzr 2018-08-17
<fullermd>  /win move l
<fullermd> Do do do...
<jelmer> hey hey fullermd
 * fullermd waves breezyly at jelmer.
<jelmer> :)
<jelmer> that reminds me, we should send an announcement out about breezy's status. We're down to only 200 out of 30000 tests failing on Python 3
<fullermd> Ooh, shiny.
<fullermd> Heck, that means with just a tiny bit of work, you'll be passing all 29800 tests!
<jelmer> :)
<jelmer> s/failing/passing/
