#bzr 2007-11-05
<sverrej> I get this error when trying to checkout a svn branch with bzr branch svn+http://foo/trunk  :
<sverrej> bzr: ERROR: bzrlib.errors.KnitCorrupt: Knit <bzrlib.knit._KnitAccess object at 0x8a639ac> corrupt: incorrect number of lines 73 != 59 for version {svn-v3-trunk1:f4d88352-fc0f-0410-91c6-821c4d51a43f:my.opera.com%2Ftrunk:329}
<AfC> sverrej: as ever in Open Source land, it would help your cause if you would tell people what version of Bazaar you were using, what OS distro, etc.
<sverrej> I read about someone having the same problem, where the solution was to do incremental pulls, because bzr-svn uses too much memory, but that did't help.
<sverrej> AfC: Sure :)
<sverrej> Ubuntu Gutsy, Bazaar 0.92.0.candidate.1 and bzr-svn-0.4.4
<sverrej> Should be latest version
<sverrej> I have a backtrace too. I'll post it somewhere
<sverrej> http://pastebin.com/m51c4dba3
<lifeless> moin
<mwh> morning lifeless
<sverrej> good morning
<lifeless> bbiab
<zerok> hi :-) short question: when you push a changeset to a remote repository, is there some hook that could be exploited for example for automatically updating the working tree there?
<beuno> zerok, there is a plugin calles "push-and-update", that might be what you're looking for
<beuno> it runs locally, and updates via SSH, so make sure you have SSH access
<beuno> I'm not sure you can add a hook on the server side without having smart server running as the "push" command is done entirely locally, but the push-and-update plugin works fine if you have ssh access
<zerok> beuno, thanks :-)
<beuno> zerok, :D
<pbor> can I use bzr-svn to do a smarter merge of two svn branches?
<pbor> lemme explain... I have a svn repo with a branch "foo" and trunk that have diverged a bit
<pbor> now I want to merge foo into trunk
<pbor> and I was wondering if using bzr-svn could help
<jelmer> pbor: Yeah, it should at least be smarter than "svn merge"
<pbor> jelmer: but if I use bzr to checkout svn/branch/foo and svn/trunk, is bzr smart enough to understand they are branches of the same repo?
<jelmer> pbor: Yes, it will recognize if they have common ancestry
<pbor> jelmer: cool... I guess my best bet is get bzr latest and bzr-svn latest, right?
<jelmer> yep
<jdong> does Launchpad currently support dirstate-tags format branches?
<Peng> Can you try it and see?
<jdong> well I tried running a bzr upgrade over sftp:// and it sat there spinning for 15 minutes
<jdong> on a fairly small sized repository
<jdong> I figured someone here might directly know, without me risking creating junk on LP
<lifeless> jdong: yes it does
<lifeless> jdong: generally launchpad supports anything supported by the release-1 of bzr
<jdong> lifeless: fantastic; how do I convert an existing branch to dirstate-tags?
<jdong> was I just impatien with bzr upgrade?
<lifeless> jdong: yes, I think so :)
<lifeless> jdong: it takes a backup for safety
<MishaS> hi. can somebody recommend a doc about bzr merging? :)
<beuno> MishaS, maybe this?  http://doc.bazaar-vcs.org/bzr.0.92rc/en/user-guide/conflicts.html
 * MishaS is checking the suggested doc
<MishaS> beuno, thanks, but it seems to address only part of my misunderstanding :)
<beuno> MishaS, what are you looking for specifically?
<MishaS> beuno, let's have i have 'trunk'
<MishaS> beuno, and a lot of people (at least somebody beside me :)) is working on that
<MishaS> beuno, now i started to work on a new feature: bzr branch trunk new-feature
<MishaS> beuno, i did some changes to the branch and would like to catch up with trunk changes: bzr merge; <resolve conflicts if any>; bzr ci -m 'merged with upstream'
<MishaS> beuno, now, for one week i do not touch my branch as other things were happening
<MishaS> beuno, in one week i decided to catch up with changes again and my natural reaction is/was: bzr pull
<MishaS> beuno, how it does not work.  i need to again 'bzr merge' and then 'bzr ci'
<beuno> MishaS, that's correct
<MishaS> beuno, so i'm looking for a document that would clarify why it must be done like this :)
<beuno> MishaS, you can also use the SVN-like model, and use checkouts
<MishaS> beuno, sorry, i don't exactly follow :)
<beuno> MishaS, http://bazaar-vcs.org/FAQ#head-73f0b8ea8515a0087ce8705fbaafc55c80a0a30e
<dato> beuno: uuh, that wouldn't quite work, since he's working in a separate branch?
<beuno> that might help
<beuno> dato, right, he'd have to do bzr update on a frequent basis
<MishaS> beuno, without having my changes committed?
<beuno> MishaS, what about that workflow don't you understand?  If the parent branch has changes, you have to merge them into yours
<beuno> MishaS, you have to have your changes commited so conflicts can be resolved
<MishaS> beuno, yes, but i did it once and then nothing was changed, why should i resolve non existing conflicts again?
<beuno> MishaS, you don't have to resolve conflicts if there aren't any
<beuno> if the merge was clean, you just have to commit the changes to your repository
<beuno> or work on them, and then commit
<beuno> conflicts are only for when bzr can't guess how to merge the changes
<beuno> so you have to interveen
<MishaS> beuno, i kinda _feel_ inconsistency...
<MishaS> beuno, and cannot really explain it... :(
<beuno> MishaS, that it's a bit hard for me to help  :D
<beuno> have you used other VCS before?
<MishaS> beuno, probably the behaviour i expect is that after that merge new changes would be just on top of the last merge without additional effort
<beuno> or rather, how would you want the workflow to work?
<beuno> MishaS, ah, I understand
<MishaS> beuno, i have :)  and it was never like this :))  i just hope that bzr is closer to what i aniticipate... :)
 * MishaS used cvs, visual source safe, p4, and now is jumping between svn/git/hg/bzr :)
<MishaS> (p4 was not for too long though)
<beuno> MishaS, have you taken a look at: http://bazaar-vcs.org/Workflows
<beuno> I'm not sure why merge can't just bring the commits into the revision history, one of the devs can probably answer that better then me
<MishaS> beuno, yes, it was quite some ago though....
<MishaS> i would say that _some_ merges cannot be brought directly, but if they can, why not?
<MishaS> and probably something like rebase would be more appriate for me..
 * beuno looks ar abentley, fullermd and jam-laptop for input
<dato> rebase *may* be what you want, *but* it doesn't fit the recommended bzr workflow
<MishaS> (appropriate)
<MishaS> dato: what do you mean "does not fit"? i believe if a feature is developed using 'rebase' than when it's merged to trunk it looks clean and nice, no?
<lifeless> ~.
<hstuart> MishaS, I think one of the ideas is to allow you to merge another developers changes without having to commit them to your branch, for looking at experimental features or what have you - at least that makes sense to me
 * MishaS is now complete lost :)
<dato> MishaS: well, in eg. git you can do many things with rebase, like merging commits into only one, and in general making them "nice"
<lifeless> MishaS: rebase sacrifices collaboration for prettiness
<fullermd> Hm?  What?  Who called?  The goldfish were in the blender when I got there, I swear.
<dato> MishaS: in bzrland, though, people have normally nothing against merging branches with many small commits, including those "merge upstream" ones
<beuno> and I also heheh
<MishaS> ok. now, i think, i get it: bzr priorities are 'collaboration' and only then 'prettyness'.  that actually helps to understand the things. really.
 * fullermd doesn't quite understand the question...
<dato> fullermd: "why do merges which generate no conflicts require a commit"
<lifeless> MishaS: there is a rebase plugin for bzr.
<dato> fullermd: more or less
<fullermd> Mmm.  Well, in this case, merging trunk into your branch, you wouldn't want rebase; that would cause big honkin' ugliness when you merge back into trunk.
<fullermd> Rebase is more for merging your branch back onto trunk, erasing all your intermediate steps.
<MishaS> lifeless, thank you
 * MishaS checks bzr web site for rebase plugin
<Peaker> fullermd: don't you want to merge in your branch, and try to only push to trunk?
<Peaker> when you say rebase you make me think ClearCase
<MishaS> fullermd, rebase will make my changes quite separate from trunk
<fullermd> Well, that's a workflow question; neither answer is "right" per se, it depends on what you're trying to accomplish.
<fullermd> I don't go in for push to trunk flows, since that could change trunk's LHS.
<MishaS> fullermd, if i really have to 'merge with upstream' only when there are conflicts it'd still look 'clean' in the changelog, otherwise they do seem to make the changelog a bit too overloaded
<Peaker> I think its probably easier to test the coherency of your work in your own branch where you usually do the work, so merges happen there, and when you push to trunk you know you are making it identical to your copy
<Peaker> fullermd: LHS?
<fullermd> Well, even if there are no conflicts, there still has to be a new revision, because you're making a state that doesn't already exist.
<lifeless> Peaker: left-hand-side history
<Peaker> lifeless: what does it mean?
<fullermd> Some of the other DVCSen automatically commit if there are no conflicts (mtn and git I know do; not sure about hg).
<lifeless> a merge merges two revisions X and Y to give Z. Z:[X,Y]
<MishaS> fullermd, i see.
<Peaker> lifeless: with common ancestor B, yeah
<lifeless> the left hand history is what you get by following just X at every step
<fullermd> bzr doesn't.  I like that better; it means you can supply a more meaningful commit message.  Also, just because there are no textual conflicts, doesn't mean there aren't any conceptual conflicts.
<lifeless> Z.parent_ids[0] -> Z.parent_ids[0].parent_ids[0] etc
<fullermd> e.g., somebody renamed a function that your code calls.  Merge won't find any conflicts, since there aren't any textual clashes in your changes, but now you're trying to call a function that no longer exists.
<lifeless> Peaker: a merge does not imply a common ancestor :)
<Peaker> lifeless: how can a merge be without one? Revision 0 is always a common ancestor, isn't it?
<Peaker> fullermd: so you want such a revision to be considered a merge?
<lifeless> well, null: is a theorietical common ancestor, but if you have partial history for two branches, then you may not reach null:, nor a common ancestor.
<lifeless> we'll still allow a merge commit to be recorded then, though doing the merge is harder :). But this what joining two existing imports or projects does.
<Peaker> lifeless: then how can you make a meaningful merge? You have a working tree merge, but not a history merge?
<fullermd> Peaker: Not sure what you mean by 'considered a merge'...
<Peaker> fullermd: that problem can happen when you merge into trunk, too, can't it?
<Peaker> fullermd: I mean, why is it a factor against pushing into trunk?
<Peaker> fullermd: if you push into trunk, you know that if it worked for you in your own development branch, then it will work for trunk, push has the nice property that it will be identical, so you know what's going to be there.. when you merge into a far away branch, you have theoretically no idea what the result is going to be
<Peaker> lifeless: is there any way to do the opposite, btw? Split the histories of your working tree into separate projects?
<lifeless> bzr split
<Peaker> lifeless: ahhh, that explains a few things :-) Now I know why svn plugin uses that format...
<Peaker> (bzr help split explains a few things, that is)
<fullermd> Peaker: But pushing into trunk will change the LHS history, which means changing the revnos and the output from log, and I don't want that.
<fullermd> Peaker: My above statements weren't re: pushing into trunk; they were re: merge requiring a commit.
<Peaker> fullermd: I see. I don't have enough experience watching revno's/logs to understand that problem you're mentioning, I guess
<fullermd> The 'rollup' action of log is really handy for those situations.  It means my merges into trunk can give a quick description of the changes, and most of the time that's all anybody needs to see.
<Peaker> fullermd: I do know that when we worked with ClearCase (yikes) there was no pull/push, only merge, so you could endlessly merge from/to trunk and never be sure the trees are identical
<fullermd> Then they don't need to schluff through the 50 commits it took me to get it right when they're just browsing the history, unless they really need to delve into the internals.
<Peaker> fullermd: I see, I guess you could use an empty merge from trunk before pushing for that purpose
<Peaker> fullermd: oh, wait, forget that :)
<Peaker> fullermd: if you're trusting developers to keep trunk clean and not pqm, then merging into trunk is a little dangerous, isn't it?
<fullermd> Well, discharging small arms is dangerous, but I still spent Saturday afternoon doing it   ;p
<Peaker> are you into weapons? :)
<fullermd> Well, that's how I keep cow-orkers from messing up trunk, see.
<Peaker> most of us in Israel handle weapons at one time or another.. I was stupid enough when I was 18 to test the bullets endurance on its explosive thing, it is not easy to blow :)
<lifeless> jam-laptop_:  bzr pqm-submit -m '(robertc) Implement WorkingTree4.update_basis_by_delta giving a 30% performance improvement for commit. (Robert Collins)'
<lifeless> :)
<lifeless> commit speed++
<mwhudson> lifeless: it would be good to get bzr.dev landings announced in here by some bot
<beuno> there is a plugin somewhere to have an IRC bot hook into commits
<lifeless> beuno: bzr.dev commits are done by pqm, on a firewalled machine.
<lifeless> mwhudson: pity launchpad won't announce to IRC: )
<beuno> lifeless, maybe we can have a mirror of bzr.dev and have the bot on a different server?
<beuno> might have a delay, but still might be usefull
<lifeless> beuno: well it is announce to the bazaar-commits list
<beuno> lifeless, that might work too, a bot parsing those emails
<Peaker> I don't understand how launchpad can be usable until it has shared repo's... it really is insane to upload entire repo/history for every branch
<beuno> and would speed up a bit
<lifeless> Peaker: we're looking at addressing the upload overhead there; shared repos are just one way to handle that.
<Peaker> lifeless: what other ways are there?
<lifeless> stacked pack repositories looks quite promising and may scale better for a multiuser site like launchpad
<mwhudson> lifeless: we don't need no new features, mate
<lifeless> mwhudson: a feature a month keeps the doctor away
<mwhudson> lifeless: the problem here is the word "a" :)
<Peaker> lifeless: what are stacked pack repos, compared to ordinary repos?
<fullermd> Repos with more feminine allure?
<lifeless> Peaker: a way of combining data from separate repositories
<fullermd> bzr unionfs.
<Peaker> lifeless: when I upload a branch to launchpad, I'd somehow have to tell it that it shares/combines data from another repo if I am to avoid uploading history? would it require explicit data from the user?
<lifeless> Peaker: magic 8-ball says future hazy, ask again later
<Peaker> :)
<lifeless> jam-laptop: it landed :)
<dato> is somebody tracking what's pending to merge for 0.92, and should I send a patch that splits  NEWS in the appropriate place, since 0.92 got branched off? (which leds me to ask: what of bzr.dev is 0.92 material, and how should it get merged, cherry-pick?)
<lifeless> dato: it will get merged/cherrypicked yes; I'm not sure what commits are what to be honest :)
<lifeless> poolie will need to make that call as RM
#bzr 2007-11-06
<somerville32> bye
<nekohayo> hello~! let's say I want to push to another computer, but this computer's files can change by themselves
<nekohayo> will bazaar warn me of a conflict if the host has changed it files since the last push?
<fullermd> Depends on which files you mean.  push only pushes the VCS data, it doesn't touch the working tree files one way or another.
<fullermd> It'll notice if the remote-side VCS data has been changed.
<somerville32> aka: It compares committed revisions
<nekohayo> fullermd: ok thanks :) (because I just had the crazy idea of using bazaar to keep my bookmarks in synch)
<nekohayo> fullermd: actually by vcs data, you mean stuff like "bookmarks.rdf", not the control data contained in ".bzr" right?
<fullermd> Other way around.
<nekohayo> arr, dang :|
<somerville32> nekohayo, No no. You're good.
<somerville32> Bzr is great for that
<nekohayo> somerville32: well, if I have my laptop pushing to ~/.gnome2/epiphany/bookmarks.rdf on my desktop computer, and the desktop computer has modified its bookmarks file (without committing or anything) since then, am I not screwed?
<somerville32> nekohayo, No.
<somerville32> It'll merge when you attempt to commit on the desktop
<fullermd> Not necessarily.  But it won't touch the desktop's bookmarks.rdf, it'll just update the VCS data.  You'd have to do an 'update' to bring in those changes, fix any conflicts, and then 'commit' to get the desktop's changes in the history.
<nekohayo> fullermd: that's strange, that I need to do a bzr update... why wouldn't bzr just tell when I commit?
<fullermd> Well, if will, if you don't update   :p
<fullermd> And 'it', too, for those of us who can type tonite...
<poolie_> lifeless, jam-laptop: hi
<jam-laptop> hi poolie_
<poolie_> should we merge this windows uninstaller fix for 0.92?
<poolie_> it doesn't seem really critical...
<lifeless> hi poolie_
<jam-laptop> it doesn't seem critical either way
<lifeless> OTOH it's low risk and alecander will probably build with it applied anyway :)
<ubotu> New bug: #72901 in bzr-pqm "win32: can't submit via localhost" [Low,Fix released] https://launchpad.net/bugs/72901
<ubotu> New bug: #160389 in bzr "change build process to (just) use setup.py" [Undecided,New] https://launchpad.net/bugs/160389
<lifeless> man freenode, get the servers in order
<jam-laptop_> that was probably just them running sort()
<Odd_Bloke> Does a list admin have to approve my subscription to the ML?
<fullermd> Not as a general rule, AFAIK.
<Odd_Bloke> Hmm, just sloooowness then.
<vila> jam-laptop__: since you're working on pqm, how about putting the commit message in the returned email indicating success/failure ?
<Odd_Bloke> If any of the list moderators are around, there should be a couple of merge requests from D.M.Watkins@warwick.ac.uk in the pending queue.  It'd be great if they could be let through and the address whitelisted. :)
<dato> aw pqm (r2972)
<Enquest> I got a foo.BASE, foo.THIS, foo.OTHER files... What should i do now?
<Arjen> Merge error?
<Enquest> Uhm I use bzr to upload it to my web project
<Enquest> I suppose that its a merge error
<Enquest> What should I do with it... I can't find anything about it in the docs
<Arjen> I'm a complete bzr noob :-)
<Enquest> me to
<Enquest> so anybody can explain me what I sould do with this?
<Arjen> Enquest: What does 'bzr conflicts' say?
<Enquest> I already did it manualy but I realy would like to know how to handle these errors
<Enquest> thanxs Arjen (you are from holland?
<Arjen> Yup
<Enquest> Belgie of moet ik zeggen Vlaanderen ik weet het niet meer
<Arjen> Well, merge conflicts which can't be handled by the VCS you'll have to fix by hand
<Arjen> Enquest: Nederland, niet Belgie :-)
<Enquest> aja, lage landen
<Enquest> Werk jij proffesioneel?
<Arjen> Dat probeer ik wel ;-)
<Enquest> Ik ook, met wat werk jij dan? zelfstandige of voor een bedrijf?
<Enquest> Ik ben zelfstandige
<Arjen> Internetprovider
<Enquest> a je programmeert niet... maar heb een isp
<Arjen> Ja, ik programmeer voor een ISP
<Enquest> verdiend dat wat?
<Arjen> Genoe
<Arjen> g
<Arjen> But, this conversation is *way* off-topic here :-)
<Enquest> Ok got the point... Just thought that its here dead and want to know how people manage ?
<Enquest> sorry
<Arjen> Merge conflicts you mean?
<Enquest> yes
<Arjen> If the VCS can't figure it out, then you'll have to fix the conflict(s) yourself and tell the VCS to continue
<Odd_Bloke> Arjen, Enquest: It's not normally this dead in here, but the majority of bzr devs are Canonical employees and it's Ubuntu conference season so they're gallivanting away there. :p
<Kinnison> :-)
<Odd_Bloke> Enquest: Presumably you ran 'bzr merge' before getting these files.  These files mean that there was a conflict within foo that Bazaar can't handle.  If you open foo, you should see some markers where the problem is.  Edit foo so it looks as it should and then run 'bzr resolve foo'.
<jam-laptop__> vila: that requires pqm changes, not changes to the submit plugin :)
<vila> jam-laptop__: arf, of course silly me |-)
<vila> but about pqm anyway, I'm still surprised that we sign a submission to merge from an url, but don't provide the revid that should be merged, leaving open a possible tip change of the submitted branch...
<jam-laptop> vila: completely agreed, it is actually because pqm was built up around Bazaar, which would always send the full archive/category--branch--version--patch
<jam-laptop> And it was never upgraded to recognize something different from bzr
<jam-laptop> I actually started working on that once.... a long time ago
<vila> haaaaa, history, as always. explain why things me *look* strange, but are, in fact, sound :)
<vila> s/me/may/
<jam-laptop> anyway, I'm off to breakfast, catch you around later
<vila> same here, very busy thought :-/
<lifeless> ola!
<lifeless> well in principle pqm accepts url;revid=XXX
<lifeless> except I don't think I've hooked that in
<vila> well, I'm not that worried about the problem since only core devs can submit, but I wondered
<lifeless> (and arch suffers here too ;)
<lifeless> (you can replace the content of a url is the basic attack)
<siretart> heyha bazaar hackers
<siretart> is it possible to recreate the knit index file from a standalone knit?
<siretart> read: I have the revisions.knit, and need to regenerate a revisions.kndx file
<dato> abentley: I can't see in bzrtool's branch the commits for 0.92, is something wrong?
<luks> siretart, not easily, maybe in some simple cases and using heurestics
<luks> but .knit files don't have all the info from .kndx stored in any direct way
<siretart> luks: I have a corrupted repository, my revisions.knit seems to be corrupted
<siretart> zcat on revisions.knit tells me something about trailing garbage, and bzr is horribly unhappy
<luks> hm
<siretart> I can of course rezip the output of the corrupted revisions.knit, but then the kndx file doesn't match it :/
<siretart> and `bzr check` doesn't seem to catch that problem
<luks> does zcat lists the last revision info fully?
<siretart> I cannot check what the last revision actually is
<LeoNerd> Be aware you can't just re-compress the compressed files. They're compressed in a very special way
<luks> last line in the .kndx file
<luks> it has the revision-id
<siretart> hm. the last 6 revisions seem to be missing
<siretart> better than nothing
<siretart> lets try to 'adjust' the .kndx file :)
<luks> yeah, that should work
<siretart> hm. bzr log now tells me 'no such revision.. blabla'
<siretart> seems i need to do some more work
<luks> /bzr/checkout/last-revision I think
<luks> er, .bzr
<luks> ok, no, branch/last-revision
<dato> or revision-history for format 5 branches
<siretart> hm. and if I remove .bzr/checkout, can I recheckout?
<luks> no
<luks> it needs to know the head revision
<luks> actually, maybe you can branch -r revid:...
<siretart> ah, lets try that
<siretart> bzr: ERROR: bzrlib.errors.ShortReadvError: readv() read 9636 bytes rather than 19321 bytes at 0 for "revisions.knit"
<luks> can't help with this one, not sure that exactly is bzrlib doing
<siretart> anyway, thanks for your help
<luks> I'd send a mail to the mailing list
<siretart> it seems my repository is horribly corrupted :(
<lifeless> siretart: sure it wasn't a network problem?
<lifeless> siretart: OTOH if you were pushing over sftp, it may be the sftp bug we haven't tracked down with openssh doing the wrong thing on append from time tot time... pretty nasty
<lifeless> jam-laptop: you've arranged to borrow the laptop?
<jam-laptop> lifeless: yes, he said he would give it to me later today
<lifeless> kk
<jam-laptop> it was currently charging in his romo
<jam-laptop> room
<siretart> lifeless: no, all operations were local. (well, over nfs, but still using the file:// transport)
<siretart> lifeless: I've been told now by the student that he noticed that committing still works, so he committed about 6 additional revisions
<lifeless> siretart: so, run check :)
<lifeless> siretart: if it's corrupt you'll probably be able to pukll from it to a backup copy to combine the work.
<lifeless> siretart: getting to a root cause of this is very important; its possible for an NFS bug to damage things -
<siretart> lifeless: check tells the same error
<lifeless> siretart: when append() on fileA works, append() to file B works, but actually only file B's change gets committed over the wire it could cause this.
<siretart> lifeless: we now decided to copy the working copy over an older repository
<lifeless> siretart: also, using packs may be somewhat less liable to cause this sort of corruption as it has less requirements on the file system.
<siretart> so we haven't lost any work, but some weeks of history
<siretart> ah, great news!
<ubotu> New bug: #160521 in bzr "specific merge algorithm for changelogs" [Medium,Confirmed] https://launchpad.net/bugs/160521
<lifeless> jam-laptop: I'm in the hearth and kettle
<jam-laptop> lifeless: is it hot in there?
<ubotu> New bug: #160530 in bzr-pqm "pqm-submit is sending messages pqm doesn't understand" [Critical,Fix released] https://launchpad.net/bugs/160530
<lifeless> jam-laptop: no
<lifeless> jam-laptop: nor is it cold
<Odd_Bloke> lifeless: Regarding my bundles, should I resend them with an appropriate MIME type?
<lifeless> jam-laptop: the laptop is with me in the h&K
<jam-laptop> ah, ok
<lifeless> Odd_Bloke: well, I can look on BB later; but next time
<Odd_Bloke> lifeless: OK, sure.
<Odd_Bloke> Sorry about that.  As my email mentions, I've changed mail client.
<schierbeck> jelmer: ka-ping
<jelmer> schierbeck, pong
<schierbeck> i'm not sure what the problem is with the brokenlines-optional branch
<schierbeck> i just destroy the current treeview and draw a new one
<schierbeck> but under all circumstances, we should support dynamically redrawing the ancestry graph
<schierbeck> so i think it's a temporary solution
<jelmer> re
<lifeless> hi
<jelmer> schierbeck: I don't think your patch is wrong, it may have regressed during gary's original rewrite
<jelmer> 'evening lifeless
<schierbeck> jelmer: i just wrote it
<schierbeck> i can't find the real problem, but having a maximum width on the graph fixes it for now
<schierbeck> and i don't think we're going to stick with the code, so it's okay to release
<jelmer> I agree, though it's up to Szilveszter to decide
<jaavaaguru> Hi, I've got a delta between two revisions using rev_tree.changes_from(parent_tree), and I'd like to get the full text of particular files from both revisions to pipe into an external diff tool. Can someone point me in the right direction to get the full text?
<asabil> hi all
<asabil> how do I use a pre-commit hook ?
<asabil> I want to refuse commits with files with trailing spaces
<james_w> jaavaaguru: I don't think you use the changes fr that , you get the texts from the two trees.
<jaavaaguru> ah, ok
<james_w> tree.get_file_text
<jaavaaguru> thanks :-)
<james_w> takes an id. You can get those with tree.path2id
<jaavaaguru> I've got the IDs
<james_w> good.
<jaavaaguru> I've been using the Bazaar API since Saturday, and working with it has been good so far
<jaavaaguru> I've written most of my wxWidgets GUI, and am just needing to get the text so that I can launch an external diff from the history window
<nevans> general merging question: I did a series of merges of single changesets (e.g. using "bzr -merge ../trunk -r 1925..1926" to get r1926), but it didn't record that the changeset was merged.
<nevans> and "bzr missing ../trunk" still shows them missing.
<nevans> remerging ends up with a bunch of conflicts, of course.
<nevans> should I have done that differently?
<nevans> FWIW: I was using bzr 0.91 and bzr-svn (using 0.92rc1 now)
<lifeless> asabil: Hi, you write a small plugin
<lifeless> asabil: it registers with Branch.commit_hooks['precommit'] IIRC
<jelmer> nevans: bzr doesn't track cherrypicks yet
<lifeless> nevans: cherrypicking is a current weakness; we have a ui to express it but we don't record it(neither does hg or git FWIW)
<nevans> jelmer: ah... I thought that was maybe what everyone meant by cherrypicks
<nevans> git doesn't either?! wow... so what's the current "best practice" for cherrypicks?
<nevans> lifeless: what's the cherrypicking UI called?  google isn't helping me out much.  :)
<lifeless> nevans: you used it
<nevans> ah.
<jaavaaguru> james_w: that did exactly what I was looking for, thanks. I've got external graphical diff working now from my history window
<nevans> lifeless: is http://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html only a halfway solution?  (since you said git doesn't support it either)
<lifeless> nevans: yes,
<lifeless> nevans: cherry picks can be much more than one commit; they need to alter the behaviour of merge and log and other commands and the only system I know of that does that today is darcs.
<nevans> lifeless: is there a bzr branch that someone is working on this currently?  or is it a little further out in the roadmap (not really specified yet)?
<jelmer> lifeless: that reminds me, what's the status on file properties?
<nevans> not that I intend to switch to an experimental branch anytime soon.  ;)  just curious
<lifeless> nevans: it's a little bit out in the roadmap; I think probably in the nexxt 6 months or so.
<nevans> lifeless: thanks
<hendrixski> :-/ bzr-svn is able to pull svn revisions rigth? from let's say a week ago?
<Peng> Yes.
<jelmer> hendrixski: from svn into bzr? yes
<hendrixski> jelmer, like instead of    svn co http://whatever -revision #12345 (not sure how to do that either)  do make a branch of a revision from last week
<jelmer> oh, sure - you can use -r
<hendrixski> oh
<jelmer> ah, you mean revspecs of dates?
<jelmer> hmm, that I'm not sure
 * hendrixski tries that
<jelmer> it may work, but I haven't ever tested it
<hendrixski> oh
<hendrixski> well, I'll play around with it :-)
<nevans> jelmer: is there a way to see/use the SVN changeset number rather than the various bzr revisionspecs?
<jelmer> nevans: the revision id for svn revisions contains the svn revno
<nevans> it would be useful if there were a revspec like "svn:123456"
 * hendrixski now knows that the word to google for is "revisionspecs"
<jelmer> nevans: please file a bug report :-)
<nevans> ah... so it does.  bzr log --show-ids is useful
<nevans> jelmer: I think I will.  :)
<nevans> jelmer: oh, and as an aside... THANKS for bzr-svn.  it rocks.  :-)
<jelmer> thanks :-)
<hendrixski> yeah.. I think bzr-svn is going to save me a ton of headaches in the near future
<hendrixski> if I can quickly learn how to use it :-/
<hendrixski> hhhmm... yeah, for bzr .90, the    bzr branch http://svn.source/directory date:2007-10-25    doesn't seem to work  I guess it has a different date structure than svn :-(
<nevans> launchpad was giving me some weird timeout errors, so I didn't search to see if there was a duplicate before adding my bug.
<nevans> hendrixski: your problem is that you want to get working tree for a particular svn revision number, right?
<hendrixski> nevans, yup
<hendrixski> though, I'm probably just putting them in the wrong order
<nevans> you do that by first doing a checkout of HEAD from svn, using that to figure out what the bzr revno will be, and then branch from the bzr HEAD to a new branch (using -r bzr_rev_number)
<nevans> a little bit indirect.  but it should work
<nevans> to quickly get the bzr revision-id, you could do "bzr log --show-id | grep 29853"
 * hendrixski is confused
<nevans> sorry
<hendrixski> nevans, not your fault... I'm a total noob
<nevans> so you want to do "svn co http://whatever -r 12345"...
<nevans> what you could do instead:
<nevans> bzr co svn+http://whatever/trunk trunk
<hendrixski> right, so that's the head of trunk, right?
<nevans> then cd into trunk, and do "bzr log --show-id | grep 12345" to find out what the bzr revision id is
<nevans> yep
<hendrixski> ah
<hendrixski> ok
<nevans> then, with the revid in hand:
<nevans> bzr branch -r revid:svn-v3-trunk1:0487d25d-142b-0410-8fcf-b82ac621bf97:blahblahblah:12345 ../branched_from_12345
<hendrixski> ah... Ok, because those things are more complex than just the revision number  I see
 * hendrixski is still waiting for head of trunk to download
<nevans> BTW, it will go faster and use less disk space if you are using a shared-repository... but if you are just starting with bzr, you should probably wait until you are comfortable before you start working with that
<hendrixski> I'm totally just starting
<nevans> hendrixski: yep.  and that is why I asked jelmer if there was a svn revisionspec.  :)
<hendrixski> ah
<nevans> presumably, if there was, the entire ordeal could be shortened to just "bzr checkout svn+http://whatever -r svn:12345"
<hendrixski> in a perfect world I suppose
<hendrixski> hah, whadya know... the revision numbers are totally different than what I see on trac
<hendrixski> I thought I was supposed to be getting revision # 1480? but it's only actually up to 103
<nevans> hendrixski: same sort of issue
<hendrixski> yup
<hendrixski> oh man, no manual would ever have shown me that...
<nevans> bzr has quite a few ways of addressing a revision... none of them as simple as svn's "global" (per repo) changeset id
<nevans> bzr help revisionspec
<hendrixski> yeah, knowing the word for it (revisionspec) helps a lot too :-p
<nevans> in svn, the revno is global through the entire repository (all projects, branches, tags, etc).  in bzr, it is for just that branch.
<nevans> hendrixski: the only way I know the word for it is "bzr help topics"  ;)
<ubotu> New bug: #160607 in bzr-eclipse "seting plugin path in bzr settings breaks bzr support" [Undecided,New] https://launchpad.net/bugs/160607
<hendrixski> hhmm... bzr branch -r revid:102 ../New/
<hendrixski> bzr: ERROR: Not a branch: /home/******/Desktop/officialBranch/New/
 * hendrixski will figure this out  :-)~
<nevans> hmm... I had it wrong... you need to give it both to and from URLs (or just a from)
<nevans> bzr branch FROM TO -r 102
<nevans> bzr branch -r revid:102 . ../New/
<fullermd> You almost certainly don't have any revisino with the revid 102...
<hendrixski> nevans, you are THE MAN!!!!
<nevans> :)
 * hendrixski does a little dance as the earlier revision downloads :-)
 * hendrixski is done dancing 
<hendrixski> So then I guess the problem was that I assumed that the wrong thing was the actual revision number, I have to get the HEAD first, browse through which revisions exist, and *then* I get the right revision number and DL it
<hendrixski> which is what nevans said in the first line
<hendrixski> but I didn't understand it until after I tried it
<hendrixski> sweet
<nevans> yeah... revision numbers mean completely different things to svn and bzr
<hendrixski> I see
<ubotu> New bug: #160626 in bzr "need to suppress upgrade warning" [Undecided,New] https://launchpad.net/bugs/160626
<jodal> Hi! We're having problems with a repository used with 0.17 (etch) and 0.90 (gutsy). seemingly randomly, we get KnitCorrupt errors at some commits, and also at checkout of the entire branch: http://dpaste.com/24408/
<jodal> any tips?
<abentley> dato: Those commits should be there now.
<lifeless> hi abentley
<abentley> Hi there.
<lifeless> kindof a shame to be int he same TZ but so busy we don't get much time to chat
<lifeless> speaking of which, time to grab my jacket for dinner
#bzr 2007-11-07
<lifeless> wow quiet day
<beuno> we're all coding away before 1.0 closes  ;)
<Peng> I'm pinging out. :)
<lifeless> ;)
<lifeless> Peng: thanks for your patch to the docs; it's been merged I believe.
<Peng_> Lagggg.
<Peng_> lifeless: :)
<Peng_> 34.7s!
<lifeless> Peng_: :)
<lifeless> Peng_: did you see what I said ?
<Peng_> "thanks for your patch ...", yes.
<Peng_> Nothing after that.
<lifeless> that was all
<Peng__> Jesus!
<Peng> Sighhh.
<lifeless> lagathon?
<dato> abentley: yeah, thanks
<AfC> How come `bzr gdiff` doesn't work if multiple files are given as arguments?
<jelmer> AfC, simply hasn't been implemented yet
<AfC> jelmer: k
<AfC> jelmer: do you need a bug for that?
<jelmer> AfC: please
<AfC> Fine.
<AfC> I've actually been meaning to try and get into the gdiff code
<AfC> I'm not much for pygtk, but there are a couple of behaviours I want to recommend changing
<AfC> [*every* single time I run it I a) maximize, then b) drag the Paned divider to give it enough room to show me the file names, then c) move from "combined" to first file.]
<AfC> [getting a bit tedious]
<jelmer> there has been some talk about what to do with the diff window
<jelmer> perhaps we could call out to meld or something like that
<AfC> jelmer: (meld?)
<jelmer> meld.sf.net
<AfC> I came across some neat code in devhelp relating to remembering previous maximized-or-not state and acting accordingly to restore it on new instantiation. It's pretty good when done right.
<lifeless> moin
<lifeless> moin
<mwhudson> allegedly
<sverrej> Using bzr-svn, is it possible to commit locally and then push the commits together to subversion later?
<sverrej> bzr commit in a bzr-svn branch always commits directly to the svn server.
<luks> not if you use 'bzr branch' instead of 'bzr checkout'
<luks> you can either unbind the checkout or use commit --local
<sverrej> I tried commit local, but it told me "bzr: ERROR: Cannot perform local-only commits on unbound branches."
<sverrej> but I can try to unbind
<sverrej> or check out again
<sverrej> thanks!
<lifeless> sverrej: it's a double negative - thats already unbound
<mneisen> One question about the new knitpack format: is it possible to automatically delete the obsolete packs in obsolete_packs, or is it even possible to stop bzr putting obsolete packs in there at all?
<lifeless> mneisen: they should auto delete; I thought I had merged that
<lifeless> I'll check
<mneisen> lifeless: I just did a small benchmark with the new format, and i ended up with about 60 megs of files in obsolete_files.
<mneisen> lifeless: I use the 0.92rc1 version of bzr.
<Enquest> I did a "rm foo.css" how can I bring a file back ... With svn I only needed to do "svn update"
<lifeless> mneisen: it's not merged sorry; I have a patch to clean it up though
<lifeless> Enquest: bzr revert foo.css
<mneisen> lifeless: great news. Hope to see it soon in the released packages ... :-D
<lifeless> mneisen: it'll be in 0.93/bzr.dev later today; it's unlikel to be cherry picked into 0.92
<mneisen> OK. Thanks anyway ...
<mneisen> lifeless: Do you know by any chance when bzr-gtk will be up to speed, i.e. when bzr-gtk can be used with up-to-date bzr packages?
<lifeless> you can rm the contents of that dir safely
<lifeless> we use it to make operations wit flakey networks safer
<mneisen> lifeless:OK, will use rm.
<lifeless> just leave the dir itself around
<mneisen> lifeless: Anything about bzr-gtk (see above)?
<lifeless> it's just been released today
<lifeless> so 24 hours probably
<mneisen> lifeless: oic, didn't know that it was released today.
<mneisen> Thanks!
<dato> lifeless: "strict arch limits" (I'm unfamiliar with PAA)
<dato> er, PPA (see? :)
<siretart> dato: it builds for i386, amd64 and lpia only (well, anything xen supports)
<dato> oh, and bazaar-vcs.org has ppc?
<lifeless> hope to soon; need to hook it up
<siretart> currently amd64 and i386 only
<siretart> and I doubt that we'd have a lot of lpia users
<lifeless> also I'd like to get rpm's up
<siretart> lifeless: aren't there any plans to offer PPAs for debian chroots as well? (no idea about that)
<dato> why are debian packages on bazaar-vcs.org anyway?
<dato> sid is covered, lenny as usual, and I normally upload backports.
<siretart> they used to be undermaintained in the past?
<dato> plus lifeless could do any of those uploads if/when necessary.
<siretart> oh, I forgot backports. thanks dato!
<dato> (and backports is autobuilt these days)
<lifeless> dato: debian waits for releases
<lifeless> bazaar-vcs.org uploads beta's
<dato> lifeless: rc
<dato> sid gets rcs
<dato> and lenny, they'd migrate if there was time :)
<lifeless> It didn't in the past;
<dato> yeah, I'm just talking about the present
<siretart> lifeless: we do since the pkg-bazaar team got into shape
<lifeless> but more importantly, when debian next starts to release it will probably stop taking bzr versions
<lifeless> when the UVF kicks in.
<lifeless> It's true that this may be next decade :)
<siretart> there is backports.org for stable and oldstable
<dato> (I'm personally not uploading for oldstable atm)
<lifeless> siretart: and it's great the team is in shape - I'm in it too :)
<dato> lifeless: anyway, I'm not unhappy in any way, just wondering.
<lifeless> the basic thing is that the bazaar-vcs.org is geared around bzr's release cycle; even sid is geared around debians release ccle, so we need something for bzr enthusiasts during debian stabilisation.
<lifeless> (this is why we have ubuntu debs too)
<lifeless> the ubuntu one is much more visible because its 6 monthly
<lifeless> I'd also like to get daily builds up; its on my todo
<lifeless> we had them for baz and users lovd them
<pattern> i'd like to put keep some of my system configuration files in /etc under revision control... so should i do something like "mkdir /etc/bzr ; cd /etc/bzr ; bzr init ; cd /etc"  ?
<pattern> and then, how would i add, say, /etc/make.conf to my new /etc/bzr repository?
<pattern> oops
<pattern> oh, that's right... i thought i mistyped that question
<pattern> but it's typed correctly :)
<pattern> or maybe i should just "cd /etc ; bzr init" and then just "bzr add make.conf" from /etc itself ?
<lifeless> statik: where are you ?
<nevans> pattern: I simply put my entire /etc dir into bzr.
<nevans> cd /etc; sudo bzr init; sudo bzr add; sudo bzr commit -m "version controlled /etc"
<Le-Chuck_ITA> hi there, I am using bzr-gtk found in ubuntu gutsy
<Le-Chuck_ITA> and olive does not seem to correctly recognize bzr branches on my disk
<Le-Chuck_ITA> it only shows the directories and not the files, and offers disabled menu entries for handling the branch
<Le-Chuck_ITA> how do I open a branch with olive? And how do I bookmark it?
<Le-Chuck_ITA> it's such a simple program that you easily exhaust all the possible operations :)
<pattern> nevans: nice :)
<pattern> the only thing is that with gentoo, there's a lot of automatic messing with files in /etc
<pattern> so i don't want to keep having to commit a ton of changes by hand
<pattern> there are handful of files that i edit manually, and those are the ones i really want to keep under bzr's version control
<pattern> anyway, the stuff that gentoo messes with itself are automatically kept under RCS version control via dispatch.conf
<bialix> luks: hi
<luks> hi
<bialix> I fixed problem with lock and pack repo in my branch
<bialix> I just wonder: when you're planning to release QBzr 0.7.0?
<luks> hmm, I guess I could do it over the weekend
<bialix> it will be great
<nevans> pattern: I just do the whole /etc directory because it's easier.  simply "sudo bzr add; sudo bzr commit", and you're done.  I don't mind that I'm versioning a few extra things that I don't care as much about.
<pattern> it's going to be a ton of extra things for me
<pattern> on the other hand, when i do a "bzr status", it lists a ton of "unknown" files and directories
<nevans> yeah, that's the other reason I do the whole thing... then I know when anything in there changes.
<bialix> luks: do you still prefer to file wishes to QBzr in bug tracker?
<fullermd> pattern: I version just a few files out of /etc (and /usr/local/etc, and similar places).  I just have '*' in .bzrignore, and manually add the bits I care about.
<nevans> fullermd: that makes sense... that's what I do in my home directory.
<luks> bialix, yes, since otherwise it's very easy to forget them
<nevans> err... the home directory itself ignores .*  ...some of the subdirectories ignore *
<nevans> (although... my home directory is actually still using svn, not bzr... and ignores behave a little bit differently in svn)
<pattern> ahh... ".bzrignore" ... i should look in to that :)
<bialix> luks: ok, because I have 2 new items to wishlist: search in qlog and working with tags in qlog window
<luks> search in qlog was on my unwritten todo list already
<luks> but please add it anyway
<luks> it's better to have all ideas on one place
<bialix> can we collaborate on search feature sometime?
<luks> I haven't touched the code for a while, so I'm not sure when I'll have time and motivation to work on it
<bialix> ok
<luks> I usually add new features only when something really annoys me or I'm really bored :)
<bialix> me usually too
<Jamon> is there a way to uncommit a specific commit out of order?
<Jamon> perhaps undo changes is a better way of saying it
<lifeless> not really; there is a way to merge it out - to reverse it. But it is part of the written history so it can't be removed without rbeaking referntial integrity
<lifeless> so - 'bzr merge -r234..233 .'
<lifeless> that will remove commit 234 for you
<lifeless> (you need to commit after that naturally)
<Jamon> i made a commit that changed mysql functions to pgsql, now later on i just want to switch back to mysql... so bzr merge -r will allow me to do that?
<lifeless> yes
<Jamon> whats the diff between that and revert?
<lifeless> revert undoes all changes to the selected paths from the revision forward
<lifeless> spiv: reconcile on launchpad is up to 4.5Gb and no progress marker yet
<Jamon> so revert is full sequential, and merge is from points out of sequence
<lifeless> yes
<dodijk> Hello! Does anybody have any experience with using bazaar on a branch on a hfsplus filesystem? I get permission errors (on .bzr/branch-format) when trying to add files. Moving the branch to ext3 fixes this...
<dato> dodijk: maybe jam-laptop knows about that, but he doesn't seem to be around right now
<dodijk> data: ok, i'll try again some other time
<nir> Is there a shortcut to create a new branch WITH the current changes in the tree?
<beuno> nir, uncommited ones?
<nir> yea
<beuno> nir, I don't think you can do that with bzr, no. As far as I can tell, bzr brings in the repository and restores the working tree from it
<beuno> rsync would work though
<fullermd> branch ; merge --uncommitted
<beuno> ah, there you go
<beuno> I learn new things here everyday...
<nir> great
<nir> although branch --uncommitted would be even nicer
<beuno> nir, you can file a bug requesting it. Unless fullermd has a good reason why not to have it
<nir> its a feature request, not a bug
<beuno> nir, right, it would be wishlist, I don't believe there is something specific for feature requests in Launchpad
<beuno> blueprints seem like and overkill, and I believe they don't have "states" so you would know when it gets implemented
#bzr 2007-11-08
<abentley> beuno: In Launchpad, wishlist appears to be a bug severity level, not a different kind of bug.  A wishlist bug is an extremely low-severity bug.  A rare, easily worked-around kind of thing.
#bzr 2008-11-03
 * fullermd calls it late for lunch.
<poolie> markh: if you're around, any idea off hand why getaddrinfo would fail on xp?
<poolie> per https://answers.launchpad.net/bzr/+question/4949
<markh> while I look - interesting pre-PEP on DVCS discussing hg and bzr - http://docs.google.com/View?docid=dg7fctr4_40dvjkdg64
<markh> poolie: 4949 is about dual-booting ubuntu?
<poolie> heh
<poolie> sorry, https://answers.edge.launchpad.net/bzr/+question/49498
<markh> so, 10022==WSAEINVAL, so winsock doesn't like one of those params I'd guess
<markh> although windows seems documented as supporting AI_PASSIVE
<markh> however, "socket.getaddrinfo('www.google.com', 80, socket.AF_UNSPEC, socket.SOCK_STREAM, 0, socket.AI_PASSIVE)[0]" works for me!
<markh> (in the more general case though, that user probably just needs to be made aware they can just 'push' to some other server - there's no real need to run an actual server on their box)
<poolie> mm
<poolie> here it's probably looking up 127.0.0.1:4155
<poolie> if she were on debian i'd almost suspect an ipv6-only configuration or something but that seems unlikely here
<spiv> Today is the last day for PyCon 2009 submissions: http://us.pycon.org/2009/conference/proposals/
<Neil> alright, bazaar in, old sources imported with history, trac integrated.    Thank you again LarstiQ if you see this.
<justizin> hiya, i have branched some code from svn, and it is in a rich-root-pack repository for bzr-svn, i want to branch it for use as pure bzr with a more modern storage means, but when pushing to a shared repo, i get an error.  is there anything i can do?
<jelmer> justizin, "pure" bzr?
<justizin> well, i mean, it uses rich-root-pack because bzr-svn requires that.  i don't care about svn compat anymore, because i am abandoning it for this branch / project.  seems i can't branch into another storage format..
<jelmer> justizin, rich-root-pack is a standard supported bzr format, and will be the default at some point in the future
<jelmer> it stores more data than the current default, so there's no way to downgrade
<justizin> oh, really? i was under the impression the current default was more modern..
<justizin> okay, well, if it's better, than i'll just roll with it. :)
<justizin> it would be nice to be able to downgrade, still, but for my purposes, clearly not necessary.
<jelmer> if you mean the 1.6.1 format, there is a rich-root equivalent of that
<justizin> yah i guess i should try it with a branch on a machine with newer bzr, i am still on ubuntu LTS with system packages... will be moving our svn / bzr / trac to ibex next weekend or so.
<justizin> anyway, if rich-root-pack is not a bad format to use for just using bzr, then that's fine, i thought it was some kind of compromise, but i guess it makes sense that it is, well, duh, richer.. ;d
<justizin> thanks jelmer
<jelmer> hopefully it'll be the default in the next version
<justizin> 1.8, or the next in 1.7 series?
<jelmer> no, more like 1.10
<justizin> that is: major / minor ?
<justizin> ah ok
 * justizin is so tired of .10 versions, seem to infect our whole python community ;d
<justizin> i think zope is working on 2.12 :-P
<justizin> is there a way to make a copy of a whole shared repository?
<justizin> as if to branch the whole thing..
<jelmer> justizin, I think there may be a plugin that can do that
<justizin> any idea of keywords i might seek? :)
 * justizin is so thankful for bzr this year, esp bzr-svn has made unimaginable things possible..
<justizin> i mean, there is svk, but, i dunno, i have a hard time sleeping with a process that depends on perl ;d
<jelmer> I'm not sure what the name could be
<justizin> eh i'll sort it later
<jelmer> Odd_Bloke wrote it, but he's probably asleep atm
<justizin> i could probably keep it all in one shared repo and share data, but maybe what i really want is like nested shared repos that can be treaated as branches, which i probably shouldn't pontificate on, on a sunday evening. :)
<justizin> like i took a set of build files, and made them into three sets.  then, i decided i wanted to do new work with trunk/head/whatever dependencies, so i want to branch those three sets, which is a shared repo with three branches of one upstream branch..
<justizin> right now, i have one deployment config with database config, software install, and app server config, and i want to separate those so that they can use different python installs, or at least not break each other when testing python updates, and for other reasons..
<justizin> so, yanno, i figured, make three copies of the deploy config, rip out the unneeded bits of each segment..
<justizin> now i want to update all dependencies, and have a merge path..
<justizin> probably something i should put some brain and coding time into if i want it. :)
<jelmer> sorry, I was about to get some sleep
<justizin> hoping to snag some big contracts which will depend on branching / forking lots of upstream code and reorganizing some.. bzr is so great for that.
<justizin> no worries jelmer, i ramble.  rest your svn-battered mind :)
<justizin> ciao..
<jelmer> :-) ciao
<justizin> :-P
<justizin> hey jelmer if you are still around, can you recommend a good nl beer? i have good imports here in SF and get tired of my same old rounds.. :)
<jelmer> justizin, heh :-)
 * justizin figures all good programmers have good beer taste
<jelmer> justizin, My favorite is "Hertog Jan", it's not too big in the US though I think
<justizin> hm, i will look around.  we certainly aren't a european import city, but we have lots of euro imports..
<justizin> i remember when i was in amsterdam, heineken was like budweiser in us
<justizin> same in hamburg, actually
<justizin> freakin' lager ;d
<jelmer> yeah, Heineken is the most generic beer you can get
<justizin> well, i grew up in texas, before i was 21 heineken was a big step up from budweiser
<justizin> but i dont think i had any when i went to AMS
<jelmer> Grolsch is also pretty common but a bit nicer (and probably available in the US)
<justizin> i think we had guiness at the bull dog
<justizin> grolsch i think we have at whole foods maybe
<justizin> i'll try it
<justizin> also tons of import taps in SF
<justizin> buddy of mine just left high-end server gig to answer phones for amex top tier folks..
<justizin> we have nice microbrew, but import is always nice here and there
<justizin> anyway, go crash
<justizin> lol
<justizin> didnt mean to keep you up
<justizin> ttyl
<justizin> oh yah and like "Server gig" i meant beer more than internet :-P
<poolie_> spiv, hi, did you decide in the end to work on that bug or to try the repo branch?
<spiv> poolie_: trying out the repo branch.
<poolie_> how is it?
<spiv> poolie_: so far it looks like there's no network regressions according to my bzr-usertest branch -- once I merge current bzr.dev in.
<poolie_> nice
<poolie_> btw is there still anything i could review for you wrt usertest?
<spiv> (Although curiously it appears that maybe initial push gotten slower on high-latency links in bzr.dev vs. the bzr.dev the repo branch was merged up to...)
<spiv> Hmm, not sure, let me look.
<spiv> I do miss the "just mail and forget" patch submission that bzr gets via bundle buggy.
<spiv> poolie_: https://code.edge.launchpad.net/bzr-usertest/+activereviews lists two things that need review, IIUC what the UI is telling me
<poolie_> ok
<poolie_> :/ i didn't really want to get back into 100% code reviews
<poolie_> but i don't want things getting stale either
<spiv> Well, maybe I should just merge them?
<poolie_> i'll have a look after i finish merging back to trunk
<spiv> poolie: ok.
<poolie> spiv, all are done now
<spiv> poolie: thanks
<Peng_> Wait, is there a subtree variant of the 1.9 format?
<igc> spiv, poolie: if it helps, I'm happy to review usertest stuff in the next few days
<igc> be a nice change from ploughing through my 2000+ emails :-)
<poolie> hello igc
<igc> hi poolie
<lifeless> Peng_: development2-subtrees
<poolie> spiv, can you send a paragraph or so about what you discovered about the repo branch and networking
<poolie> if you're still online
<spiv> Sure.
<Peng_> lifeless: Using a development format doesn't sound ideal.
<Peng_> Does "bzr pack" optimize how all of the data is ordered?
<spiv> Peng_: a quick glance at the code suggests that it does
<Peng_> thanks
<lifeless> Peng_: true; OTOH its available in 1.7 and above I think
 * Peng_ grumbles again about downgrading from subtrees to rich-roots.
<vila> hi all
<igc> hi vila
<vila> hi Ian !
<igc> night all
<gour> hi, i upgraded my system to python-2.6 and now i get "/home/gour/.bazaar/plugins/search/index.py:22: DeprecationWarning: the md5 module is deprecated; use hashlib instead
<gour>   import md5" warning all the time
<gour> how to get rid of it?
<gour> it's, afaik, lifeless's plugin
<Peng_> You...ask lifeless to use hashlib instead? :P
<Peng_> (Well, try: hashlib and fall back to md5. Anyway..)
<Peng_> gour: If you know a bit of Python, it shouldn't be difficult to fix the warnings and send a patch.
<Peng_> (I don't mean to sound unhelpful, but not everybody has access to Python 2.6.)
<gour> Peng_: well, the question is more in line what's the bzr plan in regard of 2.6 support?
<Peng_> Oh.
<Peng_> A few patches to help Python 2.6 compatibility have been merged.
<gour> that's nice to hear
<Peng_> Or at least proposed..
 * gour replaced the calls ==> no warnings any longer
<lifeless> poolie: I think I'm calling it a day :P
<lifeless> Peng_: btw development formats are stable, just not long term supported; so you can get support etc, just not expect to leave the repo unattended for 3 or more releases
<Peng_> lifeless: Yeah. Having to remember to keep an eye on my repo is stupid.
<Peng_> Eh, sorry.
<Peng_> I'm grumpy about the subtree/rich root thing again. :P
<Peng_> gour: Yeah, the big Py2.6 patch was merged in bzr.dev r3751.
<lifeless> Peng_: fair enough, I'm not thrilled either; it is moving slowly
<lifeless> Peng_: the point of --development is to allow folk that need a fix (e.g. performance/features) to access it before its finalised-forever
<gour> Peng_: ta for the info
<Peng_> I'm not that impatient.
<Peng_> I did upgrade a couple repos to --1.9 shortly after it was finalized, but I don't feel like dogfooding much anymore.
<Peng_> (Well, maybe a little, when it's safe.)
<gour> there will be some format-removal in 1.9?
<Peng_> Is there anything really difficult about supporting going from subtrees to rich-roots or is it just that nobody's done the work?
<lifeless> Peng_: dev2-subtrees wouldn't be dogfooding as such, fwiw. Its just a label :). Anyhow ..
<lifeless> subtrees to rich roots requires checking that no inventory entry is a subtree
<lifeless> noone has optimised that check
<lifeless> gour: format removal breaks older clients; we try to keep the list of visible formats short
<Peng_> So it isn't difficult to do, it's just difficult to do quickly?
<lifeless> Peng_: right
<Peng_> Or at least nobody has done the work to figure that out yet.
<gour> lifeless: i understand. it's still, imho, too big
<Peng_> lifeless: Where does "bzr branch"ing from subtrees to rich-roots fit in?
<Peng_> It works, though it's not super-fast.
<gour> lifeless: let 'em upgrade or stay with older version. how long you will drag 'em around'
<gour> ?
<lifeless> gour: I'm not sure
<Peng_> gour: Some truly ancient formats are still supported.
<lifeless> anyhow, must go
<gour> Peng_: bzr init (repo) gives too many choices ;)
<lifeless> tere is a bug about presentation here
<lifeless> which would reduce the multiplication a lot
 * lifeless goes
 * gour just built r3818 pkg
<gour> nice, no more warnings...
<gour> ahh, there are still some
<Peng_> Blaah.
 * Peng_ converts one of his subtree repos to rich-roots using the init/pull trick, since it only has one branch and is unimportant anyway.
<gour> i need to merge two branches without common ancestor, how to do it?
<gour> i'm trying with bzr -r x branch, but does not work
<poolie> gour: bzr merge  -r 0.. ../other
<poolie> should do it
<gour> why -r ancestor:branch did not work?
<Peng_> BTW, branching bzr-svn's 0.4 branch from pack-0.92-subtree to 1.9-rich-root took 2 or 3 minutes. Doing it from 1.9-rich-root to 1.9-rich-root took 4.54 seconds, including building the working tree. Nice.
<gour> Peng_: so, 1.9 adds to the list of formats..
<Peng_> gour: :)
<gour> the list of formats does not fit on one screen :-/
<gour> it's pity if devs do not see it as a problem
<Peng_> I'm sure it'd fit with a 2048x1536 monitor and a small font. :)
<gour> heh, good joke
 * gour is running 1450x laptop atm
<gour> running latest bzr with bzr-svn-0.4.13 gives: bzr: ERROR: Version mismatch
<Peng_> gour: Edit the compatibility info in bzr-svn's __init__.py.
<gour> Peng_: there is some new bzr-svn release around the corner?
 * Peng_ shrugs
<Peng_> I run bzr.dev and bzr-svn's 0.4 branch.
<Peng_> They *are* compatible, but the compatibility checking hasn't been updated.
<Peng_> (Well, it has been since 0.4.13 was released.)
<gour> i see...still, my main problem with bzr-svn is lack of support for svn:externals
<Peng_> That won't happen until bzr supports it.
<gour> stacked branches are not enough?
<Peng_> Stacked branches are totally different.
<gour> err, nested branches?
<Peng_> Oh. Yes. I have no idea what state nested branch support is in, so I can't answer that.
<Peng_> Anyway, it's not considered production-ready..
<gour> ok. that's not so important considering that i can do 'svn up' for those repos where i fetch, but reducing number of formats is definitely more serious issue
<Peng_> It's kind of too late now. Backwards compatibility is important.
<gour> sure it is, but plethora of formats shows something is wrong with bzr-format
<gour> what do you think about http://rafb.net/p/WGzz9k72.html ? is it for bzr or push-and-update plugin?
<Verterok> gour: looks like a python 2.6 <-> bzr issue
<gour> Verterok: ahh, too bad :-/
<gour> Verterok: should i submit ticket for it?
<Peng_> Uhh
<Peng_> Oh, never mind
<Verterok> gour: that would be ok, but I don't think that 2.6 is a supported version (2.4 and 2.5 are)
<gour> Verterok: hmm, what do you. 2.6 is default python here :-/
<Verterok> gour: please, file the bug. I think there is some work-in-progress (tm) to support it
<Peng_> Even if it's not supported now, the only way to support it in the future is to fix the bugs.
<Peng_> s/bugs/compatibility issues/ ..
<gour> ok, i'm going to submit bug report
<gour> submitted - #293054
<Verterok> gour: thanks
<jelmer> abentley, ping
<jelmer> abentley, any eta for bzrtools 1.9?
<abentley> jelmer: Sure, I'll see about it today.
<jelmer> james_w, hi
<james_w> hey jelmer
<jelmer> james_w: I'm going to do more (sponsored) work on bzr-git
<james_w> jelmer: great!
<jelmer> james_w: And I'd like to use your python-git module for that, extending it where necessary
<james_w> um, sure
<jelmer> james_w: However, the name is a bit non-unique - what do you think about renaming it ?
<james_w> let me know if I can help with anything
<james_w> go ahead, it was just a weekend hack
<jelmer> thanks :-)
<jelmer> james_w: Btw, any news on my merge-upstream-branch patch for bzr-builddeb ?
<jelmer> It doesn't seem to fit well into the new infrastructure, should I adapt it to that?
<james_w> let me take a look
<BUGabundo_work> hi
<BUGabundo_work> can some mailinglist admin moderate my email ? I'm not on the list!
<james_w> jelmer: my only concern would be the  upstream_branch_version() stuff
<james_w> it looks sane, but it's quite magical
<jelmer> james_w: I can document it a bit better, perhaps let the user know where we got the version from?
<james_w> yeah, that might help
<jelmer> james_w: It's only intended as fallback if the user doesn't specify a version
<james_w> it looks like it would be doing what the user wants, and this merge-upstream stuff is quite magical anyway
<jelmer> james_w, I'll see about adding some docs and being a bit more verbose as to where the version comes from
<jelmer> james_w, what branch should I submit against ? lp:bzr-builddeb or lp:bzr-builddeb/2.0 ?
<james_w> jelmer: the former please
<james_w> I'm going to merge the latter in to the former soon, and just keep the latter for any critical bug fixes for Intrepid
<james_w> thanks for looking at it. I kind of want to think about it some more, but I'm aware that I don't actually do that and it just ends up un-merged, so I'm tempted just to merge it.
<james_w> jelmer: is https://code.edge.launchpad.net/~jelmer/bzr-builddeb/452130/+merge/1511 fixed?
<jelmer> james_w, yeah, you've already merged it
<james_w> cool, thanks
<jelmer> I've just removed it (took a while to find the button)
<jam> hi mm-mysql, funny to see you around here :)
<mm-mysql> :)
<mm-mysql> I should hang out here more often, we often run into things we'd like to talk to you guys about on my team.
<mm-mysql> So, are you actually local to where we ran into each other or just visiting?
<weigon_> mm-mysql: *doh* :)
 * mm-mysql waves at weigon
<jam> I live about a 15min walk from where we met. So I think that counts as "local" :)
<jam> what about you
<mm-mysql> I'm 5 minutes walk from Flossmoor Station...do you drink beer? :)
<jam> I've been known to have some from time to time. The Brewery there is a nice restaurant.
<mm-mysql> Well, if you're up for it sometime, we should meet up...even if not for beers.
<jam> definitely
<jelmer> james_w, I've pushed an updated version to http://people.samba.org/bzr/jelmer/bzr-builddeb/merge-upstream-branch/
<gour> Peng_: bzr's user-manual says: "
<gour> ERC>
<james_w> thanks jelmer, looking now
<gour> Peng_: "Plugins are helpful at feature retirement time as well, e.g. deprecated file formats may one day be removed from the Bazaar core and be made available as a plugin instead." why it is not followed?
<dissonans> what's the best way to see the history of merges in a repository
<Peng_> gour: It would take work, I guess.
<dissonans> i.e., I want to check which revision I last merged from another repo
<gour> Peng_: then better remove that sentence from the docs ;)
<Peng_> gour: "may one day" doesn't mean it has to be now. ;P
<awilkins> dissonans: Try qlog in the qbzr plugin
<dissonans> awilkins: thanks, trying that now
<dissonans> awilkins: can that tell me the parent revision from the other branch, though?
<jam> dissonans: you might also try:
<jam> bzr log -r ancestor:other/branch
<jam> or
<jam> bzr missing other/branch
<jam> depending on what you want
<mattions> hello
<mattions> Has the svn plugin been integrated directly in bazaar ?
<Peng_> "Integrated directly"?
<Peng_> It's still a plugin, but it works perfectly well.
<jam> I have the feeling he might mean "bundled with the installer", but I'm not sure.
<Peng_> Oh.
<mattions> Ok I'm running the 1.9rc
<mattions> and synaptic does not want to install the plugin anymore
<Peng_> I guess it hasn't been marked as compatible with 1.9 yet.
<mattions> Should I install the plugin bymyself
<mattions> and see if ti works?
<dissonans> jam: thanks, "missing" was the command I was missing :]
<dissonans> Peng_: it's not even compatible with 1.8?
<mattions> actually it seems the plugin is still there because when i try to push it ask me to authenticate
<Peng_> mattions: It will work, it just might need to be marked as compatible.
<mattions> to the SVN
<mattions> but then I've got this error:
<mattions> bzr: ERROR: Transport operation not possible: http does not support mkdir()
<mattions> but I'm using https!
<Odd_Bloke> mattions: The secure version of the HyperText Transfer Protocol still uses the same protocol, which doesn't support mkdir(). :)
<mattions> but before it worked!
<mattions> well, anyway good to know
<Odd_Bloke> mattions: The same operation worked, or different operations?
<mattions> so the question is: how?
<mattions> same operation..
<mattions> added some directories with bzr and then pushed everything
<mattions> in the svn
<Odd_Bloke> mattions: Pushed everything to SVN?  And you've been able to push before?
<mattions> yep
<Odd_Bloke> mattions: OK, look in ~/.bzr.log.
<mattions> Odd_Bloke: I think I screw up something... let me check that ..
<Odd_Bloke> mattions: Sure.
<mattions> Odd_Bloke: it worked
<mattions> so the plugin has been deinstalled by synaptic
<mattions> at some point, and I didn't notice
<mattions> I installed the last plugin from the site directly and everything worked
<mattions> even the "add" of new directories
<Odd_Bloke> mattions: Cool.
<jelmer> james_w, I've just filed two more merge requests
<james_w> yeah, I was just about to reply to the get-orig-source one
<james_w> do you want the response here instead?
<jelmer> james_w, Whatever works for you
<james_w> k
<james_w> My thought was that the try for get-orig-source would come before debian/watch, why did you put it the other way around
<james_w> and also, if debian/watch exists, but uscan fails it doesn't try get-orig-source, is that what we want
<jelmer> mainly because it's a bit more verbose
<james_w> obviously if the order was swapped then that would become more complex
<jelmer> since if get-orig-source doesn't exist in debian/rules you get an error message
<jelmer> would there be situations where you would want to use get-orig-source but also had debian/watch  ?
<james_w> I'm not sure
<james_w> but I think if I had both I would want get-orig-source to be used
<james_w> but having both would be confusing
<jelmer> yeah, I think having both is undesirable
<james_w> I think I'll merge what you have, and deal with any bug reports
<james_w> then at least I can ask how they expect this to be handled
<james_w> thanks
<james_w> for the other one, I'm not so sure
<james_w> firstly, I don' think it fixes the bug Martin reported, does it?
<jelmer> it does, since it will use an existing file rather than overwrite it
<jelmer> it also fixes my problem with the checksum of the .orig.tar.gz changing
<james_w> but Martin gets the failure when the file is copied back
<james_w> sorry, moved to the result dir
<jelmer> ah, you're right - sorry
<jelmer> I should've read the bug report more closely
<james_w> no problem, it may still be worthwhile
<james_w> overwriting what was there was a concious choice when I implemented this
<jelmer> Reading the bug report again, I think overwriting is a fair choice
<james_w> for the case when you have "export_upstream" with no "export_upstream_revision", and then the upstream branch changes without the upstream version number changes
<james_w> in that case if you don't overwrite you build the wrong code
<james_w> Martin's bug report is a separate issue that doesn't even need export_upstream to trigger it, and I have an idea of how to at least improve that situation
<jelmer> yeah, there are several corner cases like that I guess - changing get-orig-source would be another
<james_w> would it work if we made it so that it didn't overwrite if you had export_upstream_revision, or you were using the ~bzr magic?
<james_w> but changing export_upstream_revision would break it
<james_w> I don't think it's soluble unless we store the revid of the version used to create the tarball with the tarball
<james_w> which isn't that easy at the moment
<jelmer> hmm, you're right
<jelmer> I'll withdraw that one and give it some more thought
<jelmer> james_w, did you have a chance to look at merge upstream branch one ?
<james_w> jelmer: yeah, I reviewed it
<james_w> jelmer: yeah, I think I'll merge it, with a couple of tweaks, once I have merged 2.0 into trunk
<james_w> thanks for working on it
<jelmer> james_w, thank you!
<jcastro> emmajane: ~1 hour until your session!
<emmajane> yup!
<emmajane> I'm already in teh classroom.
<emmajane> And I've almost got everything pre-typed...
<emmajane> jcastro: some of it may be too basic...I guess we'll find out though...
<jcastro> emmajane: it's ok alot of questions today have been by new users so this should work out just fine
<emmajane> cool
<emmajane> jcastro: I'm just making a quick tea and grabbing a snack. Notes at: http://pastebin.ubuntu.com/66903/
<jelmer> oh, it's ubuntu open week again?
<LarstiQ> new release, I suppose that gets a fair share of new users
<emmajane> yup :)
<emmajane> btw you're welcome to run through those notes and let me know if you've got any comments.
<jelmer> cool
<emmajane> I've got the UBER basic session. :)
<LarstiQ> emmajane: not bzr related, but you mention using aptitude and then go on to use plain apt-get :)
<emmajane> LarstiQ: oops, yea. :)
<emmajane> thanks
<LarstiQ> emmajane: 'bzr add' has the effect of adding all files in the tree, 'bzr add *' could miss things that the shell doesn't expand to (like .files)
<LarstiQ> that is, bzr add without any argument
<emmajane> ahh, ok.
<jelmer> emmajane, Looks good :-) Also a minor thing - I think Launchpad should be spelled with a lowercase p
 * emmajane removes the *. Not sure why I have that actually, I've never added files with an *.
<LarstiQ> emmajane: if you think it is clearer with an argument, I suggest 'bzr add .' instead of *
<LarstiQ> :)
<luks> bzr add * would also add ignored files
 * emmajane nods.
<emmajane> * gone.
<emmajane> who needs stars anyway. ;)
<LarstiQ> emmajane: bzr diff -c might make more sense than -r if you are looking at historical changes
<LarstiQ> emmajane: -c revno does -r revno-1..revno
<LaserJock> anybody know if it's possible to get bzr multi-pull to output more data like bzr pull? like showing the changed files
<LarstiQ> emmajane: whereas -r revno compares the current state of the working tree against that version
<emmajane> I thought I had both?
<jelmer> LaserJock, not atm
<emmajane> isn't $ bzr diff -r# FILENAME current to revno?
<emmajane> and $ bzr diff -v -r#..# FILENAME compares two versions in history?
<LarstiQ> emmajane: ah, I misread a bit.
<jelmer> emmajane, perhaps mention "bzr status" before the commit ? that should also be helpful when doing incremental commits and for example forgetting to add new files.
<LarstiQ> emmajane: I'd also mention `bzr help topics`
<emmajane> thanks for the suggestions!! :)
<LarstiQ> emmajane: and `bzr viz` is always nice for pretty graphs ;)
<emmajane> LarstiQ: they won't have anything /to/ graph though. :(
<emmajane> bobbo might tackle that in his session.
<LarstiQ> emmajane: bzr get lp:bzr; cd bzr; bzr viz?
<LarstiQ> emmajane: when is this session btw?
<NfNitLoop> I wish I could get my company to use bzr.
<LarstiQ> NfNitLoop: what is holding you back?
<NfNitLoop> they've built this custom deployment system against svn.
<NfNitLoop> so there would be a lot of stuff to change.
<NfNitLoop> they also seem to be fond of having a monolithic svn repo for every project, much to my dismay.
<NfNitLoop> but we're starting to get merging headaches because multiple teams will touch the same file/heararchy.
<NfNitLoop> and every time I have to manually merge something in svn 1.4 I daydream of bzr. :p
<nevans> NfNitLoop, for svn, it often makes sense to have a monolithic svn repo.  less for sysadmin's to maintain.  no overhead to creating a new project.
<emmajane> LarstiQ: started about five minutes ago.
<nevans> NfNitLoop, have you tried bzr-svn?  :)
<NfNitLoop> nevans: I have.  It breaks on our repo.
<nevans> NfNitLoop, :-(  it occasionally breaks on mine too.
<NfNitLoop> I haven't tried the bzr1.9rc/bzr-svn combo.
<NfNitLoop> I'd love to use bzr-svn for my own branches. :)
<nevans> NfNitLoop, I'm actually testing that out now to see if that combo works on my repo (it was broken in 1.7, 1.8)
<NfNitLoop> yeah, I don't think bzr-svn worked with 1.8?
<NfNitLoop> nevans: let me know if it fixes your issue and I'll give it a go with ours. :)
<nevans> I've gotten into situations where "bzr pull" would work with an already exported repo... but an initial "bzr branch" wouldn't.
<NfNitLoop> it'd be cool to just have svn for our trunk and then have bzr branches everywhere. :p
<LarstiQ> emmajane: cool, dropping by as backup
<NfNitLoop> nevans: w/ 1.9?
<emmajane> thanks, LarstiQ :)
<nevans> NfNitLoop, not sure yet.  still doing the initial dump.
<LarstiQ> NfNitLoop: I started using bzr-svn for my own branches of stuff in svn.
<NfNitLoop> nevans: Yeah, there are known issues with bzr branch w/ large svn repos.  svn1.4 python bindings have a memory leak.
<nevans> it takes more than two hours to do a branch of my main project.
<NfNitLoop> nevans: you can work around it by only pulling X number of revisions at a time.
<LarstiQ> NfNitLoop: now two of us are doing things in pure bzr, and two others have started using it as well (that's half the development team there)
<jelmer> NfNitLoop, the stock svn python bindings are no longer used
<NfNitLoop> jelmer: Oh?  Nice!
<NfNitLoop> jelmer: is that new in the 1.9-compatible versoin?
<NfNitLoop> nevans: Yeah, that bit's no fun, but once you have it in bzr, you can branch to other bzr branches, no?
<NfNitLoop> and that should be speedier.
<nevans> NfNitLoop, yep
<jelmer> NfNitLoop, no, that's been in there since 0.4.11
<jelmer> (compatible with bzr 1.5)
<nevans> jelmer, ps u | grep [b]zr\ branch | awk '{ print $6 }' tells me that I'm using 1371548 and slowly growing.  :(
<NfNitLoop> Ohrealy?  (Has it been *that* long since I've played w/ bzr-svn?)
<NfNitLoop> nevans: Yeah, that's the issue I had.
<nevans> copying revision 11839/15819 (been running for over an hour)
<nevans> NfNitLoop, in the olden days, it would have run out of memory *long* ago
<NfNitLoop> hehe.
<NfNitLoop> well, hrmm, now I want to give it a try.
<gour> jelmer: 0.4.14 works with 1.8?
<jelmer> gour, no, with 1.9
<jelmer> gour, 0.4.13 works with 1.8 (although it may warn about being possibly incompatible)
<gour> jelmer: hmm, then i cannot upgrade my archlinux pkgbuild 'cause arhc has bzr 1.8
<gour> yes, 0.4.13 spits some warnings
<jelmer> but other than that it should work fine with1.8
<nevans> NfNitLoop, one thing to be aware of with bzr-svn: there are currently some nasty race conditions (because bzr has different locking assumptions than svn), so I think that the "rebase/dpush" workflow is probably the safest right now.
<NfNitLoop> nevans: I'm not familiar with rebase/dpush...
<gour> jelmer: ok. i already put 0.4.13 in AUR
<jam> jelmer: I saw you released 0.4.14, but I don't see the tag in lp:bzr-svn
<jam> I guess it is in the 0.4 branch
<jelmer> yeah, it's there in the 0.4 branch
<jelmer> the debian-experimental branch has debian-0.4.14-1 as tag I think
<NfNitLoop> aww, 1.9/0.4.14 has the same issue w/ our svn repo.
<NfNitLoop> SubversionException: ("REPORT request failed on '/svn/app/!svn/bc/19280'", 17500
<NfNitLoop> 2)
<NfNitLoop> which I haven't really bothered tracking down.
<nevans> :(
<nevans> I'm still waiting for my branch: copying revision 12981/15819
<emmajane> jelmer and LarstiQ thank you thank you thank you!!!!
<LarstiQ> emmajane: np :)
<NfNitLoop> aha, apparently the REPORT issue is due to some incorrect proxying.
<NfNitLoop> svn log <url> gets the same error.
<NfNitLoop> (after showing quite a few revisions)
<NfNitLoop> I'll bug my sysadmins. :p
<LarstiQ> emmajane: thank you for running this intro session
<poolie> hello LarstiQ, emmajane
<jelmer> np :-)
<jelmer> 'morning poolie
<emmajane> LarstiQ: np :)
<poolie> and jelmer
<jam> poolie: hi, I forget DST switched :)
<poolie> so confusing!
<poolie> i actually bought a watch with a utc display :)
<poolie> i wonder if it's tax deductible :-)
<jam> business expense, right?
<jam> I think it would be here
<poolie> anyhow, want to talk soon?
<poolie> my net connection seems flakey so if i can't get through to you, can you call my landline?
<jam> with the caveat that 2% of your total income can go to business expense before they start actually giving you a deduction.
<poolie> hm
<LarstiQ> hi poolie
<jam> poolie: yeah, I'm just trying to get setup.exe working and documented on Kerguelen, give me a few minutes and I'll give you a call
<poolie> ok
<poolie> hi
<emmajane> thanks again everyone. that was awesome. :)
<LarstiQ> emmajane: cool :)
<emmajane> I resisted from saying, "That's not a beginner question!!" for most things. :) It was great to have you there as a backup! :)
<poolie> what did you do, emmajane?
<emmajane> poolie: I taught people how to make and use a time machine^H^H^H^H Bazaar :)
<poolie> nice
<james_w> hey poolie. It's Ubuntu open week again.
<poolie> oh, cool
<nealmcb> I just ran into this bug in my electionaudits project:  https://bugs.edge.launchpad.net/bzr/+bug/245170
<ubottu> Launchpad bug 245170 in bzr "file modification time not preserved by checkout" [Undecided,Confirmed]
<nealmcb> Am I missing anything?
 * poolie looks
<poolie> no, it's just not implemented
<poolie> we could have an option to set them to the time of the original commit
<poolie> i'm not sure about storing the mtime they had when they were committed
<poolie> perhaps that could be done in a plugin though
<nealmcb> poolie: thanks for looking.  would you know if there is an easy way to get python setup.py sdist to only include versioned files?
 * nealmcb is using setuptools_bzr
<poolie> for bzr, or for something else?
<nealmcb> for my project
<LarstiQ> and there is the problem of stupid buildsystems that look at timestamps, forcing you to touch everything to get what you're working on installed.
<LarstiQ> Yes distutils, I'm looking at you *glare*
<nealmcb> poolie: setting the files all to the same time (e.g. commit time) wouldn't help me at all.  the mod time data is important to preserve for this.
<lifeless> nealmcb: right now, we don't do that, You may find that etckeeper however has a layer on top to do so
<nealmcb> LarstiQ: can you give an example?  I like smart build tools (make) that leverage timestamps.  That's why I want bzr to preserve that.  There was a huge flap when Nautilus stopped preserving file mod times in hardy
<jam> nealmcb: you might look at the "etckeeper" project. I don't know if it preserves mtime, but I know it tracks file permissions, etc
<jam> morning lifeless
<nealmcb> jam thanks - I've looked at it before but didn't think of actually using it for this - hmmm
<lifeless> nealmcb: *however* file systems datetime is not really an audit-safe property except on a couple of very specific file systems; myself I would not depend on it.
<LarstiQ> nealmcb: python setup.py install; bzr revert; python setup.py; curse at no changes being made to installed packages
<poolie> what did Nautilus do?
<LarstiQ> nealmcb: or maybe it is slightly more complex with two different branches
<poolie> i suppose you mean preserving them when copying files or something?
<jam> does anyone know the exact revision for the qbzr 0.9.5 release? I'm packaging the win32 installer, and I just remembered that there may be some bugs in the tip of trunk
<LarstiQ> nealmcb: but I run into that too frequently :(
<lifeless> nealmcb: for starters on FAT datetime on a file is only accurate to 3 seconds
<nealmcb> LarstiQ: right - I call that a bug in bzr, not in distutils
<LarstiQ> nealmcb: this has nothing to do with bzr though
<LarstiQ> nealmcb: it works equally badly without using bzr at all
<LarstiQ> oh hmm, bzr revert would actually work
<LarstiQ> nealmcb: the problem, as far as I have determined, is that distutils looks at the timestamps of files it's about to install, and if they're older than what is installed, it does not execute that step
<nealmcb> nautilus bug: https://bugs.edge.launchpad.net/ubuntu/hardy/+source/nautilus/+bug/215499
<ubottu> Launchpad bug 215499 in glib2.0 "Nautilus not preserving timestamps" [Medium,Fix released]
<nealmcb> lifeless: what do you mean by audit-safe?
<lifeless> nealmcb: I mean can be modified with the modifier not necessrily visibl
<nealmcb> lifeless: hmm?  I'm still unclear on that
<LarstiQ> nealmcb: you need cooperation from everyone/tool that touches your files for the scheme to work.
<LarstiQ> nealmcb: it breaks very easily. So, using dates in filenumbers for example is a lot more robust to get chronological sorting.
<nevans> I've got a problem where a revision in one repository has a different parent from a revision in another repository (because of a race condition in bzr-svn)
<emmajane> LarstiQ: thanks again for sticking around to answer questions in #ubuntu-classroom. It's very much appreciated!!
<emmajane> and james_w too, of course. :)
<nevans> I've uncommitted the bad revisions from my branches... but I still can't pull from the good repo, because the bad revisions are still in the repo
<nevans> is there an easy way to remove the revisions from the repo?
<NfNitLoop> nevans: are they the most recent ones?
<nealmcb> LarstiQ: true.  but e.g. my input files come from election software which doesn't do timestamping in the filename, and asking the user to get it right when they name hundreds of files is not good.  And this is just one example - file mod times are used all the time.
<NfNitLoop> nevans: if so, 'uncommit'?
<nevans> NfNitLoop, uncommit pulls them out of the branch... but pull still fails with ERROR: Revision {svn-v3-trunk1:0487d25d-142b-0410-8fcf-b82ac621bf97:crms%2Ftrunk:48813} not present in ...
<jelmer> nevans, uncommit doesn't remove revisions from the repository
<nevans> jelmer: yeah I know.  how can I remove them from the repo now?  :)
<jelmer> nevans, but you can create a copy of the branch, that should hopefully not copy unreferenced revisions
<nevans> it's a shared repo that I use for lots and lots of branches... I'd rather not recreate the entire thing.
<LarstiQ> nealmcb: do you have any influence over the tool that is used to process the files?
<NfNitLoop> Hrmm, wasn't there an addon that did garbage collecition for shared repos?
<LarstiQ> nealmcb: as a workaround, you could store the timestamps in a seperate file and commit that
<nealmcb> I wish.  democracy wishes.  but it is closed source from the elections industry
<nealmcb> LarstiQ: easier to just package a zip file, since there would be a post-install step anyway....
<nevans> NfNitLoop, yeah.  that's basically what I'm looking for.
<NfNitLoop> jelmer wrote a "remove-revisions" plugin.
<NfNitLoop> http://bazaar-vcs.org/BzrPlugins
<LarstiQ> emmajane: np
 * LarstiQ needs to go to sleep now though
<LarstiQ> emmajane: so thanks and succes with the rest of it :)
<emmajane> LarstiQ: sleep well and thanks and you're welcome. :)
<NfNitLoop> nevans: but it was last updated in feb '07... dunno if that still works. :p
<nevans> I might just take the long route: copy all of the branches into a new shared repo.
<nevans> NfNitLoop, jelmer, at any rate, bzr-svn 1.9/0.4.14 seems to be working for me again (even if it did take 2.5 hours to do the initial branch)
<jelmer> nevans, cool
<NfNitLoop> nevans: cool.  *jealous*   :p
<lifeless> spiv: sp
<lifeless> *so*
<lifeless> the initial push, is it transcoding perhaps ?
<spiv> lifeless: hmm, that's pretty likely actually.  usertest isn't really geared for test-this-format, it's geared around test-this-tool.
<spiv> lifeless: I can try tweaking development3 to be the default format
<lifeless> now for the slow fetches
<lifeless> that 100 batch smells like the converter code I wrote
<lifeless> repository.py:3188
<spiv> Ah, I see.
<spiv> That does look highly likely.k
 * emmajane waves to meastp
<emmajane> I know that meastp had some follow up questions about Bazaar from Ubuntu Open Week, but I have to head out for a class. Hopefully there's still a few people around? :)
<emmajane> Thanks again to everyone for their help today. It was great!
<meastp> Hi! I have a problem with repositories. I have done: init-repo --no-tree, branch lp:footrunk, done checkout on trunk, and branch lp:foofeature1. However my feature branches are empty...
<lifeless> meastp: because you used --no-trees
<lifeless> meastp: you will need to checkout each branch separately
<meastp> oh.. What structure do you recommend for a shared repository?
<meastp> *file structure... with --no-trees I have ../trunk and ../features/feature1-n
<lifeless> thats fine
<Daniel999> hi
<meastp> but can I keep that with --no-trees? Oh, so no-trees just affect the file structure _inside_ the brances?
<lifeless> it just determines if a 'checkout .' is done implicitly after branching
<Daniel999> Hello everybody
<lifeless> you would use --no-trees on servers, or when you want a separate  work area to your collection of branches
<meastp> oh, so it has nothing to do with file structure, then?
<lifeless> nothing at all
<Daniel999> I'm having problems with cygwin branches, using sftp on non-common ports
<meastp> oh.. I didn't understand that last bit, but I guess it doesn't matter for now...
<Daniel999> i guess somebody could give me a hint here..
<lifeless> Daniel999: you haven't described your problem or asked a question
<Daniel999> ok, i'll describe the problem:
<Daniel999> this is the command i'm using:
<Daniel999> bzr branch -v sftp://dan@machine.com:3999/var/rep/terra_qa/testengine
<meastp> lifeless: ok, I did branch trunk and a feature branch. Unmodified files are in the feature branch, though...?
<lifeless> meastp: I don't know what you are asking
<Daniel999> and i get this :   bzr: ERROR: [Errno 20] Not a directory: '/tmp/testengine/.bzr/checkout/limbo/new-4/hernan@machine.com:3999'
<Daniel999> it seems like bzr is trying to make a temporal directory using a string containing ":"
<lifeless> Daniel999: please file a bug; that is an internal path that we probably need to url escape to accomodate the ':' as ':' isn't usable on windows
<Odd_Bloke> james_w: Thanks for looking at my installation thing BTW. :)
<lifeless> Daniel999: as a workaround, create a .ssh/config file with an alias - something like
<lifeless> Host port399
<lifeless>     hostname machine.com
<meastp> lifeless: the feature branches are not sharing files with trunk... all files are in all three branches..
<lifeless>     port 3999
<lifeless> meastp: thats what you asked bzr to do
<meastp> lifeless: do I have to run a 'sync' command?
<lifeless> meastp: sync to do what?
<Daniel999> cool! that should solve my problem
<lifeless> meastp: I think you're assuming I know something about what you want to achieve that I don't know
<lifeless> Daniel999: please do file the bug though :0
<Daniel999> oh yeah!
<Daniel999> thank you all!
<meastp> lifeless: I'm sorry, could you please tell me how to use a repository? It is supposed to share files between brances, but I can't get it to work...
<lifeless> meastp: ok, you've misunderstood what a repository does
<lifeless> meastp: *all* it does is means that the history of your branches is not duplicated per-branch
<lifeless> meastp: it doesn't affect your working areas where you write code or the behaviour of branches or anything else
<lifeless> meastp: if you look in your repository at the top level there is a .bzr/repository directory
<lifeless> meastp: inside that there is all the history of all your branches
<lifeless> meastp: each branch has a .bzr directory too, but they don't have a '.bzr/repository' directory.
<lifeless> meastp: and thats the space that you save
<orospakr> argh, I hate it when I ^C an ssh password prompt, and while the bzr process dies right away, the ssh process keeps running for a while and spams the terminal with error messages. :(
<lifeless> orospakr: hmm, would be nice to clean that up for you
<orospakr> :D
<lifeless> meastp: if you want to work with many feature branches and not have a lot of disk space taken up by your working files, bzr can do that too
<meastp> lifeless: oh, so the common revision history isn't duplicated? I get it now... Your patience is appreciated :)
<meastp> I guess what I thought is was, isn't really useful, anyway..
<meastp> I could just branch trunk, remove files I don't need (for this feature) from the branch, right?
<Odd_Bloke> meastp: If you were willing to fix their removal when you merged back into trunk, yeah.
<lifeless> meastp: uhm, what are you trying to accomplish with this deletion ?
<meastp> Odd_Bloke: , lifeless : Yeah, just me being silly, I guess. It would not be very useful, when I think about it. I'm quite new to vcs'es, and dvcs is even more to learn, so bear with me :)
<lifeless> meastp: in a feature branch you should make those changes that you want made to trunk when you merge it
<lifeless> meastp: nothing more, nothing less
<meastp> yeah... I just thought perhaps you didn't have to branch the whole trunk, for, say, a minor feature...
<lifeless> you can branch and switch a working tree to the new branch, which is less IO than making a full new working tree
<lifeless> but if you're new to all these things don't worry about optimisation
<lifeless> just get used to working with dvcs
<meastp> I'll stick too basic branching for now, I guess... and focus on the project;) Past midnight already, and up at seven - I should go. You have been very patient and helpful. I really appreciate it!
#bzr 2008-11-04
<hexsprite> hi bzr people ;) i have been using git-svn and wonder if bzr-svn has the same limitations.  particularly i want to be able to share bzr repositories between my laptop and my desktop and be able to merge between them using bzr and then commit via svn from either of them... possible?
<lifeless> totally possible
<hexsprite> great!
<ianm_> how do you force unlock a directory?
<lifeless> bzr break-lock
<ianm_> thanks
<cerw> hi there
<lifeless> hi
<cerw> i have question our repos is getting too big, we are using for archive mainly, can i somehow remove some old revision, without demiging the repo ?
<lifeless> not trivially no
<lifeless> you need to do a rebase operation skipping the bits you don't want
<lifeless> how big is too big?
<cerw> it's about 70G
<cerw> but the think is we dont need to keep all the repos
<cerw> we are using it for deploying
<cerw> everyday new version of release and taging them, that works great
<cerw> but we need to keep only maybe 20days old tags, the oder onnes we can trash..
<cerw> waht is rebase about?
<lifeless> rebase rewrites history; what you want to do can be described as rewriting history
<lifeless> there is also stacked branches which may help you and still keep history
<lifeless> are you deploying binary files?
<cerw> yeap it's final product, so some binary some scripts
<cerw> anad lots of data
<cerw> so i can remove revisions using rebase?
<lifeless> with some effort yes
<lifeless> its not exactly polished at the moment
<lifeless> someone posted a recipe to the list I think
<cerw> i am just playing with it now and it looks it it rewrutes each revision again
<cerw> not sure if i want that
<cerw> can i start branch and tell it to start it from some revision?
<cerw> then i can split it ..
<cerw> ok so is there way i can copy branch startinfr from some Revision?
<NfNitLoop> So, out of curiosity, I tried to reproduce this bug w/ 1.9rc1 & 0.4.14:  https://bugs.launchpad.net/bzr-svn/+bug/248289
<ubottu> Launchpad bug 248289 in bzr-svn "concurrent access problems" [Medium,Triaged]
<NfNitLoop> but I apparently can't commit to a bound svn branch.
<NfNitLoop> I get the error:  ValueError: invalid property value 'branch-nick' for None
<NfNitLoop> I'm not sure if that's a bzr error or bzr-svn.
<poolie> NfNitLoop: can you put the traceback from ~/.bzr.log into a new bug please?
<NfNitLoop> ok.   for bzr alone?
<poolie> for the command that gave you the error
<NfNitLoop> er, well, it was just 'bzr', but I'm not sure if it's the interaction with svn that cause it.
<NfNitLoop> in any event, the bug is here:  https://bugs.launchpad.net/bzr/+bug/293440
<ubottu> Launchpad bug 293440 in bzr "Cannot commit to bound svn branch" [Undecided,New]
<NfNitLoop> Wow.
<NfNitLoop> I just learned about stacked branches.
<NfNitLoop> That's nice!
<NfNitLoop> I should keep a closer eye on bzr-land. :)
<NfNitLoop> Is there a way, once I've got a stacked branch...
<NfNitLoop> to unstack it?
<NfNitLoop> sortof like unbind?
<lifeless> not really; just branch from it locally without the stacked parameter and it will copy everything
<lifeless> there is an internal api
<NfNitLoop> Yeah, I just tried that...
<lifeless> bt, its internal:P
<NfNitLoop> and it didn't go very well. :p
<lifeless> oh? it should work, what went wrong
<NfNitLoop> NotImplementedError: <bound method VirtualInventoryTexts.iter_lines_added_or_present_in_keys of <bzrlib.plugins.svn.versionedfiles.VirtualInventoryTexts object at 0x13d48f0>>
<lifeless> file a bzr-svn bug for that
<NfNitLoop> it *did* warn me that stacking was experimental in bzr-svn. :p
<cerw> hi there
<cerw> can i make a copy (branch) from current repository, but stariung by soe REVISION? i dont want to keep the whole repo..
<jkakar> I'm trying to merge a branch and getting this error: http://paste.ubuntu.com/67126/
<jkakar> Any suggestions on how to proceed?
<mkanat> Is there an "up and revert in one command" command?
<poolie> mkanat: no
<poolie> jkakar: :/ sorry for the bad message
<poolie> one of them is a rich-root repository probably
<poolie> bzr info will tell you
<poolie> upgrade the other one to 1.9-rich-root
<spiv> And "bzr info -v" will tell you if "bzr info" just says "unnamed".
<poolie> that is getting to the top of my shit list
<vila> hi all
<spiv> vila: hi
<SuperMMX> hi, guys, is it possible to add hooks only for a specific branch ?
<matkor> Hi ! What would be better (faster over slow network) for distributing mostly RO version of given branch ? checkout ? --lightweight checkout ? else ?
<AfC> Well, a lightweight checkout will only work if you have real time access (over your network) to the actual branch, wherever it is.
<matkor> AfC: I have branches spread over vpn ... but find doing bzr update (over plain checkout) long process, I wonder if there is way to speed it up ...
<matkor> I am using sftp://
<Peng_> Using bzr+ssh would be faster.
<Peng_> You should make sure you're using the latest version of bzr you can, and that your branches aren't in the old knit format.
<Peng_> Other than that, there's not much you can do.
<AfC> Yeah, I wouldn't particularly expect sftp:// to be fast for much of anything.
<matkor> Peng_: I will switch to bzr+ssh than .. I think I follow all upgrade suggestions seen in bzr CLI , so I suspect I am up to date in terms of branches format ...
<AfC> I mean, sure, if your VPN never breaks and has really low latency and is really fat, then sure, run lightweight. But it sounds like you have the opposite than, that which is *just* the situation where you want to have full (distributed version control) branch information locally. So, {shrug}
<matkor> AfC: Mostly what I do is bzr update (downloading newer version) over VPN, really really rarely  I need history or make comit ...
<AfC> matkor: do you do `bzr status` and `bzr diff`?
<matkor> AfC: yes
<matkor> and bzr missing <remote>
<matkor> in --lightweight checkout it's not possible withou network connection ?
<AfC> As I understand it, no.
<AfC> The whole point of distributed version control is to get the data to the other side of the bottleneck.
<AfC> and like I said, if you're complaining about your VPN's speed...
<AfC> But more to the point, why don't you try all this yourself and see?
<matkor> mhmm... OK so will switch to bzr+ssh and see if it helped with my feelings. Thank you very much, AfC, Peng_
<AfC> You're a smart person. If it works acceptably for you, then fine.
<AfC> I certainly would *NEVER* recommend this sort of thing to anyone, but I believe strongly in the premises of decentralized version control and the value of having full history somewhere locally.
<AfC> So what you're asking about is really somewhat anathema. That Bazaar supports it all has always struck me as ... strange ... but hey.
<jelmer> lifeless, ping?
<Flimm> Hello, I'm using Launchpad to host my bazaar branch
<Flimm> How can my friend download any commits I make to his computer?
<Flimm> This is the method I'm using now:
<Flimm> bzr branch lp:epidermis
<Flimm> Then whenever I commit and push, my friend does
<Flimm> bzr revert
<Flimm> bzr pull lp:epidermis
<beuno> Flimm, why does he revert?
<beuno> he can emrge from your branch
<beuno> *merge
<Flimm> merge doesn't auto commit though
<Flimm> and I don't want him to deal with any conflicts in case he has edited the files
<beuno> no, you commit after you merge
<beuno> I don't understand
<Flimm> pull automatically commits the way I commited, which I like
<beuno> well, he can pull to a separate branch
<Flimm> By why should he make a separate branch every time I commit?
<Flimm> he reverts in order to undo any changes he might have made
<beuno> Flimm, he can keep a seperate branch with the mainline
<beuno> and one he works on
<beuno> why would he have to loose his changes every time you commit?
<Flimm> He's not contributing any code at all, he's just testing the code
<beuno> uhm
<beuno> ok
<beuno> so, what's the problem
<Flimm> I just wondering if that was the recommended approach, beuno
<beuno> Flimm, well, I suppose if someone doesn'really doesn't want to play with a branch in parallel, and really will never commit, etc etc etc, then reverting all the time sounds about right
<beuno> you could potentially also use pull --overwrite
<beuno> but this is a bit of an odd use case I think
<nogden> hey people, does anyone else have a problem installing bzr-svn in kubuntu interpid?
<nogden> using the launchpad ppa for stable releases at the moment
<nogden> seems that bzr version installed is 1.8-1 and bzr-svn expects 1.8 any ideas of a workaround?
<Peng_> Where are you installing bzr-svn from?
<nogden> I'm assuming it comes from the same ppa does it not?
<nogden> or is there a seperate one for the plugin?
<Peng_> Oh, I didn't know it was in the PPA again.
<Peng_> Sorry, I can't help then.
<nogden> ah, my mistake.... it isn't
<nogden> it's in universe/devel
<Peng_> Oh.
<nogden> hmmm, acording to launchpad bzr-svn 0.4.13-2 (the version in universe/devel) just required bzr >= 1.6
<nogden> now I'm running bzr 1.8-1 from the launchpad ppa but there seems to be an issue
<nogden> ah, apt reports that it depends on bzr < 1.8
<nogden> hmmm, looks like a manual install... grrr
<nogden> ah, packages available in deb http://samba.org/~jelmer/debian/ unstable/
<abentley> jam:ping
<asabil> could someone please update the bzr-svn in ppa ?
<asabil> to disable the bzr (<1.8)
<disturbedsaint> markh I've updated the wiki page about tbzr, hope it's OK
<Kinnison> Anyone here know of an issue pushing to a knit repository over sftp with current bzr.dev ?
<Kinnison> specifically something which looks a bit like this: http://rafb.net/p/Tbug8Y55.html
<gour> nice, bzr-gtk-0.95 does not crash with bzr-trunk as 0.94
<LeoNerd> Has anyone written a bzrfs fuse module yet?
<james_w> LeoNerd: yeah, there's one around
<james_w> don't know if it's been kept up to date
<gour> oops, 1.10dev is crashing here - http://rafb.net/p/dm1VJO45.html
<Peng_> gour: Eh? Was that a change you made?
<Peng_> gour: You should use "hashlib.md5", not "hashlib.new".
<james_w> Kinnison: I haven't, I think it's bug time for you.
<gour> Peng_: hmm. maybe it's bette to rm search plugin, until it's ready
<Peng_> gour: Actually, use bzrlib.osutils.md5().
<gour> Peng_: what about this one - http://rafb.net/p/Tdc42F61.html bzr-gtk & bzr-dev ? (i fixed it by upgrade to 0.95)
<gour> Peng_: it's better that i become more familiar with python's standard lib before 'fixing blindly'
<Peng_> gour: That one I don't know.
<Peng_> gour: Well, http://bzr.mattnordhoff.com/loggerhead/bzr-search/py2.6/ should fix the md5 issue, but there might be others.
<Peng_> (I don't have Python 2.6 to test myself.)
<Peng_> gour: (And it also ruins compatibility with older versions of bzr. :P )
<Kinnison> james_w: *pout*
<Kinnison> filed as https://bugs.launchpad.net/bzr/+bug/293746
<ubottu> Launchpad bug 293746 in bzr "IndexError pushing to knit repository over sftp" [Undecided,New]
<james_w> thanks
<gour> Peng_: yes...pkgs need to (slowly) migrate to 2.6...soon there will be even 3.0
<mDuff> Does the 1.9rc1 standalone win32 installer include bzr-svn, or did I have an old copy of that hanging around from somewhere?
<ja1> abentley: sorry about the delay, are you still around?
<abentley> Yeah.
<abentley> ja1: Are you okay with me merging the shelf ui with the changes I sent?
<jam> yeah
<jam> I thought that was clear enough in the last email. Plus I gave you "tweak" anyway.
<jam> markh: I had a question about getting paramiko into the installers. Are you doing something special to have it happen?
<abentley> jam: I still figure that "tweak" doesn't count if you don't make all the changes suggested, and I haven't changed the use of bzrtools yet.
<jam> abentley: I said that was "weird" but that "we may not have anything better"
<jam> I was more bringing up the discussion than asking for a change
<abentley> jam: Okay, but I said "Is this something you want fixed before this lands?" and you didn't reply.
<jam> I probably missed that part
<jam> sorry
<abentley> np
<abentley> In terms of discussion, do you have an idea what we should do?
<jam> luks: I had a question about qbzr, if you have time
<luks> jam: sure
<jam> I'm trying to make sure I bundled the right version
<jam> but I didn't see an 0.9.5 tag in the trunk repo
<jam> do you know if it was added?
<luks> um, I don't know, alexander did the release, but I can check
<luks> but it's probably always safest to grab the tarball
<jam> luks: I just saw this:
<jam>   521 Alexander Belchenko       2008-11-03 [merge]
<jam>       merge 0.9.5 release
<jam> And I'd rather not have to download tarballs for everything for every release
<jam> it is easier to do a "bzr branch -r tag:..." when necessary
<luks> yes, the tag seems to be in the m erged branch
<luks> release-X.Y.Z as usual
<abentley> thumper: How's it going?
<thumper> morning abentley
<thumper> still knackered
<thumper> but not as bad as yesterday
<abentley> thumper: Progress is progress, I guess.
<thumper> abentley: do you know when 1.9 release is?
<abentley> thumper: Bazaar 1.9?  No, not offhand.
<abentley> thumper: Probably this week, though.
 * thumper nods
<jam> thumper: 1.9rc1 was 2008-10-31, so 1.9 would be expected on 2008-11-07
<thumper> thanks jam
<NfNitLoop> Hrmmm.
<NfNitLoop> bzr-svn seems to *explode* in memory usage when I try to pull one particular revision in particular.
<NfNitLoop> even though only a few lines were changed.
<NfNitLoop> The only thing I can see is that the lines are really long?
<lifeless> NfNitLoop: gigabytes long?
<NfNitLoop> (811 characters)
<NfNitLoop> no. :)
<lifeless> how big are the files these lines are in?
<NfNitLoop> hmm, not too big, I don't think, let me see...
<NfNitLoop> heh.
<NfNitLoop> 20k.
<lifeless> no alarm bells so far
<NfNitLoop> still, I can `bzr pull -r 510`, but `bzr pull -r 511`  nearly brings down my laptop.
<NfNitLoop> Unfortunately this against our non-public repo... trying to figure out how to reproduce this.
<NfNitLoop> Ooooh, wait.
<ianm_> is it easy to step back in time through commits?
<NfNitLoop> -r 511 might not necessarily be (svn)r511, eh?
<NfNitLoop> since I'm only grabbing one of the sub-projects?
<mDuff> ianm_, the short answer is "yes"; the long answer is "what, exactly, do you mean by that?"
<ianm_> mDuff: I see this when I start my app: Gtk-CRITICAL **:gtk_widget_event: assertion `WIDGET_REALIZED_FOR_EVENT (widget, event)' failed
<mDuff> ianm_, trying to figure out at what poit that issue was reproduced?
<ianm_> mDuff: right
<ianm_> it was recent
<mDuff> ianm_, you might find the bzr-bisect plugin interesting.
<NfNitLoop> aha, yes, it's a different revision in svn... which appears to be huge. :p   that makes more sense.
<ianm_> is there anything like "bzr previous" that I can do repeatedly until the warning disappears?
<NfNitLoop> ianm_: There's "uncommit"... but make sure you do it in a branch. :p  (it uncommits and discards your history one revision at a time)
<NfNitLoop> ianm_: bisect may help you.
<NfNitLoop> it does a binary search through your revisions. :)
<NfNitLoop> maybe faster than doing it 1 at a time.
<ianm_> it must be within the last 20 commits
<ianm_> so I currently have a working directory where when I commit it also pushes to launchpad
<mDuff> ianm_, bisect really is the right tool for the job; otherwise, you're just doing "bzr co -r [number]" or some variant thereof.
<ianm_> can I "bzr branch /that/directory" then use bzr uncommit there?
<mDuff> ianm_, checkout -r [number] is really more the right tool than branch+uncommit
<ianm_> mDuff: hmm ok.  can I do that locally?  a launchpad checkout takes like 5 minutes
<mDuff> ianm_, yes, that's a local operation
<mDuff> ianm_, do it within your existing tree
<ianm_> mDuff: all within my one working directory?
<mDuff> ianm_, well, you can just do a lightweight checkout of a specific revision into a different directory... that'd probably be the fastest+safest approach
<ianm_> mDuff: yeah that sounds good.  how do you do a lightweight?
<NfNitLoop> branch --lightweight
<NfNitLoop> uhrmm... but don't uncommit from there. :)
<NfNitLoop> (does that work from a lightweight co, even?)
<mDuff> ianm_, ie. bzr checkout --lightweight -r7 ~/myproject ~/myproject.r7
<mDuff> ianm_, ...but really, bisect is The Right Tool.
<ianm_> is bisect easy to setup?
<mDuff> ianm_, you should be able to just check it out into your ~/.bazaar/plugins/ directory
<NfNitLoop> lifeless: aha.  Yep, turns out that someone had checked in a 1G file.  Sooo, guess that repo's not a good use-case for bzr. :p
<mDuff> ianm, bzr co http://bzr.licquia.org/bzr-bisect/trunk/ ~/.bazaar/plugins/bisect
<mDuff> ianm_, then see "bzr bisect --help".
<lifeless> NfNitLoop: we're working on that, but yeah, youll need a couple of gb to check it out today
<NfNitLoop> I've got 2G RAM...
<NfNitLoop> so it looks like I'll need more than a couple. :p
<ianm_> mDuff: I found the commit, now I just have to figure out what's wrong about the glade file change, ugh ;)
<ianm_> mDuff, ï»¿NfNitLoop: thanks for your help!
<mDuff> ianm_, cool. bisect is nifty, eh? :)
<ianm_> I actually just did a bunch of local co -r but I imagine it is ;)
<lifeless> spiv: so, I would guess a mis-selection on pushing (CHKRepository, RemoteRepository)
<lifeless> spiv: which new repositories avoid because of sprout getting delegated to the FS level
<poolie> lifeless: hi
<poolie> my net access seems to be up but flaky
<lifeless> poolie: cool; we did a standup
<poolie> good for you
<lifeless> poolie: I mailed the notes to the list
<poolie> i would have said: i did everyone's reviews; today i'm going to fix the internet ;-) and then i think try inter-historic-tree diffs in CHK
<poolie> also, that needs a better name
<lifeless> true
<jam> poolie: I built a new win32 installer today, learning from user feedback. I'm wondering if I should completely remove the old installer, or if just naming the new one "-2" is sufficient?
<poolie> is there any benefit to keeping the old one?
<poolie> i can't see any
<poolie> unless someone wants to compare its bugs or something, and if we really want that you still have a copy
<poolie> i would call the new one -2 or something though
<poolie> to make it clear
<poolie> how about that?
<jam> yeah, I'm calling it -2, I just wondered about deleting the old download file
<jam> probably best  to delete it so we don't have people wondering which one to grab
<poolie> just delete it
<jam> I just had LP timeout while trying to upload, which is the first time it happened for me
<jam> but hopefully it will go through this time.
<jam> poolie: btw, I think the reason that rebooting worked for you is because you have the regular "Subversion" binaries installed
<jam> and it just got added to the path as part of the reboot
<jam> can you check?
<poolie> jam, i'm pretty sure i don't have svn on that machine
<poolie> can check
<poolie> jam, i don't have svn there
<poolie> it's a nearly fresh vm
<jam> interesting, considering I'm 90% sure that the dll isn't bundled in that installer.
<poolie> what was the name, libsvn-1.dll
<jam> libsvn_client-1.dll IIRC
<poolie> maybe there is some kind of negative cache
<poolie> if you see what i mean
<poolie> that bzr-svn *shouldn't* work on this machine, but it's normally failing quietly
<poolie> now i'm getting that message again
<poolie> jam, if we're shipping the bzr-svn plugin but not the libraries it uses that seems potentially problematic
<jam> poolie: yeah, I manually added the libs in the -2 installer
<jam> I don't understand why they aren't coming in automatically like all the other ones
<poolie> oh i see
<jam> And now, I managed to install it, and I get the icon in the systray
<jam> but when I run I get:
<jam> "ImportError: DLL load failed with error code 193"
<jam> not sure what that is yet
<poolie> i would guess what we're seeing as a windows vista feature, that if loading a dll fails the user sees a dialog with no intervention from the application
<lifeless> the windows runtime linker will show an error if a dll for an .exe can't be found
<lifeless> dynamic loading doesn't do this
<jam> well, running the 'bzr.exe' directly isn't complaining
<jam> (weird network fault)
<jam> anyway, bzr-svn seems good in the new install
<poolie> well, that's not consistent with what we're seeing here
<jam> I don't know why TortoiseBZR is failing to run the "settings" page
<poolie> jam, i'll try it out
<lifeless> jam: PATH may not match between the console and gui environments
<lifeless> jam: try logging the user out and in?
<jam> could be. I explicitly chose not to add 'Bazaar' to my path, because I wanted to unistall
<poolie> jam, i could run the settings from the tray icon
<poolie> i did add it to my path
<jam> ok, so it might just be that
<poolie> i'm waiting for more windows updates :/
<poolie> after that i'll upgrade it
<lifeless> garh, its summer
<lifeless> I can tell because the noise pollution is insane
<poolie> barely
<disturbedsaint> markh, are you there?
<markh> disturbedsaint: hi
<disturbedsaint> hi
<disturbedsaint> was wondering if the different menu's when clicking on the tray-icon work for you
<disturbedsaint> seems like tbzr has to be in the global PYTHONPATH
<markh> umm - that is possible for the tbzrcache process actually
<markh> but just start it manually and you will be OK
<poolie> so if you give a lp: url, it's the resolved form of that url that's remembered as the parent etc?
<james_w> poolie: yeah
<james_w> Aaron recently proposed to change that I believe
<disturbedsaint> markh, when launching from the command prompt it does indeed work
<disturbedsaint> just wanted to know if it's intentional the way it is
<markh> it would be possible to hack the shell extnesion code to set PYTHONPATH before launching the tbzrcache process
<markh> and its not a problem in a binary build
<james_w> the only downside I can thing of is that you need whatever directory service plugin installed to be able to resolve the parent, but I don't think that's too onerous
<markh> while I'm developing, I always run tbzrcache manually so I can see the output
<james_w> poolie: I met with Mark, some of lp-code, and others last week. Something like Russell's issue came up, and Mark was talking about how we could try and improve this.
<disturbedsaint> if it isnt a problem in the binary builds then it's fine :)
<james_w> he suggested storing both what the user asked for, and what they got, which allows you to later make decisions about what you should do
<poolie> james_w: the problem of people renaming branches?
<james_w> not only when branches move, but when they diverge and the like
<james_w> poolie: it was actually forks in development, but I think it still applies
<james_w> the UI for presenting this to the user and finding out what action they wanted to take wasn't discussed, but it's an interesting idea
<markh> disturbedsaint: have you ever seen a "would recurse to death" error?  If so, try updating the tbzr branch - I think I nailed that a couple of days ago.
<james_w> and would probably help in some situations
<markh> bb in 20
<disturbedsaint> actually I haven't
<disturbedsaint> though I do seem to lose the overlays on directories after a while
<disturbedsaint> still trying to find out why that happens
<james_w> poolie: thumper and jml were there, and they might have a different of how this was supposed to work, or what it was supposed to solve.
<disturbedsaint> Like bug 284511 (https://bugs.launchpad.net/tortoisebzr/+bug/284511)
<ubottu> Launchpad bug 284511 in tortoisebzr "overlay and menu not available in some computers" [Undecided,New] https://launchpad.net/bugs/284511
<ubottu> Launchpad bug 284511 in tortoisebzr "overlay and menu not available in some computers" [Undecided,New]
<disturbedsaint> Thats the only real issue I'm having atm
<thumper> james_w: what was the question?
<poolie> hi thumper
<poolie> we should talk sometime
<thumper> hi poolie
 * thumper needs coffee badly
<poolie> :)
<thumper> poolie: how about we talk this afternoon?
<poolie> yay jetlag
<poolie> sure
<thumper> I'm about to go and get coffee
<poolie> are you home now?
<thumper> yes
<thumper> it snowed here!
<markh> disturbedsaint: when that happens check .bzr.log - you should find an error there - and most likely is the "would recurse to death" error.
<disturbedsaint> markh: happened the last time 1,5hours ago
<disturbedsaint> But I got the source (branch) about 7 hours ago, so maybe there's another reason for it happening
<disturbedsaint> The error is "raise RuntimeError("Status of '%s' would recurse to death" % member)"
<markh> disturbedsaint: I only pushed it minutes ago :)
<markh> that is the error I think is now fixed
<disturbedsaint> ah, I see :)
<disturbedsaint> markh, I'll give it a try tomorrow
#bzr 2008-11-05
<disturbedsaint> will let you know if it solved it
<markh> thanks
<poolie> beuno: i'm a bit surprised by the bzr-pqm failure because afaics iter_changes does _not_ require 8 arguments in 1.9rc1
<abentley> poolie: It's _iter_changes, but *that* shouldn't require 8 arguments either.
<poolie> right
<abentley> I don't know what happened there.  I've been treating the sympoms because that's an old version anyhow.
<beuno> poolie, I was as well, but since slapping on the new version "just worked", I carried on without diving too deep into it
<poolie> fair enough
<lifeless> beuno: merged my fix for search?
<beuno> lifeless, argh, no
<beuno> I will now
<lifeless> beuno: nag nag nag
<beuno> it's on my starred emails
<beuno> which have grown out of proportion
<lifeless> beuno: FWIW seeing this has increased my 'do not do big layout cleanups' twitch factor
<beuno> yeah
<beuno> it did for me as well
<beuno> also, it was a patch from someone
<beuno> not something I actually did myself
<lifeless> k
<lifeless> well they don't understand python as much as they think they do :>
<beuno> seems not
<beuno> and, I should pay a little more attention, or just not merge those things
<beuno> hrm
<lifeless> more test coverage would reduce the risk
<beuno> that change still doesn't fix the problem
<lifeless> show me your diff?
<lifeless> cause it WFM
<beuno> yeah, tests are high up there next to "make it stop eating ram until it blows up"
<beuno> which we kinda know what's doing it now
<lifeless> bug 293750 might be fixed now poolie
<ubottu> Launchpad bug 293750 in bzr "Add paramiko SSH library to Windows installer" [Undecided,New] https://launchpad.net/bugs/293750
<beuno> lifeless, http://paste.ubuntu.com/67620/
<lifeless> beuno: that should do it
<lifeless> beuno: have you restarted? does command line search work?
<beuno> command line works
<beuno> I did restart
<beuno> do you have latest trunk?
<lifeless> what is the first exception
<lifeless> rev 235
<BasicOSX> python-2.6 unsupported in 1.10dev ?
<lifeless> BasicOSX: EPARSE
<beuno>   File "/home/beuno/bzr_devel/loggerhead/trunk/loggerhead/controllers/__init__.py", line 98, in __call__
<beuno>     vals.update(self.get_values(h, revid, path, kwargs, headers))
<beuno> TypeError: get_values() takes exactly 5 arguments (6 given)
<BasicOSX> lifeless:  https://bugs.launchpad.net/bzr/+bug/293886 :-)
<ubottu> Launchpad bug 293886 in bzr "bzr: ERROR: exceptions.AttributeError: sendall" [Undecided,New]
<lifeless> BasicOSX: a regression I guess; no core devs I know of are usingn 2.6 regularly
<lifeless> BasicOSX: or more accurately, we haven't announced full 2.6 support yet
<lifeless> beuno: that exception is the symptom
<BasicOSX> it's what I get for being bloody edge
<lifeless> beuno: its hiding the error
<lifeless> beuno: when I saw that I looked higher up in the log and could see the real exception, IIRC
<beuno> lifeless, ah, yes
<lifeless> beuno: I mean, you should fix that too; but its secondary
<beuno> http://paste.ubuntu.com/67625/
<lifeless> beuno: File "/home/beuno/bzr_devel/loggerhead/trunk/loggerhead/search.py", line 52, in search_revisions
<lifeless> beuno: print query there
<beuno> lifeless, [('a',)]
<lifeless> beuno: at line 1221
<lifeless> beuno: print key
<lifeless> beuno: it may be you've just found a unrelated bug
<lifeless> beuno: we can check this by doing a search for 'a' rather than a completion lookup for 'a'
<lifeless> (line 1221 of search/index.py I meant)
<beuno> lifeless, ('a',)
<beuno> yeah, I guessed that  :)
<lifeless> so type a and hit enter in the search box
<lifeless> or search for something bigger
<beuno> ah, see, I was trying the "find as you type"
<beuno> searching works
<lifeless> yes, I know :P
<lifeless> ok
<lifeless> now in the CLI
<lifeless> try 'bzr search -s a'
<lifeless> on the branch that was erroring
<beuno> aha
<beuno> same error
<lifeless> ok
<lifeless> lh is fixed
<lifeless> push that anytime
<beuno> prints (u'a',)
<lifeless> file a bug on the search - and I need a copy of the .bzr/bzr-search folder for the thing that errored
<lifeless> FWIW, 'bzr search -s a' works for me on an index of lh trunk
<lifeless> I suspect it will be a bzrlib index change
<lifeless> what bzrlib are you using?
<beuno> lifeless, sent the tarball
<beuno> I'm on 1.9dev
<beuno> nightly PPA
<lifeless> k, just tried with .dev
<lifeless> worked on my index, I'll drop yours in
<beuno> >>> bzrlib.__version__
<beuno> '1.9dev'
<lifeless> what branch does it index?
<beuno> that's for lh's trunk
<beuno> maybe it's an old format?
<beuno> the search that is
<lifeless> nah
<lifeless> if it was normal search wouldn't work
<lifeless> and the next format is btree based, but needs btree prefix searching implemented
<beuno> lifeless, deleting the .bzr/bzr-search and indexing again works
<lifeless> it'll be a corner case
<lifeless> (duh)
<beuno> ah, email is still sending
<beuno> 3.2mb apparently
<lifeless> cool
<lifeless> though you could have attached it to the bug :>
<beuno> ah, I could, yeah
<beuno> it's almost 2am here, european time doesn't seem to mix well with me
<lifeless> are you home?
<beuno> I wish!
<beuno> Spain
<beuno> for a few days
<beuno> then Washington DC
<lifeless> holidays?
<beuno> no no, LP UI world tour
<lifeless> clearly I've missed some mails :)
<lifeless> what are you doing?
<beuno> Launchpad UI
<beuno> we're gearing up for a big change in 3.0
<lifeless> I got the UI bit :P
<beuno> did you hear that we where sprinting in London for 2 weeks?
<lifeless> what I mean is what are you doing at each location that can't be done from  home
<lifeless> I knew about the EPIC
<beuno> ah, sprints
<beuno> with each team
<beuno> go through aaaaaaaaaaaaaaaall the pages
<lifeless> wow
<beuno> improve existing, plan for future dominance
<lifeless> you'll be fucked then
<lifeless> :P
<beuno> yes, I'm starting to guess that  :)
<lifeless> when do you come to .au?
<beuno> I've been in nz
<lifeless> meh, sif that counts
<lifeless> :)
<beuno> hehe
<beuno> long enough trip for me
<bob2> .au jr
<lifeless> lol
<beuno> anyway, I'm off to sleep for a while
<beuno> ping me if I can do anything else
<beuno> that email is still sending  :/
<beuno> g'night lifeless, and thanks for the patch + reminder
<lifeless> fud
 * arjenAU is trying to work out how to use tag so that it behaves as wanted
<arjenAU> it appears to apply to the last committed rev# not the next
<arjenAU> that's just so odd
<lifeless> arjenAU: hmm?
<lifeless> commit --tag tags the next commit
<arjenAU> lifeless: ah
<arjenAU> so what happens if I do bzr tag separately after doing bzr commit?
<arjenAU> does it kinda get attached to that commit, or?
<lifeless> you tag an existing revision
<AfC> arjenAU: ie, the last one, so "yes"
<arjenAU> lifeless: no I want to tag what i'm committing.
<arjenAU> lifeless: but I understand what you're saying
<arjenAU> so I should ideally just speify the --tag on the commit, that's clear.
<lifeless> arjenAU: so you want to record that you want to commit on the next commit
<lifeless> arjenAU: I don't think thats built-in, so you need to use --tag on the commit, yes
<arjenAU> lifeless: exactly. see most htings operate as a thing that gets committed later. bzr tag adds onto the previous commit. that's kinda unexpected
<arjenAU> bzr commit --tag works as expected
<Petrach> A question: When a repository is out of date, i.e. bzr update returns "working tree is out of date, run 'bzr update'"
<bob2> that would be a working tree being out of date, not a repository
<Petrach> is there an easy way to determine how foar out of date the repository is
<Petrach> ?
<Petrach> Is it possible to determine what revision the state of the working tree corresponds to?
<bob2> bzr info should tell you
<Petrach> That tells me what revision I would get if I run bzr update
<lifeless> Petrach: the wt has the revision id embedded in it, but not a revision number
<lifeless> Petrach: we should expose this I guess
<Petrach> Where would I have to look for that?
<lifeless> python -c 'import bzrlib.workingtree; t = bzrlib.workingtree.WorkingTree.open("."); t.lock_read(); print t.get_parent_ids()'
<Petrach> Ah, ok. Thanks
<lifeless> (sorry that its crude)
<Petrach> It's comprehensible enough, thanks
<lifeless> log --show-ids on the branch will let you find that rev
<lifeless> (unless someone uncommitted on the branch)
<poolie> hi all
<lifeless> welcome back
<lifeless> poolie: so, want to talk split inv
<NfNitLoop> echo "Obama" > president;  bzr commit;
<NfNitLoop> ;)
<arjenAU> NfNitLoop: hehe
<arjenAU> hmm lp not scanning branches at the mo it seems
<spm> arjenAU: no - am trying to figure out wtf is broken atm.
<arjenAU> spm: no worries, was just noting
<poolie> hi arjen
<arjenAU> hey poolie
<arjenAU> poolie: in case i haven't raved enough - bzr rocks
<poolie> that's always nice to hear
<arjenAU> not even craving back bk, this is just good. doing the weirdest cross-branch merges and it hasn't failed me yet
<poolie> arjenAU: i was going to propose to do a tutorial at the developer conference
<poolie> i think i need to send that tomorrow
<arjenAU> poolie: euh, OSDC? won't be any tutes.
<poolie> also, some canonical people including myself are going to be in brisbane next week, do you want to catch up?
<poolie> no, the mysql conference
<arjenAU> poolie: oh right. sounds good.
<arjenAU> poolie: ehm in Melb Sun eve- Wed eve, then US from Fri arvo. other than that, fine ;-)
<spm> arjenAU: and to think I felt guilty about calling myself a Qlder still; even after moving from brisvegas to canberra 18ish years ago. At least when I lived there, I *lived* there. ;-)
<poolie> heh
<poolie> where were you, spm?
<spm> In brisbane? jindalee - since about 71/72 ish.
<spm> I can *just* remember scenes from the 74 floods
<spm> poolie: what about yourself? I believe we went to *cough* .. HIGHLY... rival high schools. :-)
<poolie> in brisbane from about 1980 to 1999, and I went to BGS
<poolie> arjenAU, so i suppose you'll be pretty busy, but maybe we could meet for lunch or during the day on Thursday?
<poolie> lifeless: if you're still around, do you have an easily obtainable test branch in your new format?
<lifeless> poolie: the only precanned branch i have is the 18GB one on banchmarks
<lifeless> generally I take plugins and upgrade a copy
<poolie> in that robertc directory somewhere?
<lifeless> yah
<poolie> like of the bzr-gtk plugin?
<lifeless> but bzr branch bzrtools foo; cd foo; bzr upgrade --development3
<lifeless> is quite fast
<lifeless> poolie: and with that, I'm going to call 'day'
<poolie> i'm going to head off soon too
<poolie> cheerio
<spm> arjenAU: looks like we're scanning again
<spm> poolie: oh yes - huge rivals @ highschool - GT. :-)
<vila> hi all
<poolie> hi vila
<arjenAU> poolie: sure - you've got my mobile, right?
<arjenAU> poolie: whereabouts will you guys be?
<dissonans> what's the correct way to revert an (uncommitted) merge?
<beuno> dissonans, bzr revert?
 * LarstiQ nods
<LarstiQ> but, that will also revert any local changes you had
<LarstiQ> dissonans: if that is ok, then just `bzr revert` right ahead
<beuno> hiya LarstiQ
<LarstiQ> dissonans: if you want to keep the file changes, but not the recording of the merge, supply --forget-merges to revert
<LarstiQ> beuno: heya :)
<LarstiQ> beuno: still in London?
<beuno> LarstiQ, almost. In Spain now for the rest of the week
<beuno> then Washington DC
<dissonans> LarstiQ: actually, I'd like to keep some changes from before the merge
<dissonans> but I guess bzr can't discern those from those introduced by merge?
<LarstiQ> dissonans: correct
<LarstiQ> dissonans: you could perhaps try to do something with merging the reverse changes
<LarstiQ> but that would be tricky
<beuno> or
<beuno> shelve
<beuno> and go through the changesw
<LarstiQ> that would work if the merge didn't touch the same hunk as you changed yourself
<LarstiQ> and/or you had to resolve conflicts
<beuno> yeah, I don't think there's a perfect and simple solution
<luks> that's why such a situation requires merge --force
<thrope> how can I install bazaar 1.8 with tortoisebzr? the 1.8 win32 setup lite installer doesn't seem to include it, but I can't find a non-lite one
<thrope> also is there any documentation/tutorial online for tortoisebzr
<thrope> I have to collaborate with some not so technical windows users and I would really like to use bazaar
<poolie> thrope: hi, i think you should try the 1.9rc1-2 installer instead
<poolie> several problems have been fixed in tbzr packaging
<thrope> ok
<thrope> the trouble is I use 1.8 on other platforms
<thrope> will it be ok to mix them
<poolie> it will
<poolie> unless you specifically choose the 1.9 format for something
<poolie> i'm going to bed but if you hit problems ask someone here or on http://answers.launchpad.net/bzr
<thrope> hmmm - it doesnt work anyway - get a dll error trying to init with tortoisebzr from 1.9 installer
<poolie> really
<poolie> do you have the -2 version?
<poolie> it was just uploaded today
<thrope> yes
<thrope> i just downloaded it now
<thrope> dll load failed with errorcode 193
<thrope> anyway I think I will leave it for now
<poolie> please send a mail or file a question
<poolie> so we can track it
<poolie> possibly rebooting after installing would help that
<poolie> anyhow, good night and good luck
<davi_> is it possible to lock a branch so that no reads are possible?
<LeoNerd> chmod? ;)
<AfC> rm -r ? :)
<Tak> hmm, how does one close a bug in launchpad?
<Tak> I've already set status to "Fix Committed" ...
<LarstiQ> Tak: that depends on how the project wants to do things.
<LarstiQ> Tak: fix committed could mean that the bug is fixed in a particular branch, and Fix released means it's in trunk.
<LarstiQ> Tak: or fix committed could mean the bug is fixed in trunk, and fix released that is in a an actual release of the project.
<jrydberg> it would be nice with a bug tracking software that knew about merges
<Tak> I more meant, what needs to happen for the bug not to show up in the open bugs list
<jrydberg> you mark a bug as fixed in one branch.  when you merge that into trunk, the tracking software automaticly sets the bug as fixed in the trunk
<LarstiQ> jrydberg: yeah, either launchpad already does that or it's supposed to.
<LarstiQ> jrydberg: but what we really need, imo, is a different bug status to distinguish between merged to trunk and committed on a branch.
<luks> launchpad just links branches and bug reports, no?
<luks> it doesn't change the bug reports
<LarstiQ> Tak: either of those two statuses should do it afaict, if not, the Fix released certainly would.
<Tak> apparently "Fix Released" does and "Fix Committed" does not
<gorgapor> question: i deleted a file a few revisions ago, and now i want it back. what's the best way to resurrect this file and keep its history from before?
<rockstar> gorgapor, a reverse merge would be in order.
<LarstiQ> does that bring back the file with the same fileid as well?
<gorgapor> does revert -r do the trick?
<gorgapor> ok, how do i do that?
<gorgapor> i tried revert -r123 deleted_file, but it didn't work
<NfNitLoop> gorgapor: I think it may be:   bzr merge -r <n>..<n-1> .    (where n is the revision that deleted the file you want)
<NfNitLoop> but I don't have a repo handy to test that.
<gorgapor> okay i'll try that out
<gorgapor> so, that seems to bring back the entire changeset
<gorgapor> is there a way to just bring back the one file?
<Peng_> lifeless: ping?
<Peng_> eh
<Peng_> Hmm, searching in Loggerhead is busted in one branch, but not another.
<beuno> Peng_, I patched trunk
<beuno> did you upgrade?
<beuno> also, found a bug in bzr search index
<beuno> so you could delete de .bzr/bzr-search
<beuno> and re-index
<Peng_> beuno: Yeah, I upgraded.
<beuno> Peng_, try re-indexing the branch
<Peng_> Yeah, that fixed it.
<Peng_> Huh.
<Peng_> Oops, I didn't keep a backup of the bad indexes, if anyone was interested.
<beuno> I have a b0rked index already
<beuno> attached it to a bug
<Peng_> ok :)
<Peng_> Oh, LP is approaching 300,000 bugs.
<beuno> yeah, seems software is REALLY buggy  :p
<Peng_> OK, I just checked all of my other branches, and there weren't any more with broken indexes. Just the two.
<emmajane> beuno, I think the upload plugin is your genius invention?
<beuno> emmajane, well, vila did most of the heavy lifting
 * emmajane nods.
<beuno> and, by heavy lifting, I mean code  :)
<emmajane> hehehe
<beuno> I just complained a lot
<emmajane> Do you know if there's a way to toggle between two different servers?
<beuno> ah, interesting
<beuno> well, why wouldn't you be able to?
<beuno> it remembers the upload server-side
<emmajane> I upload to testing, and then when it's working I need to upload to the live server.
<emmajane> without having to put in the sftp:// nonsense again.
 * emmajane is lazy. :)
<beuno> ah, multiple locations
<emmajane> yeah
<vila> emmajane: you can use --remember for testing (since it's most often used) and look at the bookmarks plugin for your lazt fingers :0
<beuno> well, bzr, I *think*, has something to alias locations
<beuno> that's it
<beuno> bookmarks
<beuno> see, vila is the real brains
<emmajane> vila, awesome, thanks. :)
<vila> beuno: hi :)
<vila> emmajane: happy to help (c)
<beuno> hi vila!
<vila> emmajane: on the other hand, if you control the test server and have ssh access to it, why not install your working tree there and use sshfs if you need to access it from a remote workstation ?
<emmajane> vila, the test server is my dreamhost account. the live machine is a college mainframe superfancy machine. I'm very happy to not tie dreamhost to the college.
<vila> emmajane: ok
<emmajane> vila, I had to get Very Special Permission to even be allowed to connect to the college machine. :)
<emmajane> vila, in a normal world where deployments happened from testing to live, it would make sense to do what you suggested. :)
<vila> evrything that suits a user needs make sense :)
<emmajane> :)
<emmajane> hm. I have bookmarks installed, but the documentation is a little... vague.
<emmajane> will it just remember places that I've uploaded files to? Or do I need to enter the locations manually?
 * beuno suspects manually
 * emmajane reads the actual plugin python file to figure it out
<emmajane> beuno, let's pretend I wanted to actually add documentation for the plugins that I use (because if I can't figure it out, I'm sure there are others)... Where would I put this information?
<emmajane> Launchpad doesn't seem to have a place for project docs.
<beuno> emmajane, branch the code, addd the docs, push the branch, file a merge proposal
<beuno> I'll be happy to walk you through it
<emmajane> beuno, hrm. and then normal people would have to find it in the --help at the command line?
<beuno> emmajane, well, what other way would there be?
<emmajane> beuno, I usually check the wiki, to be honest. :)
<luks> you can create a wiki page on bazaar-vcs.org
<luks> and make sure it's linked from the launchpad page
<emmajane> luks, none of the plugins seem to have documentation online... or am I just lucky in the ones I choose...?
<emmajane> http://bazaar-vcs.org/BzrPlugins <--- there's usually a terse description but that's about it.
<luks> emmajane: why not make something better than what other people do :)
<emmajane> hehe
<emmajane> luks, that I can handle. :)
<NfNitLoop> Hrmmm.  I'm curious.  How would bzr-svn handle working with a svn repo if someone went and changed a log message in the repo history?
<NfNitLoop> I mean, I'm guessing at the very least, you wouldn't see that new message in `bzr log`, but I'm hoping it wouldn't break interoperability. :p
<vila> emmajane: 'bzr help bookmark' for usage and I'm pretty sure it stores them in .bazaar.conf
 * emmajane nods to vila 
<LarstiQ> NfNitLoop: good question
<emmajane> the pluginname with and without the S still trips me up.
<emmajane> help bookmarks != help bookmark
<emmajane> help tags != help tag
<james_w> emmajane: do they have a "See also:" at the bottom to link them?
<emmajane> help bookmarks doesn't say "see also: bookmark"
<emmajane> tags does, bookmarks doesn't.
<james_w> emmajane: that can be fixed at least :-)
<emmajane> james_w, patches welcome? ;)
<james_w> it's an easy one
<emmajane> "easy"
<emmajane> sounds like a good hour of procrastination...
<emmajane> I'm in!
<james_w> hmm, though I'm not sure what "help bookmarks" displays
<james_w> probably the module help, and I'm not sure if you can link from that
<james_w> if not then a bug report on bzr is in order :-)
<emmajane> the relevant bit is: From:     plugin "bookmarks"
<emmajane> See also: plugins/bookmarks
<emmajane> It's missing See also: bookmark
<emmajane> I think?
<james_w> yeah
<vila> emmajane: did you *try* bzr help plugins/bookmarks ? :)
<vila> I think that the one that needs love :)
<emmajane> vila, it needs love, I agree. :)
<emmajane> and I see where to edit that...
<vila> great :)
<emmajane> it /seems/ as though it would be the same information though. How come plugins/* is different than just the plugin name?
<emmajane> hrm.
<luks> because the plugin name happens to be also a command name
<emmajane> actually.
<emmajane> help bzr bookmarks != help bzr bookmark != help bzr plugins/bookmarks
<emmajane> and help bzr plugins/bookmark is not found.
<luks> because there is no plugin "bookmark"
<emmajane> that's enough to confuse a person right there.
<emmajane> luks, correct.
<emmajane> is there a way to make bookmarks/bookmark relate to each other?
<james_w> "help bookmarks" is also known as "help commands/bookmarks"
 * emmajane nods
<emmajane> help plugins/bookmarks just reads from the actual .py file.
<james_w> there are different categories of help, commands/*, plugins/*, and topics/*
<emmajane> that popping noise? that was my brain exploding. :)
<LarstiQ> iirc help plugins/foo uses the module/package docstring
 * LarstiQ trots off to jitsu
<emmajane> LarstiQ, it appears that way, yes.
<james_w> yeah, LarstiQ is right
<emmajane> LarstiQ, have fun beating up people. :)
<LarstiQ> emmajane: thanks, I'll try not to get too sore myself ;)
<emmajane> LarstiQ, duck and cover! :)
<emmajane> so I have two problems that need fixing. See also: for the help commands/* is not referencing relevant commands. AND help plugins/* could be more useful.
 * emmajane wonders if that even made sense.
<james_w> I don't understand what you mean for the first bit
<luks> emmajane: if you can write the documentation, I'm sure I can fix these semantic issues
<emmajane> james_w, the See also: at the bottom of bzr help bookmarks doesn't say "see also: bookmark" the way it does for tags/tag
<james_w> aha
 * emmajane grins at luks. "Deal!"
<emmajane> james_w, which is different than the documentation being vague in the actual plugin which is used for bzr help plugins/bookmarks
<james_w> emmajane: for that you need to add see_also = ["bookmark"] somewhere in cmd_bookmarks
<emmajane> knowing nothing about Python, /me looks
<james_w> just under """List bookmarks.""" would do
<james_w> keeping the same indentation
<emmajane> yeah
<emmajane> white space makes you able to fly.
<emmajane> I know that part thanks to xkcd.
<james_w> :-)
<emmajane> will it append, or overwrite the See also: plugins/bookmarks?
<emmajane> I don't want to lose any information.
<james_w> append I believe
<emmajane> kay
<james_w> you'll have to try it I'm afraid
<emmajane> heh
<emmajane> after making my edits do I need to do anything fancy to test? or just run the command again?
<emmajane> woo. fail.
<james_w> :-(
<emmajane> Unable to load plugin 'bookmarks' from '/home/emmajane/.bazaar/plugins'
<emmajane> Plugin 'bzrlib.plugins.bookmarks' has no docstring.
<james_w> try "bzr -Derror help bookmarks"
<luks> most likely broken indentation :)
<emmajane> hrm. I let vim do the indentation...
<luks> using tabs maybe?
<james_w> you might need ":set expandtab"
<emmajane> james_w, same error message
<emmajane> I redid the edits with :set expandtab on
<emmajane> it seems to work now. :)
<james_w> heh :-)
<emmajane> although the see also was ignored. :(
<james_w> boo
<emmajane> yeah
<emmajane> the other two plugins I have installed don't use variants, so they don't have a see_also for me to compare against
<james_w> change it to _see_also
<james_w> that seems silly to me
<emmajane> hurrah
<emmajane> that worked. :)
<emmajane> and it appends.
<james_w> cool
<emmajane> From:     plugin "bookmarks"
<emmajane> See also: bookmark, plugins/bookmarks
 * emmajane thinks that's nifty.
<emmajane> ok.
<emmajane> so.
<emmajane> I should do something with this change.
<james_w> so was there more to fix, or just documentation to improve?
<emmajane> seems greedy just to keep it on my own machine.
<james_w> commit it!
<emmajane> I want to make changes to the help at the top (which is triggered by help plugins/bookmarks) too.
<emmajane> but I haven't actually been able to /use/ the plugin yet because I couldn't find all the help files. ;)
<emmajane> first commit made for the See also: stuff.
<emmajane> I'm going to actually test out the bookmarks and then I'll bug y'all again when i'm ready to push the changes. :)
<emmajane> ok. the help information is updated.
<emmajane> Now I suppose I need to push the changes back to the server?
<james_w> yeah
<james_w> bzr push lp:~emmajane/bzr-bookmarks/fix-documentation
<james_w> or similar
<emmajane> that creates a new branch, right?
<james_w> yeah
<emmajane> fail
<emmajane> bzr: ERROR: Transport operation not possible: http does not support mkdir()
<emmajane> I don't have write permissoins I guess.
<james_w> bzr launchpad-login emmajane
<james_w> that will make the "lp:" thing use a writeable transport for you
<emmajane> it's thinking
<emmajane> which is better than failing.
 * emmajane wonders if that was the right password....
<emmajane> it's still thinking...
<beuno> depends if it fails at the end, then it's worst!
<emmajane> and new branch created.
<emmajane> erm.
<emmajane> now what?
<luks> now you ping me about merging the branch? :)
<emmajane> luks, ping!
<emmajane> luks, would you be able to take a look at the changes I made to bzr-bookmarks? :)
<emmajane> hm. I should also update my email to have the Ubuntu address I guess....
<emmajane> identity is such a hassle.
<luks> emmajane: pulled, reviewed, pushed -- thank you!
<emmajane> WOO!
<emmajane> luks, thanks :)
<james_w> emmajane: unfortunately launchpad won't yet detect that, so you should mark your branch as merged in launchpad
<emmajane> erm
<emmajane> Propose for merging into another branch ?
<NfNitLoop> so I just commented on a bzr-svn bug that appears to still be a bug despite having been marked "fixed":  https://bugs.launchpad.net/bzr-svn/+bug/290664
<ubottu> Launchpad bug 290664 in bzr-svn ""Can't get entries of a non-directory"" [Undecided,Fix released]
<NfNitLoop> do I need to do anything other than that?   (Mark it as not-fixed somehow?)
<beuno> emmajane, that creates a merge proposal
<beuno> which is useful if it hasn't alaready been merged by the magic of IRC
<emmajane> hehe
 * emmajane makes the merge proposal.
 * emmajane resists complaining about how confusing she finds LP.
<beuno> emmajane, are you on the beta-testers team of LP?
<emmajane> beuno, I'm not.
<beuno> because we *just* re-wroked the whole merge-proposals bit
<beuno> and it's 100x times simpler now
 * beuno adds emmajane compulsively to the beta testers team
<emmajane> 100x is an awful lot :)
<emmajane> hehe
<luks> I wonder how you do measure that :)
<emmajane> luks, in beers, I'm sure. :)
<beuno> luks, how much work it took  :)
<emmajane> luks, how many new gray hairs the entire team has ;)
<luks> heh
<beuno> emmajane, you're in
<emmajane> beuno, cool.
<emmajane> how does this change my life?
<beuno> emmajane, new things faster
<beuno> isntead of every 1 month or so
<beuno> (my typing is horrible today)
<emmajane> beuno, fancier tag clouds. that's what it means. ;)
<beuno> emmajane, well, to me it means more feedback on UI changes faster  :)
<emmajane> beuno, hehe.
<emmajane> beuno, are they all reported as bugs?
<emmajane> cos baby I gots feedback if you want it. ;)
<luks> it would be nice if the beta launchpad didn't insist on using edge. urls
<beuno> emmajane, yes, we live in bugs
<james_w> beuno: you don't know what you have started :-)
<emmajane> beuno, what you've started is a total release of james_w from listening to me complain about one of my favourite topics. ;)
 * beuno stops and thinks
 * emmajane chuckles.
<beuno> uhm
<beuno> maybe the beta team isn't a good fit for you (?)
<emmajane> james_w, you're going to have to buy beuno a LOT of beer at the UDS. ;)
<james_w> always :-)
<beuno> I may need beer now, from what I'm seeing happening
<emmajane> :)
<beuno> emmajane, are you going to UDS?
<emmajane> nah
<emmajane> I'm not a programmer. ;)
<beuno> good, you can help balance things out!
<emmajane> by not attending. ;)
<beuno> :)
<beuno> anyway, I'm looking forward to your feedback
<james_w> beuno: how's Madrid?
<emmajane> I'm starting REAL easy. :)
<beuno> and, now, I'm running away from the computer before I make my life harder in other new creative ways
 * emmajane grins at beuno 
<james_w> :-)
<emmajane> beuno, first one submitted.
<beuno> james_w, much better weather than london
<emmajane> beuno, vvvveeerrrrry easy
<beuno> emmajane, if that's true, i may even fix it quickly
<beuno> :)
<james_w> beuno: of course :-)
<emmajane> beuno, :)
<beuno> now, I'll be back in a few hours to go through new bugs  :)
<emmajane> :)
<beuno> good talking to both of you
<emmajane> beuno, laters :)
<emmajane> thanks again for your help today
<NfNitLoop> Hrmm, how do I enable a debug flag in bzrlib.debug?
<NfNitLoop> --debug <flag> ?
<luks> -D<something>, I think
<NfNitLoop> no, that's not it, hrmm.   I'll try that.
<NfNitLoop> luks: ah, that did it, thanks.
<NfNitLoop> So if I'm trying to branch from an svn repo that has had...  very poor standards compliance w.r.t. tags/branches....
<NfNitLoop> is there an option to tell bzr-svn to only grab /trunk and ignore everything else?
 * emmajane stops at three new bugs for beuno 
 * emmajane goes back to work-work now. :)
<NfNitLoop> I see the bzr svn-branching-scheme command, but didn't find a list of branching schemes after some goodling.
<NfNitLoop> googling*
<Peng_> NfNitLoop: "bzr branch svn://.../trunk/"?
<Peng_> Though that would still try to fetch tags.
<NfNitLoop> Peng_: right, that's what I'm doing, and it's trying to get tags.
<NfNitLoop> and someone thought it would be fun to put a *file* in /tags/
<NfNitLoop> (I wouldn't even rely on the directories in /tags/, to tell the truth.)
<Peng_> NfNitLoop: Oh. I think that's been fixed recently.
<Peng_> NfNitLoop: What did it do when it came across the file in tags/?
<Peng_> Well, from 0.4.14, there's "Ignore tags that happen to be files.".
<mickbeaver> I'm having difficulty pushing to a usb flash drive on Windows Vista 64. Using both the win32 and the cygwin version yield the same result.
<mickbeaver> bzr: ERROR: Could not acquire lock "[Errno 13] Permission denied"
<mickbeaver> Any tips for starting to debug this?
<disturbedsaint> markh, the chages you made seem to have fixed the would recurse to death error
<disturbedsaint> none of those in the log from today, been browsing the directories that are under bzr control every now and then (in explorer and different file-open dialogs)
<NfNitLoop> Peng_: it threw an exception and died.
<NfNitLoop> Peng_: and I'm using 0.4.14... is there some option I need to specify to "Ignore tags that happen to be files"? :p
<Peng_> NfNitLoop: Oh. I dunno then.
<Peng_> Sorry I can't help. :\
<jelmer> NfNitLoop, check the 0.4 branch
<jelmer> NfNitLoop, it's got another fix
<Spaz> w3
<Spaz> oops
<NET||abuse> we have an svn repo in the office here, and i was looking to work with something like bzr or git as my primary client, but i am a beginner with bzr.. is it a reasonable thing to do to take a checkout of the trunk into a bzr branch, operate away on it, maybe pull the branch between my laptop and desktop a few times (few days of development work)
<NET||abuse> then merge that work back into the svn trunk?
<NfNitLoop> NET||abuse: Yes.
<NET||abuse> ok, just looking to learn the workflow
<NfNitLoop> NET||abuse: in fact, that's exactly what I'm working on advocating at my workplace at the moment.
<NfNitLoop> NET||abuse: the nice thing is there is no "the workflow"...  bzr supports quite a few. :)
<NfNitLoop> http://bazaar-vcs.org/Workflows
<NET||abuse> ok,, well, in my case i just need to learn the commands, and "the" workflow i'm interested in is, we have central svn repo, i do bzr branch svn+ssh://me@host/path/to/repo/
<NfNitLoop> path/to/repo/trunk
<NfNitLoop> yes. :)
<NET||abuse> then i do some work on some files, which i actually just did, edited one file, delete a directory tree that was obsolete. then i do bzr commit, write my log, then bzr merge, it says mergin from remembered location svn+ssh:///blah.. Nothing to do
<NET||abuse> ??? nothing??
<NfNitLoop> (others:) I just installed and read up on `bzr help rebase`, but `bzr rebase` in my local, changed repo claims that there is no work to do?
<NfNitLoop> NET||abuse: That's merging from "upstream" into your local repository.
<NfNitLoop> NET||abuse:  you want to "push" back to the remote repository.
<NET||abuse> .. oh.
<NET||abuse> ok,, umm, little confused by the workflow description,, bzr comit --local? bzr unbind/commit/bind
<NET||abuse> looking at the centralized with local commits
<NfNitLoop> If you do "branch", you by default have local commits.
<NfNitLoop> and are working with an "unbound" branch.
<NET||abuse> ah, ok
<NfNitLoop> which means that when you "commit", it goes into only your branch.
<NET||abuse> so bzr pull is like an svn style checkout?
<NfNitLoop> if you have a "bound" branch, it means that any commits you do go into your local branch *and* the upstream.
<NfNitLoop> no, `bzr checkout` is. :)
<NET||abuse> ... umm, ok
<NET||abuse> ah, but i did bzr merge?
<NfNitLoop> `bzr pull` is like... svn update.
<NET||abuse> hmm, the forks in the process, because it's not a linear cyle of workflow, it's a bit confusing..
<NET||abuse> hmm, are there any dangers to the central repo that i should be away of for now though, big nono's that i shouldn't do when operating bzr on the central svn repo?
<NET||abuse> umm, away=i meant aware
<NfNitLoop> NET||abuse: Yes.  I've been reading up on those, actually.
<NfNitLoop> a big one:   SVN only supports linear history.
<NET||abuse> ooh, do share.. i realllly don't wanna screw up our svn repo.
<jelmer> NET||abuse, you should have a look at the bzr-svn FAQ
<NfNitLoop> so, while you could do "bzr commit (some stuff); bzr merge (from trunk): bzr commit (more stuff);"...
<NET||abuse> jelmer: will do .
<NfNitLoop> ... that would make your `svn log` look strange.
<NfNitLoop> so you probably want to use `bzr rebase` instead of `bzr merge`.
<NET||abuse> bzr rebase... hmm
<NfNitLoop> NET||abuse: it's a plugin.
<NfNitLoop> https://launchpad.net/bzr-rebase
<NET||abuse> i need a cheetsheet with the sequence of commands detailed and explained..
<Odd_Bloke> Didn't Ian make one of those a while ago?
<lifeless> its in the docs
<NET||abuse> which docs?
<lifeless> NfNitLoop: NET||abuse: I don't think y ou want rebase
<lifeless> rebase is rarely the correct tool if you are just collaborating
<NET||abuse> hmm,
<lifeless> svn supports merge as of 1.5
<NET||abuse> well, it's 5 of us building django site
<NET||abuse> 4 coders(1 is an intern) and 1 graphics guy who does some html/css also.
<lifeless> standard offline work for svn with bzr is 'bzr branch; hack, commit, hack commit, bzr merge <svn> until happy; bzr push <svn> || bzr dpush <svn>'
<lifeless> push and dpush do slightly different things, I imagine the bzr-svn docs explain
<NET||abuse> lifeless,, that's really good, thanks.. think i needed it sort of just summarized like that.
<lifeless> jelmer: you pinged me yesterday
<jelmer> lifeless, Hi!
<NET||abuse> lifeless: what's the <svn> bit, do i need to specify teh repo again?
<lifeless> NET||abuse: it should remember it, I was being clear
<jelmer> lifeless, Yeah, that was about branch.nick on bound branches - I commented in lp already (and you replied)
<lifeless> NET||abuse: also, after a 'bzr merge <svn>' you need to 'bzr commit' to save the result of the merge
<lifeless> jelmer: cool
<james_w> hey jelmer
<jelmer> 'evening James
<james_w> jelmer: I saw you said you fixed ptabtools, but you didn't upload anything
<NET||abuse> lifeless: ahh, ko.. will any changes from the svn repo be checked for conflicts
<lifeless> NET||abuse: of course
<lifeless> back in a little bit, breakfast time
<jelmer> james_w: I did, but it hasn't shown up on revu for some reason
<NET||abuse> so, bzr merge, does a sort of, svn up and svn commit..
<james_w> jelmer: ah, I'll ask an admin to have a look
<NET||abuse> the bzr commit after the merge does what though?
<Odd_Bloke> NET||abuse: A merge can cause conflicts or cause tests to stop working, so you'll want to check that before committing it.
<Odd_Bloke> So you need to commit separately.
<jelmer> james_w: nevermind
<jelmer> james_w, I seem to have uploaded a binary package..
<james_w> ah, that'll be it
 * jelmer bangs his head against the wall and uploads a source package
<NET||abuse> hmm, does the commit send the revision to itself and the remote repo at the same time?
<NET||abuse> just not sure at what point files are being written to the remote repo
<jelmer> NET||abuse, if you have a bound branch the files are going to the remote repo on "bzr commit"
<james_w> jelmer: actually, I've just noticed, your version number should be -0ubuntu1, not -1ubuntu1
<jelmer> NET||abuse, if the branch is not bound, the changes are local only and you have to push them to the remote repo using "bzr push" (or dpush)
<lifeless> NET||abuse: when you 'push' they are written to the svn repo
<lifeless> NET||abuse: using the workflow summary I gave
<jelmer> james_w, Thanks, I'll fix that as well.
<lifeless> NET||abuse: if you use 'bzr co' instead of 'bzr branch' then ignore all bzr stuff and just use your exact same svn commands
<NET||abuse> lifeless: thanks.. ok, i think i get it fairly completely now.. this is awsome.
<NET||abuse> i will get it in a linear sense, then in a day i'll try pulling code between my 2 workstations (laptop/desktop) without touching the central svn and do a real branch style work flow
<james_w> jelmer: -0ubuntu1 not -1ubuntu0 :-)
<NET||abuse> lifeless: thank you very much, NfNitLoop: you too
<NET||abuse> ok, i'm late for a dinner.
<james_w> jelmer: and is there a need for bzrtags?
<NfNitLoop> lifeless: I don't want rebase?
<NfNitLoop> If you do a 'push' back into svn with non-linear history, bzr does a replace on that branch in svn, which breaks history.
<jelmer> NfNitLoop, it's not the non-linear history that's the problem
<NfNitLoop> which would make my coworkers unhappy. :p
<NfNitLoop> jelmer: no?
<jelmer> NfNitLoop, it's the fact that the mainline sometimes changes
<NfNitLoop> oh, that's what I meant, was I misusing terminology?
<jelmer> NfNitLoop, non-linear history means merge revisions and indented revisions in "bzr log"
<NfNitLoop> in short:  if Joe has committed 10 changes to svn, and suddenly my 'bzr push' blows them away (from the perspective of svn log) he's going to be unhappy.
<jelmer> NfNitLoop, changing of mainline can also happen if you e.g. uncommit and then commit another revision
<NfNitLoop> jelmer: ah, but that's what happens when I merge in from svn, no?
<NfNitLoop> I mean, I just did "bzr merge" when someone had committed a few changes to svn and I had local changes committed.
<NfNitLoop> and I got a merge revision w/ indented revisions.
<jelmer> NfNitLoop, yes, if you merge from a svn location and then push that means the mainline of the svn mainline changes
<NfNitLoop> so to avoid doing that I should... use rebase?
<NfNitLoop> or something else?
<jelmer> james_w: there were actually older debian changelog entries (from my private debian repo) in there as well - I've removed those now
<NfNitLoop> (I'm curious... because I'm eventually going to be making the case for using bzr to coworkers.)
<james_w> jelmer: also, I was wondering how that Makefile rule ever worked :-)
<jelmer> NfNitLoop, yes, bzr rebase was written with that use case in mind
<NfNitLoop> jelmer: Ok.  So I should just always 'bzr rebase' instead of 'bzr merge'?
<jelmer> james_w, the shared library on e? :-)
<NfNitLoop> (I tried merge then rebase, but that seems to make it think there's no rebase work to do?)
<jelmer> NfNitLoop, if you don't want to change the existing mainline in svn, then yes
<NfNitLoop> Ok. :)
<NfNitLoop> jelmer: thanks!
<jelmer> james_w, It probably works if the shared library is already there
<jelmer> james_w, so it's sort of a chicken-egg problem :-)
<james_w> jelmer: heh, yeah, that'll probably do it.
<lifeless> NfNitLoop: alternatively
<lifeless> NfNitLoop: have a second branch which is a checkout of the svn mainline; cd to that, update, merge your branch, commit
<lifeless> NfNitLoop: it will not alter the mainline at all, ever.
<lifeless> NfNitLoop: and has less to do that rebase
<NfNitLoop> lifeless: but that way I lose my local revision history, no?
<NfNitLoop> all of my local revisions will appear as a single merge.
<NfNitLoop> that then gets pushed to svn?
<lifeless> unless you use dpush IIRC
<lifeless> bbiab
<lifeless> I think my point was that regular bzr does this too
<jelmer> no, dpush' behaviour doesn't differe there
<lifeless> jelmer: hmm, would be good to allow some way to set the branch flag to rpeserve mainline, for svn branches
<lifeless> jelmer: and perhaps have it on by default for svn branches
<jelmer> lifeless, problem is, you don't want to preserve the mainline of the local branch
<jelmer> but that of the branch you're merging
<NfNitLoop> lifeless: regular bzr does that too, but still maintains the history.  In bzr I can see that, yes, that merge actually merged in X number of changesets (each still containing its original commit message)
<jelmer> NfNitLoop, bzr-svn can preserve that history too but it wouldn't show up in the same svn branch
<NfNitLoop> jelmer: *nod*
<jelmer> NfNitLoop, just like it doesn't show up in the same bzr branch, but bzr has a nice way to show merged revisions (by indenting them), svn doesn't
<NfNitLoop> mostly, I'm getting at this:   If we use bzr to commit to /trunk, and bzr "breaks" 'svn log' on trunk... bzr will get blamed for it.
<NfNitLoop> fair or not. :)
<NfNitLoop> so I'm just thinking of the best workflow to document & recommend to coworkers.
<NfNitLoop> I think I may compromise and go w/ lifeless's recommendation of merging into a local mirror of trunk then committing that.
<NfNitLoop> one less plugin to install.  one less plugin for me to explain to newbies. :p
<lifeless> jelmer: I mean to honour the dont-alter-history setting on the svn side:)
<jelmer> lifeless, we already have that - the append_revisions_only setting
<jelmer> I guess it would indeed be nice to have bzr merge honor it
<lifeless> jelmer: how do you set that on a svn branch?
<lifeless> jelmer: I don't mean 'on a branch pulled via bzr-svn'
<lifeless> I mean literally on the svn branch
<jelmer> lifeless, you set it in locations.conf
<lifeless> jelmer: that won't default to on
<lifeless> jelmer: which is what I proposed above
<lifeless> jelmer: nor do other users see it
<jelmer> I don't think this sort of thing should be a default
<lifeless> jelmer: which is what I was assuming when I said it would be nice to allow this
<jelmer> unless it's a default for bzr branches as well
<lifeless> jelmer: back in a few, local interrupt
<jam> lifeless: I'm heading out to pick up my son. If I'm not back for the standup, can you have poolie/whoever call me on my cell phone?
<lifeless> jam: sure
<lifeless> jelmer: I think that branches in an svn repository have some expectations held by svn client user
<lifeless> *users*
<lifeless> jelmer: that flag makes bzr meet those expectations; I don't see why it would be an issue to have it default on for SVNBranch
<jelmer> lifeless, I don't think it's a bad idea to suggest this setting to users
<jelmer> but I don't think having a non-changing mainline is particularly expected by all svn users
<jelmer> especially now with merge tracking support in 1.5
<lifeless> jelmer: the problem is every user needs to read the right docs and set the right setting
<lifeless> jelmer: what proportion would you say?
<jelmer> lifeless, or e.g. people who embed a svn branch in their bzr project (by-value nested trees)
<lifeless> jelmer: I don't see why it would affect those people
<jelmer> lifeless, or e.g. people who push their bzr work to a svn repository but have their primary branch in bzr
<jelmer> lifeless, bzr merge will do funny things to them if they merge in a new copy of the svn branch
<jelmer> lifeless, since it will change to use the mainline from the remote svn branch
<lifeless> it will ?
<jelmer> well, that's what this setting would do, no?
<lifeless> no
<lifeless> it would only affect the svn branches
<lifeless> not anything thts been copied into bzr
<lifeless> the setting doesn't propogate
<jelmer> yes, but what happens if you "bzr merge <remote-url>" ?
<lifeless> you merge its content
<jelmer> and if you then push it, the revision changes !?
<lifeless> that setting is totally unrelated to merge
<lifeless> when you push, then the push will fail if that setting is set
<lifeless> because it enforces svn-like behaviour
<poolie> hello all
<jelmer> so you're basically suggesting append_revisions_only defaulting to yes?
<lifeless> jelmer: for SVNBranches only
<lifeless> jelmer: I'm suggesting two things: allow setting it in svn, not just in locations.conf (so that the admin can choose a setting); and defaulting it on for SVNBrach
<lifeless> *SVNBranch*
<lifeless> hi poolie
<lifeless> poolie: jam says use his mobile for the call
<lifeless> poolie: if he's not answering on skype
<jelmer> defaulting it to on would make sense, but we need to make sure to indicate properly why the push is failing
<lifeless> jelmer: sure, improving the error text shouldn't be hard
<poolie> lifeless, jam, spiv, call in 2m
<jam> poolie, lifeless: I'm back around, is the call still going?
 * NfNitLoop reads scrollback. 
<NfNitLoop> I like the idea of making the preserve-history option default to true.
<NfNitLoop> I've been using bzr since... 0.6?  ...  and have never even heard of locations.conf :p
<NfNitLoop> and breaking 'svn log' history is a definite bad impression if someone isn't expecting it, and isn't familiar enough with distributed vs. non-distributed SCMs to know why it happened.
<markh> are all the bzr-devs aware of the dvcs/bzr discussions on python-dev?
<spiv> markh: yeah
<jelmer> NfNitLoop, The thing I'm not sure about is having inconsistent behaviour between svn and bzr branch
<NfNitLoop> it's completely consistent while you're in bzr-land.
<NfNitLoop> the only inconsistency is when you try to push it back into svn.
<NfNitLoop> and things do work differently in svn-land.
<markh> I decided its best to not throw "windows support" into the mix for that thread at this time ;)
<jelmer> NfNitLoop, it's consistent in both, except svn doesn't have a good way to display it before svn 1.5 and svn users aren't used to it
<NfNitLoop> jelmer: aah, I'm still in 1.4 land, so I'm not entirely sure how 1.5 support looks for all of that.
<NfNitLoop> though...
<NfNitLoop> my initial reading of 1.5 features makes me very wary for using it for anything more complicated than one-off branches.
<NfNitLoop> there are different commands for trunk->branch and branch->trunk merging....
<NfNitLoop> and once you've merged back to the trunk, you have to throw away your branch.  (!?)
<jelmer> yes, just like you do with bzr
<NfNitLoop> You don't have to throw it away, though...
<NfNitLoop> you could keep using the branch and then merge back into trunk again and again.
<NfNitLoop> (whether or not that's a great workflow)
<NfNitLoop> So it looks like svn is just tracking r# when the branch is created, and tracking each merge from trunk into branch... then replaying diffs to merge back into main -- NOT actually keeping all revision IDs of what's been merged.
<NfNitLoop> (This is my guess after reading the svn book page on branching & merging in 1.5)
<NfNitLoop> (but I admit it wasn't all that thorough.)
<jelmer> it does keep track of what revisions were merged in 1.5
<NfNitLoop> Oh? Ok.
<NfNitLoop> Makes me wonder why you have to throw your branch away then.
<jelmer> well, you don't have to - you can have a single feature branch
<uws> jelmer: fwiw, gnome svn has been upgraded to svn 1.5 repositories recently
<NfNitLoop> So, when bzr-svn pushes into svn1.5, does it actually show merge history?
<NfNitLoop> I don't have a 1.5 install around to play with. :p
<jelmer> yes, it should be able to show which revisions were merged (if they are also present in the svn repository)
<NfNitLoop> aah.  but not if they're bzr-local.
<lifeless> jelmer: I don't think that inconsistency is bad
<lifeless> jelmer: because svn branches are by definition not bzr branches
<jelmer> lifeless, it makes behaviour less predictable
<lifeless> jelmer: you can't tell a-priori whether a bzr branch has that setting either
<jelmer> lifeless, e.g. it means we'd need a hack to be able to run the bzr repository testsuite (if it'll ever be generic enough) against svn repositories
<jelmer> lifeless, you can know that if you create a bzr branch yourself it doesn't
<lifeless> jelmer: I don't think we'd need a hack for that;
<lifeless> jelmer: I think we'd just call the api setting to set it off for any test that needs it off
<NfNitLoop> re: "predictable" behavoir:  breaking my svn history was unpredictable.  ;)
<NfNitLoop> well, at least, I didn't see it coming.
<lifeless> spiv: so
<lifeless> spiv: what inner loop was it in?
<emmajane> Instruction question... https://wiki.ubuntu.com/Training/KnowledgeBase#Launchpad%20and%20Bazaar Step # 4, Create your own branch doesn't seem to make sense to me. Can someone confirm that I'm just full of fail? :)
<lifeless> emmajane: looks the same as 3 to me
<emmajane> lifeless, Ok.
<emmajane> lifeless, would that even work?
<emmajane> I'm pretty sure it's "wrong" to include Step #4, but I'd hate to alter good instructions. ;)
<lifeless> no idea; I'd suggest stepping through the docs end to end; thats what I do to validate docs
 * emmajane nods. kay.
<lifeless> it certainly looks odd to me
<emmajane> maybe I'm not completely crazy then. Cool. :)
<emmajane> lifeless, thanks :)
<lifeless> np
<spiv> lifeless:  http://rafb.net/p/58nFen92.html
<jam> So... the installer for bzr-setup-1.9rc1-3 is built and tested on my machine, I just have to get an upload to LP to finish
<jam> It takes about 8 minutes to upload 15MB on my connection
<jam> and it has timed out once already.
<markh> yeah, that sucks :(
<markh> well - I don't see timeouts I don't think - just occasional launchpad errors
<markh> jam: any idea about that bug re the qt binaries failing to load?
<jam> markh: for whatever reason in the -2 build QtGui4.dll is only 6MB instead of 10MB
<jam> my best guess is that a copy got cancelled
<markh> right - weird!
<jam> and that the build process though the half-copy was up-to-date
<markh> right
<jam> the new build script I wrote nukes the target
<jam> and rebuilds everything
<jam> so I should be immune to that
<markh> ideally it would also nuke the 'build' dir from every sub-project too
<jam> markh: hmm... I suppose
<jam> I actually could just nuke them completely
<markh> or exact same thing could happen during *its* build
<jam> The script already is smart enough to download the latest releases, etc.
<lifeless> spiv: uhm
<lifeless> spiv: my likne 2183 is empty space :P
<lifeless> *line*
<markh> a re-download each build might be going a little too far though?
<jam> markh: We have shared repos for that
<lifeless> markh: why? reproducable :>
<jam> so it is mostly just nuking the working dir
<jam> and then connecting to LP, seeing it has everything, and checking out a WT
<markh> right - I thought you also meant all the python packages (qt, crypto, etc)
<markh> the bzr based stuff sounds reasonable
<jam> anyway, I'm done for tonight. You can find the script in C:\home\shared\bzr\releases\build_release.py if you want to give it a look
<jam> and I know the build-release for bzr uses "build_ext -i -f" to force a rebuild of everything
<jam> I'm not sure if we would want to do that for the others
<markh> I don't quite trust distutils --force
<markh> (in the same way I don't trust --dry-run to not do anything in all cases ;)
<jam> markh: as an aside, the icon overlays aren't working for me
<jam> is that a known problem for Vista?
<markh> in the binary version?  It should work - but most likely is .bzr.log is reporting it would "recurse to death" - in which case a fix has been pushed
<markh> (and assuming its a 32bit vista)
<jam> markh: I don't see tbzr putting much of anything into .bzr.log
<markh> jam: right - so no icon in the taskbar at all?
<jam> I guess I see:
<jam> 0.172  return code 3
<jam> 134.107  opening working tree 'C:/Users/jameinel/dev/bzr/bzr.dev'
<jam> 134.138  opening working tree 'C:/Users/jameinel/dev/bzr/bzr.dev'
<jam> It does have a taskbar icon
<jam> though it takes a *long* time to show up
<jam> and if I kill it
<jam> it will eventually show up again
<markh> yeah - it will come back next time an icon overlay or menu is requested
<markh> (that is also when it *first* appears)
<jam> ah, well something is causing it to not actually get results
<markh> fyi, tbzrcache.exe can be run explicitly from a cmdline to see what it is doing.  '-v' and --log-level=debug might be useful options.  You will need to shutdown the existing one before a new one will start.
<markh> (tbzrcachew.exe is a gui version that is automatically run)
<markh> but I'll grab the binary and have a play too
<lifeless> spiv: hello?
<spiv> lifeless: I think that's line 2111 in your branch
<lifeless> sure, I'm just puzzled at the difference :P
<spiv> lifeless: I had bzr.dev merged in from an earlier attempt to get apples-to-apples comparisons on network behaviour
<lifeless> ah right
<lifeless> push that somewhere if there were conflicts :P
<lifeless> I can benefit from that
<spiv> lifeless: but to be sure nothing wacky was going on, I just tried reproducing it with your pristine branch, and got a traceback instead!
<lifeless> spiv: remember my tip may be bust
<lifeless> go back 1
<spiv> Ah, ok.
 * spiv does that
<lifeless> anyhow
<lifeless> so this function is currently full-inventory every time
<spiv> Yeah, going back one fixed that.
<lifeless> spiv: that function could be better cast like the loop I put into fetch
<lifeless> to delta all the inventories in a chain
<lifeless> and only do a full inspect of the first one if the basis parent of the first is inaccessible
<lifeless> spiv: I think that would be quite managable to do and fix the major inefficiency
<mDuff> Is a working bzr-svn package available for current Ubuntu (Intrepid)? The one apt finds for me is too old for the Ubuntu-installed bzr 1.8.
 * mDuff is playing dumb user for the moment.
<mDuff> ...blerg, probably ought to upgrade to the New Shininess (bzr 1.9), and break from sticking with the Ubuntu packages anyhow.
 * mDuff finds the bzr PPA on Launchpad... oooh, didn't know 'bout that.
<lifeless> mDuff: :)
<mDuff> ...odd; "apt-get install bzr-svn" is still trying to install an older one, rather than the new package from the bzr-beta PPA.
<mDuff> ...oh, the bzr-svn in the beta PPA still depends on bzr <<1.7~ :(
<emmajane> jelmer, downloading is push?
<jelmer> emmajane, no, but it's the same bug
<emmajane> kay :)
<jelmer> emmajane, It's a bug in the progress bar handling
<emmajane> ahhh
<emmajane> do you work on olive?
<emmajane> I tried using this afternoon for the desktop course and none of us could get it to even open a downloaded branch for the course. :(
<Odd_Bloke> emmajane: How were you trying to open the branch?
<emmajane> Odd_Bloke, by clicking on the directory in Olive.
<emmajane> Odd_Bloke, massive freeze.
<emmajane> Odd_Bloke, no problems for other projects though
<jelmer> emmajane, no, though I work on most other things in bzr-gtk
 * emmajane nods
<Odd_Bloke> emmajane: Right, I think you're meant to run it from within the branch.
<emmajane> I know our team would *love* to have something other than the CLI for the project.
<jelmer> olive could use some attention :-/
<Odd_Bloke> Yeah.
<emmajane> jelmer, mostly I know how to submit bug reports. :/
<emmajane> Odd_Bloke, how do you run it from within the branch? it's got a button under applications to start it ;)
<jelmer> emmajane, that's still very useful
<Odd_Bloke> emmajane: From the CLI. >.<
<emmajane> jelmer, three today. :/
<emmajane> Odd_Bloke, nono, there's a button in the applications menu.
<emmajane> Odd_Bloke, you sholdn't have a button if it doesn't work. :)
<Odd_Bloke> Right, I'm saying there shouldn... yeah.
<Odd_Bloke> I'm too CLI-centric to want Olive, TBH.
<Odd_Bloke> I don't even used gvim. :p
<emmajane> I have a button for gvim.
<emmajane> control-S is wrong though, so I never use it
<Odd_Bloke> :D
<emmajane> jelmer, let me know if there's anything else I can do to help out with it.
<jelmer> emmajane, thanks, will do :-)
<emmajane> btw, it freezes if i open it from the command line as well... and then about 10 seconds later it kicks in
<Odd_Bloke> emmajane: How big is the branch you're running it on??
<emmajane> 500M
<Odd_Bloke> That probably explains the pause.
<Odd_Bloke> Though doesn't really justify it.
<emmajane> lots of pauses as I open folders and move around, but it's not freezing now
 * emmajane tries to remember which dir has 125 PNGs in it...
<emmajane> found it. :)
<Odd_Bloke> Leave Britney^WOlive alone!
 * emmajane waits a long time.
<emmajane> hehe
<emmajane> and there we go
 * emmajane wonders if beuno hates her yet too :)
<lifeless> spiv: does that make snese?
 * emmajane promises to go back to work tomorrow and stop reporting bugs. :)
<beuno> emmajane, you're one of my favorite people now!
 * emmajane chuckles.
<emmajane> beuno, i think I stopped at four.
<beuno> emmajane, you did. 3 of them are assigned to me already  :)
<emmajane> hehe
<beuno> you will have to start hiding once I start to produce mockups, cauise I'll hunt you down and squeeze all the information I can out of you!
<emmajane> beuno, you're welcome to ping me whenever you'd like!
<emmajane> I would love to not be complaining about launchpad anymore.
 * beuno double checks he's logging the conversation
<emmajane> :)
<beuno> emmajane, we have a big re-design ahead of us
<emmajane> beuno, good :)
<beuno> I want to stop complaining as well  ;)
<emmajane> heheeh
<james_w> beuno: I used your merge proposal redesign the other day
<james_w> beuno: I like it
<beuno> james_w, ah!  great to hear!
<beuno> I still have loads of things to improve on it
<beuno> but it's a pretty massive change  :)
<james_w> I would have your babies right now if it came with a multi-branch loggerhead thing to review with though
<james_w> and built-in PQM
<beuno> hahahahaha
<beuno> well
<beuno> PQM + Launchpad is coming soon
 * emmajane chuckles.
<james_w> woo!
<beuno> code is there, needs a proper UI
<james_w> that's your job!
<beuno> and, diffs in merges is very far ahead as well
 * james_w cheers
<beuno> so I'll plan for my babies around Jan/Feb
<james_w> I think you'll be receiving crates rather than beers from me at UDS
<beuno> haha
<Odd_Bloke> When/where is UDS?
<lifeless> dec san fran
<beuno> I'll make sure I eat often
<lifeless> right after fosscamp
<lifeless> http://www.fosscamp.org/
<james_w> it took me ages to find the thing to mark one as merged though
<beuno> james_w, they get marked automagically
<james_w> oh, great!
<james_w> I was just going to point out that it should be possible :-)
<beuno> once LP scans either the target or proposed branch, it finds the revid, and bingo
<beuno> same will happen with branch statuses
<james_w> woo!
 * james_w dances
<beuno> there is a patch floating around
<beuno> yeah, we did a lot of work in the 1 week sprint
<james_w> now just for bug statuses and I'll be happy
<beuno> plus a ton of notes  :)
<beuno> what about bug statuses?
<james_w> like Fix Committed when it's in the development focus
#bzr 2008-11-06
<james_w> and Fix Released when I tell it I release a milestone
<james_w> or something
<james_w> I'll leave the details to you guys :-)
<beuno> I don't quite understand
<beuno> fix committed automatically when what?
<Odd_Bloke> beuno: When a branch is merged to the development focus.
<beuno> ah
<beuno> what has that to do with bugs?
<Odd_Bloke> s/branch/branch that fixes a given bug/
<james_w> I'm talking about the bugs statuses
 * beuno blinks
<Odd_Bloke> Then the bug gets automagically marked as Fix Committed.
<beuno> that's a bit tricky
<james_w> you have "Fix Available" on the branch when I push a --fixes. If that gets merged to the development focus then it sets the bug "Fix Committed".
<emmajane> beuno, *grin* and you thought I was bad. ;)
<beuno> james_w, gotcha
<beuno> should be viable
<Odd_Bloke> emmajane's paying us to make her look better. :p
<beuno> file a bug, I'll try and make it happen
<emmajane> james_w, how come I have to report bugs and you just get IRC requests. ;)
<emmajane> WOO!
<emmajane> :)
<beuno> emmajane, ;)
<emmajane> beuno, hopefully the screenshots were helpful as well?
<beuno> emmajane, they're better than a patch
<beuno> deeply appreciated
<emmajane> kay
<emmajane> I'll continue to include them as I find more things.
<beuno> if all users where like you, software would beperfect
<emmajane> hehe
<emmajane> beuno, You can come and work with Drupal when you're done with LP. ;)
<beuno> (my typing, on the other hand...)
<beuno> done with LP? ha!  like that will ever happen
 * emmajane grins
<beuno> LP is *big*
<beuno> huge
<emmajane> so is Drupal ;)
<emmajane> it will be ready for you when you're done ;)
<Flare183> When I try to push my bzr branch to launchpad it give me this error: Transport operation not possible: http does not support mkdir()
<beuno> heh, I'm sure it will
<Flare183> What can I do to fix this?
<beuno> Flare183, you need to specify your launchpad login
<Odd_Bloke> Flare183: 'bzr launchpad-login -h'
<beuno> bzr launchpad-login <username>
<Flare183> oh ok
<beuno> -h?
<Odd_Bloke> Help. :D
<beuno> right, fish/teach to fish
<beuno> I hate fishing, so I just give people food
<Odd_Bloke> NOM NOM NOM
<Flare183> ok Now I get this error: Target directory already exists. Please select another target.
<Flare183> I know it exists thats why I'm pushing it there. Duh bzr!
<Flare183> How can I fix this on?
<Flare183> one*
<Odd_Bloke> Flare183: What command are you using?
<Flare183> bzr push
<Odd_Bloke> Or, rather, what's the full command-line?
<Flare183> Actually I'm using Olive
<Flare183> But I can use the command line
<Flare183> hold on
<Odd_Bloke> Heh, serendipitous.
<Odd_Bloke> What's the location you're trying to push to?
<beuno> Flare183, add --use-existing
<Flare183> oh ok
<beuno> the error should be telling you to add the flag  ;)
<Flare183> jesse@jesse-desktop:~/Python Projects/bot$ lp:~richardson183/ubuntu-bots/flarebot --use-existing
<Flare183> bash: lp:~richardson183/ubuntu-bots/flarebot: No such file or directory
<Flare183> jesse@jesse-desktop:~/Python Projects/bot$
<Flare183> ...
<Odd_Bloke> 'bzr push ...'? :)
<Flare183> hold on
<Flare183> sorry i screwedup
<Flare183> screwed up*
<Peng_> lifeless: FWIW, Launchpad hasn't been able to mirror https://code.launchpad.net/~lifeless/bzr/repository for a month.
<lifeless> fail
<lifeless> :P
<loxs> folks, is there any permissions implemented in bzr itself?
<loxs> because we are having a problem... one of my devs has read access to the main branch, but cannot co the trunk
<loxs> http://dpaste.com/88990/
<Odd_Bloke> loxs: Have you checked FS permissions?
<bob2> won't read-access via ssh (try to) take a lock?
<lifeless> no
<loxs> Odd_Bloke, they have read access
<loxs> bob2, what do you mean by "take a lock"?
<Odd_Bloke> Well, checkout implies commit access.  Does 'branch' work?
<bob2> loxs: don't mind me
<loxs> hmm, I didn't know that, we'll try with branch
<Odd_Bloke> loxs: Also, do they have execute permissions on .bzr?
<Odd_Bloke> Because if not then they won't be able to access anything under it.
<Odd_Bloke> "chmod -R a+rX .bzr" or some equivalent is probably what you want.
<loxs> yes, they have +x
<james_w> beuno: thanks
<Odd_Bloke> james_w: Whereabouts are you based these days?
<james_w> Odd_Bloke: Bristol
<Odd_Bloke> loxs: And can they actually read that file via other means?
<Odd_Bloke> james_w: Cool, I remembered that your old job was there, but didn't know if you were still there.
<james_w> Odd_Bloke: yeah, no reason to leave yet
<james_w> Odd_Bloke: how's work treating you?
<Odd_Bloke> james_w: Eh, so-so.
<james_w> oh no, that will be over now won't it?
<james_w> oh, it's a year isn't it?
<Odd_Bloke> 9 months.
<Odd_Bloke> I'm finding getting up in the mornings quite difficult.
<Odd_Bloke> And there's rather more OpenOffice in my life than I'm entirely comfortable with.
<Odd_Bloke> I don't really know whether I have issues with this job, or with 9-5 jobs in general, though, this being my first of more than 2 weeks.
<james_w> OpenOffice should come with a health warning
<james_w> yeah, I found 9-5 tough
<loxs> yes, Odd_Bloke they can read the file when they do it via cat etc... and it raises the same exception when using branch
<Odd_Bloke> We're doing so much crazy stuff with OO.o.
<james_w> though I ended up working like 7-3 quite often so that I actually had an evening
<Odd_Bloke> Ranging from writing an automated presentation player to backporting OO.o 3 to Sarge. >.<
<james_w> ouch
<james_w> my sympathies
<Odd_Bloke> Thankfully I've mostly avoided the backporting.
<Odd_Bloke> It's also a little frustrating that I don't feel I'm working _on_ free software so much as I'm working _with_ it.
<Odd_Bloke> Which is nice, but this presentation player we're writing is going to be non-free.
<Odd_Bloke> Making it, IMO, a complete waste of my time.
<Odd_Bloke> Certainly it's a far cry from stage diving. :p
<james_w> :-)
<lifeless> spiv: ping me when you're online please
<Odd_Bloke> james_w: Anyway, the reason I asked where you were is that I have a friend at Bristol, and it'd be good to meet up for a drink if I ever get around to visiting him.
<james_w> Odd_Bloke: sure, I'd like that
<Odd_Bloke> Cool.
<lifeless> loxs: hi
<lifeless> loxs: /home/bazaar/bloxs/trunk/.bzr/branch-format is the path reported in your error
<lifeless> loxs: can you have one of the users try 'scp HOST:/home/bazaar/bloxs/trunk/.bzr/branch-format .'
<loxs> lifeless, thanks but we resolved it... typical administrator error... :)
<loxs> they had permissions to read the repositories... but they didn't have permissions to read the top /home/bazaar/ directory :)
<lifeless> heh
<spiv> lifeless: pong
<spiv> lifeless: was online, just not looking at IRC very much!
<lifeless> spiv: I wanted to know if my comments made sense etc
<lifeless> spiv: the void was a tad disturbing
<spiv> lifeless: don't stare into the abyss ;)
 * spiv quickly rereads
<spiv> lifeless: so, I see a loop you added to fetch, although I don't grasp how it's deltaing a chain of inventories
<spiv> lifeless: the high-level description you gave makes sense, I just don't see the code.
<lifeless> spiv: ah yes
<lifeless> spiv: I lied apparently
<spiv> Heh.
<lifeless> spiv: the loop would be something like:
<lifeless> grab the the inventory meta node for all the inventories
<lifeless> plus one for any arbitrary inventory outside the set that the target has
<spiv> lifeless: _install_revision looks like it has added code related to this, maybe?
<lifeless> then do a set based difference on the node's pointers
<lifeless> and repeat
<lifeless> spiv: not really
<lifeless> spiv: _install_revision has a inventory cache to get deltas, because it can insert deltas more cheaply than full inventories
<spiv> lifeless: thanks
 * spiv -> lunch
<lifeless> spiv: the packer has no cache set
<lifeless> spiv: you should chat more :>
<lifeless> spiv: ugh, I hate lp's handling of attachments
<lifeless> send me the damn diff, biatch
<spiv> lifeless: http://rafb.net/p/9LQyFJ98.html
<spiv> lifeless: or do you mean email?
<lifeless> spiv: lol I was ranting at lp
<lifeless> at what it does
<lifeless> not at you
<spiv> Oh, right :)
<spiv> Yeah.
<lifeless> I clicked to see the attachment
<lifeless> and I commented too
<emmajane> lifeless, careful or beuno will tell you to post a bug about LP. ;)
<lifeless> emmajane: oh theres plenty of those already
<lifeless> emmajane: :)
<emmajane> heheh
<emmajane> he likes it when you *attach* pictures. ;)
<gour> morning
<gour> am i right that 'shelve' is moving into core?
<luks> already moved, as far as I know
<spiv> Yep.
<gour> yeah, i saw r3823...very nice
<gour> fix for #293054 will go into 1.9 ?
<lifeless> gour: its a new shelf, not the old one moved
<lifeless> bug 293054
<ubottu> Launchpad bug 293054 in bzr "bzr fails with python2.6 and https missing sendall" [High,Fix committed] https://launchpad.net/bugs/293054
<lifeless> gour: I don't know, it might, 1.10 for sure
<gour> lifeless: but the new shelf provides the same functionality?
<lifeless> different
<lifeless> much in common
<lifeless> it can shelve more things
<lifeless> but some aspects are not as mature
<gour> aha...still it's nice that plugin's functionality goes into core...
 * fullermd really looks forward to being able to shelve more things.
<fullermd> A notable percentage of the times I've wanted to shelve, there have been renames or binary files involved.
<vila> hi all
<vila> gour: I doubt bug #293054 will make it into 1.9 but I'll try
<ubottu> Launchpad bug 293054 in bzr "bzr fails with python2.6 and https missing sendall" [High,Fix committed] https://launchpad.net/bugs/293054
<gour> vila: thanks
<vila> gour: you're welcome, your testing of python-2.6 support is very much appreciated :)
<gour> vila: heh, python-2.6 is default in archlinux, so i didn't do any extra work :-)
<gour> ...except using bzr
<vila> gour: which is exactly the point of having testers :) I had to rebuild a python-2.6 from sources to reproduce the problem, and a pycurl too (for different but related reasons) since my setup wasn't as clean as I thought, so indeed, it was harder for me to notice the problem
<gour> i'm glad if i was somewhat useful in improving my beloved tool
<fullermd> Man, I hate the half-assed VCS capability of wikis sometimes...
<eydaimon> Is there a plugin or some such that allows emails to be sent out from the server when commits are made?
<lifeless> the bzr-email plugin; I *think* its been updated to work with commits as long as you're using bzr+ssh
<lifeless> spiv: ^ do you recall?
<lifeless> eydaimon: you can definitely just install it on each machine
<lifeless> eydaimon: there is also a cron based plugin that can mail when a branch changes
<eydaimon> ok, thanks
 * fullermd figures he's spammed enough people for one night.
<spiv> lifeless: don't know, sorry
 * gour just re-read http://andrew.puzzling.org/diary/2008/July/29/rebase-criticism post and wonder whether there is scope for rebase in bzr
<gour> what's happening with loom plugin? it looks like not much since 1.3...
<spiv> gour: there's a rebase plugin for bzr.
<spiv> gour: I just happen to think it's usually not the best option :)
<gour> spiv: yeah, i did not go into looms yet, but example of selective merge is simple & good enough that i wodner why i'd need rebase
<dissonans> I just merged a bunch of revisions from another branch using bzr 1.9rc1 and bzr-svn 0.4.14, but apparently the merge wasn't recorded
<dissonans> first off, bzr st showed only straight modifications and no merge, then the "missing" command still shows the merged revisions as missing
<spiv> gour: the attraction of rebase is that it's a fairly simple mental model to work with
<gour> spiv: heh, it seems my mind is at different wavelength then :-D
<spiv> gour: so if you are the sort of person that thinks in terms of "this branch would be better if revision #N was done differently" then rebase seems natural
<gour> what is the price for it?
<spiv> Well, you lose the original history.
<gour> and new merge will produce (more) conflicts?
<dissonans> when you've merged, it's supposed to be indicated by "status" no?
<spiv> Which impacts operations that use history, most obviously merge -- if someone else has branched off your original branch, then you rebase, now you have two branches that independently make similar changes.  Which means you've almost certainly created conflicts that you didn't have before.
<spiv> dissonans: right
<dissonans> well, it isn't :/
<dissonans> I just confirmed
<spiv> dissonans: but we don't record merge history for cherrypicks yet
<gour> spiv: yes, similar with doing unrecord in darcs after the patch went into wilderness?
<spiv> dissonans: how did you do the merge?  "bzr merge -r A..B"?
<dissonans> spiv: ah hm
<dissonans> yep, specific revisions
<dissonans> that's a problem
<spiv> gour: I'm not familiar enough with darcs, but that sounds likely.
<dissonans> I know merge has worked as I expected, but maybe I wasn't cherrypicking
<spiv> dissonans: probably.  Or maybe the base of your cherrypick was already in the branch you were merging into.
<dissonans> spiv: nah
<gour> spiv: is it possible to record merge history when cherrypicking in bzr?
<gour> (by bzr's design)
<spiv> gour: there was talk about how to support them at the March 2008 sprint
<spiv> I forget the details, but they're probably on the list somewhere.
<gour> cool. cherrypicking-ala-darcs would be great
<spiv> It would.  It's a pretty common request, unsurprisingly.
<dissonans> should I follow any other pattern to integrate changes from the trunk in my release branch then?
<crisb> hi everyone.  has anyone got any tips about converting from an RCS like system (PVCS) to bzr?
<dissonans> can't see how to avoid it, and I kind of relied on having the merge history
<gour> btw, what is with the bug #109143 ?
<ubottu> Launchpad bug 109143 in bzr "hpss does not support ~ (tilde) for home dir access on bzr:// or bzr+ssh://" [High,Triaged] https://launchpad.net/bugs/109143
<spiv> gour: not enough people have complained about it recently ;)
<gour> ok, let me add myself to the list
<fullermd> I knew I shoulda set up that cron job...
<spiv> gour: actually, you're the second person to mention it to me in the last week or so.  It's probably due to be bumped up to the top of my list of things to do...
<crisb> we want to convert to bzr and i'm thinking of moving just the head over then manually recreating any branches we had (PVCS has no concept of a whole project branch, just a file by file one) does that sound stupid?
<crisb> i mean can i somehow change timestamps of commits?
<fullermd> crisb: I would suspect converting PVCS to CVS or SVN, and then going from there to bzr, would be the simplest thing to try...
<fullermd> (since there are existing tools for both those paths out of PVCS, and both of those paths into bzr)
<crisb> fullermd: yes sorry thats my plan, its just they dont give me anything very sane at the end of it if I leave it all up to the conversion tool
<fullermd> Mmm.  Yeah, if you started doing the sort of weird per-file stuff PVCS/RCS/CVS let you do, I can see that...
<crisb> fullermd: so as we really dont want to end up with people having to know 2 (very different) tools we want to make a complete break from the past :) but do i have the ability to go in and fiddle about with the bzr repository when i'm making these manual branches from the historical stuff?
<fullermd> You can't change existing commits, no.  But you can certainly [through bzrlib; not through the CLI] set whatever attributes (including timestamps) you want on freshly created revisions.
<gour> where can one find more info in regard to "Predefined formats for dumping version information in specific languages are currently in development." ?
<fullermd> gour: "bzr help version-info"?
<gour> fullermd: i mean if there is some work for other concrete language-formats like it's for 'python'
 * gour thinks (un)shelve is great stuff
<vila> so one can go from zzz to afk and hist IRC client noticed...
<vila> so one can go from zzz to afk and his IRC client noticed...
<gour> hmm, cdiff prints in grey on white bg...how to fix it?
<NET||abuse> uhoh,, i just ran bzr merge in my local svn working copy of a project i'm working on... i'm tired and think i just didn't think,, will this do anything bad?
<NET||abuse> it says it's generating file id map at the moment.
<lifeless> NET||abuse: just hit ctrl-C if you didn't want to do that
<NET||abuse> .. well, doing a svn up on the working copy doesn't give out
<NET||abuse> svn status shows up no new weird entries
<NET||abuse> seems ok
<NET||abuse> back in my bzr copy now
<fullermd> As I see it, the problem is that that project isn't in bzr   ;)
<NET||abuse> did bzr merge to get changes from other people down, bzr log only shows rev 487, we're on 520
<beuno> james_w, hey hey, happy birthday!
<lifeless> NET||abuse: thats normal
<lifeless> NET||abuse: revnos are per-branch
<lifeless> NET||abuse: (by analogy, consider multiple svn repos being synced with svk; revno's are per repository there)
<lifeless> gnight
<NET||abuse> lifeless: cheers. :)
<NET||abuse> lifeless: seeya
<james_w> thanks beuno
<Rolly> I have a live website that is a standalone tree. I want to allow someone remote read+write access to the repository (htdocs/.bzr/), but I don't want to give them any access to the working tree files (htdocs/) or in fact any path on my server's filesystem. What would be the quickest way to accomplish this?
<Rolly> Oh and SSH / SFTP are out of the question
<awilkins> Holy monkey, why does this "bzr log -v" require 500MB of ram.....
<awilkins> It's a rather large tree, but even so
<Rolly> I also forgot to mention I need some sort of authentication, even if it's rudimentary. I think that rules out "bzr serve"
<quicksilver> I'm not aware of any other form of write access
<quicksilver> since you've ruled out ssh, sftp and the smart server
<quicksilver> well, except bridging the filesystem to them somehow.
<Rolly> Hm, but I've read that the smart server can be used with http
<quicksilver> you can't write over http.
<Odd_Bloke> You can, with the webdav plugin.
<Odd_Bloke> vila will know more.
<soren> How can I tell a signed commit from an unsigned ditto?
<Rolly> argh
<Rolly> I didn't see that mentioned in the docs, thanks
<vila> bzr+ssh, bzr+http[s], webdav all provide various kind of authntication
<Rolly> right I was just looking at authentication.conf
<vila> wrong path
<vila> authentication.conf is how you describe *your* credentials when accessing remote servers not how you want your local server to handle authentication
<Rolly> Right, I think I understand that. It's SSH/webserver/webdev/etc that provide the server-side auth
<vila> and if you install a smart server in your http server you *have* write access and you can use http[s] to handle authentication
<vila> Rolly: yes
<Rolly> Ah, you mean like with bzr-smart.fcgi or fcgi.py I can get write support?
<vila> yes
<Rolly> fabulous
<Rolly> It's a little confusing at first
<vila> If you feel you can make that clearer in the doc at any place, patches are welcome :)
<Rolly> just to be clear, using the smart server in the http server will just allow my remote user to just access the repository, yes? No filesystem access?
<Rolly> (ignore that redundant "just")
<vila> Rolly: that's the idea yes
<Rolly> Cool
<Rolly> the user reference definetely needs some clearing up, maybe I'll take a stab if I wrap my head around this
<vila> Err, wait, re-reading your description: access to htdocs/.bzr but no access to htdocs itself is a bit contradictory since the later is the working tree for the former
<vila> if you really want to separate the two just give your user write access to a different branch at a different place and merge/update locally what you want
<Rolly> I didn't mean literal filesystem access to htdocs/.bzr/, I actually meant "access to the repository"
<Rolly> like with svnserve, you can serve a repository through svn:// and the users don't have filesystem access
<vila> In that sense then yes if .bzr is a repository and not a branch my warning doesn't even apply
<Rolly> Well, when I "cd htdocs && bzr info", I get "Standalone tree,  branch root: ."
<Rolly> In SVN terminology, htdocs/ is my repository _and_ my checkout. I need to give remote access to the repository but not the checkout
<vila> You realize that if you give write access to your repo, even if the smart server doesn't update your working tree when your remote user commit, you will take his commits into account the next time you do bzr update ?
<Rolly> yeah, that's what I want
<Rolly> I just need a firewall (me) to check missing revisions before I update
<vila> Then you'd better give him access to another branch from where you can pull or merge (IMHO)
<vila> That will give you more control of your htdocs content
<vila> While taking his modifications will still be easy (even easier the day you disagree with some modification)
<Rolly> I see your point
<vila> That's a usual setup where your user pull from your repository, push to a staging one and *you* pull or merge from the staging one acting as the gatekeeper (or firewall as you said)
<Rolly> Hm, in what cases is that more convenient for the gatekeeper?
<Odd_Bloke> Rolly: In the case where you don't want some changes.
<Odd_Bloke> Because then you just don't pull, rather than having to perform acrobatics with the history of the branch.
<Rolly> But in a production<->staging scenario, a bad commit can just be deleted (there isn't going to be a lot of activity on this repository, and no parallel coding going on
<Odd_Bloke> A bad commit can be deleted, but should you be deciding the best way to do that, or should the developer?
<Rolly> in this case, me
<Odd_Bloke> In that case, there's not a massive amount to be gained from pushing to a separate branch, except that it is: a) good practice, and b) more future-proof.
<Rolly> gotcha
<Rolly> by the way, in the user reference, there is one mention of using an "http:// URL when a smart server is available via HTTP"
<Rolly> everywhere else, it talks about "bzr+http://". What is the difference?
<Odd_Bloke> Rolly: Where is that reference?
<Rolly> http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#hooks
<Rolly> and then if you look here, it also mentions both protocols: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#serving-bazaar-with-fastcgi
<Rolly> "Now you can use bzr+http:// URLs..."
<Rolly> "Plain HTTP access should continue to work..."
<Odd_Bloke> Hmm, I'm afraid I don't know.
<Odd_Bloke> I've never set up smart HTTP access.
<Rolly> I'll just dive in and see what happens
<vila> Rolly: the smart client probes any http server and revert to plain http when no smart server answers
<Rolly> aha
<Odd_Bloke> vila: You can disable that behaviour using http+nosmart://..., right?
<vila> right
<Odd_Bloke> And does the HTTP smart server give me any benefit on read-only branches?
<Rolly> a benefit would be speed, right?
<vila> Odd_Bloke: more and more :)
<Odd_Bloke> Right, I wasn't sure if 'smart' meant 'I can write to this', or meant 'generally better in every way'.
<vila> and if you find a place where it is slower than raw http, file a bug
<vila> the later
<Odd_Bloke> Cool.
<Odd_Bloke> I'll look into setting it up at some point.
<jml> lifeless: *nudge* https://code.edge.launchpad.net/testresources/+activereviews
<loxs> hello, is there a way to version control ODT documents with bzr?
<gour> loxs: odt is compressed xml or not?
<loxs> gour, I have no idea
<beuno> loxs, I don't thing there is a good way to do so ATM, no
<beuno> it will version it as binaries
<gour> loxs: it looks it's zipped xml content, so not the best candidate
<beuno> which isn't very good
<luks> a good way to do what exactly?
<beuno> OO has versioning built in
<beuno> and you can plug VCSs into it
<beuno> but I don't know too much abput it
<loxs> hmm, OO has versioning? interesting
<gour> loxs: i decided to use reST markup for all my writings...it can be nicely versioned with bzr, and there is nice rst2odt converter
<loxs> but I suppose there is no good way for collaboration built in OO
<gour> loxs: ...if reST markup satisfy your writing needs.
<luks> loxs: what do you expect when you say 'to version control ODT documents'?
<loxs> gour, the thing is that most of my contributors won't manage to do it
<loxs> luks, version control and collaboration :)
<luks> what does that mean?
<gour> loxs: hmm, reST is so simple and one can write it in Notepad
<luks> bzr can do it just fine, if you use my definition
<gour> loxs: and using some bzr-gui it's easy for your contributors to commit and/or send you 'bundles' for merging
 * gour --> lunch.bbs
<loxs> I'm afraid that I need rich formatting in a WSIWYG editor... so rest is not the best option, gour
<loxs> it's not technical documentation, but medical one...
<Odd_Bloke> Well, versioning ODTs in bzr won't be pretty.
<loxs> and we need to collaborate on things like presentations etc
<Odd_Bloke> Or, for that matter, much better than saving copies of the ODT, AFAIK.
<luks> versioning binary files won't be pretty in any vcs
<luks> but as this question is in #bzr, I don't think that's the problem
<Odd_Bloke> But if you could get it in an intermediate format, then things might be better.
<loxs> yeah, after all I can give up and use google docs :(
<loxs> the thing is that I want the docs "in-house" :)
<luks> it's not like google docs can merge documents better than bzr
<jonnydee> hi, when I try to push my branch to a shared repository via ftp protocol I get:
<jonnydee> zr: ERROR: Transport error: FTP temporary error during APPEND /bzr-repo/.bzr/repository/upload/bh3t4m7b8vud2womzv46.fetch.Aborting. 451 /bzr-repo/.bzr/repository/upload/bh3t4m7b8vud2womzv46.fetch: Append/Restart not permitted, try again
<jonnydee> Does anyone know what this means?
<luks> jonnydee: your FTP server doesn't support APPEND
<luks> jonnydee: which probably means you can't use it with bzr
<guilhembi> weird... after a "bzr pull" of the latest bzrtools, all bzrtools command are gone (absent from "bzr help commands")...
<jonnydee> well, that's not good news :(
<Odd_Bloke> guilhembi: What do you see in ~/.bzr.log?
<guilhembi> Odd_Bloke: I see
<guilhembi> 'dict' object has no attribute 'register_lazy'
<guilhembi> Unable to load plugin 'bzrtools' from '/home/guilhem/.bazaar/plugins'
<luks> you are using old bzr, upgrade to 1.9
<guilhembi> on the screen, that's interesting... now updating to latest bzr.dev
<luks> or downgrade bzrtools
<guilhembi> luks: thanks, it's the solution
<jonnydee> I just asked our IT to create an ftp account for hosting bazaar branches and now the APPEND functionality should be the problem? ok, I see I will not be able to use Bazaar in our company... :(
<Odd_Bloke> jonnydee: :(
<Odd_Bloke> Do you really only have FTP to access your servers?
<jonnydee> thanks Odd_Block
<Odd_Bloke> You might want to start slapping your IT department around if that's the case. :p
<jonnydee> well there is also a windows network share...but this one is not reachable from our development-intranet network. the only server which is reachable from everywhere is our ftp server....
<jonnydee> ok, anyway, thanks
<Odd_Bloke> It seems likely that a workaroubnd could exist (i.e. fetch remote file, append locally, push new file back).
<Odd_Bloke> But I don't know where append is used, so that might be prohibitive in terms of performance.
<luks> I wonder what do packs need append for
<Odd_Bloke> jonnydee: Could you paste the .bzr.log section for the command run in question?
<Odd_Bloke> Or, better, file a bug containing it.
<jonnydee> ok, I will file a bug. Thanks for your attention.
<Odd_Bloke> jonnydee: No worries.  Sorry this didn't work. :(
<jonnydee> Maybe one day I will be able to use Bazaar in our development team. At the momen I can at least use it locally...
<gour> loxs: have you considered something like lyx (latex-front end)? it's wysiwym
<gour> loxs: it can be nicely versioned, it has some collaboration tool integrated...
<loxs> hm, a good idea gour, thanks
<loxs> but that will solve only the "doc" needs, we still have to find a way for the presentations
<gour> loxs: use latex beamer class for presentation and create presentation in pdf without worrying whether it can be presented or not ;)
<loxs> the thing is that the documents will be written by people who have never heard of latex
<gour> loxs: check http://wiki.lyx.org/Examples/Beamer....well lyx hides almost all of latex stuff, it's like wysiwyg editor
<gour> loxs: i was once burnt with binary format when working on one book and was not able to open it next day - program was crashing immediately...after that, i never wrote and save in binary format...only text formats (LaTeX, ConTeXt, reST....)
<loxs> yet, I think it will be impossible to convert them to lyx.... I had gread difficulties to make them use OO, and I think it's impossible to change them any more :)
<Odd_Bloke> The LyX beamer stuff probably isn't good enough...
<gour> Odd_Bloke: good enough for what? you mean OO has better features?
<Odd_Bloke> Sorry, good enough for people who don't want to know about LaTeX.
<Odd_Bloke> I vastly prefer Beamer to any other presentation software, but always use vim for it.
<Odd_Bloke> I do use LyX for other documents.
<gour> ahh, ok then ;)
 * gour is moving to ConTeXt instead of lyx/latex
<Odd_Bloke> That sounds suspiciously Mac-like.
<loxs> never heard of context
<jonnydee> Odd_Bloke: I've just filed a bug regarding my previously reported issue: https://bugs.launchpad.net/bzr/+bug/294709
<ubottu> Launchpad bug 294709 in bzr "Pushing to shared repo using FTP doesn't work: "Append/Restart not permitted, try again"" [Undecided,New]
<Odd_Bloke> jonnydee: Thanks. :)
<gour> Odd_Bloke, loxs: check http://wiki.contextgarden.net/Main_Page
<gour> it's kind a 'what-latex3-is-supposed-to-be-one-day'
<jonnydee> Odd_Bloke: You're welcome :)
<fynn> Hi. How do I serve a bzr repo off a dumb HTTP server?
<Odd_Bloke> fynn: Put it somewhere HTTP accessible.
<fynn> Odd_Bloke: can I just put an empty directory with the .bzr dir inside it?
<Odd_Bloke> fynn: Just 'bzr branch <BRANCH> <PUBLICALLY ACCESSIBLE LOCATION>'.
<luks> um, `bzr push <PUBLICLY_ACCESSIBLE_LOCATION>` instead?
<fynn> OK, that would publish a working copy with its .bzr directory, right?
<NfNitLoop> not if the destination is remote.
<NfNitLoop> bzr doesn't try to build a working copy when it pushes to remote locations.
<NfNitLoop> for performance reasons (I think?)
<fynn> sounds like "a bare repository" in git...
<Keybuk> Why isn't the bzr-svn in the PPA installable?
<Odd_Bloke> luks: I don't know, I fail. :p
<Odd_Bloke> Keybuk: I think mostly because PPAs don't keep old versions of packages around.
<Keybuk> Odd_Bloke: the version of bzr-svn in the PPA explicitly depends on the version of bzr *not* in the PPA though
<Keybuk> that's kinda odd
<Odd_Bloke> Keybuk: A newer version or an older version?
<Keybuk> it depends:
<james_w> a new bzr-svn hasn't been uploaded yet
<Keybuk> bzr >= 1.6~, bzr << 1.8~
<fynn> one more question: is there a way to publish a bzr repo on a dump HTTP server as a single file?
<Odd_Bloke> fynn: You could just tar it up.
<fynn> Odd_Bloke: would people be able to pull directly from the tarred form?
<luks> fynn: no
<fynn> OK, it's like git in that sense then.
<fynn> you need to publish the full .bzr tree if you want people to pull from it.
<luks> right
<sven> hi! when i run 'bzr visualize', it says "bzr: ERROR: No module named dbus  You may need to install this Python library separately.". but i have dbus installed.
<sven> i'm using the current development branch of bzr, and the latest dbus that comes with ubuntu
<Odd_Bloke> sven: Check the appropriate part of ~/.bzr.log.
<sven> Odd_Bloke, ok, here: http://pastebin.com/m38ce1a03
<fynn> OK, not sure I got it:
<fynn> how do I clone to a bare repository in Bazaar?
<fynn> ("bare" == a repository without a working copy, essentially only the .bzr directory)
<luks> first you need to fix your terminology
<luks> you can't clone a repository, you can get a copy of a branch
<luks> `bzr branch PUBLIC_LOCATION`
<fynn> OK, and how do I make a copy of a branch that contains only the .bzr, and no working files?
<luks> I don't think you can do it directly, either setup a treesless local repository and run `bzr branch` or run `bzr branch` followed by `bzr remove-tree`
<luks> or better, what are you doing?
<fynn> publishing a bzr repo over a dumb HTTP server.
<luks> maybe it's something git-specific for which has bzr a different solution?
<luks> what's the use case for a not having the working tree?
<luks> locally, of course, it won't be on the server
<fynn> the server is not to house a working tree, because nobody is editing files on the server.
<fynn> it's just a server to pull/push from/to.
<luks> right, so it's a misunderstanding
<sven> Odd_Bloke, did .bzr.log tell you anything?
<luks> let's say you have ~/project (where you work) and ~/public_html/bzr/project (where you want to publish the repo)
<luks> now, in ~/project you run `bzr push ~/public_html/bzr/project`
<luks> and on another computer you run `bzr branch http://example.com/~user/bzr/project`
<luks> that's all
<luks> you can replace ~/public_html/bzr/project with any bzr-supported procotol, e.g. sftp://example.som/home/user/public_html/bzr/project
<luks> fynn: did that help or did I confuse you even more? :)
<fynn> luks: "now, in ~/project you run `bzr push ~/public_html/bzr/project`" -> but wouldn't that recreate also the working tree of ~/project inside ~/public_html/bzr/project?
<luks> fynn: no
<luks> fynn: oops, yes if it's local
<luks> fynn: in that case run `bzr remove-tree` in ~/public_html/bzr/project
<luks> fynn: but if it's a different server, you won't need it
<fynn> luks: right, and it looks like 'bzr remove-tree' in a branch makes it a "working-copy-less" branch, i.e. what git calls "a bare branch"
<luks> fynn: yes, but in case of pushing over network if will not create the working tree
<luks> fynn: it happens only if you push to a local location
<fynn> so it's the same concept, and the same outcome, just that in bzr for local branching, it's a two-step process (push and remove-tree) while in git it's a single step with a switch (clone with the --bare flag.
<fynn> luks: thanks a lot, all clear now.
<fynn> luks: ah, there's another small different.
<fynn> *difference
<luks> note that it will remember the "no working tree" flag, so if you push the next time it will be all fine
 * fynn nods
<fynn> in git, if you create a bare branch in ~/public_html/bzr/project, ~/public_html/bzr/project would contain the contents of ~/project/.git directly.
<Odd_Bloke> sven: Sorry, I've been called away.
<Odd_Bloke> Someone else here should be able to help you though.
<fynn> in bzr, it would contain ~/project, it's just that if you also did remove-tree, it would only contain .bzr inside, and no working files.
<sven> Odd_Bloke, hmm, actually, from looking at the code it seems like you need not only dbus, but the bzr-dbus plugin. a bit hard to tell from the error message though
<sven> hi! i'm having trouble using the latest bzr-gtk development branch, because it depends on the dbus plugin, which fails to compile for me with the message "libxml-2.0 >= 2.6.0... configure: error: No XML library found, check config.log for failed attempts". i have the version 2.6.31-dfsg-2ubuntu1.2 libxml2 package installed
<sven> or rather, dbus fails to configure
<jam> guilhembi: ping
<emmajane> beuno, ok there's your bug for today. :)
 * beuno looks
<beuno> emmajane, I have some work done already which addresses that  :)
<emmajane> woo!
<emmajane> I should double check that the other bug that I commented on (that mpt commented on) makes sense as well...
<emmajane> it's sort of the same problem...
<beuno> yeah, navigation needs re-working
<beuno> it's high on my list
<emmajane> cool
<emmajane> I think my biggest problem with LP is the navigation. And it's hard to interact with the site when I can't find things. :)
 * emmajane goes back to boring work now.
<beuno> emmajane, so is mine!  :)
 * beuno goes back to fun work
<emmajane> :)
<guilhembi> jam: sorry I missed your ping; going to dinner now, bbl
<jam> guilhembi: np
<jam> Just wanted to talk about the upgrade stuff
<EarthLion> hey how can i get a list of all the files that have been changed between revno x and revno y?
<beuno> EarthLion, bzr log -r X..Y -v --short?
<EarthLion> many thanks
<james_w> "bzr st -r X..Y" as well
<beuno> oh, status has revisionspec
<beuno> interesting
<EarthLion> bzr st -r 86..91 actually works better in this situation because i get a summary list rather then a revision to revision breakdown
<beuno> yeah, james_w is much smarter
<james_w> heh :-)
<beuno> and today is his birthday, so we have to be extra nice to him
 * emmajane sings the birthday song to james_w 
<emmajane> without tune, but with appreciation for his bzr cleverness. :)
<Peng_> Oh, really? Happy birthday. :)
 * awilkins sends james_w a cookie
 * beuno avoids singing. Even on IRC
<james_w> thanks everyone :-)
 * gour is singing...happy birthday to you, happy birthday to you...happy birthday dear james_w, happy birthday to youuuuuuuuuuuuuuuuuuuuuuuuuuuuu
<jam> hey, let me join in... happy b-day james_w
 * gour sends nice cake to james_w http://www.iskcon.net.au/kurma/2008/02/20#a4566
<NET||abuse> hi guys,.. just did a series of stuff for the first time with bazaar and svn, the process so far looks a little like the following=>  bzr branch svn+ssh://blah.... ; hack; bzr commit; hack; bzr commit; bzr merge; bzr commit; hack; bzr commit; bzr merge; bzr commit; and i'm finally trying to do bzr push; but it says it doesn't have a remembered location
<james_w> gour: that is a very nice cake, thanks
<emmajane> Where can I find documentation on how to accept a proposed "code" change in launchpad? I'm going to be helping the training team, but I've never done this before...
<emmajane> we'll be using bzr to push changes to LP... and then ... what happens next?
<beuno> emmajane, nowhere yet, it's work-in-progress
<beuno> but, basically, you push, go to the branch, "propose for merge", do the reviewers dance
<beuno> and merge
<beuno> LP will mark it as merged when it seessss the tip of the proposed branch in trunk
<emmajane> yeah, it's the reviewer's dance that I need to know about.
<beuno> ah, well
<beuno> by default
<beuno> the review will be requested to the owner of the targetted branch
<gour> james_w: i'm glad you like it. i bought kurma's DVD set (11 disc) fulle of great vegat. dishes...
<emmajane> beuno, https://wiki.ubuntu.com/Training/KnowledgeBase <--- what happens after step 7
 * beuno looks
<gour> james_w: see http://kurma.net/videos/index.html and bon appetit ;)
 * emmajane rewrote the instructions last night with popey. Suggestions welcome if I'm missing or wrong about anything. :)
<beuno> emmajane, well, the reviewer bit really just concerns the reviewer, mostly
<beuno> once you file the merge proposal
<beuno> you have to wait for the reviewer to approve it
<emmajane> beuno, yup. and the reviewer instructions won't be included on this page...
<beuno> (you don't really have to, it's a social constraint)
<beuno> once he reviewed it, you'll get an email saying so
<beuno> and if he approved
<emmajane> my reviewer doesn't know how to use LP. I need to teach her. :)
<beuno> well... usually the reviewer merges it into trunk
<beuno> ah, double the fun
<emmajane> yes :)
<emmajane> we taught the team how to branch the documentation from LP last night.
<emmajane> next we we're teaching how to push back up. but I also need to help out with how to accept merges.
<beuno> ah, I see
<beuno> hrm
<beuno> I can send you something
<emmajane> that would be great. :)
<fynn> is there a way to convert a git repo to BZR?
<lifeless> fynn: yes, fastexport it
<lifeless> there is info on the bzr wiki
<fynn> lifeless: thanks.
<thrope> so the rc1-3 windows installer tortoisebzr seems to work - but I still can't find a way to add a file from the context menu
<thrope> am I missing something?
<Odd_Bloke> bzr-buildpackage should be able to work out when I'm building a native package from the changelog, right?
<Odd_Bloke> james_w: *catches up with scrollback* Happy birthday. :)
<lifeless> garh spammers
<maco> hi, i want to use bzr on a directory.  i'm not sure which bzr ____ command to use though.
<james_w> Odd_Bloke: thanks.
<james_w> Odd_Bloke: it doesn't detect it from the changelog, you have to use --native or set it to native mode
<lifeless> maco: what is ____ ?
<lifeless> Odd_Bloke: people have been known to upload as native non-native packages and vice versa
<maco> lifeless: well i *think* i have to put something after "bzr" since in the manpage there's like "bzr add" and "bzr branch" and all that...
<lifeless> maco: have you read the tutorial ?
<maco> ive only ever branched from things that were already in bzr
<maco> um...where?
<lifeless> maco: http://doc.bazaar-vcs.org/bzr.1.9/
<lifeless> if you've used bzr before, and you just want to know how to make a brand new project - just 'bzr init project-root'
<lifeless> where project-root is the path to the existing project files (and if omitted defaults to '.')
<maco> lifeless: thank you
<emmajane> maco, http://doc.bazaar-vcs.org/bzr.1.9/en/mini-tutorial/index.html <--- skip to that one. the other pages are scary. :)
<maco> aha
<maco> emmajane: thanks, the part where it mentions +junk just explained the cryptic error i got trying to push to lp :P
<maco> this "bzr: ERROR: Generic bzr smart protocol error: Permission denied: "/~maco.m/fusa"
<maco> doesn't really explain much
<emmajane> maco, ahh
<emmajane> maco, have you told bzr about your LP account?
<emmajane> bzr launchpad-login LPLOGINNAME
<maco> emmajane: it was upset by "fusa".  i had to expand it to fast-user-switch-applet
<emmajane> maco, all solved now?
<maco> yep
<emmajane> WOO!
<maco> still dont think that error message is terribly helpful though
<emmajane> maco, that I can't help with :/
<lifeless> jml: ^ is there are bug?
<emmajane> maco, are you on the mailing list? You could suggest an improved message...
<lifeless> emmajane: its a launchpad error
<emmajane> lifeless, heh. Good ol' launchpad.
<thumper> what about launchpad?
<thumper> lifeless: I feel like I've missed something...
<lifeless> thumper: the error on an unknown project in a branch path
<thumper> lifeless: oh, I'm about to talk to bkor about gnome
<lifeless> thumper: permission denied is less informative
<thumper> lifeless: on a conf call, want to join us?
<lifeless> thumper: skype?
<thumper> lifeless: my conf call number
<lifeless> oh hmm
<lifeless> its 7am, got getting up things to do;
<lifeless> if you'd like me there I'll join, but I don't think I'm critical
<thumper> lifeless: if something comes up I may ping
<lifeless> sure
<lifeless> do that
<NET||abuse> hmm, bzr push's back to the svn repo make a lot of notes come up in the rss report
<lifeless> NET||abuse: I believe that some of the default change->notification scripts are overly sensitive
<lifeless> there was a thread about this recently on the list
<NET||abuse> really? hmm,
<lifeless> (on the svn side)
<NET||abuse> so on the server i can tone down the notification scripts
<NfNitLoop> Woo!   I got the OK to do a presentation about bzr/bzr-svn here to try to convince people to adopt it.
<lifeless> sweet
<lifeless> NET||abuse: should be able to filter it out yes
<lifeless> also the first one is the worst AIUI
<NET||abuse> NfNitLoop: if you do a full blown presentation, you should publish any notes or slides or even video the thing
<NET||abuse> vimeo rocks.
<NET||abuse> hmm, can you use bazar as teh server, and svn as a client?
<NET||abuse> in a mixed svn/bzr client base
<dobey> no, i don't think so
<dobey> you can use bzr-svn to interact with an svn server, i don't think there is an svn-bzr to do the reverse
<NET||abuse> hmm, ok
<LarstiQ> well, there is ish
<LarstiQ> but it's not as mature as bzr-svn
<lifeless> jam: let me know if you want to chat re: those things in the repository branch
<lifeless> dobey: 'bzr svn-serve', a jelmer production
<dobey> oh
<dobey> n/m then
<dobey> i guess you can do that
<LarstiQ> dobey: in practicality I think you're right, unless I have severely missed development on svn-serve
 * LarstiQ goes to bed, ciao
<lifeless> spiv: ping
<lifeless> spiv: I've pushed
<lifeless> spiv: can you send again?
<spiv> Ok.
<lifeless> thanks
<lifeless> spiv: ping
<lifeless> spiv: how are you generating that bundle?
<lifeless> spiv: is it using your local mirror, o r my branc on people, or something else a gain?
<jam> poolie, lifeless: What do you think about creating a bzr.dev mirror that would be in 1.9 format?
<jam> My back-of-the-envelope numbers show it being a pretty big win for me
<jam> and even if I upgrade my local repo, I don't really get the benefit
<lifeless> jam: I'm fine with that
<lifeless> alternatively, wait for 1.10 or 1.11 and upgrade bzr.dev
<Peng_> How often would the bzr.dev mirror be updated?
<jam> lifeless: well, I think it would be good to have someone/some people actively using it before we make it primary branch
<spiv> lifeless: your branch on people'
<Peng_> Better performance would be cool, but I'd use the most up-to-date repo instead.
<Peng_> s/repo/branch/
<jam> Peng_: well, we used to do the same thing for the weaves => knits and then the knits => packs upgrades
<lifeless> spiv: its included changes to Makefile
<spiv> lifeless: "bzr send http://people.ubuntu.com/~robertc/baz2.0/repository/"
<jam> I think it was updated each time pqm committed
<jam> if not, < every hour
<Peng_> That works then.
<Peng_> How do the smart server and LP factor into this?
<Peng_> I mean, what's optimal?
<jam> Peng_: I'm not quite sure what you are looking for.
<lifeless> today httpw/btrees is probably optimal pull
<jam> I can't tell LP to mirror a branch into a different format
<lifeless> future is smart server for sure
<jam> and if I could, it still only allows 1 mirror of a public branch
<lifeless> jam: I think peng is asking about performance and so on, not about making mirrors :P
<lifeless> Peng_: lp will support 1.9 formats soon
<Peng_> Right.
<jam> Peng_: So in working on: https://answers.edge.launchpad.net/bzr/+question/38599
<jam> I worked out that the new index format can often transmit < 1/8th the data the old format used
<Peng_> Wow
<jam> and that is when both are performing "optimally"
<jam> which the new format has a much better time getting to
<jam> the big issue is log2(N) for bisection, versus log100(N) for btree
<jam> both are logarithmic, but the constant factor is a big deal
<Peng_> How relevant are btree indexes when pulling over the smart server? Do they even get accessed over the vfs?
<lifeless> Peng_: today, they are directly read
<Peng_> lifeless: FWIW, I wrote a trivial patch to work around one Python 2.6 warning in bzr-search. (I don't know if there are others.) http://bzr.mattnordhoff.com/loggerhead/bzr-search/py2.6/
 * Peng_ shrugs
 * fullermd can't help thinking that SS VFS support was a mistake...
<Peng_> heh
<lifeless> http://bzr.mattnordhoff.com/loggerhead/bzr-search/py2.6 is permanently redirected to /loggerhead/bzr-search/py2.6/changes
<lifeless> http://bzr.mattnordhoff.com/loggerhead/bzr-search/py2.6/ is permanently redirected to http://bzr.mattnordhoff.com/bzr/bzr-search/py2.6/
<Peng_> :D
<Peng_> Oh.
<Peng_> The bzr branches are at /bzr and Loggerhead is at /loggerhead. I did a small hack to redirect /loggerhead/.../.bzr/ to /bzr/.../.bzr/, but I guess it wasn't enough for everything.
<lifeless> Peng_: oh it worked
<lifeless> just a bit, circuitous
<lifeless> Peng_: anyhow, my osutils has no md5 symbol
<Peng_> It's rather new.
<lifeless> Peng_: right, so this will break compatibility with older bzr's
<Peng_> Yeah.
<Peng_> Might be better to live with the warning or do a try/except ImportError yourself.
<lifeless> try:
<lifeless>     from bzrlib.osutils import md5
<lifeless> except ImportError:
<lifeless>     from md5 import new as md5
<lifeless> from bzrlib.osutils import split_lines
<lifeless> seems to work, except jam's index changes cause the whole test suite to barf on the lower range map not being parsed
<lifeless> Peng_: future reference, please put something in NEWS :)
<spiv> lifeless: I've done another send, it might work better for you
<jam> lifeless: ?
<lifeless> Peng_: how do you prefer your name in NEWS - Matt Nordhoff ?
<lifeless> jam: https://bugs.edge.launchpad.net/bzr-search/+bug/293906
<ubottu> Launchpad bug 293906 in bzr-search "suggestion failure on some indices" [Undecided,New]
<Peng_> lifeless: Oh. Yes.
<Peng_> jam: Nice job on your "back of the envelope" calculations.
<Peng_> Might be useful to put them in the docs somewhere.
<jam> lifeless: ah, sounds like you need to switch over to _nodes from time to time.
<jam> though I thought you were using btree indexes for bzr search anyway
<lifeless> jam: no, I need to implement key-element-prefix-iteration to do that
<lifeless> search is damn fast anyway, because it's use pattern doesn't fragment index buffers
<lifeless> jam: interestingly, using _nodes is probably going to be slower in some cases here :P - because the parsed key map is sorted
<lifeless> jam: so what I'll probably be doing is backing out your heuristics in the subclass
<jam> lifeless: anyway, I'm done for the night
<lifeless> jam: sleep well
<lifeless> spiv: thanks, commit+pushing
<lifeless> spiv: it is pushed btw
#bzr 2008-11-07
<lifeless> beuno: search should be fully fixed now
<lifeless> Peng_: thanks for that fix if I didn't already say so.
<Peng_> :)
<lamalex> Hi, is there any documentation on setting up loggerhead?
<lamalex> I'm trying to figure out how to configure apache to forward requests to it, but not really having a lot of luck
<lifeless> lamalex: uhm, 'serve-branches.py PATH'
<lifeless> lamalex: then in apache just setup a proxypass
<lamalex> i did that... it's not working
<lifeless> lamalex: check its working directly
<lifeless> that you can use ff on the localhost port 8080 (where loggerhead starts)
<lifeless> oh, there is also an optionI think to enable host munging via apache - in server-branches
<lamalex> yah, i didn't want to do localhost because that means having to ssh portforward
<lamalex> which while not hard
<lamalex> is just annoying
<lamalex> but i'll try it
<lamalex> ok yah it's working on localhost
<lifeless> lamalex: make sure you have python-pastedeploy installed
<lamalex> lifeless: yah, i do
<lifeless> lamalex: specify --prefix=/apacheprefix/
<lifeless> lamalex: to serve-branches
<lifeless> e.g. if you want loggerhead at http://host/loggerhead/
<lifeless> specify --prefix=/loggerhead/
<lifeless> (IIRC - the help could be better on this)
<lamalex> what about if i want bzr.host.com
<lifeless> it should autodetect the host
<poolie> spiv: did you have other stuff for 1.9? is it up for review, merged, or not ready yet?
<spiv> poolie: nothing else for 1.9, no
<thumper> spiv: so server side autopacks have made it for 1.9?
<poolie> thumper: yes
<thumper> w00t
<thumper> I wonder if this fixes a problem we were having on LP
<thumper> poolie: is format 1.9 the default format?
<thumper> I didn't follow the answer to that one before
<poolie> no
<poolie> it also has some fixes for the transient pack-file-not-found bug
<gauthierm> I exported a svn repository to my local machine, set it as a bzr repository and made a hundred or so revisions. I now have commit access to the svn repo. Is it possible to push my individual bzr commits to the svn repo?
<poolie> gauthierm: i *think* just pushing back will move them across, but i've barely used bzr-svn myself
<gauthierm> bzr crashed when I tried to merge my bzr changes into svn.
<gauthierm> Looks like its bug #240597.
<ubottu> Launchpad bug 240597 in bzr-svn "bzr crashed on merging from local bzr branch into a local svn branch" [Undecided,Fix released] https://launchpad.net/bugs/240597
<gauthierm> heh, you're good.
<gauthierm> wait, you're a robot!
<gauthierm> I'll sort it out tomorrow.
<poolie> lifeless: ping? can you read bug 293440?
<ubottu> Launchpad bug 293440 in bzr "Cannot commit to bound svn branch: "invalid property value 'branch-nick' for None"" [High,Confirmed] https://launchpad.net/bugs/293440
<lifeless> poolie: I am assuming the new code in 1.8 did something like 'config = master.get_config()' ... rather than 'master_nick = master.nick'
<lifeless> poolie: yes, I am able to read it
<lifeless> and your patch looks decent
<lifeless> (decent and appropriate)
<poolie> thanks
* poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | 1.9 released 7 Nov | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<Peng_> Whee :)
<poolie> yep
<Peng_> BTW, the NEWS file says 1.9 was released on 2008-10-31, not that 1.9rc1 was.
<poolie> yes
<poolie> it's fixed in the actual 1.9
<poolie> if you're looking on the web it may take a little while to update
<poolie> ah
<poolie> now that was actually pretty easy
<poolie> automation yay
<Peng_> ok :)
<DBO> is there any status on monodevelop-bzr other than "it still does nothing"?
<vila> hi all
<lifeless> hi
<lifeless> gnight
<jszakmeister> jelmer: you there?
<jelmer> jszakmeister, hi
<jszakmeister> Hey!
<jszakmeister> I reported a bug a few days ago: https://bugs.launchpad.net/bzr-svn/+bug/291370
<ubottu> Launchpad bug 291370 in bzr-svn "bzr-svn seems to corrupt a knit repository" [Undecided,New]
<jszakmeister> I was curious if you had seen something like that before.
<jszakmeister> I thought I was using a "typical" workflow with bzr-svn... but perhaps I'm doing something wrong.
<jszakmeister> Oh, and I just tried to reproduce with bzr 1.9 and bzr-svn 0.4.14... I get a different error, but it still backtraces.
<jszakmeister> brb...
<jszakmeister> ...alright, I'm back.
<verterok_> 'morning
<jelmer> jszakmeister, thanks
<jelmer> jszakmeister, I'll see if I can reproduce here
<jszakmeister> jelmer: I added a script for the new bzr 1.9 release... but that produces a different error at the moment: alueError: invalid property value 'branch-nick' for None
<jszakmeister> ...and thanks for looking into it.  I appreciate it!
<Odd_Bloke> Could someone help me diagnose what's going on in http://paste.pocoo.org/show/90470/?
<luks> broken server that responds 302 instead of 404 to a missing page?
<Odd_Bloke> Right, that's what I thought.
<Odd_Bloke> luks: Thanks. :)
<nekohayo> hmm. bzr-svn is not built in the ppa
<nekohayo> I tried getting the latest tarball but when doing make I get this:
<nekohayo> http://pastebin.com/d6f2ed19f
<nekohayo> any ideas?
<jelmer> nekohayo, you need to have libsvn-dev installde
<jelmer> *installed
<nekohayo> that should be mentionned in the INSTALL file or wiki :)
<jelmer> it is :-)
<jelmer> Requirements/Subversion development files in INSTALL
<nekohayo> jelmer: http://pastebin.com/d641f37ac I couldn't find a package named rst2html? what did I miss?
<jelmer> nekohayo, install python-docutils
<nekohayo> it builds! :)
<jelmer> beuno, hi
<beuno> jelmer, hi
<jelmer> beuno, now I forgot what I wanted to ask :-(
<beuno> jelmer, still nice that you said hi
<beuno> we can leave it at that until you remember
<jelmer> :-)
<jelmer> looking forward to the new loggerhead btw
<jelmer> the new code.bitlbee.org should also be running it soon, in favor of bzr-hgweb
<beuno> cool, it's been a while since we released
<dash> i've got an old mercurial repository I want to convert to bzr. how are people doing that these days?
<dash> neither bzr-hg or bzr-hgimport seem to work with the latest versions of things.
<Odd_Bloke> dash: fastexport and fastimport, I think.
<luks> bzr-fastimport with soem of the git exporters, probably
<uniscript> is there a bzr-svn for bzr 1.9? Or shall I repackage the 1.6-1.7 version to allow 1.9?
<dash> Odd_Bloke: Fancy. Looks like that did the job
<dash> thanks guys :)
<jelmer> uniscript, there is a bzr-svn for 1.9, 0.4.14
<uniscript> any plans for a package? each time bzr comes out I lose bzr-svn
<uniscript> :(
<jelmer> uniscript, there's already a debian package, http://bzr.debian.org/pkg-bazaar/bzr-svn/experimental/
<uniscript> directory is empty
<jelmer> it's a bzr branch
<jelmer> the actual package can be found at http://packages.debian.org/search?keywords=bzr-svn
<uniscript> ta
<uniscript> hmm no i386 support and I get tied in dependency knots trying to build the thing
<jelmer> uniscript, what sort of dependency knots?
<uniscript> pdebuild depends on 1.9 and debuild has sqlite3 problems due to using medibuntu
<jdong> hey bzr folks :)
<uniscript> but why is debian bzr-svn 0.4.14 not available for i386?
<jdong> I'm looking at a bzr backport to Hardy. Would like to get Jaunty up to 1.9 first
 * jdong grabs changelog of 1.9~rc1 vs 1.9
<james_w> jdong: 1.9-1 is in Debian if you hadn't seen it
<jdong> james_w: obviously I should stop using packages.d.o :)
 * jdong clobbers that shortcut for a p.qa.d.o one :)
<james_w> good choice :-)
<jdong> james_w: is there a sync request open for jaunty yet?
<james_w> jdong: nah, I assumed it would auto-sync
<james_w> yeah, it will
<james_w> jelmer: hey, is everything in shape for bzr 1.9 in Debian?
<jdong> yeah ok the problem ("problem") is sid only has 1.5-1.1 from what I can see
<jelmer> jdong, we can't upload to sid yet because it's kept open for uploads for lenny
<james_w> ah, of course
<james_w> jdong: would you like to request it, or shall I do it?
<jelmer> uniscript, the debian auto-builders haven't build bzr-svn yet for i386 (but they haven't built bzr itself either yet, so that shouldn't be a problem)
<jelmer> james_w, Yeah, everything in Debian should be in shape for 1.9
<jdong> james_w: please do, you are more experienced with the stack of packages involved :)
<james_w> jelmer: great, thanks. We're going to work on backporting it to Intrepid/Hardy so we need a group that works well together.
<jdong> awesome :)
<jelmer> james_w, I gave the .orig.tar.gz checksum issue some more thought
<james_w> cool
<jelmer> james_w, I think the best solution would probably be to use the version from the apt repository if there is one, and otherwise generate one
<jelmer> james_w, would that make sense?
<james_w> that could work
<jelmer> james_w, do you have any idea about 466244 and  477431 ? it seems to me like they're both pycentral bugs
<jelmer> (Debian bugs)
<james_w> yeah, not sure about them
<Odd_Bloke> Can ubottu be goaded into linking to Debian bugs?
<james_w> debian bug 466244
<ubottu> Debian bug 466244 in bzr "bzr: Left python files behind after being removed" [Important,Open] http://bugs.debian.org/466244
<Odd_Bloke> Debian bugs 466244 and 477431?
<ubottu> Debian bug 466244 in bzr "bzr: Left python files behind after being removed" [Important,Open] http://bugs.debian.org/466244
<ubottu> Debian bug 477431 in bzr "bzrlib/patches.py gets in the way for configuration of python2.4-minimal" [Important,Open] http://bugs.debian.org/477431
<Odd_Bloke> Sweet.
<emmajane> beuno, ok, I promise that's enough bugs from me today. :)
<NfNitLoop> asdfasdfso I'm writing up documentation on bzr-svn for a presentation to coworkers...
<NfNitLoop> and I noticed an inconsistency:
<NfNitLoop> when I push my trunk back to svn, I just 'bzr push $REPO/trunk'
<NfNitLoop> but if I'm working on a new branch that I want to mirror in svn, I have to 'bzr svn-push $REPO/branches/mybranch'
<NfNitLoop> should I be using svn-push in both cases?
<lifeless> NfNitLoop: no, svn-push is a special case to handle svn's need to atomically create the new branch
<NfNitLoop> so I should only use svn-push to create a new branch in svn, but 'push' is fine to update an exitsting branch w/ new changes?
<lifeless> NfNitLoop: yes
<emmajane> Who was I bugging about olive the other day? I think it was jelmer ?
<jelmer> emmajane: Yep :-) Hi!
<emmajane> jelmer, hey :)
<emmajane> I have a qustion that *might* be a bug but I'm not sure.
<emmajane> I'm just going to pastebin some output
<emmajane> http://pastebin.ubuntu.com/68977/
<emmajane> I get this dump when I start olive from a directory that has no .bzr folder
<fullermd> Sheesh.  Man, somebody is going to say jelmer's name while he's asleep, and we'll all be sure he's dead when he doesn't respond...
<emmajane> fullermd, hehe
<jelmer> 'morning fullermd :-)
<jelmer> emmajane, Yeah, that's definitely a bug
<emmajane> jelmer, and this is when I start it with .bzr in the same folder: http://pastebin.ubuntu.com/68979/
<emmajane> jelmer, same bug?
<emmajane> jelmer, I think it's the same output but I'm feeling crosseyed at python outputs...
<jelmer> emmajane, yes, I think so
<emmajane> jelmer, kay.
<emmajane> jelmer, thanks. :)
<emmajane> jelmer, suggested title for the bug?
<jelmer> emmajane, Generally, I think any terminal output from bzr-gtk (other than "can't open display") would be a bug
<emmajane> "garbage on start" probably won't cut it. ;)
<emmajane> kay :)
<fullermd> Hm, I get some...
<jelmer> emmajane: perhaps something like "finalized floating point object used"
<jelmer> s/point//
<emmajane> jelmer, oooo that makes me sound clever :)
<fullermd> Used to anyway.  Don't see it in a quick check.
<jelmer> emmajane: I'm just rephrasing the error message as short as possible; I have no clue what's going on either at this point (-:
<emmajane> hehehe
<emmajane> jelmer, submitted.
<jelmer> emmajane, thanks!
<emmajane> jelmer, thanks for clarifying that it was "bad" output...
<Leonidas> I have just updated to bzr 1.9 and there are two new repo-formats
<Leonidas> Which one is to choose? I don't really understand what this rich-root thing is.
<Peng_> Leonidas: If you're not using a rich-root format already (rich-root, rich-root-pack, ...), you don't need to.
<Leonidas> Peng_: I have pack-0.92, so which one would be best?
<Leonidas> to clarify: I don't need backwards-compatibility, so I don't need to stick to an older format
<jelmer> Leonidas, 1.9
<Leonidas> jelmer: does it support stacking? bzr help formats is a bit ambivalent in this regard.
<jelmer> Leonidas, yes, it does
<Leonidas> ok, great.
<Leonidas> the branch format 0.15 is still the most recent, right?
<fullermd> I thought stacking had a new branch and new repo format.
<emmajane> jelmer, I found olive to be full of fail for downloading a branch. Do you know if you've been able to get it to work? Or should I just download using the command line utility?
<jelmer> Leonidas, No, 1.9 has a new format. 0.15 is ancient, btw, much older than 0.92
<jelmer> emmajane, About to get coffee, I'll give it a try after that
<emmajane> jelmer, no worries.
<Leonidas> jelmer: how to update these? bzr update on each checkout?
<Leonidas> jelmer: 0.15 is ancient, but somehow since I started using bzr 0.15 on that project, I somehow missed updating the branches & checkouts because I didn't know that there were new formats.
<Peng_> 0.15's Branch 6 was the newest branch format until the 1.6 format.
 * Leonidas will update all that stuff today, after he's done with todays commits
<Peng_> All the latest branch format buys you is stacking, so you don't really need to bother.
<fullermd> And without the branch format upgrade, you probably end up with another one of those "unknown" formats.  Fun for the whole family.
<Peng_> Heh, yep.
<lifeless> Leonidas: we nag after a while
<james_w> hey lifeless
<james_w> didn't get a chance to investigate moving to 1.9 today
<lifeless> no worries
<james_w> they branches use 1.6, so 1.9 would just be GraphIndex, correct?
<lifeless> yes
<lifeless> 'just'
<lifeless> (btree index btw, graphindex is what < 1.9 uses)
<james_w> oh, yeah, sorry
<james_w> I'm away next week, but I'll see if I have time to run a script to do it
<james_w> the initial flood to jaunty died down today, so it would be feasible to do it at this point
<james_w> I could kick it off tonight I guess
<Peng_> If it's relevant, there's a script to convert from packs to btrees more efficiently. http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49133617.8080600%40arbash-meinel.com%3E
<james_w> yeah
<james_w> thanks
<jelmer> it would be nice to see that integrated into "bzr upgrade"
<Peng_> Yeah. The review comments discuss that. http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/48951/focus=48962
<Leonidas> ok, update went without problems. I got some 'unknown' format repositories, so I just updated all.
<Leonidas> And it was quite fast. Not like last time
#bzr 2008-11-08
<aboSamoor> I am trying to add svn folders to bzr, I got this message "bzr: ERROR: Permission denied: ".": PROPFIND request failed on '/svn/trunk'"
<lifeless> see my reply in #launchpad
<Peng_> Err.. bzr just did an autopack. .bzr.log said it was packing from 14 packs to 10, but instead it packed them down to...3. I don't get it.
<Peng_> (I mean, it was right about there being 14 initially.)
<lifeless> Peng_: it lied
<lifeless> Peng_: please file a bug
<lifeless> Peng_: (what it really meant was 'all but two of the packs needs to be combined' -> 3 (its simpler and more efficient than the original code
<lifeless> but the debug output is the original plan of what would happen
<Peng_> Oh.
<Peng_> It should've combined them into 2 packs anyway. It left one with only like 2 revisions in it. :\
<lifeless>   Peng_ well, could be a bug
<Peng_> Wait...what do you mean? It was originally going to leave 10 packs, but changed its mind after writing the debug message?
<Peng_> Well, I filed bug 295486. Kinda crappy title though.
<ubottu> Launchpad bug 295486 in bzr "Autopack's debug output is wrong about how many packs will be left" [Undecided,New] https://launchpad.net/bugs/295486
<Peng_> lifeless: Not to be a stalker, but you seem to have identical branches at lp:~lifeless/+junk/bzr-index2 and lp:~lifeless/+junk/index2.
<fullermd> Peng_: Don't try and act innocent.  We all saw you checking out his branches.
<RedLizard> What is usually done with a feature branch once the feature is stable and has been merged into the trunk? I don't want it to clutter the branch namespace for all eternity, yet I do want it available for all eternity.
<LarstiQ> RedLizard: I usually do nothing to it, or move it out of the way.
<yml> Hello, I am having some hard time to understand how to make bzr happy after a big reorganisation in my project.
<RedLizard> LarstiQ: i would like to mark it as "closed for development" in some way
<LarstiQ> RedLizard: mv it to done/ ?
<yml> In fact I have moved/rename some folder in the terminal an now I try to make bzr aware of this modification
<LarstiQ> yml: bzr mv --after oldname newname
<LarstiQ> yml: this may be a little tricky if you have also done renames of children of that directory, it is doable but a bit more work than ideal
<yml> LarstiQ:  thanks I am going to try this
<yml> LarstiQ: I have not done any renaming of the children
<RedLizard> LarstiQ: that should work, i think
<LarstiQ> yml: good :)
<yml> LarstiQ:  bzr mv --after django_glue/* projects/simple_project/
<yml> bzr: ERROR: Could not move to simple_project: projects/simple_project is not versioned.
<LarstiQ> RedLizard: ime that is enough to clear the namespace isssue.
<LarstiQ> yml: are you sure that is what you want?
<LarstiQ> yml: could you describe the rename you did?
<RedLizard> LarstiQ: optimally, i'd like the branch to be destroyed, and its history contained in the history of the trunk, available by "zooming in" on the merge commit
<LarstiQ> RedLizard: if not, you can always delete a branch, since it's revisions are all merged into trunk, you can always recreate it when necessary
<LarstiQ> RedLizard: but why bother?
<LarstiQ> the burden of keeping around old branhces is very low
<yml> Bzr was aware of a folder named django-glue in the root of my bzr directory then I did mv django_glue projects/simple_project
<LarstiQ> yml: right, so it looks to me that should be 'bzr mv --after django_glue projects/simple_project' then
<RedLizard> LarstiQ: because otherwise, i'd have to keep my branch names unique for all eternity
<LarstiQ> yml: without the /* wildcard, that would be moving the children of django_glue, not django_glue itself
<RedLizard> LarstiQ: i can't call my branches 'test' or something similar
<yml> LarstiQ: bzr mv --after django_glue projects/simple_project
<yml> bzr: ERROR: Could not move to simple_project: projects/simple_project is not versioned.
<yml> same thing
<LarstiQ> RedLizard: eh, a branch called 'test' imo is not worthy of staying around, nuke it :)
<LarstiQ> yml: what version of bzr are you using? and is projects/ versioned?
<RedLizard> LarstiQ: but the history will still be available in the trunk? great :)
<LarstiQ> RedLizard: yes, absolutely
<RedLizard> :)
<yml> no project is not yet versionned
<LarstiQ> `bzr branch trunk -r tip_revision_of_test resurrected-test` to bring it back
<yml> and I amusing bzr : Bazaar (bzr) 1.3.1
<LarstiQ> yml: did projects/ previously exist, or did you mkdir it for this reorginasation?
<yml> I mkdir project
<yml> for this reorganisation
<LarstiQ> yml: try 'bzr add --no-recurse projects/' before you do the mv --after
<yml> same thing
<yml> I also try to bzr add projects/simple_project before doing the mv but it also didn't work
<LarstiQ> right, that you do not want to do
<LarstiQ> yml: in my small test it worked, but let me try with 1.3.1 instead of 1.9
<yml> LarstiQ: Is there an easy way to update to 1.9 on ubuntu
<yml> by easy I mean sudo apt-get install ...  :-)
<LarstiQ> yml: yes, there is
<jelmer> 'morning yml, LarstiQ
<LarstiQ> moguh jelmer
<yml> ok so might be an option if you found out that it is not working with 1.3.1
<LarstiQ> yml: use the bzr ppa, https://launchpad.net/~bzr/+archive
<LarstiQ> yml: just a moment though
<LarstiQ> yml: I'll give you my test script, maybe what I'm doing is too simplistic and doesn't actually cover your case
<yml> ok
<LarstiQ> yml: indeed, 1.5 and up succeed where 1.3 does not
<LarstiQ> yml: http://rafb.net/p/AFkUPw64.html fwiw
<yml> LarstiQ: Excellent news
<yml> LarstiQ: so now I just have to move to the latest bzr
<yml> does bzr-svn is working on 1.9 ?
<jelmer> yml: yes, with bzr-svn 0.4.14
<LarstiQ> jelmer: oh! you did a release, sweet!
<yml> jelmer: How can I install it on ubuntu ?
<yml> apt-get install ?
<jelmer> I don't think it's been uploaded to the PPA yet or synced from Debian
<LarstiQ> the ppa has 0.4.13-2
<jelmer> you may be able to install the Debian package or otherwise install from source
<yml> LarstiQ: thank you very much for your help
<yml> 1.9 solve my issue
<yml> Is it just me and my happyness or does bzr status is faster ?
<yml> jelmer: do you have an idea when the PPA will be updated?
<LarstiQ> yml: there have been improvements to status speed between 1.3 and 1.9, so that's entirely possible :)
<yml> Thank you so much for your effort in bzr
<yml> for some reason that I cannot explain I just feel good with it
<yml> the only thing missing to me at the moment is a bzr-git
<yml> it is such a pain for me each time I have to work with git
<jelmer> yml: you may want to subscribe to bug 293009
<ubottu> Launchpad bug 293009 in bzr-svn "Bzr-svn conflicts with bzr in the PPA" [Undecided,New] https://launchpad.net/bugs/293009
<yml> jelmer: I am actually on hardy
<yml> but I get the same error message when I try to apt-get install bzr-svn
<jelmer> the packages are always uploaded for all ubuntu releases at the same time
<yml> thank I will wait for its resolution
<Flyser_> Hi. is it possible to use bzr for my local repository and then push it to a remote svn server?
<jelmer> Flyser_, hi
<jelmer> Flyser_, yes
<jelmer> jszakmeister|awa, hi
<RedLizard> How can I restore a branch that I merged into some other branch in the past?
<luks> RedLizard: get the latest revision number of the merged branch and run: bzr branch -rX orig new
<RedLizard> and how do I get the latest revision number of the merged branch?
<RedLizard> it doesn't appear in `bzr log`
<luks> it should, if the branch was merged
<luks> (and you don't have bzr log aliased to something like bzr log --short)
<RedLizard> http://pastebin.com/m60c521ed
<RedLizard> no revision number there
<LarstiQ> RedLizard: revid:redlizard@ruud0-20081108134022-03073670ea55866a
<LarstiQ> RedLizard: what version of bzr is that?
<LarstiQ> or, what custom logformatter are you using?
<luks> what version of bzr is it?
<RedLizard> 0.11.0
<LarstiQ> right :)
<LarstiQ> RedLizard: etch?
<RedLizard> yup
 * LarstiQ hasn't seen that log output in a loooong time
<luks> me neither :)
<luks> I was confused by the merged line
<LarstiQ> RedLizard: anyway, `bzr branch -r revid:redlizard@ruud0-20081108134022-03073670ea55866a resurrect`
<LarstiQ> RedLizard: veel plezier :)
<LarstiQ> RedLizard: (fwiw, we're up to 1.9 now)
 * RedLizard wonders what gave him away
<LarstiQ> RedLizard: 'gemerged'
<RedLizard> ah :)
<RedLizard> it works
<RedLizard> good :)
<RedLizard> Is there any reason I should _really_ upgrade from 0.11.0?
<LarstiQ> If you're not interacting with anyone else, 0.11 will work fine.
<LarstiQ> That is, other bzr branches might be in a format 0.11 does not understand.
<LarstiQ> And, if you're asking for help, it pays to mention the version you're using :)
<RedLizard> yes, i noticed
<RedLizard> (stupid debian testing on development servers :p)
<LarstiQ> hmm, isn't testing lenny by now?
<RedLizard> yes
<LarstiQ> that should have bzr 1.5
<RedLizard> it does
<LarstiQ> which, for this discussion, has a logformat that looks more familiar to us ;)
<RedLizard> are the ubuntu packages on launchpad debian etch compatible?
<LarstiQ> in the ppa? I believe not
<LarstiQ> RedLizard: do you need a system wide bzr? Or is running from source good enough?
<LarstiQ> RedLizard: 1.5 is in etch-backports fwiw
<luks> etch-backports has 1.5
<luks> he
 * luks is too slow
<RedLizard> LarstiQ: yeah, but then i'd get the entire backports repository
<LarstiQ> RedLizard: personally, I run bzr from ~/src/bzr/<version>/bzr
<RedLizard> hm, given that bzr depends only on python, the ubuntu packages will probably work fine on etch
 * RedLizard tries
<luks> it contains compiled code
<LarstiQ> and the packaging standards might be different, say python-central
<luks> you might have better luck just dpkg -i the deb from backports
<RedLizard> why doesn't launchpad contain a debian repos as well, by the way?
<strk> how to release al stale lock ?
<strk> held by strk@gnash on host gnash [process #32194]
<luks> bzr break-lock
<strk> thx
<RedLizard> hm, the ubuntu package doesn't work :(
<LarstiQ> RedLizard: that is something that may happen in the future, but it requires buildd maintenance per suite.
<LarstiQ> RedLizard: as well as the entire archive.
<RedLizard> true
<LarstiQ> RedLizard: so, I'd either try the etch backports .deb, or download and unpack a tarball, and run from that
<RedLizard> LarstiQ: actually, i think i will build my own debian package
<LarstiQ> ok :)
<RedLizard> will `bzr branch` respect the repos format of the origin?
<LarstiQ> RedLizard: if it can, yes.
<LarstiQ> so branching from 0.11, hack hack, 0.11 should be able to pull the changes back
<LarstiQ> RedLizard: just don't `bzr upgrade` it with 1.9 :)
<RedLizard> LarstiQ: of course
<LarstiQ> or branch it into a shared repo that uses a different format
<RedLizard> hm, you really have to be quite careful when working together using different bzr versions
<RedLizard> especially if you don't use a single repository for everything
 * LarstiQ blinks
<LarstiQ> RedLizard: what do you mean? Having one repository for all your branches would make collaborating with older clients almost impossible.
<LarstiQ> RedLizard: do note 0.11 is over 2 years old (roughly half the projects lifetime) and pre 1.0
<RedLizard> LarstiQ: unless the repository is in an old format
<LarstiQ> RedLizard: which then makes other things impossible, like, say, bzr-svn
<RedLizard> LarstiQ: so, the only solution is to make sure everyone uses the latest version at all times?
<jelmer> RedLizard, the current default format has been supported since version 0.92, which is about a year old
<LarstiQ> RedLizard: no, if you have one repository per project (which is good practice anyway), you should have an easy time of staying compatible with the least capable clients that work on that project
<LarstiQ> RedLizard: that should reduce the friction to a level of not having to think about it
<RedLizard> LarstiQ: good point
<RedLizard> jelmer: good, that makes things easier... getting everyone to run >= 0.92 looks reasonable
<LarstiQ> RedLizard: if you just have standalone branches, the only point where you run into trouble is by running upgrade yourself.
<LarstiQ> RedLizard: but yeah, there is room for error
<RedLizard> LarstiQ: not much if the default format is quite old
<LarstiQ> RedLizard: right, in default cases you're safe
<LarstiQ> RedLizard: but it's still possible to have a non-default repo, branch something old into that, work, try to get it back in, and notice the format got upgraded when you branched it
<RedLizard> LarstiQ: won't it be saved in the default format again when merging it back in?
<LarstiQ> RedLizard: if it's compatible, yeah. Not so when you are trying to stuff rich-root in non-rich-root
<LarstiQ> </gripe>
 * LarstiQ has some dinner and goes off to a verdiepingsfeetsje
<LarstiQ> modulo spelling bugs
<RedLizard> have fun
<LarstiQ> thanks
<RedLizard> How can I init a branch on a remote server?
<Kinnison> bzr init sftp://blahblahblah
<Kinnison> :-)
<LarstiQ> RedLizard: bzr init remote/path, or (my preference) work locally and publish changes when you have them
<LarstiQ> Kinnison!
<LarstiQ> Kinnison: how are you?
<Kinnison> LarstiQ: Good thanks, busy busy busy :-)
<RedLizard> bzr: ERROR: sftp://$PATH/.bzr/ is not a local path.
<LarstiQ> Kinnison: that explains the not having seen you in a while ;)
<Kinnison> LarstiQ: well that, and not going to any ubuntu/canonical confs due to lack of cash :-)
<LarstiQ> RedLizard: yeah, I may have fixed that post 0.11
<RedLizard> LarstiQ: this is using 1.5
 * LarstiQ blinks
<LarstiQ> RedLizard: do you have paramiko installed?
<RedLizard> LarstiQ: yes
<RedLizard> LarstiQ: i do have a bazaar config file automatically created with 0.11, if that matters
<LarstiQ> RedLizard: it works for me, what exact command did you try? (~/src/bzr/1.5/bzr init sftp://localhost/tmp/hagedis in my case)
<RedLizard> LarstiQ: which, on inspection, does not contain anything relevant
<RedLizard> LarstiQ: update: it gives me that error message, but it has in fact succeeded
<RedLizard> LarstiQ: that is, on trying it a second time (unmodified), i get:
<RedLizard> bzr: ERROR: Already a branch: "sftp://10.0.2.100/home/redlizard/repo".
<RedLizard> LarstiQ: also, i forgot: i init-repo'd that directory just before init'ing it
<LarstiQ> I recall old code trying to open a workingtree on the branch that just got inited, even when remote. It sounds roughly like that.
<LarstiQ> RedLizard: ah.
<LarstiQ> RedLizard: was that a mistake, or did you conciously do it that way?
<RedLizard> LarstiQ: i did it conciously
<LarstiQ> ok, in that case, why? :)
 * LarstiQ files a bug that co-locating a branch and a shared repo remotely gives a confusing message
<LarstiQ> RedLizard: it is not a normal thing to do
<RedLizard> LarstiQ: really? I thought it is a common optimization
<RedLizard> LarstiQ: appearantly i misunderstood something; what exactly IS the common optimization using init-repo?
<LarstiQ> RedLizard: the optimization only helps if you store multiple branches in a repository, at which point having the root of repo _also_ be a branch is weird.
<LarstiQ> RedLizard: bzr init-repo sftp://host/repo; bzr init sftp://host/repo/branch;
<RedLizard> LarstiQ: i use (read: am planning to use) the "nested branches" layout
<RedLizard> LarstiQ: in which case having the shared repo also being the root branch sounds logical
<LarstiQ> RedLizard: it could be. I still doubt it.
<RedLizard> LarstiQ: what's so strange about it?
<LarstiQ> RedLizard: the relation of the branch at the root to the other branches.
<RedLizard> LarstiQ: otherwise, i would have /host/project (a --no-trees repo) containing only a directory trunk (a branch) containing other branches (recursively)
<RedLizard> *containing only a directory "trunk"
<LarstiQ> RedLizard: ah, I think I see what is going on here.
<LarstiQ> RedLizard: what branches are in trunk/ then?
<RedLizard> LarstiQ: feature branches, probably
<RedLizard> LarstiQ: see section 10.2.2 of the user guide
<LarstiQ> RedLizard: why wouldn't they be siblings of trunk, instead of children?
<LarstiQ> RedLizard: just a moment, still filing that bug
<RedLizard> LarstiQ: because they are created from trunk, and will ultimately be merged back into the trunk (a clear parent-child relation)
<RedLizard> LarstiQ: and child objects residing in the parent directory is a Good Thing from a logical standpoint
<LarstiQ> RedLizard: hmja. I disagree about there existing a parent/child relationship, but I see your point.
 * LarstiQ looks at the user guide
<RedLizard> LarstiQ: permanent forks (say, splitting off 2.6 (the new unstable) from 2.4 (stable)) would be siblings of trunk
<RedLizard> LarstiQ: which, come to think of it, is a good reason not to have trunk equal the repository root
<LarstiQ> RedLizard: right. From my point of view any branch is equal in footing to trunk.
<RedLizard> LarstiQ: even feature branches, which only exist for a short period of time, only to be merged back into the trunk?
<LarstiQ> RedLizard: yes. But they're not very likely to exist in a central repository anyway, but live on my machine.
<RedLizard> LarstiQ: unless you work on a project on multiple machines
<LarstiQ> RedLizard: but I see some merit in nesting like that.
<LarstiQ> RedLizard: https://bugs.edge.launchpad.net/bzr/+bug/295704 btw
<ubottu> Launchpad bug 295704 in bzr "Colocating a branch a repository remotely complains about .bzr not being a local path" [Undecided,New]
<pygi> hello people
<LarstiQ> hmm, should be 'and' instead of 'a', a well
<pygi> me needs some numbers about bzr if possible
<pygi> anyone awake? :)
<LarstiQ> pygi: you didn't ask a question yet ;P
<pygi> truuue :)
<pygi> basically, number of projects using bzr, and some high-profile names of projects ;)
<LarstiQ> RedLizard: I still think it's unnatural, but I might be oldfashioned ;)
 * LarstiQ doesn't know of research into the former
<jelmer> pygi, http://bazaar-vcs.org/WhoUsesBzr
<pygi> jelmer, ok, and how about number of downloads? :)
<jelmer> pygi, I don't think that's easy to track
<pygi> jelmer, indeed it isn't
<jelmer> as most people get bzr from their distribution
<pygi> jelmer, right
<pygi> jelmer, just trying to convince some people to do some bzr stuff, and this will help ;)
<LarstiQ> pygi: who are those people? Are they convinced by 'ubuntu, launchpad, mysql'?
<pygi> LarstiQ, O'Reilly :)
<LarstiQ> pygi: aha :)
<jelmer> pygi, you may want to check ubuntu's popcon
<pygi> LarstiQ, I think mysql accounts for lot more then ubuntu & LP ;)
<jelmer> pygi, IIRC that lists bzr as the second most popular DVCS
<LarstiQ> pygi: depends what they are looking for
<pygi> LarstiQ, true that too
<pygi> LarstiQ, I guess adoption rate by external projects
<LarstiQ> pygi: right
<pygi> LarstiQ, and we can't really consider LP & ubuntu external :p
<LarstiQ> pygi: tried the very scientific approach of looking at amount of google hits?
 * LarstiQ now really is off
<pygi> LarstiQ, laters, and thanks
<pygi> jelmer, thank you too, data sent ;)
<jelmer> np, hope you can convince them :-)
<lifeless> Peng_: yeah, its the 'locations defaults override remember values' annoyance; I really must fix that
<pygi> everyone wants to do a Git book, but bzr one is different stuff...
<RedLizard> pygi: probably because bazaar is easy enough that you can use it without a book :p
<pygi> RedLizard, actually, I'm talking from publishers POV ...
<Pieter> I'd guess it is because there are more git users
<pygi> Pieter, indeed
<RedLizard> pygi: I was just kidding. I guess git is popular for one reason: that the linux development team uses (and wrote) it ;)
<RedLizard> therefore, instant fame
<jelmer> afaik there was a bzr book on the way
<Pieter> git didn't become really popular until about a year ago, and it's been in use for the kernel for 2-3 years now
<jelmer> not sure how far they got though
<pygi> jelmer, yea, I heard that too ... but nothing new on it since ages ...
<pygi> I talked about the book with few people here some time ago :)
<pygi> Pieter, well, it was VERY unfriendly before
 * jelmer still uses git reluctantly
<pygi> jelmer, what project do you use it for?
<jelmer> samba mainly, but also several other projects I've contributed to (ikiwiki, loudmouth, etckeeper, btslink)
<pygi> aha
<jelmer> this is one of the reasons why picking a vcs is so different than picking an editor - it affects not just you, but the rest of the project as well
<pygi> true
<Pieter> you can always use git-bzr ;)
<jelmer> :-)
<jelmer> Seriously though, I'm not sure how that helps me, it still forces me to use the git UI
<Pieter> only to push to git, you can use bzr for all the other stuff
<jelmer> Doesn't gain me an awful lot, it still e.g. requires a local copy of the git repo and a more complex way to upload to the remote git repo
<jelmer> bzr-git should come close, once I finish implementing remote fetch support
<Pieter> :) I guess it's more useful the other way around, as git has real branch and remote support
<jelmer> I would say it the other way around, being the bzr adept that I am :-)
<jelmer> git requires you to fetch data locally before you can do anything with it, bzr allows you to work directly on remote data
<jelmer> it would indeed be nice to have git-like branches in bzr, I think that's actually my top-wishlist-item atm
<pygi> jelmer, wasn't there some work going on getting those?
<jelmer> not afaik
<jelmer> it shouldn't be too hard to implement, just nobody hasn't done it yet
<jelmer> and it would require a format change
<emmajane> In other news: this is the best use of the internets ever... live web cam of PUPPIES. http://cdn1.ustream.tv/swf/4/viewer.45.swf?cid=317016
 * emmajane apologies and encourages you to resume normal activities. :)
<jelmer> lol :-)
<emmajane> :)
 * jelmer fears he'll just end up looking at puppies all evening, rather than adding new awesome bzr features
<emmajane> LOL
<emmajane> +1
<emmajane> jelmer, screen casting has just taken a dramatic back seat to puppy watching. :)
<Pieter> it has sound too \o/
<jelmer> emmajane, :-)
<emmajane> Pieter, yup :)
<emmajane> must be supper time?
<Pieter> that's what they thought
<jelmer> and there's 8000 more people watching, amazing
<emmajane> one of them have been assigned box duty... for our viewing pleasure. :)
<emmajane> back later. :)
<pygi> jelmer, more format changes :P
<pygi> jelmer, I don't think people would like that :)
<jelmer> beer o'clock
<jelmer> g'night *
#bzr 2008-11-09
<LaserJock> are there any tricks to getting pulls going any faster?
<LaserJock> I'm guessing not, but it just seems like it's awfully slow compared to other VCSs and I wonder if there are any tricks to it
<dobey> LaserJock: what version?
<LaserJock> especially when there's no new revisions it seems to take a long time considering
<LaserJock> I've got 1.6.1 (intrepid default)
<dobey> ah
<LaserJock> but for instance I timed a multi-pull in a repo with 5 branches and it took over 1 minute
<LaserJock> and there were no new revisions so it should have just been checking to see
<dobey> 1.9 was just released. i think it's a bit faster than 1.6. performance is one think people are working on
<dobey> s/think/thing/
<dobey> not me though. i'm just a user for the most part
<LaserJock> I was wondering if it was maybe a bzr-svn thing as most of my branches are from svn repos, but it seems like the native bzr ones are "slow" too
<AfC> I never quite got it straight what the conclusion was on the list...
<dobey> not sure
<AfC> is format=1.9 backwards compatible, or did it introduce rich-root (thereby putting a floor on
<AfC> backwards compatibility, of something 1.9 (or $whatever)?
<dobey> i'm not sure
<AfC> [recognizing that bzr 1.9 client, bzr 1.9 server, and format=1.9 promises some fairly juicy improvements, it seems worth trying for, but in a public project I'm not sure if I'm going to screw people over, so it seemed prudent to ask]
<lifeless> AfC: there is 1.9 and 1.9-rich-root
<AfC> lifeless: ah
<AfC> So we haven't culled rich-root yet. Ok.
<AfC> Can a ~1.6 client read a 1.9 branch and downgrade?
<AfC> (format=1.9 branch, that is; I know a bzr version 1.9 server will work)
<LarstiQ> lifeless: on the off hand it's a simple answer, what is keeping rich-root from becoming default?
<Peng_> AfC: 1.9 repos are only compatible with 1.9.
<Peng_> AfC: I mean, you can certainly downgrade them to pack-0.92 or knit or whatever, but you'd need to do it with 1.9 or newer.
<Peng_> (Well, 1.9rc1 I guess)
<stampp-> Howdy folks
<codeRat> Hi, I installed bzr 1.9rc1 on my windows XP machine. When I try to use tortoise I allways get the "ImportError: No module named command" error. The overlays icons shows right on the projects I already have set up. What does this error mean?
<jszakmeister|awa> codeRat: it sounds like its using a module that's not installed in the Windows version of Python (the command module is Unix only)
<codeRat> so there's no way around?
<jszakmeister|awa> dunno.
<codeRat> ok, thank you
<jszakmeister|awa> I'm not sure how/when that module is used.
<codeRat> at least I know what to look for :)
<jszakmeister|awa> Looks like bzrlib/shellcomplete.py is the culprit
<codeRat> but it strange that a program that is made for windows does use a module for unix :S
 * jszakmeister|awa agrees
<alefteris> hello all. why when i commit with bzr ci -x a_folder, deleted files in the bzr root directory are not being removed?
<alefteris> i meant in the bzr branch root directoy
<pygi> hi ho
<willwill> hello, I want bzr branch to branch my repository then another one
<willwill> (like apt-get dependencies)
<AfC> Write a shell script?
<willwill> AfC, I think svn can do this
<AfC> so?
<willwill> OK, I found this http://bazaar-vcs.org/NestedTreeSupport
<willwill> still not supported yet :(
<hno> Argh.. now bzr again downloaded over 10MB of data for a simple pull operation.. nearly all .tix index crap. Have -Dhpss logs if anyone is interested to look into this. bzr 1.8 on both sides, using bzr+ssh:// protocol.
<hno> this is a lightweight checkout from a local repository where the branch is bound to the remote repository.
<jelmer> hi hno
<hno> hi jelmer
<jelmer> hopefully one of the Australians can have a look when they wake up
<hno> a pull within the local repository seems to do the same thing so it's not due to the lightweigth checkout.. will try it without the bind also.
<hno> does the same without the bind as well..
<hno> next, upgrade to 1.9...
<berto-> i have a branch of bzr's repo; how can i view the 1.9 release?
<berto-> i tried bzr tags but got nothing on the command line.
<Peng_> Yeah, there aren't tags.
<berto-> how do i find out what rev v1.9 was cut from?
<Peng_> The 1.9 release branch is http://bazaar-vcs.org/bzr/bzr.1.9/ . I'd assume it was cut from that.
<berto-> since i already have a copy of the dev branch can i pull from there and my local copy will reflect that branch?
<berto-> i'm about to try that.
<berto-> it would be silly for me to have to rebranch the whole thing when i have the repo already.
<Peng_> If you use a shared repo, it won't have to download the data again.
<berto-> right, ok, cool.
<rocky> jelmer: ready for a simple bzr-svn bug report? :)
<jelmer> rocky, always :-)
<rocky> jelmer: http://cluebin.appspot.com/pasted/3001
<hno> 19 behaved better. Still not good, but much better.
<hno> 1.9 i meant..
<jelmer> rocky, thanks, fixed
<Peng_> hno: 1.9 introduces a new index format which should be much more efficient. Of course, it's not compatible with older versions of bzr.
<hno> Peng_: The local was already updated to btree, but the remote can not be updated as it's a shared repository.
<Peng_> Ah.
<hno> Peng_: And I think it's silly. The basic bzr pull/update over bzr+shs SHOLD do a smart call getting a bundle back of the new revisions, not raw reading of the indexes and packs..
<Peng_> Yeah, it /should/.
<hno> Peng_: Waiting for a test upgrade of the remote to see how much of a difference the new index format makes in this operation.
<hno> bzr upgrade still running...
<rocky> jelmer: there a branch i should get?
<jelmer> rocky, yes, the 0.4 one
<rocky> jelmer: hm, launchpad isn't seeing the fix ... http://bazaar.launchpad.net/~jelmer/bzr-svn/0.4/changes/1741?start_revid=1741
<rocky> http://bazaar.launchpad.net/~jelmer/bzr-svn/0.4/changes rather
<jelmer> rocky, launchpad isn't the main location for bzr-svn, it just has a mirror
<rocky> ohhh
<jelmer> http://people.samba.org/bzr/jelmer/bzr-svn/0.4
<rocky> jelmer: any reason the log isn't up to date when viewing http://people.samba.org/bzr/jelmer/bzr-svn/0.4/ with a browser?
<rocky> basically i'm trying to see the last revision so i can just do a manual fix here ;)
<jelmer> I don't have the right plugin installed from my current machine
<jelmer> so it's not updated atm
<rocky> gotcha
<meoblast001> hi
<rocky> jelmer: how does your bzr/http setup work? you using the stock http smart server or something more ?
<jelmer> no, I'm pushing to a remote server using bzr+ssh
<jelmer> the location I push to is accessible using http
<rocky> gotcha
<rocky> i'm a little surprised that there doesn't seem to be any bzr repos out there with r/w using the http smart server
<lifeless> rocky: there are
<lifeless> rocky: the uk NHS's bzr repos are read-write http(s I think)
<hno> lifeless: Hi!
<lifeless> hno: hi
<rocky> oh cool
<lifeless> rocky: on windows with IIS for extra fun :P
<rocky> why don't more people use that? i mean r/w http: is way more accessible then proprietary bzr: repos ... is it that much slower or something?
<lifeless> rocky: bzr+ssh is what most people use I think, because its basically zero setup
<lifeless> bzr: is a registered port with the IANA, so its not that proprietary :P
<rocky> i have 1 dedicated box, giving people shell access is not acceptable for my setup ... and i know a lot of people in the same boat... plus people coming from svn backgrounds are accustomed to only dealing with http
<lifeless> rocky: sure, but you asked about other people :P
<rocky> ;)
<lifeless> bbiab, morning $foo
<hno> how long is an bzr upgrade supposed to take?
<rocky> jelmer: it's too bad  easy_install bzr-svn doesn't install bzr-svn properly
<jelmer> rocky: install should work though
<rocky> jelmer: yeah "python setup.py install" works fine
<rocky> but my steps for installing new bzr these days is:   virtualenv.py bzr-1.9; cd bzr-1.9; ./bin/easy_install bzr
<rocky> it'd be nice if the last step was ./bin/easy_install bzr-svn
<lifeless> hno: if its in the same model and local, a few minutes
<jelmer> What would be required to support easy_install? I must admit I've never used it
<lifeless> hno: what exact command did you run ?
<hno> bzr upgrade --format=1.9-rich-root
<lifeless> hno: cancel that
<lifeless> hno: remove .bzr, rename backup.bzr to .bzr
<hno> it was on a copy..
<lifeless> then just cancel it
<hno> done, and restored.
<lifeless> hno: is this the squid repo ?
<hno> yes, still having trobles with those indexes..
<lifeless> hno: 'bzr upgrade --1.9'
<lifeless> hno: and you need a 1.9 client to use a 1.9 repository
<rocky> jelmer: well it's not really an issue of supporting easy_install, it's making sure bzr-svn is packaged properly to be an egg ... are there any other bzr plugins packaged as eggs?
<rocky> i wouldn't think it'd be much work
<hno> lifeless: 1.9 on both.
<lifeless> hno: cool, was just answering your question from scrollback
<jelmer> rocky, I'll happily apply patches that fix easy_install, as long as there's no overhead per release
<hno> lifeless: 1.9 did behave better than 1.8, but still very heavy.
<rocky> jelmer: should just be a one-time change
<hno> lifeless: with the old index format that is. Upgrade of bzr brought the operation down from 8MB of indextransfer to ca 1MB I think.
<lifeless> hno: sounds about right
<hno> lifeless: followed by 75KB of actual pack data.
<hno> lifeless: Corrected numbers. 1.8 read 9576413 of indicies 71598 bytes of packs. 1.9 read 3426251 bytes of indicies, same packs. (from the main squid3 repo with old index format)
<lifeless> hno: the btree index will help immensely I think
<lifeless> hno: 4K pages, 100-way fanout
<lifeless> breakfasttime
<hno> lifeless: Testing..
<hno> done.
<hno> lifeless: Using 1.9 format on the remote result in a transfer of indicies 448673 bytes, packs 70842 bytes.
<jelmer> the smart server should be smarter :-)
<lifeless> hno: interesting
<hno> packs got a little smaller as upgrade also repacks the repository.
<hno> but still, that's at least 445k unwanted overhead..
<lifeless> hno: we're agreed that it should stream
<lifeless> hno: I'll need to check and see if we are doing prefetching on btree indices, because 445K of index data is 111 pages
<lifeless> which is arge
<lifeless> *large*
<hno> lifeless: I can tar up my local repository for you to experiment from, if you need a startingpoint to trigger this..
<lifeless> hno: I have a separate performance issue I'm working on at the moment
<lifeless> hno: but thanks
<hno> lifeless: Ok. I'll keep a copy around for some time anyway.
<lifeless> jelmer: bug 295611 - whats the summary?
<ubottu> Launchpad bug 295611 in bzr "NoSuchRevision: KnitPackRepository" [Undecided,Confirmed] https://launchpad.net/bugs/295611
<jelmer> lifeless, basically it's similar to the bug we looked at during the summer
 * jelmer looks again
<jelmer> lifeless, sorry, it's actually related to ghosts
<jelmer> where "bzr diff" assumes that the revision info for the last-changed-revision of all files in the tree are present
<lifeless> jelmer: I can't parse that. Is a valid rephrasing 'the last-changed-revision is used as the key for the file text'?
<jelmer> lifeless, nope
<jelmer> lifeless, bzr diff prints the timestamp of the original text of a file and of the new revised one
<lifeless> with you so far
<jelmer> in order to obtain the timestamp for the old text, it uses the text revision and calls Repository.get_revision(text_revision)
<jelmer> if that text_revision happens to be a ghost, things break
<lifeless> ah
<lifeless> so there are some interactions here
<lifeless> we really need to sit down and clean up the ghost handling once and for all
<lifeless> the interaction I'm thinking of is: we only copy text (id,X) when we copy revision X
<lifeless> so that repository isn't clonable by bzr at all anyhow
<lifeless> (as it currently stands)
<jelmer> that would break bzr-svn, which usually only pushes lhs revisions
<jelmer> that may contain references to texts introduced by rhs revisions
<jelmer> *those lhs revisions may contain references to texts introduced by rhs revisions
<lifeless> jelmer: 'does break'
<lifeless> jelmer: though I think I've mentioned before that having those references isn't strictly valid
<lifeless> under the current rules. And thus the need to fix this forever
<lifeless> the inventory work being done at the moment will open the door to handling this efficiently and preserving arbitrary revision text values, which would make the revision-being-absent a valid bug
<jelmer> lifeless, ah, that makes sense
<lifeless> the problem at the moment is that doing 'inventory_delta(X,Y)' is very expensive
<lifeless> so we can't tell what texts are new for a set of inventories by doing that, instead what we do is a bit of hack by examining all the delta'd lines
<lifeless> the problem there is that fulltext inventories cause every line to be examined, so we end up either copying, or checking-for, the entire tree on every pull of 200 revs (on average)
<lifeless> and that is very very bad on big trees; which are also likely to have more committers and thus trigger it more often
<yml> I have a quick question regarding bzr-svn and bzr 1.9. I am working to on Ubuntu and as of now I cannot install it because : bzr-svn: Depends: bzr (< 1.8~) but 1.9-1~bazaar1~hardy1 is to be installed
<yml> I would like to know if this is going to be solve in a matter of day or if I should downgrade to bzr 1.8
<lifeless> yml: I imagine we just need to upload a new package to the ppa
<lifeless> yml: if you are using the ppa
<yml> lifeless: Yes I am using PPA
<yml> lifeless: else is there a place where I could download bzr-svn  .deb ?
<jelmer> yml, Debian should have one
<jelmer> lifeless, what's the ETA on split-inventories?
<lifeless> jelmer: draft results are promising
<lifeless> jelmer: no specific timeline, you know how software dev goes
<jelmer> lifeless: Ah, cool - how complete is it though?
<jelmer> Initial work done? Some things already work ? Only a few tests left that need fixing?
<lifeless> chk layer is about 95%, dictionary built on that is ~60% I would say, inventories on that are very thin, mainly need optimisers and tuning call it 70%
<lifeless> needs lots of profiling and feedback cycle
<lifeless> compression is not really touched, call that 10%
<jelmer> ah, so this is the CHK stuff I've seen scrolling past on bazaar-list.. :-)
<lifeless> yes
<lifeless> chk is content hash key
<lifeless> which is the obvious implementation to satisfy a canonical representation with nested hashability
<yml> jelmer : Is that the deb that I should download ?
<yml> http://packages.debian.org/fr/experimental/bzr-svn
<jelmer> yep
<lifeless> its slightly more general than git's keys, because its forward extensible (in disk layout) to sha256 etc
<jelmer> lifeless, ah, nice
<lifeless> CHKMap is a dict built in that layer
<lifeless> which as a basic datatype is reusable
<yml> ubuntu complains about libsvn1 being to hold ?
<jelmer> yml, They probably have different versions of libsvn1
<yml> ok I will wait for a while
<fullermd> lifeless: Speaking of inventory stuff...   does the new stuff you're working on support referencing unchanged files in a revision?
<lifeless> fullermd: how do you mean?
<fullermd> bzr ci --unchanged some/file
<lifeless> fullermd: no
<fullermd> I'm going to give you another chance to answer   :)
<lifeless> fullermd: no
<lifeless> fullermd: because..
<jelmer> fullermd, why would you ever want to do that?
<fullermd> Well, why would you ever want to commit --unchanged?
<fullermd> If there's a reason for the one, there's a reason for the other.
<lifeless> fullermd: the last-changed field on inventory entries is derived data; we don't provide (nor should we) a knob to fiddle it; its not included in testaments for instance
<poolie> hello
<poolie> hello lifeless
<lifeless> fullermd: annotating history so you can find a commit that marked 'foo' interesting is really quite orthogonal - I would approach it by adding a rule to the derived data logic that adds a last-change value for the commit, probably by recording in the commit that that path was interesting
<lifeless> fullermd: and as such the inventory layer is unaffected - its no more or less capable of doing what you desire than current inventories
<lifeless> hi poolie
<poolie> i'm going to try running john's packaging script
<fullermd> Hm.  'k...   it seemed to me that last time we discussed it, you said it needed inventory-level changes, and so would end up falling into the next round of inv work.  Guess I misunderstood.
<lifeless> fullermd: I think you asked about a variation ;P
<lifeless> fullermd: or my thinking has refined
<fullermd> Well, we could always use more refinery.  Or distillery, anyway.
<lifeless> k, time for full screen code, poolie - ping me via skype(chat|voice) when ready
<poolie> lifeless: ok, the net here may be a bit slow to actually do voip
<poolie> we'll see
<fullermd> Dragonfly ended up with git, BTW.
<fullermd> http://article.gmane.org/gmane.os.dragonfly-bsd.kernel/12212
<fullermd> (not overly surprising; hg had a late surge, but git was up 2:1 most of the voting time)
#bzr 2009-11-02
<mwhudson> splorf
<mwhudson> mwh@grond:trunk$ cd /home/mwh/canonical/repos/bzr-git/trunk
<mwhudson> mwh@grond:trunk$ python setup.py sdist
<mwhudson> running sdist
<mwhudson> warning: sdist: manifest template 'MANIFEST.in' does not exist (using default file list)
<mwhudson> error: .plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/
<mwhudson> .plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git/.plugins/git: Too many levels of symbolic links
<mwhudson> (something to do with the test suite i think...)
<lifeless> rotfl
<spiv> Whee!
<jelmer> mwhudson: yeah, 'make check' creates an empty directory .plugins and a symlink to .. in that (to point BZR_PLUGIN_PATH at)
<poolie> spiv, how are you today, and what are you up to?
<poolie> for myself i'm going to do a bit more mail and then perhaps try the startup time test i've been wanting to do
<lifeless> poolie: which one is that?
<poolie> making some assertions about the output of 'python -v bzr st'
<spiv> Drat, missed poolie.
<igc> back
<igc> afk for a few hours - bbl hopefully
<poolie> jelmer: hi?
<poolie> spiv: hi? did you send that mail about ubuntu stories?
<spiv> poolie: working on that atm
<poolie> kthx
<lifeless> EOD for me
<vila> hi all
<lifeless> hi vila
<poolie> hello vila
<vila> lifeless: KnownFailure are still failures for --parallel=fork --subunit so bug #419776 is not fixed ?
<ubottu> Launchpad bug 419776 in bzr "selftest --subunit output incompatible with --parallel=fork" [Medium,Confirmed] https://launchpad.net/bugs/419776
<vila> lifeless: that's with: your fix and trunk version for subunit and testtools
<lifeless> vila: try now, rev 25 of testtools
<vila> lifeless: trying
<poolie> spivvo?
<vila> lifeless: BZR_PLUGIN_PATH=-site ./bzr selftest --parallel=fork --subunit | subunit-stats
<vila> lifeless: Failed tests:     38
<vila> with revno 25
<lifeless> vila: *interesting*
<lifeless> vila: name one of the tests please
<vila> bzrlib.tests.per_repository.test_fetch.TestFetchSameRepository.test_fetch_into_smart_with_ghost(RepositoryFormat5)
<vila> bzrlib.tests.test_lock.TestOSLock.test_read_locks_block_write_locks(fcntl)
<vila> BZR_PLUGIN_PATH=-site ./bzr selftest --parallel=fork --subunit -s bzrlib.tests.test_lock.TestOSLock.test_read_locks_block_write_locks | subunit-stats
<vila> Failed tests:      1
<visik7> anyone have used the win32-symlink plugin ? it doesn't behave like the msys ln command
<TigerP> is there a list of exit values of the bzr commit command?
<lifeless> vila: works for me
<vila> lifeless: argh
<lifeless> vila: possibly the expectedFailure support improvements in my protocol branch of subunit
<poolie> TigerP: i think it's in the manpage
<vila> lifeless: sounds quite probable :-) url ?
<vila> lp:~lifeless/subunit/protocol ?
<vila> lifeless: indeed, works for me with that branch, can you merge it on subunit's trunk ?
<TigerP> poolie: I can only see exit codes of the bzr diff command
<lifeless> vila: I'll submit it for review
<lifeless> vila: oh
<lifeless> vila: actually, try this
<lifeless> vila: just delete BzrTransformingResult
<lifeless> and use subunit release
<lifeless> that should work, I think.
<vila> lifeless: yup, works !
<vila> lifeless: can you update lp:~lifeless/bzr/subunit and resubmit then ?
<lifeless> vila: this branch is for --subunit, not --parallel, primarily.
<vila> lifeless: *you* linked it to bug #419776 :-)
<ubottu> Launchpad bug 419776 in bzr "selftest --subunit output incompatible with --parallel=fork" [Medium,Confirmed] https://launchpad.net/bugs/419776
<lifeless> vila: as you have fast test environment, perhaps you could delete BzrTransformingResult completely, and its tests.
<lifeless> vila: yes, with a comment that perhaps more work was needed ;)
<vila> wow, I missed that comment !
<vila> ok, I thought it was linked to indicate it fixed the issue, I'll assign it to myself and fix it after having approve your patch
<lifeless> vila: anyhow, I know the current branch passes all tests.
<lifeless> So I'd like to review and land that before making other changes that need a full test run
<vila> lifeless: I had reviewed and was ready to approve but thought I tested for that bug first, I'll approve now
<vila> lifeless: approved
<vila> lifeless: please land asap so I can submit the fix for deleting BZRTransformingResult ;)
<lifeless> vila: pushing up now
<vila> lifeless:  ? Pushing what ?
<vila> lifeless: if I could pull working versions what do you need to push ?
<vila> or did you mean pqm-submitting ?
<vila> err. wait I was too fast, that does work !
<vila> err. wait I was too fast, that doesn't work !
<lifeless> vila: to -integration, where I pqm submit from
<vila> ok, approved anyway, my objection was about fixing the bug so irrelevant
<vila> lifeless: deleting BTR works only with your subunit-protocol branch, so I'll wait for that to land before submitting the fix fr bug #419776
<ubottu> Launchpad bug 419776 in bzr "selftest --subunit output incompatible with --parallel=fork" [Medium,In progress] https://launchpad.net/bugs/419776
<lifeless> vila: huh?
<lifeless> vila: what happens with subunit release?
<vila> KnownFailure is seen as a failure
<lifeless> but BTR does that
<lifeless> its BTR's fault ;)
<vila> yes and no, with subunit release KnownFailure is seen as a failure with or without BTR :)
<lifeless> testing
<vila> and with your subunit branch it works with and without BTR :) But I'd love to get rid of BTR anyway.
<lifeless> vila: so, 0.0.2 TestProtocolClient has no addExpectedFailure
<lifeless> so that should be degrading to success in _do_known_failure
<vila> lifeless: lost in the indirection via AutoTimingTestResultDecorator ?
<lifeless> ah yes
<lifeless> thats a policy change in subunit
<lifeless> to degrade more gracefully
<lifeless> I can do a separate branch for that
<lifeless> -protocol- isn't fully baked yet
<vila> ha :-/
<lifeless> Wire changes are tricky
<vila> certainly
<vila> I'm not complaining, just trying to understand the migration path
<vila> on the other hand 419776 is not blocking so there isn't an urgency either
<lifeless> vila: how isn't it blocking ? :)
<vila> well, it blocks subunit usage, not --parallel=fork usage :-p
<lifeless> vila: I want to get stdout/warnings/log capturing working in testtools
<lifeless> vila: and the bzr log stuff using the same PAI
<lifeless> *API*
<vila> you mean log as in trace.py, not bzr log the command right ?
<lifeless> I mean as in printErrorList
<vila> ha ok
<vila> lifeless: that's the missing part for making your subunit protocol fully baked ?
<vila> s/protocol/& branch/
<lifeless> it will show that I've closed the loop in a tolerable way
<lifeless> I also need t-i-p by-in
<vila> t-i-p ?
<lifeless> testing-in-python
<vila> ECONTEXT :-/
<lifeless> its a mailing list
<vila> haaa, you need approval there ?
<lifeless> social not technical
<lifeless> buy-in, not approval
<vila> yes, that what I meant.
<lifeless> if I have t-i-p buy-in its a good indicator for an eventual PEP and API changes in Python itself
<jml> anyone know why bzr was removing from ohloh?
<vila> jml: no idea :-/ Where did you see that ?
<jml> ohh, I see https://www.ohloh.net/p/bzr is gone https://www.ohloh.net/p/bazaar is there
<vila> fullermd: around ?
<bialix> hi all
<igc> bialix: hi
<bialix> hi igc
<igc> bialix: could I ask a favour?
<igc> bialix: we have new translations I'd like to get into Explorer ...
<igc> and then tag it as 0.9.0
<bialix> you want import?
<igc> I'd like that to go out with the 2.1.0beta2 installer jam is packaging today
<igc> bialix: I was planning to do it but I'm really tired
<igc> (started chemo again today) :-(
<bialix> ok, I'll do it now
<bialix> sad to hear this
<igc> bialix: mega thanks
<igc> bialix: I put out a plea for more translations on the weekend to launchpad-users and the response was *awesome*
 * bialix also has mixed feelings about today poolie's mail
<igc> bialix: so you'll notice a few more
<igc> bialix: I've responsed to that thread btw
<bialix> igc: I'll just import them, have no time to review
<igc> bialix: that should be ok. All I wanted was ...
<bialix> yeah, a bit more :-)
<igc> (1) import of transations
<igc> (2) tag as 0.9.0
<igc> (3) jam to package 0.9.0 in 2.1.0b2.
<igc> I think 2.0.2 should stick with 0.8.3 of explorer
<bialix> import may take half hour or couple of hours. it depends how fast lp will react
<bialix> igc: according to garyvdm mail in qbzr ML I think bzr 2.0.x should stick with latest stable releases
<igc> bialix: right
<bialix> so 0.8.3 is ok
<igc> bialix: I hope all is going well work wise - I hear you're flat out right now
<igc> bialix: if there's no questions, I'll say good night
<bialix> flat out?
<igc> busy
<bialix> yep, night Ian, I'll tag it for you
<igc> thanks
<igc> night all
<bialix> igc: done.
<jml> igc, do you know if there's an agenda for the bzr sprint?
 * jml missed the "night all"
<jml> sleep well, I'll send an email
<vila> jml: apart from the focus defined on the wiki, not that I know of
<jam> morning all
<bialix> hi jam
<jam> bialix: thanks for tagging bzr-explorer 0.9.0
<bialix> jam: :-)
<bialix> jam: garyvdm has planned to release qbzr 0.16 but it seems he's not finished it. use qbzr 0.15 for 2.1.0b2 please
<jam> well, he's got a couple of hours :) but yeah
<jam> I'll use whatever is available
<jam> I'm going to be pushing for a faster "gone gold" to "official release" this time
 * bialix has wanted to release 0.15.1 but...
<bialix> jam: will be nice to speed up this process, really ;-)
<jam> well, I did some 'pre-build' work last week
<jam> so hopefully the build process for the windows installers is smoothed out
<vila> morning jam
<jam> hey vila
<vila> jam: care to recheck https://code.edge.launchpad.net/~vila/bzr/186920-lp-proxy/+merge/14238
<vila> ?
<vila> jam: I can summarize here if you want
<vila> james_w`: ping, sorry for friday, I had more reading to do than I thought :)
<james_w`> vila: hi, np
<jam> vila: a quick summary would be nice
<vila> jam: I took your remarks into account. There was an additional glitch that is now fixed and Gordon Tyler confirmed it now works in all his setups
<jam> so a quick question about http://bazaar.launchpad.net/~vila/bzr/186920-lp-proxy/revision/4782
<vila> jam: the remaining question is where to land (in addition to bzr.dev), you and I seem to agree for 2.1
<jam> What happens if you were trying to use a non-standard https port?
<vila> before ?
<jam> vila: so you have the comment that "self.port" is always None, and so you grab the port attribute from whether you are using http or https
<jam> however, what if I was trying to go through my proxy to get to something like:
<jam> http://babune.ladeuil.net:26862/waterfall
<jam> You don't have to fix this to land the code, btw
<jam> I'm just probing to see if I understand what is going on
<vila> the comment is about urllib2.Request being brain-damaged and always using host  = 'xxx:nn' instead of host  ='xxx' and port = 'nn'
<vila> i.e. self.port is *never* used so alwats None
<vila> this is trappy because HTTPConnection objects cleanly separate host and port
<vila> there is a grey area about the proxy behavior *without* that patch regarding what port were used... but only for the CONNECT request, all other cases are ok (AFAIK)
<jam> vila: doesn't CONNECT have to go to the same port as the rest of the requests?
<jam> (to be clear, I approve your patch, but I'd like to keep chatting to understand)
<vila> it *has* to, it weren't for CONNECT
<vila> all other requests ended up calling HTTPConnection.connect() which handle the default port, the last part of the patch is mimicking that for CONNECT
<vila> because CONNECT is like connect expect it obviously wasn't (as fullermd would put it I think :)
<jam> vila: so how does that work when connecting to a non-standard port?
<vila> jam: port is not None in that case and is propagated correctly
<jam> self.proxied_hostÂ =Â '%s:%s'Â %Â (self.get_host(),Â conn_class.default_port)
<jam> There is no "port" in that statement
<bialix> hmm, does ftp dumb transport unable to read part of file?
<jam> bialix: So there is a "resume" sort of command in ftp
<jam> which I believe means you can start in the middle
<jam> I don't know how to set it up, or what the command is, etc.
<jam> Just that I've seen it happen before
<jam> I wouldn't be surprised if we don't properly support that in bzrlib
<bialix> working with bzr over ftp is so slow
<jam> bialix: FTPTransport doesn't seem to implement readv, which means it uses the base implementation
<jam> which is get+seek
<jam> which is, certainly, going to download the whole file
<bialix> or bzr do something wrong, there is one pack ~3MB in ftp repo and bzr trying to download much more than that
<jam> and then do it for each request
<bialix> f***
<jam> bialix: 3MB for every readv() request
<jam> FTPTransport should either implement partial reading, or download to temp files and do it from there
 * bialix wonders why not cache already downloaded data
<jam> because nobody who cared enough to work with FTP put in the time to do so
<bialix> right
<bialix> I prefer to not care too, but I have not found any decent and cheap way to have private repos
<vila> jam: hmm, you're right, there is still something wrong here :-/ I need a more complex setup to test it (i.e. an https server on a non-standard port)
<jam> vila: anyway, it is good enough for now
<jam> you should be able to test with an http server on a non-standard port
<jam> such as babune.net :)
<vila> jam: no
<vila> CONNECT is called for https only
<jam> really?
<jam> ok I guess
<vila> that's how you established the ssl wrapping if using an http proxy for example
<jam> what if you were using an SSL proxy to a non SSL host?
<jam> anyway, I've voiced my observation, and the code is still far better than what we have today
<jam> so please land it in bzr.dev
<jam> if you want, you could land it in 2.1.0b2 if you hurry
<vila> jam: If I target 2.1.0, it will come back soon in bzr.dev right?
<jam> vila: Once I get around to releasing, I'll be 'merging up' everything
<jam> so it will be done today
<jam> (2.0.2 => 2.1.0b2, 2.0.2 => 2.0.x, 2.1.0b2 => bzr.dev, 2.0.x => bzr.dev)
<jam> not necessarily in that order, but approximately so
<jam> 2 integration branches is... a bit of overhead for RMs
<vila> jam: sorry, I'm confused, should I target bzr.dev or lp:~bzr-pqm/bzr/2.1.0 or both ? Ha ok, so I'll target 2.1.0
<jam> vila: 2.1.0b2
<jam> 2.1.0 does not exist
<jam> merge-up is painful because of the number of combinations to take care of
<vila> meh, why 2.1.0b2 and not 2.1.0 ? The later can be used for all releases leading to 2.1... Still confused >-/
<jam> vila: every release gets its own branch
<jam> so you can later "bzr branch lp:~bzr-pqm/bzr/x.y.z.b"
<jam> we *could* do it differently
<jam> so far, we have chosen not to
<vila> rats, I branched too late to merge cleanly :-/
<vila> huh ? Only for NEWS >-/
<vila> oooh, no, the bug fixes were part of 2.0.2...
<vila> wow, weird conflict
<jam> yeah, there is some 'unknown' as to whether bug fixes in 2.0.2 should be repeated in 2.1.0b2
<jam> for now, I've said no
<jam> others have said yes
<jam> but I don't like seeing them twice
<jam> and we're always releasing a 2.0.x at the same time as 2.1.0x
<jam> I believe lifeless originally posited that they would have different release schedules
<vila> ok ok, RM priviledge :-) I haven't seen the physical consequences yet :-)
<jam> and thus we may release one without the other
<jam> and thus we should have the bug comments listed
<vila> as long as you merge things in a coherent way, your way is good enough, you may add a note that 2.1.0b2 includes the fixes for 2.0.2 for completeness
<jam> vila: so are you targetting 2.1.0b2 ?
<jam> vila: it is in the summary
<jam> if you didn't read it
<jam> make sure it is there
<jam> because I thought I did
<vila> It is !
<vila> Good, we agree then :)
<jam> vila: so I should clarify slightly... we need a separate 2.0.x branch from a 2.0 branch, so that once the branch is split off, we can still land updates into 2.0
<jam> just like we need a separate release branch for at least 2.1.0 so that we can keep landing in trunk
<jam> (bzr.dev)
<jam> we *could* have a single '2.0-releases' or something like that
<jam> and then match that with a 2.1.0-releases
<jam> however, once 2.1.0 is final, we will then need 2.1-releases, etc.
<vila> that's how I organized my integration branches, 2.0, 2.1, etc
<jam> for now, we just have 1 branch per release
<jam> and not worry about what would be clustered with what
<jam> I currently have "lp" and "lps" for stable targets versus dev targets
<jam> bialix: i would think that "bzr serve" would be the easiest to set up, and provide ~ the same security as ftp
 * vila runs to dentist 
<vila> jam: pqm'ed, I'll be back soon
<jam> vila: I don't see it on pqm
<jam> Peng: looks like I reproduced your earlier failure: bug #471193
<ubottu> Launchpad bug 471193 in bzr "StaticTuple failure while pulling from bzr+ssh" [Critical,In progress] https://launchpad.net/bugs/471193
<jam> I'm trying to sort it out now
<jam> I'm a bit surprised we don't run into this more often since I've been using bzr.dev for a while and doing bzr up/bzr pull regularly...
<jam> vila: I'd like to chat about possible fixes if you get a chance
<vila> huho, pqm acting again ?
<jam> vila: your patch is there now
<jam> do you have any time to chat about bug #471193 w/ me?
<ubottu> Launchpad bug 471193 in bzr "StaticTuple failure while pulling from bzr+ssh" [Critical,In progress] https://launchpad.net/bugs/471193
<vila> jam: sure, that's clearly a red-button case
<jam> vila: so I can fix it in a variety of ways
<jam> I can make the chk map code not require StaticTuples
<jam> either by changing the internals not to fail
<jam> or by wrapping more locations with "StaticTuple.from_sequence(key)"
<jam> In my ideal world, all keys in memory would be ST
<jam> so I've been trying to push the 'from_sequence' code higher in the stack
<jam> so it doesn't have to be reproduced everywhere
<jam> It isn't terribly expensive, but it is a couple of function calls
<vila> the higher in the stack they are, the less we care
<jam> alternatively, I can fix *this* bug by changing either the code that reads from Remote
<jam> (such as _benencode.decode_as_tuples)
<jam> to cast into StaticTuple earlier
<jam> or I can change BTreeBuilder
<jam> to cast into StaticTuple
<vila> so, the bug shows that the test suite is incomplete, as long as you can reproduce it with a test, you will increase the robustness
<vila> the worrying thing is: can you revert some changes to avoid the issue ?
<bialix> jam: setup bzr serve on my hosting?
<vila> and why nobody running bzr.dev encoutered it sooner ?
<jam> bialix: I was mostly doing a jab that ftp is not very secure
<Peng> jam: Huh! I thought my original failure was just because I had forgotten to recompile the extensions?
<Peng> jam: I do a lot of bzr+ssh pulls too, so I'm surprised I haven't run into this one, either.
<bialix> jam: I know it's not very well secure but it's ok for me
<jam> Peng, vila: I have very little clue why this wouldn't be deterministically failing for everyone repeatedly...
<bialix> bzr serve --alow-writes is not secure at all
<jam> perhaps it has to do with the chk_map cache
<jam> it is possible that the chk_map page cache is intercepting the calls and returning the contents differently than hitting the BTreeBuilder
<jam> so only 'big-enough' pulls that overflow the cache are caught
<jam> however, _read_nodes_from_store doesn't *use* that cache at all...
<jam> so that doesn't seem to be the answer
<hexmode> quick, easy, switching between branches on bzr.  How do I do it?
<jam> hexmode: 'bzr switch' ?
<jam> depends on how you have your branches/working trees laid out
<vila> jam: are you sure you're not running into a running-pull-with-pulled-code issue ?
<jam> vila: "pull with pulled code" ?
<jam> I think I know what you mean, and this dir has no tree
<jam> just a branch
<hexmode> jam: so, I've modified code in my current checkout/branch/whatever
<bialix> jam: if you talk about cache with me then I should say that I'm still using pack-0.92 / 1.9 formats
<jam> vila: and I can step through the code and see the problem
<vila> jam: so you can reproduce it at will ?
<hexmode> and want to switch back to the pristine source, but still have my changes available.
<jam> vila: on *this* branch it reproduces every time
<hexmode> I haven't tried switch yet.
<jam> as the pull fails to complete
<vila> jam: in a branch where your extensions are up to date ?
<jam> hexmode: perhaps 'bzr shelve' if you want to revert to pristine
<vila> ha, the pull fials...
<hexmode> jam: k, reading the docs
<jam> vila: I've diagnosed the specific steps in the bug, and it is fully reproducible
<jam> the BTreeBuilder has a tuple() key
<jam> and when yo ucall "get_record_stream()" the record.key attribute is that same tuple
<vila> what I meant was: 'bzr pull' in my bzr.dev branch, i.e. the code is updated while running
<jam> vila: sure, that's what I thought, and no, that isn't happening here
<vila> jam: ok
<jam> I'm updating a tree-less branch of 2.0.2
<vila> with a bzr.dev bzr ?
<jam> vila: yse
<jam> yes
<jam> hexmode: 'bzr shelve' will revert your changes to the previous commit, and put them 'on a shelf' to be restored later with "bzr unshelve"
<hexmode> jam: right, just saw that, but was thinking of a way to maintain it: i.e. branches, not temp shelves
<jam> hexmode: it also depends what you mean by "pristine source", is that a different branch, or the previous commit on this branch
<hexmode> jam: I think shelve will do for now, though
<jam> hexmode: I can go into deeper config to make multiple branches a bit easier to work with, but it does take a bit of explaining
<hexmode> jam: maybe later.  Was looking at help for bzr switch: where can I find out about lightweight vs heavyweight checkouts?
<jam> hexmode: you might try 'bzr help checkouts'
<hexmode> jam: excellent.  thanks
<vila> jam: I just pulled in my 2.0 branch without trouble :-/
<jam> vila: so it will depend explicitly on the data stream
<jam> specifically, you 1 have to pull from bzr+ssh
<jam> 2 it has to try to read a page from the newly created btree
<vila> I do (AFAICS)
<vila> confirmed by .bzr.log
<jam> so it needs to transfer a chk page from the source, which it then needs to verify
<vila> what revno are you at when pulling ?
<jam> 4696
<jam> note, though, that it will probably depend what pages are in your local repo already
<vila> yeah...
<bialix> jam, vila: does one still should write tests for each bugfix? e.g. for fixing https://bugs.launchpad.net/bzr/+bug/389648 there is need only to add Hooks.__init__(self) to some derived classes constructors...
<ubottu> Ubuntu bug 389648 in bzr "internal error on bzr hooks" [Medium,Confirmed]
<hexmode> bzr shelve: I'm in love
<jam> vila: I feel like I understand the bug, I'm just trying to get a feel for the fix
<jam> specifically, do I make the code *stricter* everywhere
<jam> or *more relaxed*
<jam> do I push to require StaticTuples in BTreeBuilder
<jam> or do I relax requiring StaticTuples in chk_map
<jam> and to what degree ...
<vila> jam: I'm from the more stricter school by default :-) And you said you want ST everywhere. BUT,
<vila> you're also the RM and you want to release today
<jam> vila: So I *think* that for performance and memory minimal that pushing ST everywhere is ideal
<vila> So I'd say, relax for today, it's a beta, and dig that asap in bzr.dev
<jam> There is always the "transition" phase
<jam> and wondering about when is good-enough
<jam> vila: ok, I'll create a 'relax' patch in about 10 min
<jam> if you can review it, it would be nice
<vila> the decisions IMHO is about is that bug likely to hit people ? You seem to think it's quite hard to reproduce, so.
<vila> I sure will
<vila> jam: could you replace the check with a upcast ?
<jam> vila: of course I can cast it, the point is how strict to be
<jam> casting random tuples => StaticTuples makes memory consumption worse
<jam> as now you have 2 objects representing the same thing
<jam> so you *want* the caller to do the cast
<jam> I'm doing a quick "assert when a debug flag is set" patch
<jam> and cast
<vila> jam: oh sure, I was thinking of the 10min approach, not the long term one
<vila> ouch, 1h30 time drift in 5 hours on my FreeBSD8 slave :-/
<jam> wow
<vila> fullermd: whenever you have a minute to discuss possible workarounds ^, I don't blame FreeBSD here, more likely VB (and they seem to be aware of the overall issue), but that seems to have to many side-effects for me to ignore :-/
<vila> and same thing for the FreeBSD7 slave, I love coherent OSes :)
<bialix> jam, vila: can you look at my fix http://pastebin.com/m125a467e for bug 389648 please?
<ubottu> Launchpad bug 389648 in bzr "internal error on bzr hooks" [Medium,Confirmed] https://launchpad.net/bugs/389648
<bialix> fix is 2 liner, and ten lines of tests
<vila> bialix: hehe, you're getting in the TDD mood :-D
<bialix> I'm stuck with my current job, so I've decided to fix this simple one
<bialix> vila: :-P
<bialix> vila: I do very much TDD at my job
<vila> bialix: why don't you push that branch and make a merge proposal ?
<vila> it makes reviews easier
<bialix> if you say that it ok in principle then I'll push
<vila> but from the paste bin, I'd say, put these import at the beginning of the file, use import mod ; mod.func instead of from mod import func ; func
<vila> bialix: hehe, that's not how we review :-D You asking for approval before review here :D
<bialix> imports in the tests?
<vila> yup
<bialix> I'm asking about tests approach
<bialix> the fix is obvious but I have no time to rewrite my tests zillion times later
<vila> if they fail without your patch and your patch make them pass, who will argue ?
<bialix> I dunno, lifeless?
<bialix> sometimes he argue about things I don't care so much
<vila> You think you put them in the wrong files ? Or that you test at the wrong layer ?
<bialix> ok, I'll push
<bialix> from the bug description bzr-svn triggers that bug registering a hook
<bialix> I don't register a hook and anyway can trigger the bug
<vila> bialix: 8-/
<bialix> I don;t know how in ideal world the tests for such bug should like
 * bialix bbl
<vila> It seems to me the bug in format_rio, so the tests could be in the corresponding test file, or we could try to make hook more resistant by ensuring the right constructor is always called, but that will certainly be quite ugly
<vila> oh, info.py is bogus too
<vila> bialix: right, so please do like the other classe that derived from Hooks, use the super() notation
<vila> bialix: of course, I found other examples that don't use super() :-/
<nxvl> hi, i just reported Bug #471292
<ubottu> Launchpad bug 471292 in bzr "import-dsc fails on UTF-8 characters" [Undecided,New] https://launchpad.net/bugs/471292
<nxvl> bzr import-dsc is failing basicaly because the debian chagelog has UTF-8 characters
<nxvl> wich is odd since there are packages in the ubuntu repo that has them aswell
<nxvl> and bzr supports them
<james_w> urgh, sorry nxvl
<jam> vila: sorry about the delay, got hit by a "Jehova's Witness' if you know what that means
<vila> jam: hmpf
<vila> jam: yeah, I know, not seen for years... luckily :)
<jam> it being the end-of-days and all
<jam> I suppose fixing this doesn't matter then
<jam> :)
<vila> lol
<vila> bialix: argh, he's gone :-/
<jam> vila: https://code.edge.launchpad.net/~jameinel/bzr/2.1.0b2-471193-st-and-chk-map/+merge/14309
<lugo> hi
<AnMaster> oh 2.0? when did that happen
<lugo> a checkout i use has recently changed it's name
<lugo> well the branch name has changed actually
<jam> AnMaster: Sept 22, approx 1.5 months ago.
<AnMaster> jam, sigh, university really made me miss out on the rest of the world recently
<lugo> since i'm really new to bzr i just don't know how to tell it the name change ;)
 * AnMaster looks for some release notes or overview of the major changes since 1.17 or so
<GaryvdM> lugo: bzr bind new/url
<jam> lugo: 'bzr switch --force' ?
<jam> GaryvdM: /wave
<GaryvdM> lugo: sorry bzr switch
<GaryvdM> Hi jam
<vila> jam: you requested merging against lp:bzr ?
<jam> GaryvdM: 'bzr bind new/url' is accurate if using a heavy checkout, I think
<lugo> switch ok i'll try that
<jam> vila: meh, you know what I mean :)
<jam> it *is* for 2.1.0b2
<jam> Just forgot to set the target
<jam> it will get into bzr.dev soon anyway
<vila> jam: ok, just checking, I'll stop waiting for lp to generate the diff then and do it locally
<jam> GaryvdM: bialix mentioned you were hoping to get qbzr 0.16 released for 2.1.0b2, do you think that will happen?
<lugo> yay worked, thank you guys
<GaryvdM> jam: Yes - My weekend was a nightmare (Partially self inflected.)
<GaryvdM> There were some features that I was hoping to finish, Which are not done yet.
<vila> jam: so the plan is to get rid of expect_static_tuple in the end right ?
<jam> vila: long term, yes
<GaryvdM> Trunk is stable so I guess I should just release it as it is.
<GaryvdM> jam: What is my deadline?
<jam> GaryvdM: take your pick. *I'm* happy enough to release w/ 0.15
<jam> GaryvdM: I'd like to cut bzr tonight
<jam> and then have the windows installers by tomorrow
<GaryvdM> Jam: I'll try, but if I miss it, no worries
<GaryvdM> jam: After  2.1.0b2, how many release cycles before 2.1.0 Final?
<jam> GaryvdM: well, do what you can, and realize that I'm pushing to be more 'timely', mostly because that should *ease* your burden
<jam> since if you miss it, it won't be long til you get to try again
<jam> GaryvdM: https://edge.launchpad.net/bzr/ says we should expect b3, rc1 and rc2 before final
<jam> https://edge.launchpad.net/bzr/+milestone/2.1.0 says final is 2010-02-03
<vila> jam: approved, running the full test suite right now just in case
<GaryvdM> jam: Ok - My motivation is to have new features tested before the final, so I'm going to let it slip, as there is another beta.
<vila> jam: full test suite passing
<jam> vila: thanks.
<GaryvdM> Hi vila
<jam> of course, it was passing before my patch...
<jam> I would like to test it, but the setup is hard
<vila> hey GaryvdM
<jam> the real fix is to test the index code to make sure they return ST
<jam> and the Remote streaming code, etc.
<vila> jam: no worries, I always run the full test suite when I review, I wanted to give view the approval in advance
<vila> s/give view/give you/ wow..... what's that for a typo ?
<vila> lol
<jam> vila: you know, I didn't even notice
<jam> I read 'you' just fine
<jam> 'give you'
<jam> it sounds the same as 'give view'
<vila> yeah, that's what surprises me the most...
<vila> *I* supposed to make typos because my fingers slip, not that kind of typo (I don't even think I ever do that in French...)
<vila> OR only on purpose for jokes...
<jam> it *was* an impressive coincidence.
<jam> you had just talked about 'review', so it could be just that
<vila> it also carries the meaning: "I wanted to give you visibility on my review" more freudian that way :)
<vila> bialix: http://pastebin.com/m829db9b is an alternative that *also* fail before your patch and succeeds after
<vila> bialix: just to maintain the universe balance, that makes a two-line fix with one-line test fix :)
<vila> bialix: hope you're reading the log history...
<GaryvdM> vila: lol - Was just about to point out to you that he's not here...
<vila> GaryvdM: I know he's gone, but I'll quit shortly... But now, *you* are responsible to carry that paste :-D
<GaryvdM> Oh No.
<phoenixz> I do "cd /home/sven/project/test" then "bzr whoami 'Sven <sven@blah.com>'", then a bzr whoami, and it shows the right thing.. Then I do a "bzr whoami /home/sven/project/test" and bzr tells me: "/home/sven/projects/kloud" does not seem to contain an email address.  This is allowed, but not recommended.
<phoenixz> what is this about? the whoami is a global setting or just per project?
<Peng> phoenixz: Well, "bzr whoami /home/sven/project/test" tries to set your name to "/home/sven/project/test".
<phoenixz> Peng: ah, doh!
<Peng> phoenixz: s/tries to set/sets/, probably.
<Peng> phoenixz: I'm not sure if you can set it per-project. You could try setting it in ~/.bazaar/locations.conf or $branch/.bzr/branch/branch.conf
<jam> phoenixz: you can use "bzr whoami --branch USERNAME" to set it for a specific branch
<jam> or, as Peng said, use locations.conf to set it recursively somewhere
<Peng> Oh, I didn't know that.
<kfogel_>  this one ring a bell to anyone? http://paste.ubuntu.com/307835/  "bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for parent_id_basename_to_file_id maps"
<phoenixz> When  I do an bzr annotate --all --long file.php, I get lines like this: 1   sven@kionetworks.com 20091102 |  * blah blah blah
<phoenixz> I see email, a date, but what is the 1 in the first position of that line?
<Tak> revno
<phoenixz> Tak: yeah, just found it in the help too, thanks!
<phoenixz> Another question.. BZR does NOT have support for copy, right? How do I do it with.. well, under SVN I had a template library, I used to copy all my libraries from there.. Make a small update to the template library, merge it to the other libraries, etc.. But with BZR, there seems not to be such a history possible.. How would I do this?
<kfogel_> rockstar: (see my question above?)
<rockstar> kfogel_, what version of bzr are you using?
<rockstar> kfogel_, fair warning: if you say 1.17 I will slap you.  :)
<kfogel_> rockstar: 2.0.1
<kfogel_> rockstar: :-)
<rockstar> kfogel_, huh, okay.  jam? ^^
<phoenixz> Another question.. BZR does NOT have support for copy, right? How do I do it with.. well, under SVN I had a template library, I used to copy all my libraries from there.. Make a small update to the template library, merge it to the other libraries, etc.. But with BZR, there seems not to be such a history possible.. How would I do this?
<Peng> Right. Bazaar does not support copies.
<phoenixz> Peng: so how could I do what I just mentioned?
<phoenixz> or better, will copies be supported in the future?
<Peng> phoenixz: Probably, but likely not any time soon.
<phoenixz> And another one.. I just added an entire tree, and one directory keeps showing as unknown.. When I specifically add that directory with bzr add, I get bzr: ERROR: '/home/sven/projects/blah/lib.e/blah/directemplate' is not a working copy
<Peng> phoenixz: Why not make the template thing a branch, and make your other projects branches of it?
<phoenixz> what is this about?
<Peng> phoenixz: Not sure. Does that directory have a .bzr, .svn, .git or .hg directory in it?
<phoenixz> Peng: Well, Im considerring making each library a branch, but since we have like 140+ libraries to manage.. gets to be a lot of branches..
<phoenixz> Peng: bingo, it has an .svn directory in it yeah!
<phoenixz> If I have a  branch with in there various directory, and each directory is a library.. Can I -at one point- branch each of those libraries from the current branch?
<phoenixz> simply said, can I create branches from sub directories in a branch?
<Peng> phoenixz: Eh. Are you looking for "bzr split"?
<bialix> vila: thanks for paste, but your variant is completely new. I think you have to send merge request yourself
<vila> bialix: well, *you* found the fix, I was just curious about how to test it :-)
<vila> bialix: I'll send the fix tomorrow and give you credit. Deal ?
<phoenixz> Peng: I dunno, let me see what "split" does :)
<bialix> vila: the fix was so simple, so I don't dare to get credits really
<bialix> vila: do as you wish, please
<bialix> vila: and thanks
<blackxored> hello
<blackxored> how can I instruct my friend on windows to checkout to a branch at a gforge install with bzr plugin?
<bialix> what?
<bialix> GaryvdM: heya
<GaryvdM> Hi bialix
<bialix> how's 0.16?
<GaryvdM> Has not happend yet... :-(
<bialix> do you want 0.15.1?
<GaryvdM> Weekend was not productive, but I'm making some progress now.
<bialix> btw about qcommit anf grouping
<bialix> I found several really weird cases on weekends while I'm working on my project
<bialix> e.g. remove many files and dir itself
<bialix> or rename many files to some folder
<GaryvdM> Ok  -I'll take a look
<GaryvdM> also bug 471591
<bialix> things like '/foo.txt => foo.txt' is not really looks fine
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/471591)
<GaryvdM> Huh - I though I fixed that.
<bialix> sometimes I just think folders does not works good
<bialix> err
<bialix> I mean sometimes group by folder is not really fine
<bialix> and absence of any icon for deleted files/dirs is irritating
<GaryvdM> bialix: It's easy to make a config option for it. Should I do that?
<GaryvdM> (switching off trees)
<bialix> group/no group?
<GaryvdM> yes
<bialix> maybe, but not tonight perhaps
<GaryvdM> yes - other things I need to do
<bialix> I don't want to slow down, just produce some feedback because you asking me in saturday
<GaryvdM> Yes - I do want feedback.
<GaryvdM> These things are so subjective.
<GaryvdM> So you don't like the way moves show?
<bialix> I can't say for sure
<bialix> it's not very intuituve
<bialix> sometimes it looks buggy
<bialix> I'm not sure what it should be in ideal
<bialix> plain list is more straightforward, though I understand some people may want folders
<lifeless> moin
<GaryvdM> bialix: If a file has moved, then I try show the path it was moved from relative to it the dir it has been moved to.
<jam> morning lifeless
<GaryvdM> bialix: like ../../foo => foo
<bialix> :-/
<bialix> IMO we need to show moves separately
<GaryvdM> bialix: maybe "foo (moved from /bar/)
<bialix> or show full pahs, e.g. foo.txt =>dir/foo.txt
<GaryvdM> dir/
<bialix> this first slash is really weird for windows-minded people
<GaryvdM> ? I use to do "\Program File\xxx\bzr.exe" long before I ever heard of linux
<bialix> maybe "foo (moved from bar/)
<bialix> I understand your intent to highlight root of the tree
<bialix> GaryvdM: I don't try to hurt you, sorry
<GaryvdM> No problem - Just trying to work out what is the best for all.
<bialix> heh
<bialix> best for all :-)
<GaryvdM> bialix: I've just pushed to trunk the rename and move functionality for qcommit and qbrowse
<bialix> ok
<bialix> my i-net is not very well tonight though
<GaryvdM> and if you rename/move a file out side of bzr, you can select the missing, and the non-versioned, right click, and choise "Mark as moved", which does a mv --after :-)
<corp186> I've got my own project in bzr, and I've currently got a populated debian directory
<corp186> I'm thinking the debian dir would be a good candidate for splitting into a sub tree
<corp186> I ran bzr upgrade (on karmic), and then ran bzr split debian
<corp186> then I did bzr join --reference debian
<corp186> I committed both . and debian
<corp186> but now if I branch from the repo, I don't get the debian subtree
<corp186> what am I doing wrong?
<lifeless> corp186: at least for ubuntu, standard packaging practice is to use a single tree for the code & debian dir
<lifeless> corp186: thats what the build-by-commit code will be looking for
<corp186> lifeless: what about when after I submit it for ubuntu, some debian dev wants to maintain the package in debian?
<lifeless> they've a bunch of options
<lifeless> debian developers do it all sorts of different ways
<lifeless> what I do recommend is that you have two branches:
<lifeless> 'upstream' and 'packaging'
<lifeless> the packaging branch adds the debian dir and other packaging metadata.
<corp186> first, I'm upstream
<corp186> so this isn't traditional in that sense
<corp186> and second, I don't want to have to continually merge code between branches
<corp186> if I have a subtree for the debian/ dir, I can keep all the code in one branch, and have separate debian branches for different distros/releases
<lifeless> corp186: I'm upstream for a number of things too, and it is quite traditional.
<corp186> lifeless: even so, isn't it a pain to be merging between different branches just for packaging?
<lifeless> Debian policy frowns on upstreams having a debian dir in their releases
<lifeless> and a nested branch will show up as a debian dir
<lifeless> corp186: not at all, I package about 20 things from cron at the moment, using bzr-builder and a merge recipe.
<corp186> lifeless: release tarballs would have the debian dir manually removed
<corp186> and I'm not that interested in maintaining release scripts merging things between various branches
<corp186> I guess, why wouldn't the debian dir be a good candidate for being a subtree?
<corp186> I see that it may not be that bad to have separate branches, but subtree still seems like a better approach
<bob2> then you'd still have a debian dir in the upstream branch
<corp186> bob2: it's not against policy to have a debian dir in the repo
<corp186> just not in the tarball releases
<corp186> side-stepping details about packaging, can anyone help diagnose why bzr branch doesn't branch the subtree as well?
<lifeless> corp186: nested trees aren't a supported feature yet
<corp186> oh?
<corp186> I didn't realize that
<corp186> I figured since it's in there, it must work
<corp186> lifeless: since you've had some experience with being upstream and doing packaging, do you do things as native packages, or do you somehow generate the diff.gz file with the debian directory?
<lifeless> I generate the tarball from my trunk or release branch, which doesn't have the debian dir.
<lifeless> I merge to my debian packaging branch & build debian packages from there, which uses the tarball and generates a regular package.
<enatom> I dont understand
<enatom> how would i setup bazaar for team collaboration ?
<enatom> ?
<GaryvdM> enatom: Bazaar can be use in many ways. Some of these are documented here: http://doc.bazaar-vcs.org/latest/en/user-guide/bazaar_workflows.html
<enatom> do i have to install it on the internet, to get my team from overseas to work together
<enatom> i dont get it
<GaryvdM> enatom: I guess that you want to have "Decentralized with shared mainline"
<GaryvdM> enatom: All you need is a shared location that any of the team can access.
<GaryvdM> enatom: this can be via sftp, ftp, webdav, smb etc...
<GaryvdM> enatom: If you can setup a bzr server, you will have better performance. But this is not a requirement.
<GaryvdM> enatom: Do you have such a location?
<enatom> GaryvdM, i have a hostgator account
<enatom> would that be ok ?
<GaryvdM> enatom: Not ideal, but it would work. You would need to give the password to each of the team.
<enatom> ok, fair enough but i dont understand
<enatom> what do i actually install on the server
<enatom> like with phpmyadmin, its just a php script
<enatom> but what the hell is bazaar, it aint a php script
<enatom> is it?
<enatom> btw if you havent noticed
<enatom> iv never used a versioning control system
<enatom> but would like to
<GaryvdM> enatom: As I said, you don't have to set up a server. All you need is a shared folder, that you can all right to.
<enatom> so would i need my computer on, so people can connect to my computer and work of it, with bazaar installed ?
<corp186> enatom: it wouldn't hurt to read http://doc.bazaar-vcs.org/latest/en/user-guide/index.html through to get an idea of what bzr is, how to use it, and how to install it
<GaryvdM> enatom: If you are working on a open source project, there are sites that will host it for you for free, e.g. http://launchpad.net/
<enatom> and does launchpad use bzr ?
<GaryvdM> Yes
<enatom> oh cool
<enatom> so is git or bzr better?
<enatom> coz im hearing github is pretty big
<corp186> enatom: I doubt you'll get an honest answer in #bzr
<GaryvdM> bzr, but I'm biased...
<corp186> I didn't mean dishonest, just biased
<enatom> yeah but what exactly is the difference
<GaryvdM> enatom: http://bazaar-vcs.org/BzrVsGit
<enatom> gits way complex anyway
<RAOF> github is big, but does a *lot* less than launchpad.
<RAOF> Also, I think it's smaller than launchpad, too, so if you're going by size... ;)
<GaryvdM> enatom: Oh - don't go to that page, it's out of date.
<enatom> im using ubuntu btw
<enatom> anyone heard of Nautilius SVN
<enatom> and also , is there any Video tutorials or similar on using bazaar
<phoenixz> Where can I find a list of the short status indicators that BZR might give me for bzr st -S ?
<GaryvdM> enatom: There is a Nautilius bzr, but it's needs some work. I can recommend using bzr-explorer if you looking for a gui to easy you into things.
<enatom> wait, doesnt BZR already have a GUI
<enatom> wtf is BZR if it aint a GUI
<enatom> someone here, should really do a Youtube Video tut
<enatom> 137 people, would it hurt to do a quick video
<enatom> to get beginners into things
<enatom> like theres no videos on youtube or google
<Peng> enatom: Bazaar started out as a command-line program, like many/most other VCSes.
<enatom> yeah
<enatom> but i mean does it have a Gui now ?
<GaryvdM> Yes  - bzr-explorer
<enatom> or do i need to isntall certain things like this nautilius thing or bzr explorer
<enatom> so do i install both?
<enatom> bzr and bzr-explorer?
<GaryvdM> enatom: If you install bzr-explorer, it will automatically install bzr
<GaryvdM> enatom: what version of ubuntu are you running?
<enatom> karmic
<enatom> so is the standalone bzr just a command line app?
<GaryvdM> yes
<enatom> ok, so iv gone into Ubuntu Software Centre, ... and iv typed in bzr
<enatom> it has Bazar version control system
<enatom> and olive bazaar branch manager
<enatom> and it also has "diffuse merge tool"
<GaryvdM> enatom: I just checked - bzr-explorer is not in karmic, but you can install it easily by adding the bzr ppa
<enatom> what is a "ppa"
<GaryvdM> package archive
<enatom> ok whats the ppa for it
<GaryvdM> Ah - just hold on a sec.
<GaryvdM> enatom: This will install bzr-explorer in 2 steps - Form the command line run:
<GaryvdM> sudo apt-get install qbzr
<enatom> ok ill do that now, and how would i unistall it when i need to
<GaryvdM> bzr branch lp:bzr-explorer ~/.bazaar/plugins/explorer
<enatom> ok
<GaryvdM> sudo apt-get remove qbzr
<GaryvdM> rm ~/.bazaar/plugins/explorer -r
<GaryvdM> To uninstall ^^^^
<GaryvdM> enatom: Someone is working on packing bzr-explorer this miniute, so it will be more easy in the future.
<enatom> btw is this the explorer bzr homepage
<GaryvdM> enatom: http://doc.bazaar-vcs.org/explorer/en/
<enatom> by packing do you mean, available on the ubuntu software center ?
<GaryvdM> Yes
<GaryvdM> enatom: what do you hope to use bzr for?
<enatom> i sware to god, if i learn how to use it, ill make the video tutorials for others like me to learn easier
<enatom> php app
<GaryvdM> Great
<enatom> im developing a social networking app for graphic designers onlocalhost
<enatom> why is what ill be doing with it, importnatn ?
<enatom> important*
<GaryvdM> Just intrested. bzr will work well for that.
<enatom> oh ok
<enatom> ill wait for the guy to package it
<enatom> that way i can install it via software center, and which will be easier to remove if needed
<enatom> i dont like typing stuff in terminal
<enatom> wow
<enatom> bazaar is made by canonical
<enatom> :)
<enatom> GaryvdM, has he packaged it yet?
<GaryvdM> enatom: Not yet - It will take some time.
<enatom> how long ?
<enatom> kind of waiting for him, to do it, so i can install it
<GaryvdM> https://bugs.launchpad.net/bugs/425507
<ubottu> Ubuntu bug 425507 in ubuntu "[needs-packaging] bzr-explorer should be packaged in ubuntu and the ppa" [Wishlist,In progress]
<GaryvdM> enatom: you can subscribe to that bug. It will notify you when it he is finished.
<enatom> how long does things like tha ttake
<enatom> 1 week ?
<enatom> 2 hours?
<enatom> also what is "signed revisions" ... in the features comarison table of all VCSs its says bazaar does "partial" signed revision
<Peng> enatom: Signing them with GPG, so that you can be sure of their authenticity. Unfortunately, Bazaar doesn't support the "verifying" part yet...
<enatom> whats GPG ?
<GaryvdM> enatom: I would just install it with the command I gave you - It is quite a simple command.
<enatom> sure GaryvdM
<Peng> enatom: Google it.
<enatom> i have, many abbreviatiosn come up
<enatom> which GPG?
<GaryvdM> http://en.wikipedia.org/wiki/GNU_Privacy_Guard
<phoenixz> Where can I find a list of the short status indicators that BZR might give me for bzr st -S ?
<enatom> GaryvdM, you gave me to commands to remove it, which where "bzr branch ip:bzr-explorer" and sudo apt-get remove qbzr
<enatom> what does this do : bzr branch lp:bzr-explorer ~/.bazaar/plugins/explorer
<GaryvdM> enatom: I gave you 2 commands to install it, and 2 command to remove it.
<GaryvdM> To install:
<GaryvdM> sudo apt-get install qbzr
<enatom> ok i installed that
<enatom> i did that now
<GaryvdM> bzr branch lp:bzr-explorer ~/.bazaar/plugins/explorer
<enatom> i pressed y
<enatom> it installed
<enatom> now the termainal says "processing triggers for python-support..."
<enatom> and its kind of stuck here
<enatom> how to i run bzr-explorer ?
<GaryvdM> enatom: run bzr explorer
<enatom> yeah how, there is not icon in the applications menu, or the desktop
<enatom> how do i run bzr explorer
<GaryvdM> enatom: when the packing is done, it will create a icon for you.
<GaryvdM> enatom: for now: step 3: create the icon your self
<enatom> how?
<GaryvdM> or run it form the command line.
<enatom> where?
<enatom> how?
<enatom> whats the command?
<GaryvdM> bzr explorer
<enatom> bzr branch lp:bzr-explorer ~/.bazaar/plugins/explorer
<enatom> sorry i mean
<enatom> enatom@enatom-laptop:~$ bzr explorer
<enatom> bzr: ERROR: unknown command "explorer"
<enatom> enatom@enatom-laptop:~$ ^C
<enatom> enatom@enatom-laptop:~$
<GaryvdM> enatom: did you run bzr branch lp:bzr-explorer ~/.bazaar/plugins/explorer
<enatom> GaryvdM, i typed bzr explorer... and i got this :enatom@enatom-laptop:~$ bzr explorer
<enatom> bzr: ERROR: unknown command "explorer"
<enatom> no i didnt run that command line, that was just on my clipboard accidently pasted it here
<enatom> but
<enatom> enatom@enatom-laptop:~$ bzr explorer
<enatom> bzr: ERROR: unknown command "explorer"
<GaryvdM> enatom: you must run alos run this command to install bzr-explorer:
<GaryvdM> bzr branch lp:bzr-explorer ~/.bazaar/plugins/explorer
<GaryvdM> *also
<GaryvdM> enatom: that will get the source code for bzr-explorer using bzr
<enatom> dude can you refer to a tutorial that i can follow to install this easeily
<enatom> this is complicated
<GaryvdM> entom: http://doc.bazaar-vcs.org/explorer/en/install-linux.html
<GaryvdM> you allready have qbzr
<GaryvdM> entom: now you need to get bzr-explorer
<enatom> im getting this error: You have not informed bzr of your Launchpad ID, and you must do this to
<enatom> write to Launchpad or access private data.  See "bzr help launchpad-login".
<enatom> when i enter this bzr branch lp:bzr-explorer explorer
<GaryvdM> enatom: you can ignore that for now
<enatom> ok ignored
<phoenixz> Where can I find a list of the short status indicators that BZR might give me for bzr st -S ?
<enatom> its not working
<enatom> enatom@enatom-laptop:~$ bzr branch lp:bzr-explorer explorer
<enatom> You have not informed bzr of your Launchpad ID, and you must do this to
<enatom> write to Launchpad or access private data.  See "bzr help launchpad-login".
<enatom> Branched 311 revision(s).
<enatom> enatom@enatom-laptop:~$ bzr explorer
<enatom> bzr: ERROR: unknown command "explorer"
<enatom> enatom@enatom-laptop:~$
<GaryvdM> enatom: You did not read the instructions on http://doc.bazaar-vcs.org/explorer/en/install-linux.html
<GaryvdM> "Then change to the directory holding your plugins (normally ~/.bazaar/plugins) and run"
<GaryvdM> or just ran the commad I gave you:
<GaryvdM> bzr branch lp:bzr-explorer ~/.bazaar/plugins/explorer
<enatom> ok
<GaryvdM> phoenixz: the source code. I'll look for you now.
<enatom> ok i did what you said, and its still not working GaryvdM
<enatom> : enatom@enatom-laptop:~$ bzr branch lp:bzr-explorer ~/.bazaar/plugins/explorer
<enatom> You have not informed bzr of your Launchpad ID, and you must do this to
<enatom> write to Launchpad or access private data.  See "bzr help launchpad-login".
<enatom> bzr: ERROR: Parent of "/home/enatom/.bazaar/plugins/explorer" does not exist.
<enatom> enatom@enatom-laptop:~$ bzr explorer
<enatom> bzr: ERROR: unknown command "explorer"
<GaryvdM> enatom: run:
<GaryvdM> mkdir ~/.bazaar/
<phoenixz> GaryvdM: Im not too much for the sourcecode myself.. thanks! Maybe something that could be documented in a wiki somewhere?
<GaryvdM> mkdir ~/.bazaar/plugins
<enatom> ok did that and i just typed in : bzr branch lp:bzr-explorer ~/.bazaar/plugins/explorer
<enatom> after making the directories
<enatom> its downloading something
<enatom> ok so its done
<enatom> basically
<enatom> all i had to do was setup a plugins folder
<enatom> its running now woop
<enatom> the next hurdle : understanding
<enatom> cheers GaryvdM
<GaryvdM> \o/
<enatom> just for clarification
<enatom> what is qbzr and what is bzr-explorer ?
<enatom> GaryvdM,
<GaryvdM> phoenixz: not sure. Docs are here: http://doc.bazaar-vcs.org/latest/
<phoenixz> GaryvdM: could you find anything in the sourcfe code?
<GaryvdM> enatom: I'm one of the devs for qbzr
<enatom> cool
<enatom> but what is it ?
<GaryvdM> phoenixz: yes in multiple places
<GaryvdM> enatom: we started building a gui based on the Qt toolkit. We have many powerfull commands: bzr qlog, bzr qcommit, etc..
<GaryvdM> enatom: We have not finished our main window.
<GaryvdM> enatom: The starting point
<enatom> so whats the difference between Bzr-eplorer and qbzr ?
<GaryvdM> enatom: bzr-explorer is just a main window, that uses qbzr for all its other windows.
<enatom> oh ok
<phoenixz> GaryvdM: Guess I'll just have to figure this the hard way
<GaryvdM> phoenixz: http://paste.ubuntu.com/307983/
<phoenixz> GaryvdM: another question.. in SVN I could svn delete a file.. How do I do that with bzr? don't see no delete... bzr remove? bzr help remove shows more soemthing about stopping with tracking
<Peng> phoenixz: Yes, bzr remove (aka rm).
<phoenixz> okay
<phoenixz> GaryvdM: thanks for the list!
<GaryvdM> pleasure
<GaryvdM> phoenixz: It was gather with a quick skim over the source. So I may have missed somthing...
<phoenixz> GaryvdM: don't worry, I just want the most important one.. Working on an web based versioning interface that can work as front-end for SVN, SVK (strarted on that), GIT and bazaar.. Since I work with PHP and don't have a BZR library available, I just shell interface for the commands
<phoenixz> not perfect, but it works
<GaryvdM> I see
<enatom> GaryvdM, if i want to add a new project to my localhost as the location what would i enter in "location" field ?
<enatom> should i enter /var/www/ ?
<GaryvdM> /var/www/my_project
<spiv> Good morning.
<GaryvdM> Hi spiv
<enatom> and how would i access the files via a browser
<enatom> would http://localhost get me to that folder
<enatom> OMFG !!!!
<enatom> I JUST GOT A GOOGLE WAVE INVITE
<enatom> I JUST GOT A GOOGLE WAVE INVITE
<GaryvdM> enatom: I think thats a question for #apache
<RAOF> enatom: As I understand it, that means you now have 8 invites to give out.  I hereby stake my claim to one!
<enatom> CALM DOWN PEOPLE, LET ME REGISTER MINE
<enatom> I ONLY JUST RECIEVED THE EMAIL
<enatom> OMFG
<enatom> omfffffffffff gooood!
<enatom> google wave
<phoenixz> GaryvdM: bzr add file will always producs +N when bzr st -S ?
<enatom> GaryvdM, Do you have a google wave account ?
<enatom> I GOT 8 GOOGLE WAVE INVITES TO HAND OUT
<GaryvdM> enatom: Nope - But I would not mind one. garyvdm@gmail.com
<enatom> OK, ILL SEND YOU ONE NOW
<GaryvdM> phoenixz: Yes
<enatom> ANYONE ELSE ?
<RAOF> Throw one at raof@ubuntu.com, please :)
<GaryvdM> enatom: thanks
<enatom> ROAF
<enatom> ROAD
<enatom> ROAF
<RAOF> r. a. o. f. ;)
<enatom> RAOF HOW EVER THE HELL YOU SPELL YOUR NAME
<enatom> uhm where abouts do you live ?
<RAOF> .au
<enatom> GaryvdM, where abouts do you live ?
<enatom> raof, you have to suck my balls abit, coz it aint fair on GaryvdM , his helped me quite abit today
<enatom> and you aint done shit
<enatom> so... do something
<RAOF> Um...
<RAOF> I can point you at GNOME Do?
<enatom> point me?
<RAOF> apturl://gnome-do
<enatom> whats the do ?
<enatom> what does that do ?*
<GaryvdM> What ever you tell it to :-)
<RAOF> It's a bit like quicksilver on Mac.  It's an... "action interface", I guess.
<GaryvdM> enatom: He has a @ubuntu.com address, which mean he is a ubuntu memeber, which mean he allready rocks!
<enatom> GaryvdM, is RAOF an important person, like does he develope things like you ?
<enatom> or is he just a bum, who hangs around here
<RAOF> If you *haven't* tried gnome-do, I'd suggest giving it a whirl.  It's awesome, and I don't only say that because I'm the maintainer :)
<GaryvdM> enatom: He is a ubuntu member which means he is a hardcore dude
<fullermd> Hm?  Somebody call for a bum?
<enatom> no we dont need bums
<GaryvdM> enatom: You have to do lots of work to become a ubuntu member!
<fullermd> Oh.
<enatom> oh ok
 * fullermd slumps back to his cardboard box.
<enatom> well ill send you guys one
<enatom> raof and GaryvdM  will be getting an invite soon
<RAOF> Thanks.  And try out gnome-do.  It's awesome!
<enatom> yeah i already have gnome do
<enatom> using it now, pretty good actually Â¬_Â¬
<enatom> nice work
<phoenixz> fullermd: Just a question... SVN has Add, modified and "added and modified"... does BZR has that last one too?
<phoenixz> RAOF: gnome-do? whazda?
<fullermd> phoenixz: Well, I don't know what svn means by that.  It doesn't seem to make sense; if it's added, there's no previous version to say 'modified' against.
<RAOF> phoenixz: Heh.  Install the package, give it a whirl :)
<phoenixz> fullermd: ah, now I remember.. added and modified is where the previos revision was a copy.. SVN supports copy, BZR does not..  if I would svn copy a file and then modify it, it would be added and modified..
<GaryvdM> phoenixz: you can have modified and renamed in bzr though
<phoenixz> GaryvdM: ah, thanks, another one for my list..
<enatom> GaryvdM, and RAOF , apparently i have to wait a couple of days till i hand out the wave invites, since im a new user i can only go through the "Preview" period
<enatom> its pretty shit actually
<enatom> i cant "wave" to anyone else, since no one i know has a google wave account
<GaryvdM> enatom: I see. They did the same thing with gmail.
<enatom> yeah and also... you get another email
<enatom> enatomx@googleWAVE.com
<phoenixz> oh THAT sucks..
<enatom> yeah, well ill send you a blank email, to keep you in my contacts when till i can actually send the invites out
<phoenixz> by the way, may I add that I really hope BZR will be supporting file copies? This was really a rather nice option of SVN / SVK, where all file history was preserved...
<spiv> phoenixz: we'd like to add that, but it's not at that top of the todo list yet.
<enatom> i cant write to my WWW folder,
#bzr 2009-11-03
<johnf> quick question re packaging. When we release 2.0.2 will there be a 2.0.2rc1 or are we just releasing since it should only be bug fixes?
<sven_oostenbrink> Can bzr diff also NOT throw errors when a file has a diff?
<igc> morning
<sven_oostenbrink> don't really like that behaviour :) I need it to just show the diff and thats it
<bob2> throw error = set return code?
<enatom> i just setup my project
<sven_oostenbrink> bob2: correctly, sorry, it sets a return code while there is no error
<enatom> but where in "trunk" folder will i put my files ?
<sven_oostenbrink> igc: Evening..
<poolie1> sven_oostenbrink: you're talking just about the shell return code?
<sven_oostenbrink> poolie1: yes
<poolie1> there's no builtin option to turn it off
<igc> hi sven_oostenbrink
<sven_oostenbrink> poolie1: interresting...
<bob2> svn diff || true
<johnf> I just did "bzr branch svn_reop trunk; bzr check" if I get a sha1 mismatch should I file/look for a bug or could it indicate dodgey svn data (which isn't inconceivable in this case)
<johnf> or I could just search first instead of wasting peoples time and find the existing bug in launchpad
<spiv> johnf: :)
<johnf> hmm except that bug is fr symlinks which this isn't
<johnf> is bzr-svn the best way to move from svn to bzr. Assuming that I don't care about any of the svn data at all. I just want the revisions. I don't cae about svn ids etc
<johnf> Maybe I should try tailor
<spiv> johnf: people mostly seem to use bzr-svn or fast-export
<johnf> can't use fast-export since I don't want the whole svn repo just a few branches
<johnf> and bzr-svn is creating the above problem with a bzr-check :(
<spiv> I believe fast-export and/or the importer can do some filtering of that sort of thing
<bob2> there's a filter thing
<johnf> ahh :)
<spiv> igc knows lots about it
<jelmer> johnf: that check issue is the symlink one?
<jelmer> johnf: reconcile should be able to fix that
<johnf> jelmer: I thought it was the symlink one but the file it is complaing about isn't a symlink. Reconcile thinks everything is OK which is strange since bzr check doesn't
<johnf> hmm I had a very old version of python-subversion 0.6 even though subversion was 1.5 I wonder if that could cause problems
<spiv> IIRC bzr-svn doesn't use python-subversion, it uses jelmer's subvertpy
<johnf> that's special fast-export-from-svn skips every single revision :)
<johnf> spiv: ahh looks that way
<johnf> This SVN repository is doing a good job of protesting my move to bazaar
* jam changed the topic of #bzr to: Bazaar version control system | 2.0.2 and 2.1.0b2 have gone gold! time to build those installers|  try https://answers.launchpad.net/bzr for more help | http://bazaar-vcs.org | http://irclogs.ubuntu.com/
<jam> johnf: we are *just* doing simple releases. The only 'rc' we will be doing is just before a new stable release
<johnf> jam: ok cool
<johnf> thanks
<jam> johnf: and 2.0.2 and 2.1.0b2 are now out
<jam> well, 'gone gold' waiting on you to build installers :)
<jam> as for '~beta-ppa' stuff. The 'b1' release is generally going to cause problems
<jam> but b2+ shouldn't cause as much strife
<jam> because the 'major.minor' version isn't changing
 * jam crosses fingers eyes and toes, because b1 was pretty awful :)
<johnf> agh I missed the 2.0.2 email. Will sort that tonight
<jam> well, just came out.. 5 min ago
<jam> :)
<jam> anyway, see y'all around later
<igc> poolie1: now that 2.0.2 and 2.1.0b2 have gone gold, can we work together on automating the doc builds some more?
<igc> johnf: fast-export-from-svn just does trunk currently and it has a range of problems
<igc> johnf: jelmer has fixed the biggest of those by adding fast-export support to subvertpy 0.7.1
<johnf> igc: ahh I need a newer subverty
<igc> johnf: ping jelmer if you need help running his fast-export script
<igc> johnf: I want to change fast-export-from-svn to use his script if it's present but I haven't done that yet
<johnf> Although I think I just got it working. I just need trunk anyway
<Kilroo> Oooh, 2.0.2.
<Kilroo> Here's hoping somehow building subvertpy against Subversion 1.6 for the Windows installer's bzr-svn gets worked into that somehow...
<poolie1> igc, hi
<poolie1> igc, good idea
<poolie1> spiv, hi?
<enatom> how can i use BZR with my www folder, if my www folder wont even allow me to create folders?
<RAOF> enatom: Change the permissions on your www folder so that the users who should have commit access can write to your www folder?
<enatom> ok ill try that
<RAOF> ie: add all the users who should be able to commit to bzr to a "bzrusers" group or somesuch and then chown the relevant directory.
<enatom> hmm sounds relatively easy, ill go through it now
<enatom> bzrusers group doesnt exist, should i just create it RAOF
<RAOF> You certainly could.
<RAOF> The details of what you want to do will depend on what, exactly, you want to do. :)
<RAOF> But the general plan is: "give all the users who'll need to commit to bzr permissions to write in the relevant directories".
<enatom> the problem is bzr-explorer doesnt even create the trunk folder
<enatom> becuase the actual program doesnt ahve access etc
<jam> poolie1: ping
<enatom> the group i created isnt in the list, for the permission of the folder
<jam> poolie1: Something is wrong with the Visual Studio 2008 installation on 'desolation'. It shows up as being in the start menu, but there is nothing in D:\ where it thinks it is installed.
<jam> I'm going to stop trying to configure it for now, in case we need to start with a new EC2 image
<poolie1> jam, hi
<poolie1> jam, ok, i may look at it too
<jam> poolie1: please do
<poolie1> i think this is because of the distinction between the two types of storage
<poolie1> it may be that disk needs to be remounted or i may have broken it
<jam> sure
<jam> that is sort of what I was thinking
<jam> I started installing and documenting my progress, and I didn't want to get to far
<jam> too far
<poolie1> does another volume come up in the mgmt console for that account?
<mwhudson> is D: the part of the storage that doesn't persist on bunding?
<mwhudson> like /mnt for linux images
<jam> poolie1: there is a 'D:' present
<jam> but it only had a 'hash' directory in it
<jam> I see a "created volumes" section, but I don't see anything present
<poolie1> mwhudson: yes, D: is the part stored on S3
<poolie1> i can't recall what the state of it is
<mwhudson> oh ok
<johnf> Say I have two branches. Branch A created by bzr-svn  has 20 revision and branch B created by fast import has the first 10 revision in branch A.
<johnf> Can I merge from B to A somehow. Can i manually specify the common ancestor or something?
<SamB_XP_> I think you'd need to use something evil
<SamB_XP_> like rebase or more fast-export | fast-import
<johnf> yeah I tried fast-import but it can't add revisions to an existing branch
<SamB_XP_> oh, lame
<johnf> I wonder what happens if I cat to fast-import files together :)
<SamB_XP_> I don't think that's going to help!
<SamB_XP_> another option is to make patches for each change and apply/commit each of those ...
<johnf> yeah trying to avoid that
<SamB_XP_> well, what you should really avoid is using fast-import on SVN repos ;-P
 * igc lunch
<johnf> sweet catting together fast-import files works!!
<johnf> Is it possible to set a branch as readonly?
<johnf> Reasoning is I have a branch on a web server where  I want to be able to pull
<johnf> but I want bzr to slap me if I try and commit
<johnf> I suppose I could write a pre-commit hook
<spiv> johnf: chmod -R a-w yourbranch
<spiv> Oh, but you want to pull.
<spiv> That's not readonly, exactly.
<johnf> spiv: yeah only sort of read only :)
<johnf> just don't want anyone to commit to it
<johnf> let me try writing a hook
<spiv> I guess a pre-commit hook is probably the way to go then.
<spiv> Or only make it writeable to a special user and then provide a sudo command to run pull (and only pull)?
<lifeless> precommit hook won't necessarily do it
<lifeless> as commit on a bound branch is a fetch operation
<lifeless> but if you are worried about local commits, then yes, precommit is fine
<jam> johnf: alternatively make the branch a checkout of the thing you want to pull from, and make the upstream location readonly from your local branch
<jam> It is what I do for my 'bzr.dev' local copy
<jam> I used to checkout from http
<jam> anyway, night all
<lifeless> gight jam
<igc> night jam
<cody-somerville> I had local commits and against a binded branch and then I did bzr update
<cody-somerville> how can I undo the bzr update as it totally did not turn out good
<cody-somerville> oh, luckily I still had the files open so I can just resave and overwrite what bzr did.
<bob2> have you considered just using unbound branches?
<vila> hi all
<fullermd> vila: Heydere.  What was it you muttered at my about this weekend?
<fullermd> Oh, time drift.
<fullermd> I think that's usually "solved" (worked around anyway) by dropping the kernel HZ.
<fullermd> You can do that in loader.conf...   kern.hz="100" say.
<fullermd> (the default 1000 sometimes interacts poorly with VM's...  thought I thought there were actually some changes made that detected in-VM status and dropped it)
<vila> fullermd: hi !
<vila> fullermd: I *have* kern.hz=100 already
<vila> fullermd: I'm glag you already know that much context...
<fullermd> Oh.  Well, so your problems solved then   8-}
<vila> s/glag/glad/ :)
<vila> hmm, interesting, freebsd7 lost 4 hours in the last 41 hours while freebsd8 lost "only" 20 minutes
<fullermd> Is it steady drift or jumps?
<vila> What I use so far to resync is: 1) reboot :-/ OR 2) ntpdate
 * fullermd has no idea what to actually _do_ with the answer to that question of course...
<fullermd> Well, you should probably run ntpd in them anyway...
<vila> I don't actually monitor that closely but I often see messages about calcru something... of course none are available right now :-/
<vila> ntpd is enabled
<fullermd> runtime went backwards.
<fullermd> Symptom.
<vila> yeah
<vila> but is that a drift or jump symptom ?
<vila> I suspect drift myself but that may be seen as jumps by some processes
<fullermd> Doesn't really differentiate.  Just sorta a general symtom of "WTF, time isn't seeming monotonic"
<vila> The most annoying one is that the slave lost the connection with the master... that's the symptom I want to cure
<vila> . o 0 ( Monotonic time is too boring for FreeBSD )
<fullermd> If ntpd is running, letting it drift like that means it's over the correction rate.  You could probably watch the offset grow via that.
<vila> 'via that' ?
<fullermd> Yah, watching what ntpd is doing.
<vila> /var/log/ ?
<fullermd> Well, I was thinking more "watching ntpq -p"
<fullermd> Though it probably spits something in messages when it gives up on slewing.
<vila> grep -i ntp /var/log* => ./Xorg.0.log:24:(**) FontPath set to: , yeah great
<vila> :)
<vila> My impression is that ntpd is run only at boot and never more from there... Any idea how to check that theory ?
<fullermd> ntpd is a daemon...
<fullermd> You can use ntpq to see if it's running.
<vila> how ?
<fullermd> ntpq -p
<bob2> ntpdate is the thing that (sometimes) runs only at boot
<bob2> but modern ntpd has an option for "jsut set the damn clock at boot"
<vila> ntpq -p
<vila> ntpq: read: Connection refused
<vila> daemon not running ?
<fullermd> Yeah, and they keep yacking about obsoleting ntpdate because of it.  Totally missing the point...
<fullermd> vila: Yah.
<vila> haaa
<bob2> do you need to run ntpq as root?
<vila> bob2: I'm root
<bob2> ah
<fullermd> Not unless you have funky firewalling or something.  It talks over UDP.
<bob2> oh
<fullermd> vila: So you presumably need to enable it in rc.conf (and then fire it up manually for this boot)
<fullermd> And edit the config to point at your local ntp server, of course.
<vila> the later is done, remind me the magic path to search for the options I can use in rc.conf ? (That's not /usr/ports/net/ntp)
<fullermd> % grep ^ntpd_ /etc/rc.conf
<fullermd> ntpd_enable="YES"
<fullermd> ntpd_sync_on_start="YES"
<vila> ntpdate_enable="YES"
<vila> is all I have !
<fullermd> (grep'ing in /etc/defaults/rc.conf would be how you'd find the choices)
<fullermd> Yah.  Which is why you're running ntpdate, but not ntpd   8-}
<vila> fullermd: great, you rock :)
 * fullermd buffs his nails on his lapel and looks important.
<fullermd> Now, that still suggests a hyuge amount of drift.  It may be more than ntpd is willing to cope with.
<fullermd> I believe the default builds refuse to skew more than 500ppm.
<vila> fullermd: my feeling is that the drift is not constant, so having ntpd *running* may be enough, I'll need a couple of days to be sure though :-/
<fullermd> Naturally.  Checking on problems with time requires time   ;)
<vila> hehe, yeah, non-monotonic time and virtual time help a bit, but not that much here :)
<vila> ha. I have ntp.conf under bzr, I *thought* I was using it at one point... :-/
<vila> ...but since there is a typo in it....
<fullermd> Oooh, somebody made a port of dulwich.
<fullermd> As a side effect of making a hg-git port.  Cute.
<vila> Interesting...
<marccc> good morning
<marccc> i was wondering how i could add revision number and branch in the source when commiting automatically, any qlue's?
<vila> marccc: bzr help version-info
<vila> but putting such infos somewhere when committing is rarely the right thing to do
<marccc> why is that?
<fullermd> It sounds like what you really want is keyword expansion.
<bob2> because it is already visible with bzr version-info
<bob2> it's arguably useful in source tarballs, so hook version-info into your build system
<marccc> true, but i want to export source tarballs
<vila> . o 0 (Thanks guys, you type faster than me ;)
<bob2> so have your 'generate source tarball' script call version-info :)
<bob2> no need to do it on every ommit
 * igc dinner
<marccc> is there a nice way to checkout and create a tarball with a revision number?
<vila> fullermd: Ha, got that message back: calcru: runtime went backwards from 5773628818061961 usec to 4285 usec for pid 12 (intr)
<Adys> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<fullermd> That's a pretty significant jumpback.  Probably corresponds to a big clock step.
<Adys> trying to update loggerhead, any idea how to fix?
<vila> fullermd: as in: ntpd started after some processes and they catch up ? (I have several messages)
<vila> marccc: $ export REV=`bzr version-info --custom --template 'no}' `
<vila> marccc: bzr export ../package-${REV}.tar
<vila> errr
<fullermd> Well, it's basically just a general symptom of time not being monotonically increasing.  ntpd doing a step is one way that could happen (I believe it logs when it steps, and they end up in messages)
<vila> marccc: $ export REV=`bzr version-info --custom --template {revno}' `
<vila> fullermd: ha, yes, I have messages in /var/log/messages now
<thumper> Adys: launchpad doesn't support updates over http
<thumper> Adys: what is the command line you are using?
<vila> fullermd: I don't have an /etc/ntp.conf for FreeBSD7, any idea why ?
<Adys> thumper: nvm, I just branched again
<fullermd> Pre-8, there wasn't one made by default.
<fullermd> 8 added one with pool servers.
<vila> fullermd: great, thanks for confirming, I'll just copy the 8 one
 * fullermd has all the CVS logs in his brain just for questions like that  ;p
<vila> :)
<Zapelius> Could someone point me to a howto, how to convert/merge a 'bzr init':ed repo to a new 'bzr init-repo trunk':d one ?
<fullermd> Zapelius: That question in and of itself doesn't quite make sense...
<fullermd> You can use reconfigure to conver a standalone branch to using an existing shared repo (or vice versa).
<Zapelius> I have a project that I initially
<Zapelius> ... init'ed but that grow a bit too big and now needs several branches
<Zapelius> so I just read that the init-repo would save my HD a bit
<Zapelius> when doing a lot of branches
<bob2> so: bzr init-repo ~/repo/ ; bzr branch /wherver/it/is/now ~/repo/thingo/trunk
<fullermd> That would be one way.  It can lose config though.
<fullermd> Moving the standalone branch in and using reconfigure is probably better.
<Zapelius> I'll look into that. thanks
<ferringb> insane question... anyone looked into doing a caching proxy for bzr?  specifically, I've multiple clients locally accessing the same remote repo, been toying w/ having the clients hit a bzr server first which in turn returns what it has (updating as needs be)
<ferringb> yes it's insane.  yes, I probably could do it via having the share an nfs/remote mount of some sort instead and a bit of trickery
<ferringb> just wondering if anyone has poked around deep enough to comment if it's viable w/ the architecture
<spiv> ferringb: it'd be nice to do, but I don't think anyone has done one.
<ferringb> spiv: anyone looked into it?
<bialix> hi all
<spiv> ferringb: not that I know of
<ferringb> wonder if a lightweight checkout could be bastardized for it
<ferringb> basically do a pull from a bzr server serving a lightweight checkout that caches...
<ferringb> via that, could reuse it's "always connected" design, although I suspect lightweights still have a specific rev bound to the local checkout
<vila> hi bialix
<bialix> hi vila
<bialix> bugfix for hooks really was simple, not sure why you don't try to apply it for 2.0.x series
<bialix> but it was you choice
<vila> wow the series and milestones picture makes sense on https://launchpad.net/bzr ... that wasn't always the case...
<vila> bialix: it's importance is medium, I didn't think it was urgent...
<bialix> I don't understand this
<vila> ?
<bialix> IMO if bugfix is not API break it should got to latest stable release too
<bialix> it seems you guys using different judge here
<vila> The added test may detect bugs in plugins, that's what betas and trunk are for
<bialix> ok, nm
<marccc> vila: thanks
<vila> marccc: ?? export... bzr export... ?
<marccc> bzr export
<vila> marccc: ok, so you don't need any commit hook anymore ? (Just trying to understand if you original need is addressed)
<marccc> yes, but the only thing i need now is the tag
<vila> hmm, version-info doesn't support tag ? Worth filing a bug...
<marccc> lets do that!
<backslash> Hi, we have a bzr repository running on Linux server. There's a weird problem with branching the repo from Win 7. When the bzr branch command is issued an error is returned: bzr: ERROR: [Error 183] Nelze vytvoÃ¸it soubor, kterÃ½ jiÅ¾ existuje: u'C:/Users/Backslash/Work/novawinnona/.bzr/checkout/limbo/new-3/AbsoluteLayout/ ..' -- that non-english part is Unable to create a file which already exists -- what could be the problem? Thanks a lot
<backslash> Strange thing in that error message is the double dot at the end and the slashes in the path while Windows use backslashes ^^
<bialix> backslash: mjst likely in your branch there is 2 files which different only in case, e.g. Foo.txt and foo.txt
<bialix> backslash: most likely in your branch there is 2 files which different only in case, e.g. Foo.txt and foo.txt
<bialix> backslash: or directory
<backslash> bialix but those files are not the AbsoluteLayout direcotory, are they? I'll try to find them under it...
<bialix> you can run qbrowse command for this branch (even on server) and inspect files
<backslash> bialix: thanks a lot, I'll look into it ^^
<bialix> "soubor" means file or directory?
<bialix> what is your language?
<bialix> backslash: ^
<bialix> I see it slavic
<backslash> soubor is file
<backslash> it's actually Czech
<bialix> ah, ok
<GaryvdM> Hi igc
<bialix> backslash: just for the record: bzr.exe v.2.0?
<GaryvdM> igc: I landed the rename/move functionalty into lp:qbzr last night.
<bialix> hi GaryvdM
<GaryvdM> Hi bialix
<backslash> bialix: yes, 2.0
<backslash> bialix, is there a problem with that version?
<bialix> backslash: most likely case name clash
<bialix> backslash: no no no
<backslash> bialix, damn :)
<bialix> IIRC it was "fixed" in bzr 1.0, I just don't remember how exactly it should report this problem to user
<bialix> although error message could be clearer, yes
<backslash> bialix, but why does it output that directory name when you are saying that it can be any file in the repo?
<backslash> bialix, that's what's strange :)
<bialix> backslash: the error comes from deep internals of bzr, from TreeTransform class. This class use special pseudo-names for newly created files/dirs to avoid clash
<bialix> and then on some stage it renames them into your working tree with real names
<bialix> can you show me relevant part of .bzr.log
<bialix> ?
<backslash> bialix, could that be because Windows filesystems cannot store file which paths are longer than 255 chars?
<bialix> the author of TreeTransform is abentley, you can try to catch him several hours later
<bialix> backslash: yes, this is also problem
<backslash> bialix, I'll try to branch it somewhere else.
<bialix> backslash: you can check this easily too, just using shorter base directory
<bialix> e.g. C:\Users\1
<bialix> short enough ;-)
<backslash> bialix, I'll go with C:\Project :)
<bialix> :-)
<bialix> C:\Prj :-D
<backslash> bialix, possibly not, I got the same error with the u'C:/Winnona/.bzr/checkout/limbo/new-3/AbsoluteLayout/ ..' path...
<backslash> bialix, why are  there the two dots at the end ? :)
<bialix> no idea, really
<bialix> there is space before 2 dots, see?
<bialix> pastebin relevant part of .bzr.log please
<backslash> bialix: I know, that is the strangest thing I've ever seen :)
<backslash> bialix, where is the log usually located?
<bialix> run `bzr version` it will show you location
<backslash> bialix: http://pastebin.com/m7fb93aa
<backslash> bialix, that's mostly weird :)
<bialix> backslash: it seems this is exact path u'C:/Winnona/.bzr/checkout/limbo/new-3/AbsoluteLayout/ ..'
<bialix> some file or dir in your branch named as ' ..'
<bialix> is it possible?
<bialix> I suggest using qbrowse to inspect
<backslash> bialix, unlikely :) I'll try to search for it
<bialix> otherwise file a bug and attach that part of .bzr.log
<bialix> something really bad happens
<bialix> also it fails on attempt to create directory
<backslash> bialix: the directory is really there :DDD
<bialix> what?
<backslash> bialix, there really was a directory named ' ..' :)
<bialix> ah
<bialix> how's weird
<bialix> :-)
<backslash> bialix, someone at our team is weird for commiting such directories :)
<bialix> bite him
<bialix> and ask to rename/delete this directory
<bialix> when this directory will gone you can get the branch
<backslash> bialix, thanks a lot for your help :)
<backslash> bialix, the person is already a dead man :)
<bialix> :-)
<bialix> really?
<SamB_XP> meaning you already yelled at him and told him he has to take out the garbage next ?
<SamB_XP> or that his bus number came up?
<Peng> Murder seems a disproportionate response to crappy directory naming... :P
<guilhembi> Unable to load plugin 'gtk'. It requested API version (1, 17, 0) of module <module 'bzrlib' from '/home/mysql_src/logiciels/bzr_versions/bzr.dev/bzrlib/__init__.pyc'> but the minimum exported version is (2, 1, 0), and the maximum is (2, 1, 0)
<guilhembi> after pulling the latest bzr-gtk and bzr.dev.
<guilhembi> It's a bit tiring... such "wrong API version" errors have happened in the past already...
<Peng> 1.17.0? That's not very recent...
<guilhembi> I continue to think that it would be great if the bzr unit tests included a basic test of compatibility with bzr-gtk if bzr-gtk is present; it would catch those bugs before they affect people...
<Peng> The version numbers are more a feature than a bug.
<guilhembi> Peng: ahah, this time it's my "cd plugins/gtk; bzr pull" which didn't work, hence the error;
<guilhembi> regarding feature vs bug, I mean that in the past, someone bumped the API in bzr,
<guilhembi> and that broke bzr-gtk. Whether the fault is in bzr or bzr-gtk,
<guilhembi> a test before push would have avoided spreading this problem to users (several colleagues hit this at Sun).
<vila> guilhembi: but we can't make bzr check for all existing plugins, it has to be the other way around
<guilhembi> vila: it looks natural that the one who does a change does the check too; otherwise, how do you prevent the problem from spreading?
<vila> bumping the API is intended to *avoid* bugs, the check failing early helps
<vila> but the fix has been done in bzr-gtk, if the check wasn't failing how would *you* know you need to update ?
<vila> the problem is not in the plugin nor bzr IMHO, it's a packaging issue
 * bialix_ mutters things will be much simpler with qbzr. :-P
<vila> this is being worked on with the PPAs that provide coherent versions, but then you have to use them
<guilhembi> vila: you remember a certain bug report, where the latest bzr.dev and the latest bzr didn't work together, and it took days to fix;
<vila> guilhembi: yes
<guilhembi> so it means that for some days, things were just unusable for users (they had to revert to older versions, not obvious to remember which one they had before pulling);
<vila> yes
<guilhembi> so, how do you suggest that this doesn't happen anymore.
<guilhembi> ?
<vila> by running automated tests
<vila> this is planned, but not yet implemented
<guilhembi> vila: then I think we are in agreement. Automated with high frequency ("every few days" wouldn't improve the situation).
<vila> Oh I'm sure we agree on the goal :)
<guilhembi> vila: I wasn't sure; I had the impression that you were telling me that everything is right.
<vila> The planned frequency is at least once a day at most once on every commit on bzr.dev
<guilhembi> vila: looks perfect!!
<vila> Sorry for the confusion, I meant the design is right, there are still rough edges for people running bzr.dev and plugins tips
<guilhembi> ok I get it
<vila> http://babune.ladeuil.net:26862/waterfall is where things are at today
<guilhembi> vila: ok... nice... looks similar to buildbot?
<vila> May be because it *is* buildbot :-D Good catch ;)
<guilhembi> ahah
<vila> guilhembi: by the way, your failing pull may be due to bzr-gtk migrating to the 2a format
<Peng> guilhembi: Yeah, what was the error message?
<mthaddon> pqm machine going down for hardware maintenance
<Peng> Fun. What kind of maintenance?
<jam> mthaddon: I'm trying to decide how hard to cheer for that :)
<mthaddon> jam: I'd go with "a little"
<vila> morning jam !
<jam> morning vila
<vila> mthaddon: a little cheer for hardware upgrade to a quad-core CPU !!!
 * vila just loves spreading rumors :)
<mthaddon> vila: just updating firmware I'm afraid
 * vila doesn't always succeed :)
<Peng> Maybe the firmware upgrade unlocks the secret power inherent in the CPU?
<beuno> vila, sometimes they *say* firmware, but they mean "128gb of ram"
<vila> lol
<Peng> Great, now PQM can test 450 patches at once. :D
<vila> james_w: ready for you when you are
<james_w> vila: good timing!
<jcastro> emmajane, about an hour!
<emmajane> jcastro, amber already pinged me. ;)
<emmajane> jcastro, you're late. ;)
<jcastro> heh
<LarstiQ> hour?
<emmajane> LarstiQ, I'm giving a "so you think you want to be an author" talk for Ubuntu Open Week.
<LarstiQ> aah :)
<marccc> ls
<marccc> :-)
<Tak> is it intentional that bzr doesn't handle symlinks to symlinks?
<Tak> hmm, it does handle them somewhat - but a recursive add misses them
<phoenixz> When doing an bzr push while still having uncommitted changes in my WT, bzr errors with bzr: ERROR: Working tree "/home/sven/projects/kloud/" has uncommitted changes (See bzr status). Use --no-strict to force the push...
<phoenixz> Whats the "danger" of pushing whilst still having uncomitted changes?
<Peng> phoenixz: It's just a safeguard, in case you have something you forgot to commit. There's zero "danger".
<phoenixz> Peng: Ah, perfect.. I figured so, but I wanted to be sure :)
<phoenixz> Peng: thanks!
<Peng> :)
<jfroy|work> verterok: pushed my changes for 2.0.2 to lp:~jeanfrancois.roy/+junk/SnowLeopard-package
<phoenixz> If I have a trunk and users A, B, C.. We all work from the trunk, push, pull, merge, etc.. but one day, user A pushes some revisions to user B.. then all continue.. Will there be a problem? Will BZR know that the revisions that B recieved? Will those revisions also end up in the trunk? When A, AFTER the push to B, pushes to the trunk again, will the same changes sent to B also be sent to the trunk again? Will BZR know what changes B already received from A
<phoenixz>  by means of the trunk? how does this work?
<ferringb> phoenixz: revs commited to a branch are uniquely identified, and are handled accordingly
<ferringb> phoenixz: iow, a -> b, a -> trunk, b -> trunk, will work as you'd expect
<phoenixz> ferringb: sooo.. if A pushes its own rev 5 to B, that same rev will also be sent to trunk when pushing there, correct?
<ferringb> yes.
<phoenixz> ferringb: and then when B pulls from the trunk, it will not again receive that revA5, because it already has it..
<ferringb> yep
<phoenixz> perfect, perfect...
<ferringb> yes'm.
<mwhudson> hmm!
<mwhudson> commit just failed for me
<mwhudson> aborting commit write group: AssertionError("deserialise should be called with a StaticTuple not <type 'tuple'>",)
<mwhudson> happens with no-plugins too
<mwhudson> seems something of a regression......
<mwhudson> jam: here?
<mwhudson> seems to only happen on committing a merge
<mwhudson> and a trivial test case doesn't reproduce
<mwhudson> bah :(
<lifeless> mwhudson: file a bug
<mwhudson> lifeless: yeah will do
<lifeless> some fallout expected
<lifeless> releases will disable this with a flag to enable it
<lifeless> trunk will continue to die die die
<mwhudson> hm
<mwhudson> bzr.dev actually committed it ok
<jam> mwhudson: that should be a bugfix from: 4671 Canonical.com Patch Queue Manager 2009-11-02 [merge]
<jam>      (jam) Fix bug #471193, make chk_map type checking less strict.
<jam> in 2.1.0b2
<jam> which should be merged into bzr.dev
<ubottu> Launchpad bug 471193 in bzr "StaticTuple failure while pulling from bzr+ssh" [Critical,Fix released] https://launchpad.net/bugs/471193
<jam> bzr.dev 4782:
<mwhudson> jam: ah ok
<jam> 4782 Canonical.com Patch Queue Manager 2009-11-03 [merge]
<jam>      (jam) Merge 2.1.0b2 (-final) to bzr.dev
<mwhudson> i guess the ppa is a little out of date
<jam> mwhudson: nightlies?
<mwhudson> jam: yeah, i think so
<jam> mwhudson: btw, is this a commit of a merge in a heavy checkout?
<mwhudson> jam: no, lightweight
<jam> hmm...
<jam> anyway, should still be fixed
<jam> though I should figure out why it is happening there
<mwhudson> yeah, seems to be
<mwhudson> jam: want the crash file?
<jam> I *want* to have strict type checking, but I need to track down the code that is introducing it
<jam> mwhudson: sure
<lifeless> jam: interesting, StaticTuple broke bzr-search
<lifeless> s/g,/gly,/
<mwhudson> jam: http://pastebin.ubuntu.com/308926/
<lifeless> jam: suggestions were printing the result keys out and they because StaticTuples
<jam> lifeless: yeah, I saw your patch there
<jam> though your code was assuming the form for 'repr()' of keys
<lifeless> yes ;)
<jam> mwhudson: what really surprises me about the bug, is that I've been running bzr.dev with the chk_map strict type checking for a while, and didn't encounter any problems until the day of release
<jam> which is when I relaxed the type checking
<jam> anyway, off to pick up the little boy
<jam> have a good night
<lifeless> never underestimate the power of users
<poolie> hi jam
#bzr 2009-11-04
<maxb> How do I run the bzr-fastimport testsuite?
<lifeless> bzr selftest fastimport
<maxb> Ah, there's no such thing as running in the source tree? It only runs as part of a bzr installation?
<lifeless> maxb: ./bzr selftest fastimport
<lifeless> :)
<maxb> mhm. Not if you're in a branch of fastimport itself
<lifeless> maxb: so, the plugin has to be loaded to get at the tests
<lifeless> you can symlink it into a bzr source tree, if you want to test with an uninstalled bzr
<lifeless> (or just run that bzr)
<maxb> I guess hacking on it in ~/.bazaar/plugins/fastimport isn't a silly idea, then?
<lifeless> but the plugin needs to be discoverable to '$bzr plugins'
<lifeless> maxb: I have a symlink from ~/.bazaar/plugins/PLUGIN to ~/source/bzr/plugins/PLUGIN/working
<lifeless> maxb: where working is a lightweight checkout of whatever branch of the PLUGIN i'm currently hacking on/using
<igc> morning
<lifeless> igc: Just!
<igc> lifeless: it's still 11am here :-)
<sven_oostenbrink> So I use bzr now for one project. I have one central repo that I use as trunk, three developers have branches from that one.. Now, first I want to tag a certain version, but thats where bzr eludes me a little.. I can not have a trunk, since thats just another branch, but I can have tags?
<sven_oostenbrink> how does this work exactly?
<lifeless> you can tag a commit
<lifeless> or you can add a new branch
<lifeless> both wors
<sven_oostenbrink> then another question.. I have another project, B, which is based on my current project, A.. so I think, I make a brach of A, called B, and all developers can just sub-branch B to work locally, for them, B will be the trunk of project B... whenever there are changes in B that are interresting for A, I can push them from B to A and if there are ever interresting changes for B in A, I can just push these changes from A to B..  Is this reasoning
<sven_oostenbrink>  correct, or am I just plain silly here?
<sven_oostenbrink> lifeless: tag a commit? you mean tag a revision?
<lifeless> yes
<lifeless> your second questions reasoning is fine
<sven_oostenbrink> lifeless: so I could also just do something like bzr push trunk file://tag0.1.0 or something?
<sven_oostenbrink> and that then, would be a tag?
<sven_oostenbrink> lifeless: But whats the difference, when I bzr tag, the tags are like a revision or somehting?
<lifeless> tags are metadata within a branch
<lifeless> branches are branches
 * spiv -> food
 * igc lunch
<poolie> igc, want to talk when you're back?
<mneptok>  /m poolie i is sexy hots American booblady. you makes to chats me now!?
 * poolie puts on his wizard hat and cloak
<ferringb> -.^
<igc> poolie: sure
<poolie> 1m
<MTecknology> How can I make something like lp: ?
<spiv> MTecknology: write a plugin that implements a "directory service"
<MTecknology> that sounds kinda sucky to do...
<spiv> MTecknology: see bzrlib.directory_service, and of course the implementation of bzrlib.plugins.launchpad
<spiv> MTecknology: it's not so hard, IIRC
<MTecknology> spiv: I just don't want to need to type "bzr+ssh://bzr.server.com/bzr/" all the time
<MTecknology> I want to run my own LP server but I don't have the hardware for it...
<lifeless> MTecknology: install bzr-bookmarks, create an alias
<spiv> MTecknology: echo export MYREPO=bzr+ssh://bzr.server.com/bzr/ >> ~/.bashrc  ;)
<lifeless> MTecknology: or write a small directory service plugin as spiv says
<lifeless> its really quite easy
<MTecknology> thanks :)
<MTecknology> I like the export idea except for needing $MYREPO
<MTecknology> I'll try out the directory service idea
<spiv> Look at bzrlib/tests/test_directory_service.py perhaps, it should show you how to make a pretty simple service, because that's what the unit tests do :)
<MTecknology> spiv: aside from no understanding of python and that looking like a lot of code; I also have no idea how to impliment it :P
<spiv> MTecknology: it's just the lines 26 to 30 of that file, plus the call to bzrlib.directory_service.directories.register
<spiv> (that file == http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/bzrlib/tests/test_directory_service.py)
<spiv> Put that plus the imports into ~/.bazaar/plugins/my_directory_service.py and you're practically done.
<MTecknology> spiv: thanks
<MTecknology> no
<MTecknology> s/no// wrong chan
<igc> bbl
<vila> hi all
<vila> bah, babune failure of the day: doctests are not properly isolated, setting 'debug_flags = static_tuple' in bazaar.conf makes one of them fail....
<vila> Failed doctest test for bzrlib.branchbuilder.BranchBuilder
<lifeless> vila: doctests; enough said
<fullermd> I "corrected" a whole bunch of doctests in that DWIM thing.  I think most of them were totally useless.
<fullermd> (I mean, even before, they were pretty lightweight, but after the change....   utterly pointless)
 * vila whistles
<vila> Hmm, not sure if whistling carries the same meaning as in French, which in that case would be around: "Hey, I don't like doctest much myself, but I said nothing...." :-D
<vila> I mean, I agree with many intents of doctest, but the implementation is too brittle and this is one more example...
<vila> On the other hand, a single slave failed here, the one that is not properly isolated itself (it uses *my* bazaar.conf), and that's what I will fix first :)
<fullermd> So, you're saying doctests aren't the problem, vila is?   :p
<vila> hehe. no I'm saying there is one problem and at least three fixes, all needed :-D
<fullermd> vila: How goes timekeeping?
<vila> fullermd: weirdly
<vila> freebsd7 did a reset this morning, I dunno if it's related (in fact I didn't know that could happen without me noticing...)
<vila> both 7 and 8 says ~10:00AM when it's 10:29...
<vila> so time is still drifting, less, but still
<fullermd> ntpd give up?
<vila> I was about to search a bit the ntpd period of updates, but may be you already know that ? :-D
<vila> hmm, let me look the logs
<fullermd> Well, the poll period steps back at powers of two.  The default range starts at 16s and goes up to 1024 as it learns the system.
<fullermd> But there's no way it should be 29 minutes off unless it gave up on sync'ing.
<vila> nothing eye-catching for 7
<fullermd> What does the peer list tell you?
<fullermd> That should gives you the poll frequency, as well as the offset.
<vila> ntpq -p doesn't specify units, let me see...
<vila> poll is 64 for both 7 and 8
<fullermd> Poll frequencies are on seconds, delay and offset in ms.
<vila> delays are in 6 to 12 range, offsets are in the 300.000-500.000 range
<vila> err, no 5.000.000 for 7 !
<vila> gha and 3.000.000 for 8 sry
<fullermd> 5 million ms = 5 thousand seconds = 83 minutes.
<fullermd> That's a "screwit" sign.
<vila> grrr, I can't read these damn things ! 364481. for 8 that's 300.00 the trailing period tricked me
<vila> in the 8 logs I have: Nov  4 08:20:10 freebsd8 ntpd[766]: time reset +20146.933261 s
<vila> Nov  4 08:20:10 freebsd8 ntpd[766]: kernel time sync status change 6001
<vila> Nov  4 08:21:00 freebsd8 ntpd[766]: kernel time sync status change 2001
<vila> so, hmm, looks like it doesn't update frequently enough
<fullermd> The 6001/2001 messages are flipping between FLL and PLL mode (which ntpd flips on at the 512/1024s polling interval boundary)
<fullermd> It sounds like the drift is just more than ntpd will accept.
<fullermd> Ah, I'm off, 64s is the default minimal poll frequency.
<fullermd> So, yeah, it just never gets past trying to initial sync up.
<vila> And what is the option to get around that ?
<fullermd> Isn't one, really.  I kinda expected it, from the size of the offsets you were talking about yesterday.
<vila> Or should I just call ntpdate in a cron ? :-/
<fullermd> Really, the solution is to figure out WTF it's so far off from reality, which is probably something to do with VB.
<vila> wow,  4 Nov 10:10:51 ntpdate[1007]: no servers can be used, exiting
<fullermd> cron'ing a ntpdate every stupidly often (like 5 minutes) is an ugly brute-force solution, but may be your best shot.
<vila> Does that clearly says ntpd gave off ?
<fullermd> That's from ntpdate, not ntpd.
<vila> ntpdate 0.fr.pool.ntp.org
<vila>  4 Nov 10:11:46 ntpdate[1025]: the NTP socket is in use, exiting
<fullermd> You can't run ntpdate while you're running ntpd.
<bob2> don't cross the streams.
<fullermd> Mmm, marshmallows...
<vila> Ho, so revert the ntpd and cron the ntpdate is what you suggest ?
<vila> Otherwis, yes, VB is clearly the culprit, the log file is filled by messages about that, the bug is known and working on
<fullermd> Well, I'd suggest tracking and solving the problem.  But that takes time and energy, so it's probably not leading your todo list.
<vila> some incomplete fix in 3.0.10 made things worse for me, that's why I'm searching for a work-around from *inside* the slaves
<fullermd> Brute force should always work, if enough is used   :p
<vila> VB is still working on the bug but I dunno when that will come it could be 3.0.12 or 4.0.... nothing in the coming *month* at least (if past releases are an indication for the schedule)
<fullermd> Whether anything will freak out when the clock starts jumping around all the time...  well, we'll find out when we find out.
<vila> 23:58:57.284 TM: Giving up catch-up attempt at a 60 001 205 850 ns lag; new total: 20 580 677 930 084 ns
<vila> is the kind of message in the VB logs :)
<vila> TM probably refers to Time Manag{er,ing,ement}
<fullermd> I get creeped out when my time is more than 10ms off, and have it in my long-term plans to get a good disciplined OXCO in the lab with a clean PPS input to the system to cut an order of magnitude or two off that error   :p
<fullermd> Obviously, I'm slightly more anal than average...
 * vila notes to self: mail forward the VB logs to fullermd every morning
<fullermd> (Soekris 4501's are notoriously excellent for that, since you can use the GPIO pins to get the PPS signal into the OS with much less latency and jitter than using a RS232 port like you do on 'normal' systems)
<vila> You do that just for fun or you have a valid reason for it ? Hard real-time constraints or ?
<fullermd> Well...   I guess you could say "fun".
<fullermd> More like "I'm an obsessive person and I can't stand when things are WRONG".  So it's not necessarily _fun_ per se...
<vila> But how do you even know you're off by 10ms ?
<vila> and off comparing to what ?
<vila> may be you're right and *they* are off !
<fullermd> Well, now we get into definitions.  But I run a diverse set of peers (many of which I run, and in turn deal with a different diverse set of peers), which track back to CDMA and GPS sources.  All of which, through offsets etc, should track back to TAI.
<fullermd> If you don't get all uppity about the difference beween GPS time and TAI and UT0 and UT1 and UTC, you probably don't care   :p
<vila> wow, wow, not so fast, CDMA and GPS, I roughly understand, TAI is ?
<fullermd> Temps Atomique International
<vila> Haaaa, now you're talking French :)
<fullermd> Hey, I didn't make the acronym   :p
<fullermd> (and don't even get me STARTED on the insanity of defining POSIX time_t...)
<vila> Right, ok, so you're not *that* obsessive, your reality requires you to be precise :)
<fullermd> Well, any time scale is arbitrary, since you have to pick a point in time to declare the second boundary (and that's even before you consider how relativity destroys the concept anyway)
<fullermd> But any point is as good as any other for most purposes, as long as it's widely agreed on.  TAI fills that role.
<fullermd> Why yes, I DO hang out on mailing lists with people who take one of a match pair of cesium beam clocks on vacation into the mountains with them to demonstrate relativity; why do you ask?   :p
<vila> damn it restarting ntpd fixed time on 7 but not on 8 :-/
<fullermd> It probably didn't fix it, it just did its initial step.  Now it'll start slipping into the future.
<vila> and it knows about not doing its intial step too often ? Even across reboots ?
<vila> On the overall, I feel better knowing you *had* to know the details about ntpd more than me :-D
<fullermd> It only does the initial step as a first sync when it starts.
<vila> So starting it should provides me a "correct" time, it doesn't here
<fullermd> Past that it slews, or makes tiny steps.  If it drifts faster than some arbitrary amount, ntpd won't touch it (and it sounds like you've in that position)
<vila> /etc/rc.d/ntpd restart
<vila> is what I did (repeatedly even)
<fullermd> Well, don't do it so much; it doesn't happen for some time after it starts.
<fullermd> 's one of the reasons ntpd's "sync once and exit" mode is never going to be a replacement for ntpdate; there's a need for a quick, synchronous syncup, even if it lacks quite the precision of a longer baseline.
<vila> so, given I'm using a VM with no precision, ntpd is the wrong tool, right ?
<bialix> heya all, vila, fullermd
<vila> morning bialix
 * bialix likes what fullermd wrote about the process of inclusion patches and railroad
<bialix> bonjour vila
<fullermd> Yeah, without serious hacking (or possibly much more config than I know how offhand to do on it), ntpd won't handle the situation you're in.
<bialix> poolie1: I think I deserve your pun about "care about windows". vila teaching me to shut up
<fullermd> It's possible dropping the minpoll interval will give it enough oomph to make things happen.  But that would be real unfriendly unless you're pointing at your own local ntp servers.  And it's still questionable that it would work.
<vila> But isn't using ntpdate unfriendly too then ?
<fullermd> Well, dropping the minpool means every 16 seconds.
<vila> yeah and I can survive with an ntpdate every hour I think
<fullermd> ntpdate every 5 minutes isn't near that bad.  It's only 3x as often as the standard ntpd ceiling of 1024s polling interval.
<fullermd> I'd try something like 10 or 15 minutes.  That's rarely enough-ish, and will leave you with smaller steps each time, which is more likely to slide under the radar of running apps.
<fullermd> (of course, 'd be as good or better to have a local ntp server of course, but...)
<vila> hey, the only app running is bzr selftest and time should always go forward and tests shouldn't be time sensitive, what could go wrong (famous last words :-)
<vila> local ntp server may be an option though....
<fullermd> Probably wouldn't change anything materially, but is nicer to the net at large, and may let you experiment with more drastic usage of it.
<fullermd> I consider a local ntp server to be like a local DNS server; every subnet should have one.
<vila> hmm, looks like I *already* have one ntp server... at least ntpdate is happy to use it
<vila> fullermd: so, I'll try with 'server saw.local iburst minpoll 4 maxpoll 9' in ntp.conf and see
<vila> fullermd: sounds correct ?
<Peng> Ooh, time nerding! /me reads backlog.
<vila> fullermd: well, 'minpoll 1' seems accepted by a restart even if the doc says 4 is the minimum, I'll try that
<fullermd> I'd do burst as well as iburst.  But yah, that sounds like a plan.
<fullermd> (burst won't help if it can't keep up without it, it'll just do a bit better if it DOES keep up)
 * fullermd is a reliable source for nerdery   :p
<Mez> hmm, bzr gannotate is telling me a file isn't version3ed, but it is.
<lifeless> vila: /419776
<lifeless> vila: bug 419776
<ubottu> Launchpad bug 419776 in bzr "selftest --subunit output incompatible with --parallel=fork" [Medium,In progress] https://launchpad.net/bugs/419776
<Mez> also, how do I get the nautlius extensions working?
<vila> lifeless: I'm waiting for your subunit protocol change to land. Why the ping ?
<lifeless> vila: oh thats right
<lifeless> don't wait on subunit
<vila> should I un-assign myself and revert to confirmed ?
<lifeless> whats the remaining defect
<lifeless> just 'automtimingdecorator degrades ExpectedFailure' ?
<lifeless> vila: if you subclass AutoTimingDecorator
<vila> not sure exactly about the *cause* but the effect is to produce failures for expected failures IIRC
<lifeless> and add an addExpectedFailure method, as per subunits addFailureMethod, does it work?
<lifeless> ah here it is
<lifeless> timing -> hooked -> decorator
<lifeless> return self._call_maybe("addExpectedFailure", self.decorated.addFailure, test, err)
<lifeless> subunit 0.0.2 doesn't know how to serialise xfail
<lifeless> though it can parse it
<lifeless> [long story]
<lifeless> in 0.0.2 xfail -> failure in the case of a missing method
<lifeless> in 0.0.3 xfail -> success
<lifeless> so
<lifeless> class BzrAutoTimingDecorator
<lifeless> def addExpectedFailure(self, test, err):
<lifeless>     self._before_event()
<lifeless> return self._call_maybe("addExpectedFailure", self._degrade_skip, test, err)
<vila> i.e. introducing a new class in bzr until your subunit protocol lands ?
<lifeless> should fix it, for subunit 0.0.2, at the cost of not supporting the details API, which is not in 0.0.3 yet anyhow, and which degrades well anyhow.
<lifeless> we can cater for that later
<vila> lifeless: http://paste.ubuntu.com/309377/ is what you meant ?
<vila> it seems to work here and I can understand why, at least
<lifeless> the lambda x:x was gine
<lifeless> *ine*
<lifeless> *fine*
<vila> as a base class ?
<lifeless> as the final value
<lifeless> do the definition in the try:
<lifeless> what you've written won't work if subunit is absent
<lifeless> you'd need __new__ not __init__
<lifeless> which is uglier than a lambda
<vila> oh yes, of course
<vila> lifeless: shouldn't HookedTestResultDecorator define _before_event ?
<lifeless> no
<lifeless> its an ABC
<lifeless> thats why you subclass subunit.test_results.Autotiming...
<vila> I can see that, but why not being explicit and make it raise NotImplementedError is what I meant
<lifeless> 'meh'
<lifeless> small contract
<lifeless> reasonable docs
<lifeless> not like e.g. repository in size
<vila> ok, I just thought the idiom was agreed upon, no worries
<lifeless> well, for bzr yes :)
<lifeless> I'm more lassez-faire in other situations
<vila> hehe, yeah, having python on the bzr code base doesn't help me there :)
<vila> hehe, yeah, having learned python on the bzr code base doesn't help me there :)
<lifeless> so as I say, small contract
<lifeless> if it was a bigger API and this was an optional thing that you might not encounter for a bit, it would be another matter
<lifeless> but you can't use a subclass at all until its implemented so its pretty obvious
<vila> yeah, on the other hand, it's only two lines and you can then forget about it whatever happen later :-D
<lifeless> 2 lines and a test
<vila> but no problem, I was just wondering if it was deliberate or not, I'm happy either way
<lifeless> deliberate decision
<vila> you meant: a test and 2 lines :-P
<lifeless> oh wow
<lifeless> http://lab.arc90.com/experiments/readability
<lifeless> anyhow, I'm glad you've got it working
<lifeless> toss it up for review if you like
<lifeless> gnight
<vila> lifeless: waiting for lp to update my pushed branch before clicking propose for merging :)
<vila> done
<vila> https://code.edge.launchpad.net/~vila/bzr/419776-subunit/+merge/14413
<johnf1> how do you remove  a branch from inside a shared repo? do you just rm it and there is some sort of grabage collection later?
<lifeless> rm, gc will be implemented some day
<johnf1> lifeless: Am I correct in thinking that a few weeks ago you where sugesting we should upload the beta releases into debian?
<lifeless> yes
<lifeless> talk to me tomorrow though, ESLEEP
<johnf1> ok
<johnf1> will upload 2.0.2 for now
<jam> morning all
<abentley> jam: Good morning.
<jam> hey aaron, haven't said Hi to you in a while
<jam> Getting ready to fly to AU?
<abentley> True.  Not really getting ready yet.  I'll start that tomorrow.
<abentley> But yeah, we
<abentley> 'll be saying hi in person really soon.
 * mtaylor getting oops
<mtaylor> AssertionError: second push failed to complete a fetch set([('inventories', 'mordred@inaugust.com-20091103224655-9f5d1vgb4alj11vi'), ('inventories', 'mordred@inaugust.com-20091103213736-nu2owzobdp73t6h8'), ('inventories', 'mordred@inaugust.com-20091103222806-e2ta52lskoqvfhrz'), ('inventories', 'mordred@inaugust.com-20091103214523-pxwopxc4tuasn4ul'), ('inventories', 'mordred@inaugust.com-20091102171023-wm0v26gdzzutxxzg'), ('inventories', 'mordred@inau
<mtaylor> gust.com-20091103212344-3esgm3d5rnhvia2t'), ('inventories', 'mordred@inaugust.com-20091027224205-4yirn3hveb1zma5k'), ('inventories', 'mordred@inaugust.com-20091103220723-4xhq2frowehfes2n'), ('inventories', 'mordred@inaugust.com-20091027181920-mcf0d5zyf9tptghn')]).
<mtaylor> of course - this was during a pull operation, so "second push" seems like an odd message there
<mtaylor> bzr 2.0.1 on python 2.4.4 (Solaris-2.10-sun4v-sparc-32bit)
<mtaylor> fwiw
<mtaylor> ooh. looks like it's fixed in trunk
 * mtaylor withdraws all above statements
<jam> mtaylor: should be fixed in 2.0.2 as well
<mtaylor> jam: awesome
<tsmith> I have an SVN project.  I want to commit locally to bzr and then, when I'm ready, pull changes from and commit changes back to the svn.  I want to create several bzr branches against this svn repo. What should i do when initially checking out the svn?
<corp186> what is the bzr export --filters option, and how do I use it?
<luks> tsmith: nothing special compared to when working with a native bzr project
<luks> in this case, it sounds like you want bzr branch/pull/push
<lifeless> jelmer: https://edge.launchpad.net/~cjwatson/bzr-cia/server-side/+merge/14057 claims the merge hasn't landed
<Tak> tsmith: more specifically than `bzr branch svn://foo/bar` ?
<tsmith> Tak, some guy in here was saying how he did bzr init or something
<tsmith> bzr init then bzr branch or something
<Tak> probably `bzr init --rich-root-pack`
<Tak> or similar
<jelmer> lifeless: yeah, that's actually correct
<jelmer> lifeless:  I should note that in the merge request
<jelmer> lifeless: nevermind, seems I already did
<lifeless> jelmer: you did?
<lifeless> status is still 'needs review'
<lifeless> jelmer: ^
<jelmer> lifeless: reviewed
<lifeless> jelmer: you might like to change the review status too
<lifeless> jelmer: I don't have access to do that
<bialix> hello jam
<bialix> is there any problems with 2.0.2 installer for windows?
<jelmer> lifeless: done
<jelmer> lifeless: I'm still a bit uncomfortable marking something "reject" if I really mean "resubmit"
<lifeless> jelmer: isn't there 'in development'
<lifeless> jelmer: work in progress
<lifeless> jelmer: is what you should change it to
<eydaimon> I've got a conflict where a couple of files got deleted. I want to resolve the conflict sot hat the files do not get deleted
<eydaimon> how can I do that?
<spiv> eydaimon: "bzr revert filename1 filename2"
<eydaimon> spiv: what about when I merge next time? will those files not get deleted again?
<spiv> Correct.
<eydaimon> thanks
<jam> bialix: I'm waiting on igc to build the chm documentation
<jam> otherwise, I don't know of any problems
<bialix> ok, thanks
<bialix> there is not so much changes since 2.0.1
<eydaimon> http://pastie.org/684067  why aren't they merging here? (I was going to try out what spiv said just to verify)
<eydaimon> oh, coz it's a checkout, not a clone
<poolie> hello
<jam> poolie: hi
<jam> Hey, it looks like I'm not able to save a snapshot of an EC2 instance to the S3 store.
<jam> I'm guessing I need a separate set of S3 credentials to do that.
<jam> Which means that when I 'stopped' a running instance, I couldn't start it again
<jam> and I had to "launch a new one"
<jam> which meant all my state was definitively lost
<jam> anyway, I'm still hoping to get EC2 working, but I'm sort of at a stalled point.
<jam> Also, I'm waiting on igc to get the new documentation built, so I can build the win32 installers, so I can announce the new release.
<poolie> jam, hm, i don't see what other credentials you would need beyond what i had
<jam> poolie: If I try to save to "ec2.sourcefrog.net" it says I don't have access
<poolie> oh ok
<jam> I have an account id but not an email address, etc
<poolie> but you could create a new bucket and save it there?
<jam> poolie probably, if I signed up for S3 and gave Amazon a CC
<jam> I've been avoiding that so far
<poolie> no, i mean within this single account
<poolie> you can't share this stuff across accounts
<jam> So I guess... I don't really know
<poolie> ok
<jam> I've looked at the S3 stuff, to try and figure out how to create a new buckte
<poolie> so
<jam> but that looks like I need a *separate* set of credentials
<poolie> thanks for letting me know that you were blocked
<poolie> i was actually wondering this morning what to do next
<poolie> i've felt a bit in the weeds as far as responding to a bunch of little things
<jam> Trying to use S3 Firefox Organizer, "Create Bucket" fails with "unable to connect to server"
<jam> that may be the plugin issue
<jam> or may be any of a bunch of things
<jam> I wanted to test if writing stuff to D, then taking a new snapshot
<jam> really nukes the D directory on restore
<jam> so we know whether we *have* to mount things via the Elastic Block Store
<jam> (it is recommended, but the Postgres image has everything installed on C so you are 'up-and-running' easily)
<jam> But they have VS 2008 Express, not Standard or Professional
<jam> anyway, I switched to other things
<jam> so if you want to spend time, #1 is getting the docs built so I can get the release announced
<jam> #2 is playing with EC2
<poolie> ok
<poolie> and vs express is not enough, right?
<jam> btw, I worked on Windows glob expansion, and it took about 2 hours to implement.
<poolie> oh nice one
<jam> poolie: express doesn't have atl which is needed for tbzr dll
<poolie> i worked a bit on ec2 last night, and then i think got interrupted
<jam> until naoki teaches us the secret
<poolie> k :)
<poolie> you could ping him?
<jam> anyway, I need to get going
<poolie> or we could build that separately, if it's rarely used?
<jam> I'll try to get ahold of him
<poolie> ok, thanks for letting me know
<poolie> i'll do the docs first, then poke at ec2 and tell you how it goes, then have a think about what to do next
<jam> poolie: I think we are pretty close, and the apis look sufficient that we could probably leave the instance stopped most of the time
<jam> and just cron to spin it up, and then run the buildbot tests
<jam> and spin up a second instance when I need to build installers manually, etc.
<poolie> mm
<poolie> it looks like about 10m to spin u
<poolie> up
<jam> yeah, fairly long
<jam> but not something you would notice in the 3-hours it takes to get stuff done
<poolie> but it's feasible as "ok today i'm going to do installers" then it'll be ready when you get to it
<poolie> right
<poolie> i think that ties in too to which disk things are installed on
<poolie> anyhow, the basic idea was that we would all share one account
<jam> I could spin it up at "gone gold" time, and then spin it down once we actually released
<jam> yeah, so far the one-account seems to be working for me
<jam> just S3 and buckets are being weird
<poolie> you creating your own wouldn't help because there's basically no way to share things between accounts except by making them totally pubilc
<jam> ok, really gone now :)
<poolie> k
<poolie> how about you today, spiv?
<CoffeeIV> does "bzr revert -r NNN filename" do anything in the repository, or just in my local copy ?
<lifeless> local
<CoffeeIV> ok, thanks
<spiv> poolie: working on full writeup of those stories, and breaking them down into smaller pieces/goals.
<poolie> sounds good
<poolie> can you please put some agenda items onto the sprint page too?
<spiv> Ok, will take a look
<eydaimon> would is a lost word
<maxb> Ouchie... 8 minutes just for bzr-fastimport to update 33 branches *after* importing all the revisions
#bzr 2009-11-05
<cr3> how can I create a branch from a previous revision? I tried bzr revert -r### and then bzr push'ing that code, but the pushed code contain the same as the trunk
<poolie> cr3: bzr branch -r1234 . ../other
<poolie> igc, do you think we still want the non-sphinx doc builds?
<poolie> i'm working on this atm
<cr3> poolie: excellent, thanks!
<lifeless> cr3: if you want to push something somewhere, push -r xyz URL
<poolie> igc: sphinx build seems to be passing in the chroot now
<poolie> output not copied yet
<poolie> thwack- well up to the point of wanting pdflatex
<igc> poolie: I don't see a need for non-sphinx builds
<poolie> k
<meoblast001> would it be hard for me to modify bazaar to only let me uncommit twice daily?
<lifeless> not at all
<lifeless> write a plugin, decorate the command
<meoblast001> lifeless: ok, i need to make it hard for me to find a way around it
<meoblast001> i'm struggling with a mental condition
<meoblast001> and after reading an article, i figured out that i need to limit how many times i can repeat operations in order to fix the condition
<maredzek> hi i have a very basic question, i would like to use bzr for managing my symofny project, it is now on local, i want to push it to my sftp server, do i have to do anything on my server? like installing bazaar?
<jelmer> maredzek: to push using sftp you just need a sftp-capable ssh server
<jelmer> maredzek: no bzr server is necessary on the server side
<maredzek> ok i have one, i used:
<maredzek> arek@marek-laptop:/var/www/fakt$ bzr push --create-prefix sftp://admin@91.121.177.88/var/www/ble --use-existing-dir
<maredzek> but apart from .bzr dir i cannot see anthing in /var/www/ble....
<jelmer> maredzek: it will just create a branch, not a working tree
 * maxb wonders if anyone else has used bzr qlog on branches with 10000 revisions before
<jelmer> maredzek: yes
<maxb> It appears to trim revnos to 4 digits :-)
<jelmer> s/maredzek/maxb/
<jelmer> maxb: IIRC there is an open bug about that
<maredzek> how can i upload "working tree"?
<jelmer> maredzek: you can either run 'bzr co' on the remote side (will create a working tree, but required bzr to be installed)
<jelmer> maredzek: or you can avoid push and use the 'bzr-upload' plugin
<jelmer> maredzek: that will just upload the contents, not any of the history
<spiv> maredzek: if you want just the tree and not the history, e.g. to publish a website, then the bzr-upload plugin jelmer mentions is probably a better fit
<maredzek> ok, so if i will have 3 people working on this project, it is better to use bazaar on remote side?
<maredzek> what will happen if:
<maredzek> there is a file action.class.php already on sftp server, commited with bzr-upload
<maredzek> then devA adds two funstions in this file and uploads
 * maxb can't find a qbzr bug for that
<maredzek> hwo devB coulc know that somebody modified that file?
<maredzek> ok, dont answer that
<maredzek> i would like to have smth like my launchapd
<maredzek> i have to isntall bzr on server
<maredzek> and init projects
<maredzek> and also i need to install bzr on clients
<maredzek> and checkout and commit from them right?
<maredzek> how can i install bazar upload?
<spiv> maredzek: if you are using ubuntu, you can just apt-get install bzr-upload
<spiv> maredzek: http://doc.bazaar-vcs.org/test/en/user-guide/plugins.html
<maredzek> ok so my quewstion, how should i use bazaar if i have a couple of developers, working now remotely on clients server
<poolie> igc: ok i think it's all running aside from pdf generation which is waiting on a gsa
<poolie> maredzek: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
<poolie> igc, i'm going out to run an errand and then will look for breakage (which likely exists) when i get back
<poolie> pdfs are rt 36401 btw
<meoblast001> lifeless: is it possible to completely remove the uncommit feature from bazaar?
<meoblast001> as long as repeating things is possible, i'll be stuck in an infinite loop
<lifeless> meoblast001: sure, a plugin could do that
<meoblast001> lifeless: i need something that is very hard to disable
<meoblast001> i'm fighting myself here, so i need to outsmart myself
<lifeless> meoblast001: sorry, can't really help you there - seriously.
<meoblast001> i'll try to find something out
<lifeless> bzr --no-plugins will disable plugins
<lifeless> apt-get install will restore a base bzr with the feature present
<meoblast001> lifeless: maybe i just need to see a psychologist or suck it up and figure things out myself
<spiv> meoblast001: maybe something less drastic than total removal would help, e.g. make uncommit trigger an annoying buzz sound?
<spiv> meoblast001: anyhow, writing a plugin is probably going to be the best way to do any of these options.
<meoblast001> spiv: that won't work
<meoblast001> i'm trying to fight OCD (repetitive things) and it can get very bad
<meoblast001> luckily i don't have a severe case, some people do things for hours on end
<meoblast001> i can just sit uncommitting and recommitting multiple times until i have to hit myself
<meoblast001> but a buzzing sound won't stop me
<lifeless> meoblast001: so, if I thought I had something wrong with me, I'd go see a doctor ;)
<meoblast001> i need to make it impossible
<meoblast001> lifeless: but you're not a dependent
<maredzek> i dont completely understand Distributed development
<maredzek> can you confirm is it corrct?
<maredzek> 1. on main server
<spiv> maredzek: in the user guide?
<maredzek> spiv - yup:
<maredzek> 1. on main server - i create bzr with init
<maredzek> add and commit
<maredzek> right?
<spiv> maredzek: it doesn't really matter how you create the branch on the server
<maredzek> ok, so next
<spiv> maredzek: it's probably simplest to create it locally and then 'bzr push' it to the server
<maredzek> ok
<maredzek> but when i push to server - server needs to have bzr right?
<spiv> maredzek: nope
<spiv> maredzek: you can use plain SFTP, for instance.
<maredzek> ok but when i tried to push files from my machine to my server, only .bzr folder was created
<maredzek> no files were pushed
<spiv> Right.
<maredzek> and i need to use uplaod plugin
<maredzek> so if i create file slocally and push to server, i will have no files in it - right?
<spiv> Because 'bzr push' pushes a branch, which is a line of development.  But it sounds like you want/need the tree of files on the server.
<maredzek> hmmm
<maredzek> i'm starting to understand
<spiv> Operations to do with branches and operations to do with trees of files are mostly separate things.
<maredzek> so i will have 3 developers
<maredzek> they will work on php framework - symfony
<maredzek> they will have thoose installed locally
<spiv> Some operations involve both, e.g. "bzr commit" takes the current tree and records that as a new version on a branch.  But mostly they are separate concepts.
<maredzek> so tell me, how files will travel between developers?
<maredzek> via central server?
<maredzek> or directly between devs?
<spiv> For you, I think you perhaps want to think about "commit and share changes" as being not necessarily the same as "deploy changes to live web site"
<maredzek> i was thinking about this kind of architecture
<maredzek> 3 devs (bzr) -> central repo (bzr) -> live web serwer (no bzr)
<spiv> Sounds reasonable.
<maredzek> last arrow - only from time to time
<maredzek> like after completeing milestone
<spiv> Right.
<spiv> You could use the bzr-upload plugin for that (it can work over SFTP I believe).
<maredzek> upload plugin for last arrow right?
<spiv> Or you could have a developer do a "bzr export" to get a tree and then rsync it.
<spiv> Right.
<maredzek> ok, so dev1 wil lcreate new module
<maredzek> test it, change files
<maredzek> locally
<lifeless> spiv: upload works over sftp
<maredzek> and he would commit changes locally
<maredzek> and see if his work works :)
<spiv> maredzek: that's an important step :)
<maredzek> can this be automated?
<spiv> which part(s)?
<maredzek> dev1 adds 3 lines to class.php
<maredzek> saves file in his editor
<maredzek> we have to commit it manually on his local repo?
<maredzek> ok so he will, he does 5 or more tasks from this module
<maredzek> and wants to upload that data to central repo
<maredzek> how it is done
<maredzek> upload dont saves revision history right?
<maredzek> push will do spiv?
<spiv> Right, push updates (or creates) a copy of the branch.
<maredzek> so command will ok like:
<maredzek> bzr push --create-prefix sftp://your.name@example.com/~/public_html/my
<spiv> Sure.
<maredzek> ok so why after this push i can see no files in central server?
<maredzek> thats is the part i dont understand :)
<bob2> it updates the branch data
<bob2> not the working copy
<bob2> there's an update-after-push plugin that does that
<maredzek> if i install this plugin, will it upload all files or only modified ones?
<bob2> I think it just does 'bzr up' on the remote side
<bob2> so neither - it'll get updates from the remote branch
<maredzek> remote branch = central server?
<cody-somerville> If I have a binded branch that I've made local commits to, my understanding is that I should be able to do a normal commit to have everything uploaded. Is this correct?
<cody-somerville> Because I'm trying this with bzr 2.0.2 and it isn't working. It says I have to run bzr update first which last time caused all sorts of incorrect conflicts.
<bob2> maredzek: = whatever you push to
<bob2> cody-somerville: if it is bound and you made commits, they're already "uploaded"
<cody-somerville> bob2, I made local commits
<spiv> maredzek: People can "bzr branch", "bzr pull" etc from the place you "bzr push" to.
<cody-somerville> bob2, ie. bzr commit --local
<spiv> cody-somerville: to minimise issues with local commits, make sure you have no uncommitted changes before updating.
<bob2> cody-somerville: then you need to catch up to the remote branch before you can 'push' to it
<bob2> up on a bound branch with missing commits should probably bail if you have uncommited changes
<cody-somerville> I am up to date.
<cody-somerville> I'm ahead
<maredzek> spiv, so devs are push-ing to central server, and also pull-ing  from central server, right?
<bob2> or bound branches could go away
<lifeless> cody-somerville: if you're ahead just push to the master
<spiv> maredzek: right.
<cody-somerville> lifeless, shouldn't bzr commit do that automagically?
<cody-somerville> thats what bzr help commit advertises it will do
<maredzek> spiv, so i pushed to central server not files, but information about what i changed, right?
<spiv> maredzek: the complete record of what you have changed, from which the files can be reconstructed by bzr, e.g when someone does "bzr branch" of that location
<lifeless> cody-somerville: it will unless you committed offline
<cody-somerville> spiv, okay, thanks for that. made another local commit and ran bzr update. However, now all my commits are "rebased" (they show up as a pending merge).
<lifeless> cody-somerville: which is the only possible way to get ahead of the master
<cody-somerville>   --local               Perform a local commit in a bound branch.  Local
<cody-somerville>                         commits are not pushed to the master branch until a
<cody-somerville>                         normal commit is performed.
<spiv> cody-somerville: that is almost exactly not what rebasing is! :)
<lifeless> cody-somerville: ok, if you've done a local commit and an up, now do a commit.
<cody-somerville> lifeless, I tried to and it said I needed to run update
<lifeless> cody-somerville: no, you tried before you updated
<maredzek> spiv, so dev1 puts that info to central server, where dev2 will obtain files? it will ask central server about changes, finds that dev1 have changed 4 files and then? download them from dev1 repo?
<cody-somerville> lifeless, oh, right. it'll commit just fine I'm sure.
<spiv> maredzek: all the data is on the server
<lifeless> cody-somerville: after a commit --local you must either push, or update + commit, to make the local commit be centralised
<cody-somerville> lifeless, the help should be updated then
<spiv> maredzek: the .bzr directory contains a database with all the files and their changes etc compacted into it.
<maredzek> ahhhh ok!
<lifeless> cody-somerville: yes
<maredzek> i got it 100%
<cody-somerville> lifeless, it suggests to me that it'll automatically push all commits (and I think it should) if an update isn't needed.
<lifeless> cody-somerville: huh?
<maredzek> i will instal lupdate_after_push plugin
<lifeless> oh, the subsequent commit?
<cody-somerville> lifeless, No one else committed to the master branch while I was working offline
<lifeless> its an area forimprovement
<cody-somerville> lifeless, so now that I'm online and do a normal commit, everything should just be pushed
 * cody-somerville nods.
<maredzek> and when dev1 will push something, also all files wil be uploaded to central serfver right?
<cody-somerville> the way it works now, I have to merge in all my commits into a single commit
<lifeless> cody-somerville: or do a push, as I mentioned before
<lifeless> cody-somerville: rather than an update
<lifeless> cody-somerville: note that your commits are still itemised
<lifeless> cody-somerville: just folded up
<cody-somerville> lifeless, how do I view the full commit message for pending merge tips?
<lifeless> what do you mean
<Peng> "bzr st" I imagine; it only shows the first line.
 * Peng is guessing, and goes /away
<jam> igc: do you know what the status is for the doc building? I don't see http://doc.bazaar-vcs.org/bzr.2.0.2/downloads yete.
<maredzek> hi, im using bazaar for one day, how can i "save" sftp passwords?
<maredzek> it is quite annnoying to type them each time i want to push
<bob2> don't
<bob2> use ssh keys instead
<maredzek> it is something like this bob2? http://pkeck.myweb.uga.edu/ssh/
<bob2> that's the basic deal
<bob2> if you're on debian or ubuntu: ssh-keygen ; ssh-add ; ssh-copy-id remotehost
<maredzek> im on uubntu
<bob2> just do the above then
<bob2> that page makes you do far too much work :)
<vila> hi all
 * vila never saw a network switch fall apart. Now he has.
<maredzek> hi, what does it mean? http://pastebin.com/m27d6ee04
<maredzek> i wanted to push
<maredzek> from locahost to remote
<mkirby> I just installed bzr and am trying to follow the online docs but am getting an error when I try to 'bzr svn-import' in folder where I checked out from an svn repo
<mkirby> bzr: ERROR: unknown command "svn-import"
<mkirby> C:\pelco\source\vmas>bzr --version
<mkirby> Bazaar (bzr) 2.0.1
<mkirby>   Python interpreter: C:\Python26\python.exe 2.6.2
<mkirby>   Python standard library: C:\Python26\lib
<mkirby>   Platform: Windows-post2008Server-6.1.7100
<mkirby>   bzrlib: C:\Python26\lib\site-packages\bzrlib
<mkirby>   Bazaar configuration: c:\python26\Scripts\bazaar\2.0
<mkirby>   Bazaar log file: c:\python26\Scripts\.bzr.log
<mkirby> I thought the bzr installer came packaged with svn client support
<mkirby> Here is the doc where I started from: http://doc.bazaar-vcs.org/latest/en/user-guide/svn_plugin.html
<awilkins> mkirby, You've installed the python distribution... which alas, does not come with so many batteries
<awilkins> mkirby, It's good for the server (you seem to have installed it on a server) because you can configure a smart server to run with IIS off it
<awilkins> mkirby, But doesn't have any bundled plugins like the py2exe distribution does
<mkirby> awilkins, thanks. this is my win7 dev box
<mkirby> awilkins, I think I saw a bzr installer with python included, will that work?
<awilkins> mkirby, You want the one that ends -setup.exe
<awilkins> mkirby, The python included ones have a useful selection of plugins
<mkirby> i see it: Standalone http://launchpad.net/bzr/2.0/2.0.1/+download/bzr-2.0.1-1-setup.exe
<awilkins> That's the one
<mkirby> k, thx
<awilkins> mkirby, For svn interop I just prefer to branch straight from the SVN server
<mkirby> awilkins, is that not using svn-import
<mkirby> bzr checkout svn+ssh://svn.gnome.org/svn/beagle/trunk beagle-trunk
<awilkins> mkirby, With the bzr-svn plugin you can just ` bzr branch http://my.svn.server.org/my/branch `
<awilkins> You end up with a local native bzr branch ; I then tend to branch that for feature branches, keep the direct branch up to date with the SVN repo and merge those revisions outward before merging my feature back to it and pushing it up to the SVN repo
<awilkins> Depends on whether you have the ability to move development away from the SVN repository or not
<mkirby> it is a different team that controls the repo/build artifacts... but we are on good terms ;)
<awilkins> mkirby, I wouldn't use a checkout because that will bind the branch to the remote repo ; it will try to push any local commits to the remote repository
<mkirby> I like all the workflow bzr supports and ease of branching, but I'll have to try first before I can sell the company on it
<awilkins> mkirby, bzr-svn is excellent ; it provides the benefits to you even if you can't sell the company on it because you have full read/write interop with your SVN server
<awilkins> Could be a selling point ; you can migrate developers incrementally
<mkirby> awilkins, agreed
<awilkins> If any of them have to work outside the office they would be great targets for evangleism
<mkirby> awilkins, ppl are already complaining about branching an merging in SVN, so I need an alterative
<mkirby> awilkins, yeah we have remote offices that suffer the co,ci cycle
<jszakmeister> mkirby: what version on svn are you using?
<mkirby> jszakmeister, 1.5.4 (r33841)
<jszakmeister> Merge tracking isn't working for you?
<awilkins> mkirby, The 1.6 series has better branch/merge management but still (AFAIK) suffers from weaknesses
<mkirby> I saw bzr support the merge tracking info in svn
<mkirby> jszakmeister, ppl are still making mistakes... not using --reintegrate etc.
<jszakmeister> Ah.
<mkirby> I like the pqm (think that is right) idea too
 * jszakmeister agrees
 * awilkins also agrees
<awilkins> Alas, our current contractor has produced code with 0.3% test coverage
<jszakmeister> I've been using bzr-svn in a production environment for a while now... it's definitely worth playing with
<jszakmeister> :-(
<jszakmeister> That hurts.
<mkirby> jszakmeister, thanks, don't want to risk my job if things started failing/corruption
<awilkins> I've been using it over a year since around the 0.5 versions
<jszakmeister> It's using the svn libraries to interact with the repo
<awilkins> I think the worst thing I've ever seen it do is duplicate data
<jszakmeister> ...so it behaves much like the real svn client
<awilkins> (as in - not use previous bases and deltas, not make extra trees)
<mkirby> excellent
<mkirby> ru guys linux or windows users for bzr?
<awilkins> mkirby, Both
<mkirby> excellent
<jszakmeister> The stuff that would really confuse folks, like reordering your mainline commits in SVN, are disabled by default
<jszakmeister> Same here
<awilkins> The windows performance has really improved since the earlier versions
<bialix> since?
<awilkins> It started out, it kicked SVNs ass. (like, SVN was a 12 minute checkout on this tree, Bazaar was 4)
<awilkins> Now it _really_ kicks its ass
<mkirby> we are using crucible for changeset reviews, anything like that I can work into a bzr workflow prior to hitting trunk?
<bialix> it's for 2a?
<jszakmeister> mkirby: remind me how crucible works... you submit a diff?
<awilkins> bialix, The performance increments on Windows came mostly around ... oooh, 1.6? 1.9?
<awilkins> bialix, The readdir() implementations... I've not noticed 2a being that much faster (and it packs a lot slower)
<bialix> well, I've noticed this even earlier, but 1.9 is safe choice
<mkirby> jszakmeister, they mostly trigger off changesets that are already commited, but you can push a dif, but it is a pita to get the full context from svn diff command
<jszakmeister> That's what I though... it was kind of designed for post-review of changesets
<mkirby> jszakmeister, exactly
<bialix> awilkins: readdir for win32 was added around 1.6, maybe 1.7
<jszakmeister> ReviewBoard can do pre-commit reviews (that's what it was designed for)
<jszakmeister> We've been using it at our place.  It's better than nothing, but could stand to get a few improvements
<mkirby> k, i'll check it out
<mkirby> jszakmeister, awilkins, you guys in here much?
<jszakmeister> Occasionally.
<awilkins> Often
<jszakmeister> Depends on whether I remember to fire up the IRC client.
<mkirby> you've been a great help to ease my mind.
<jszakmeister> Most of my day, I'm away though. :-(
<jszakmeister> mkirby: check out an article I wrote: http://www.szakmeister.net/blog/2009/oct/12/bazaar-subversion-super-client/
<mkirby> k
<jszakmeister> And the migration docs: http://doc.bazaar-vcs.org/migration/en/
<mkirby> jszakmeister, "$ bzr branch http://svn.example.com/svn/project-name/trunk/ trunk" in your First steps
<mkirby> thanks
<jszakmeister> In particular, http://doc.bazaar-vcs.org/migration/en/foreign/bzr-on-svn-projects.html
<mkirby> ahh, I read the migration doc already
<jszakmeister> Cool.
<jszakmeister> My article has very similar information (both were written by me), but I tried to call out a few more of the individual steps in the article.
<Peng> ("bzr branch http://svn.example.com/svn/project-name/trunk/" would work too, since the default destination is the last directory in the URL, in this case "trunk".)
<mkirby> jszakmeister, excellent. have you checked out buildbot that google is using for chrome?
<jszakmeister> I dunno if Google is using something different, but I've looked at buildbot before.
<jszakmeister> It's not my first choice for a build tool. :-)
<jszakmeister> Quickbuild is: http://www.pmease.com/
<mkirby> I like all the stats it collects per build/test run
<mkirby> jszakmeister, http://build.chromium.org/buildbot/perf/xp-release-dual-core/new-tab-ui-cold/report.html?history=150
<jszakmeister> It does have some useful stats... I just think that are some others that are easier to set up... at least in a corporate environment.
<mkirby> jszakmeister, you gave me a good start with bzr, and a lot to look into. thanks for your time
<mkirby> awilkins, thanks alot too!
<jszakmeister> Your welcome!
<awilkins> mkirby, You're welcome... I think it's the best choice for Windows unless you have some seriously large projects.
<fullermd> maredzek: Re your earlier error, that's coming from trying to push from a rich root repo (2a format) to a poor-root (0.92 or 1.9, I'd guess)
<bialix> poor-root, lol
<fullermd> Well, unless you're in New Orleans; then it's a poroot.
<mkirby> jszakmeister, you wrote: http://doc.bazaar-vcs.org/migration/en/foreign/bzr-on-svn-projects.html
<jszakmeister> Yep
<mkirby> what did you use for the diagrams?
<mkirby> http://doc.bazaar-vcs.org/migration/en/_images/rebase-before.png
<jszakmeister> I used Omnigraffle.
<jszakmeister> Best diagramming tool evar!
<mkirby> ah, I love their tools
<jszakmeister> Only available on a mac though
<mkirby> I know...
<jszakmeister> Yeah, they're great
<mkirby> I'm running OSx86 just so I can have those on my laptop
<jszakmeister> :-)
<jszakmeister> I have to admit, they weighed in my decision to move to a Mac
<mkirby> closest thing I've found is gliffy... web based, but still not as smooth and featured
<jszakmeister> Heh.  Neat!
<mkirby> collaboration works well too
<mkirby> in gliffy that is.
<jszakmeister> Cool!
<bialix> cool
<mkirby> be careful, it acts up when you start copy/paste a lot of objects/lines
<mkirby> but it works well when everyone has their laptops and we sketch a design. I'm waiting for google docs to get something like this.
<mkirby> jszakmeister, bzr branch http://svn.myserver.org/svn/project/trunk tells me "Error: Not a branch"
<jszakmeister> What's the top-level layout look like?
<jszakmeister> trunk/, tags/, branches/?
<mkirby> yes
<jszakmeister> That's odd.
<mkirby> svn ls yeilds branches/
<mkirby> tags/
<mkirby> trunk/
<mkirby> i'll throw the last slash on...
<mkirby> jszakmeister, maybe it is my authentication
<mkirby> it is asking for creds to on the bzr command, is that normal?
<jszakmeister> It usually uses the cached credentials provided by svn
<jszakmeister> ...so no
<jszakmeister> try using svn+http://...
<mkirby> do I need to be in my svn wc?
<jszakmeister> No
<mkirby> k, good, and do I need to do a bzr init?
<jszakmeister> No.  Just branch and go
<jszakmeister> It might be the OPTIONS probe that's causing trouble...
<jszakmeister> bzr-svn does that to see if the remote end is a SVN server
<jszakmeister> Some server setups seem to dislike it though
<jszakmeister> svn+ disables the options probe
<mkirby> unsupported protocol
<jszakmeister> Does 'bzr plugins' show svn?
<mkirby> svn+http://svn.myserver.org/svn/project/trunk
<jszakmeister> I think you might be suffering fallout from your previous install of bzr
<mkirby> No module named qbzr.lib.commands
<jszakmeister> Ouch.
<mkirby> jszakmeister, I think you are correct
<mkirby> I'll give it a shot on my linux box and windows box @ work
<mkirby> this time I'll pull the standalone for the windows box
<mkirby> @ work
<jszakmeister> How did you install bzr before?
<mkirby> bzr-2.0.1-1.win32-py2.6.exe
<mkirby> then I pushed bzr-2.0.1-1-setup.exe over the top of it I guess.
<jszakmeister> Oh, I see.
<jszakmeister> You might want to uninstall that
<mkirby> ohhh!
<mkirby> I think I still have the old one in PATH
<jszakmeister> the -setup has everything... exactly.
<mkirby> yeah, i remember setting up the path... let me kill it
<mkirby> haha, %BZR_HOME%;C:\Program Files\Bazaar
<mkirby> the %BZR_HOME% is me, the other is from the new install
<jszakmeister> Nice. :-)
<mkirby> jszakmeister, sweeeeeet
<jszakmeister> That sounds like success. :-)
<mkirby> I like the progress bar
 * jszakmeister too
<jszakmeister> It's a nice bit of user feedback
<davidstrauss> If I run Branch.open(), what exceptions can I expect from that?
<mkirby> ok, so I'll still read up on your article, but when I do commits, it will be local, then a push will land it on trunk
<jszakmeister> Yes, if you used 'bzr branch'
<davidstrauss> NotBranchError?
<jszakmeister> The best workflow is probably to a branch and merge paradigm
<mkirby> jszakmeister, k, great
<jszakmeister> Otherwise, you're going to have to get familiar with rebase
<mkirby> i've rebased in SVN on my branches, prior to reintegrating...
<mkirby> but I understood how you kept your trunk, branched, cd to branch, committed, then moved back to ur trunk and merged the branch directory in.
<jszakmeister> SVN kind of enforces that workflow... especially since it'll silently rebase your changes during commit, if another one is already taking place.
<jszakmeister> Great, then you're ready to rock! :-)
<jszakmeister> Plus, that paradigm is better for long term feature branch development too
<mkirby> jszakmeister, thats why I am here ;)
<jszakmeister> Rebasing makes it hard to share changes, and the more changes you bring in and add, the more chance you have a conflict.
<jszakmeister> :-)
<jszakmeister> Same here. :-)
<jszakmeister> Well... that, and I wanted to contribute to some open source projects that are using SVN
<mkirby> yeah, I am still looking for my opensource project to contribute my hobby time to...
<jszakmeister> Be careful... once you start, you can't stop. :-)
<jszakmeister> I wish I had more time for it... I truly love it.
<mkirby> jszakmeister, good to hear... so far I am at rev 1100 or 3373
<mkirby> of
<mkirby_returns> jszakmeister, I'll have to give it a shot @ work from the LAN, my VPN is failing, and there are some other things about the contents in that trunk I don't like.
<mkirby_returns> again thanks, hope to see you around, do you have twitter acc?
<jszakmeister> Your welcome!  And yes, I do: twitter.com/jszakmeister
<jszakmeister> Although, I've been rather quiet there lately. :-0
<jszakmeister> I mean :-)
<mkirby_returns> k, tomorrow will be exciting, night
<piem> hi! i'm looking for two post commits: one that would force me update the changelog, and one that would run indent on the modified files
<free> hi all!
<free> is something changed in LP? I can't run bzr checkout http://bazaar.launchpad.net/~landscape/landscape-client/trunk/ anymore.. but maybe I'm not supposed to use that scheme?
<free> (it's used by a buildbot)
<vila> lp is down for at least 2 hours now
<vila> argh, I hate it when I hit refresh on an error page :-/
<vila> hmm, by bot still fails to checkout too...
<vila> s/by/my/
<free> strangely if I check out using the lp: schema everything works
<vila> free: yeah, it seems the smart server is doing fine while the http one isn't
<vila> It's known and being working on AIUI
<fullermd> Fie on http anyway.  Who wants to be dumb when you can be smart?
<vila> Sometimes the smart redirects to the dumb and.... :-)
<fullermd> That's pretty dumb.
<free> can you use the smart one without login?
<free> oh, you can
<free> buildbot doesn't work very well with the lp: schema, it would need a patch
<vila> free: relly ? What problems do you encounter ?
<free> vila: it simply tries to replace branch urls starting with "lp:" with "bzr+ssh://bazaar.launchpad.net/"
<vila> that's intended behavior, bzr is doing that not buildbot
<free> vila: buildbot too, in the bzr_buildbot.py backend
<vila> 8-(
<vila> free: where is that file in the buildbot namespace ?
<free> vila: it's a contrib file
<free> vila: it's in the main distribution (or at least the Ubuntu/Debian package), but not in the namespace, you can place it where you want
<free> and import from it in your config
<free> /usr/share/buildbot/contrib/bzr_buildbot.py
<vila> ENOTFOUND, what buildbot version are you using ?
<free> 0.7.11p3-1
<free> http://packages.ubuntu.com/karmic/buildbot
<vila> shudder, not upgraded yet for the host that uses buildbot :-/
<vila> so I'm still at 0.7.9-1
<free> oh, okay
<arkanes> so I have a branch from which I've deleted lots of subdirectories, and merging from the trunk is generating a ton of conflicts in all those paths
<arkanes> is there some way I can indicate that I removed these specifically and that merging shouldnt update them?
<bialix> nope
<bialix> free: http://twitter.com/launchpadstatus/status/5449277080
<free> bialix: the problem is that you need an ssh key to use bzr+ssh? the buildbot user doesn't have one
<bialix> I'm not LP dev but I believe you have to use your own ssh key
<bialix> if you don't have key -- you don't have ssh access, right vila?
<free> bialix: yeah, the point is that you should be able to checkout without authentication, for things like bot etc.
<bialix> this is http for
<bialix> today is LP upgrade day if I've tracked announce correctly
<free> bialix: it is
<bialix> it's not the every day such problems occurs
<vila> bialix: I don't the lp implementation enough to answer here but I think you're right
<free> indeed, that's why using bzr+ssh it's not an option in this case (buildbot), unless you set up a key and an LP account for that only
<bialix> vila: IIUC ssh access is rarely passwordless/keyless, that's what I mean
<bialix> free: it's sounds like one time hassle
<vila> yup
<bialix> and LP ssh is only key auth
<free> bialix: well, and you should make sure that the ssh key is installed in all your buildbot slaves, and if you add a new copy it over.. I agree it's a one time hassle, but I really think unauthenticated checkouts is a feature LP must have anyway, and indeed it has
<bialix> it is
<gioele> hello
<gioele> does anyone actively use trac-bzr?
<mkanat> Hey hey. If I have a persistently-running bzr server, is there a way to get loggerhead to use it, or does loggerhead just use bzrlib?
<mkanat> Come to think of it, it probably does use bzrlib and there would be no advantage to its using a persistent server.
<MTecknology> How do I pull a branch over http? I'm trying to do this with LP
<jelmer> gioele: we're using it on bugs.biutlbee.org, but with an older version of bzr\
<gioele> MTecknology: doesn't bzr pull http://..../ work? Does it give you an error?
<jelmer> *bugs.bitlbee.org
<MTecknology> gioele: I guess there's a server issue atm - thanks
<gioele> jelmer: I'd like to suggest my project admin to switch to bzr from svn, but that requires trac support. I doubt trac-bzr is just a drop-in plugin at the moment (given the advent of bzr 2 and so on)
<jelmer> gioele: trac-bzr is pretty much unmaintained at the moment, and it has memory leak issues
<bialix> gioele: I'm using trac-bzr with bzrlib 1.5
<bialix> MTecknology: http://twitter.com/launchpadstatus/status/5449277080
<gioele> jelmer: that was the impression I had. My only hope is to use bzr-svn. But I guess that, in the future, bzr-git will be developed more than bzr-svn (as samba moved to git).
<jelmer> gioele: not really; bzr-svn is a goal in itself for me these days
<gioele> jelmer: good to hear that. I thought that after the switch the attention to bzr-svn would become zero
<jelmer> gioele: no - Samba switched to git over 2 years ago, and bzr-svn is still alive and kicking :-)
<jelmer> It's also nice to see that there are other people making contributions
<lamont> what command did I give bzr to cause it to have bound=file://$PARENT in branch.conf?
<jam> lamont: 'bzr checkout' versus 'bzr branch' ?
<jam> or 'bzr bind'
<lamont> thanks
<jam> note that the previously bound location is remembered even if you 'bzr unbind' later
<lamont> yeah
<jam> rockstar, abentley: Anything I can do to help out with the codehosting issues? It seems very strange to have files randomly disappearing from the http site. (for example .../~bzr-pqm/bzr/bzr.dev is missing .bzr/repository/format, but lp:~bzr-pqm/bzr/2.1.0b2 is missing .bzr/branch/format)
<abentley> jam: Okay, that's interesting.  I was under the impression that all files were 404ing.
<jam> abentley: .bzr/branch-format for both of those worked just fine
<jam> but then fails later on
<jam> (well, *other* files fail later)
<jam> yeah, I hit a "not a branch" so opened it up in my browser, and things worked
<jam> so I kept probing until I found what it didn't like
<abentley> jam: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/repository/format works for me.
<jam> abentley: same here, though http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/.bzr/branch-format is timing out
<jam> now it worked
<jam> but it did give a timeout first
<jam> similarly: http://bazaar.launchpad.net/~bzr-pqm/bzr/2.1.0b2/.bzr/branch/format is timing out
<jam> but I imagine after a refresh it will 'just work'
<jam> abentley: still getting timeouts/404 on 2.1.0b2
<abentley> jam: yeah, that works for me now.
<mthaddon> I'm seeing the same for http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/.bzr/branch-format - times out, refresh and it's fine
<jam> abentley: so I'm guessing it is some sort of caching/filesystem mapping issue?
<jam> so it makes a request which takes a while
<jam> hangs and times out
<jam> but eventually the os does get the file it wanted
<abentley> jam: We have a script that rewrites urls for apache, translating them from ~me/proj/branch paths to /00/00/7F/3E paths.  That scripts does have a cache, but I'd be really surprised if it has bad data.
<abentley> jam: But it's not the sort of tricky virtual filesystem stuff we do with sftp.  It's pretty simple.
<jam> abentley: so to *do* the translation, I assume you have to do a db query to get the mapping?
<jam> though if that was timing out, I would think that you would miss *all* files for a branch until later
<abentley> jam: Indeed.
<jam> and not random files
<abentley> jam: That's right-- the cache is a cache of the part of the path that we rewrite, so once it's been mapped, it should be fast and repeatable.
<jam> abentley: and I assume it is done at the ~user/project/branch level, and not down in the .bzr/* level
<abentley> jam: Right, the cache is done at the ~user/project/branch level.
<jam> abentley: side question. I'd like to create a "bzr-builder" user for the windows buildbots. Is just logging out and "Register"ing a new user the best way to do that?
<abentley> jam: I think so.
<marek__> hi, i have a problem with understandign bazaar, so far i used svn and after modyfing files on my local system i just made a checkout, and that was all, on server there were new files. Currently i have two coputers - one is server and the other - is my client that i work on, i made following setup: on server i init a project, extracted there some core files and than from my client machine i did branch, now i edited file and commited locally that
<marek__> change, what do i have to do, to affect server files and repo?
<beuno> marek__, when you push, the repo will be updated
<beuno> if you want the working tree files to be updated, you will need to run "bzr update" on the other end
<marek__> ok i pushed it
<marek__> i also wanted to upload:
<marek__> bzr: ERROR: sftp://marek@192.168.7.109/var/www/trac/.bzr/ is not a local path.
<marek__> (i have plugin installed)
<beuno-lunch> marek__, what command are you running?
<marek__> marek@marek-laptop:/var/www/trac$ bzr update sftp://marek@192.168.7.109/var/www/trac
<beuno-lunch> marek__, right, you can't update remotely
<beuno-lunch> you need to run it on the other end
<marek__> ok
<beuno-lunch> marek__, there is a plugin called "push-and-update" that will do the update for you
<beuno-lunch> you will need ssh access
<marek__> i have i also tried to install that plugin but i dont know how it works
<marek__> but tell me one thing
<marek__> do i have to provide user name and host for my client machine?
<beuno-lunch> marek__, provide where?
<marek__> you told me that i need "to run it on the other end"
<beuno-lunch> when you do it locally
<marek__> in server?
<beuno-lunch> it's just "bzr update"
<beuno-lunch> when yourin the branch's directory
<marek__> ok
<marek__> i did, but it wont change file on remote server?
<marek__> heh it did
<beuno-lunch> :)
<marek__> magic
<beuno-lunch> if you just need to have the files, no the repo, you can use bzr-upload instead
<marek__> i need both :)
<marek__> i have another problem , at first i commited change in one file, after succesfully updateing it with server, i changed 2 more files and wanted to commit i got this:
<marek__> aborting commit write group: PathsNotVersionedError(Path(s) are not versioned: "male zmiany w schema.yml")
<luks> sounds like you typed `bzr ci "male zmiany w schema.yml"` instead of `bzr ci -m         check_references(searcher, )`
<luks> er
<marek__> i typed:
<luks> instead of `bzr ci -m "male zmiany w schema.yml"`
<marek__>  bzr commit "male zmiany w schema.yml"
<luks> yep
<luks> you forgot the -m/--message option
<marek__> ouch
<luks> so you told to commit a file named  "male zmiany w schema.yml"
<luks> and there is no such file
<marek__> ok so now i have:
<marek__> aborting commit write group: PointlessCommit(No changes to commit)
<marek__> i changed file
<luks> bzr st
<marek__> bzr st returns nothing
<luks> then there is nothing to commit :)
<marek__> :/
<luks> which file have you changed?
<marek__> ok, it is right
<marek__> i just did it on server
<marek__> not on client
<marek__> ok but once again i have this problem wth working tree
<marek__> files are not updated after update
<luks> you mean after push?
<marek__> agrr ok,
<marek__> so prcedure is:
<marek__> 1, modify files locally, 2. push, 3. update \
<marek__> right?
<luks> if you have a standalone branch, you need this: 1. modify files, 2. bzr commit, 3. bzr push, 4. (on the server) bzr update
<luks> if you have a checkout: 1. modify files, 2. bzr commit, 3. (on the server) bzr update
<luks> (or you can avoid the update step by installing the push-and-update plugin)
<marek__> ok, what if there are more clients that are doing pushing? how can i be sure, to have latest version first... with branch?
<luks> only one client can push as a time
<marek__> ok, but if he does it 30 min before?
<luks> if somebody pushes to the server, and you would try to override it, bzr will complain
<marek__> ok, thats like in svn
<luks> then you can use bzr merge, bzr commit and then bzr push again
<marek__> so i do something like this:
<marek__> 1. branch latest version from server
<marek__> 2. modify files
<marek__> 3. bzr comit
<marek__> 4. bzr push
<marek__> 5. pzr update (on server)
<marek__> does it make sense?
<luks> yes
<marek__> great
<luks> but if you want to work this "centralized" way, I'd suggest you to use bzr checkout
<marek__> about that plugin
<luks> then you don't have to explicitly push
<luks> and if you try to commit to an out-of-date branch, it will tell you
<marek__> so i would change 1 stage? 1. checkout latest version from server?
<luks> yes
<luks> and remove point 4
<marek__> oh, ok
<marek__> about that plugin - so i have to install it on server or client?
<luks> on the client
<marek__> will i need this while using checkout?
<luks> yes, I believe so
<fullermd> I don't know if the plugin runs off and does the update on commit...
<luks> hm
<marek__> but if i use branching - it will work perfectly?
<mems> hey.  Can anyone tell me how to list the branches in a remote repository?
<alefteris> hi all. I got this error after doing pull:
<alefteris> bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~ubuntu-gr-webteam/ubuntu-gr-website/drupal6-site/.bzr/branch/".
<alefteris> then I tryed again, and got:
<alefteris> bzr: ERROR: Not a branch: "/var/www/html/ubuntu-gr/drupal/lp:ubuntu-gr-website/".
<alefteris> log: http://paste.ubuntu.com/310739/
<alefteris> I did a branch localy from the lp branch, and branch was created and can pull
<alefteris> I also notised this diference between the format files in server and local branch: http://paste.ubuntu.com/310738/
<alefteris> I'm using bzr 2.0.0 localy and bzr 1.3.1 in the server. I help would be realy helpful, thanks :)
<alefteris> Anyone knows if there are newer versions of bzr for centos?
<mkanat> alefteris: I just rebuild the Fedora RPMs, myself.
<alefteris> the one I got is from Extra Packages for Enterprise Linux (EPEL)
<jam> alefteris: http://bazaar.launchpad.net is currently 'down for maintenance'
<jam> if you are using bzr 1.3.1 I don't think it understand "lp:" urls
<jam> 1.3 is... ~2 years old
<jam> well, 1yr 7mo
<fullermd> Urr?  I'm pretty sure bzr understood lp: URL's in 0.6...
<alefteris> jam, I can see the lp plugin commands though, I thing it does support lp urls
<fullermd> (of course, 0.6 would fare poorly with bzr+ssh...)
<jam> alefteris: (11:12:39 AM) alefteris: bzr: ERROR: Not a branch: "/var/www/html/ubuntu-gr/drupal/lp:ubuntu-gr-website/". would indicate it in't
<jam> isn't
<jam> were you running "--no-plugins" ?
<alefteris> nop
<alefteris> I can't branch even with the full url though
<alefteris> oh, code hosting is down right now?
<jam> alefteris: http is
<jam> you could use bzr+ssh or sftp
<jam> if you have a key shared
<alefteris> I haven't, so I gess I'll have to wait, I'm so unlucky to try to update the site, while lp is down :/ thanks all for the help :)
<vila> jam: ping
<jam> hey vila
<jam> I think I figured out what was wrong with the build stuff. 'hexagonit.download' released a new version
<jam> and the build script wasn't version-locked for that
<jam> specifically looking here:
<jam> http://pypi.python.org/pypi/hexagonit.recipe.download
<jam> 1.3.0 says: We now require zc.buildout >= 1.4.0
<jam> and we were version locked to zc.buildout 1.2.1
<jam> anyway, what's up for you vila?
<vila> I had a lot of internal network problems today and I still need to pack (I'm leaving tomorrow)
<vila> jam: oh great you found that !
<vila> I just committed a fix for bug #475585
<ubottu> Launchpad bug 475585 in bzr "Launchpad plugin is not compatible with python-2.4 anymore" [Critical,Fix committed] https://launchpad.net/bugs/475585
<vila> but I can make the MP because lp tells me: updating branch.... I suspect it will stay like that for a while :-/
<vila> s/I can/I can't/
<jam> I can create an MP while the branch is still updating
<jam> but I expect you'll run into whatever the current codehosting issues are
<jam> before it shows a dif
<vila> really ? I never dared...
<jam> vila: it works just fine
<jam> I do it all the time
<jam> *I'm* not going to wait for it everytime I want to submit something :)
<vila> ok, I'll do that then, but I can only target lp:bzr...
<jam> versus?
<jam> bzr 2.1.0b2 has been cut
<jam> so we'll have to do b3 early to get your fix in
<jam> (no rc policy and all)
<jam> but your changes aren't in 2.0.* series so it shouldn't affect thta
<jam> that
<vila> right, I wasn't sure, so lp:bzr is enough
<jam> vila: well, probably I would create a 2.1.0b3 derived directly from 2.1.0b2 and not including new bzr.dev stuff
<jam> but that is negotiable
<jam> you *could* target lp:~bzr-pqm/bzr/2.1.0b2
<jam> and just have us manually track the "Merged" status
<vila> time is running short :-/ I'll see what I can do tomorrow, if you don't beat me to it, I did test against 2.4/2.5/2.6 with -s bp.launchpad and had ~50 failures without my patch
<jam> vila: so no failures on 2.5/2.6 but failures on 2.4, right?
<vila> also, I put babune in reduced mode starting now (only hardy. jaunty, karmic left active, I won't be able to tweak manually as I do for a couple of weeks for the others :-/)
<vila> jam: yes
<jam> vila: so at least give me the url for your patch, but it would be nice to have it as an mp so I can easily comment on it
<jam> certainly, we should land it in bzr.dev today
<vila> mp is done
<jam> and see where we get to for 2.1.0b3
<jam> vila: url?
<jam> (in case it takes forever to generate the preview)
<vila> argh, can't copy/paste here :-(
<jam> type out the short name
<vila> you should find it back from the bug report
<vila> the branch is linked to the bug and starts with 475585
<jam> vila: only once lp updates...
<jam> but https://code.edge.launchpad.net/~vila/bzr/475585-lp-proxy-py24-compat/+merge/14489
<jam> looks good
<jam> well, looks like what you worked on
<jam> *argh*...
<jam> because you uploaded to ~vila I only get access to the mirrored side
<jam> which won't give me access until the mirroring script finishes running.
<vila> yeah, I daggy-fixed to ensure the patch was minimal
<vila> aaaaaargh
<jam> you could push it to ~bzr
<jam> and I could get the writeable side
<vila> done
 * vila EODing
<jam> vila: can I get 1 min to make sure I can get the code
<jam> done
<jam> thx
<jam> vila: you stopped passing "use_datetime"...
<jam> I'll clean that up I guess
<vila> jam: sure, I'll certainly be around ;ater, but only for short moements
<vila> we don't use it
<vila> so we mat as well don't pass it
<jam> vila: mmm if we are going to do that, then we shouldn't expose it as part of the __init__ interface
<jam> since if anyone *does* use it, it will just mysteriously not work
<jam> ah, I missed the fact that you did exactly that
<jam> abentley: any eta on the codehosting fix? it seems that it has broken the mirroring script, which means that if I push new code to lp, then it doesn't get mirrored to the public side, so I can't access it with different access rights
<jam> not to mention disabling merge proposals, etc.
<abentley> jam: We have just cowboyed a fix a minute ago.
<abentley> jam: It has not broken the mirroring script-- that was separate breakage which has also just been fixed.
<jam> abentley: ah, well good to know they are both fixed at least :)
<jam> is that "cowboyed" into production then?
<abentley> jam: That's right.  I'm working on a cherrypick for the branch-rewrite script, whose faulty cache was at the root of the issue you saw.
<jam> abentley: so it *was* the cache being faulty
<jam> surprising
<abentley> jam: Yes.  The issue looked like some files were working and others weren't, but it was actually that requests which hit the cache failed, and those that didn't worked.
<jam> abentley: I don't want to take you away from doing the fix, but I'm curious how the cache knows when to invalidate itself (like when a branch gets renamed, etc.)
<abentley> jam: It is time-based.  Entries older than 10 seconds are discarded.
<jam> abentley: ah, so you just avoid hammering the db when a person is requesting 10k files underneath a branch, but you don't keep it around too long
<abentley> Right.
<jam> also explains why it sometimes worked, if that 10s had just expired
<jam> and why "bzr branch" fails, because it would work for the first request, but the second would come in within 10s
<abentley> jam: When a branch gets renamed, the cache doesn't prevent lookups on the new name from working, but it allows lookups on the old name to work 10s longer than they technically should.
<jam> right
<jam> well, you could have a double-rename do things you may not want
<jam> but it is a race condition anyway
<jam> as renaming something underneath you is going to do bad things
<jam> argh... this mirroring thing is killing me
<jam> I can't get the latest bzr.dev but I can't submit to pqm because NEWS conflicts
<jam> because *pqm* has the latest version
<abentley> jam: Yes, the double-rename is problematic.
<bialix> jam: hi
<bialix> jam: do you merged win32 glob patch so fast to ensure it will get more real world testing?
<igc> morning
<jam> hey igc
<jam> I hope your feeling good today
<igc> hey jam
<jam> btw, I'm still stuck without docs for bzr 2.0.2 and 2.1.0b2
<jam> though I'll need to release 2.1.0b3 soon
<jam> so don't focus on those
<igc> jam: better but still not great. I'm doing the docs right now
<igc> jam: I slept nearly all of yesterday
<jam> igc: thanks. and i'm glad to hear that you're feeling better
<jam> looking forward to seeing you in about 72 hours
<jam> well, maybe 96...
<jelmer> moin igc, jam
<jam> hi jelmer
<igc> hi jelmer
<jam> igc: for myself, I'm still trying to sort out all the issues for getting the buildout stuff working on ec2
<igc> jam: :-(
<jam> The recent round of changes showed that we hacked some stuff together on kerguelen
<jam> like putting packages in PATH rather than having buildout do the work
<igc> jam: I'm still catching up - 2.1.0b2 is no good?
<jam> and sometimes hard-to-diagnose failures like having to manually hack python2.4's disutils
<jam> I forgot about that in the pats
<jam> past
<jam> igc: it is not compatible with python2.4
<jam> the proxy code stuff
<igc> ah
<jam> turns out in 2.4 it is a 'old-style' class without __init__
<jam> and PQM no longer runs python2.4
<jam> because we couldn't convince mthaddon about how it should be configured
<jam> and then sort of dropped the ball on it
<jam> Anyway, writing up the steps I take to get things working now
<jam> as a real document :)
<jam> and then we should be able to snapshot the EC2 instance
<igc> jam: that will be good
<jam> the major issue we'll run into is how to do VS 2008, whether we need Standard
<jam> or whether we can work out what SDK you need in order to build tbzr w/ Express
<jam> igc: yeah, so far the build process is a lot nicer on EC2
<jam> I think the disk access is better
<jam> and if necessary, we can easily spin up an instance in 'medium' rather than small (I believe)
<igc> jam: my bzr on vista is failing for some weird reason
<igc> jam: so I'll get the chm's built as soon as I can but it may be an hour or so, depending on what's going on
<jam> igc: well, I'm done for today anyway. but it would be nice to either build in about 3hrs when my family goes to bed, or at least tomorrow before I fly away
<igc> jam: ok.
<jam> I'll note that at least on Kerguelen everything builds fine as long as I tell it to use the old docs
<igc> jam: I'm really sorry I couldn't do this earlier
<jam> igc: well, not exactly your fault either
<jam> igc: I hope you have a good day today, maybe I'll see you around later
<igc> jam: but I was simply too sick (despite trying a few times to do it)
<igc> ok. If not, in a few days
<igc> jam: have a safe flight btw
<maxb> Is there a good doc which summarizes what looms and pipelines actually *are*? I have seen the documentation for the plugins' commands, but I'm still a bit hazy on what a loom and a pipeline are and when I would want to use them.
<maxb> Likewise, I could really use a pipes vs. looms comparison
<poolie> hi all
<poolie> spiv, hi
<spiv> poolie: hey
<poolie> how's stuff?
<poolie> i'm planning to get offline in a bit and think about next week
<igc> hi poolie, spiv
<igc> poolie: before you go, where did the doc stuff get to?
<poolie> just got a few queries from the hotel
<spiv> I saw the udd mailing list is alive, I just did the mailman dance.
<poolie> igc, i think it's buliding ok
<poolie> modulo gremlins, which have probably broken some links
<poolie> oh and we're waiting on the rt for pdf builds
<poolie> the next action would be to poke around more thoroughly looking for broken links i guess
<poolie> or to run a bot to do the same
<igc> poolie: where are the doc builds going to?
<igc> poolie: see http://doc.bazaar-vcs.org/
<igc> there's no bzr.2.0.2 yet?
<igc> or bzr.2.1.0b2 yet?
<poolie> !
<poolie> ok
<poolie> you need to go down into eg http://doc.bazaar-vcs.org/current/en/
<spiv> I'm shortly going to put up a wiki page with the bzr/ubuntu stories and some analysis of them.  I've been trying to wrap my head around as much of the existing bzr-builddeb/bzr-builder/DistributedDevelopement stuff as possible, there's no shortage of text to sift through...
<poolie> so apparently we need to remove the existing docs that are hiding them at a higher level
<poolie> igc i don't think it's worth having a directory for every single release
<poolie> i think one per 6m branch is enough
<igc> poolie: let's sort it out next week then
<igc> poolie: it's certainly a little weird now, e.g. http://doc.bazaar-vcs.org/latest/en/
<igc> says "2.0.3dev" when it needs to say "2.0.2" IMO
<poolie> hm
<poolie> i guess that is a more interesting case
<poolie> not so much that people might want the specific docs for old releases
<poolie> but that even the current release may be confusing if you see later docs
<poolie> (this should anyhow perhaps be partly addressed by describing some features with the release that introduced them but you can't do that everywhere)
<poolie> igc, to me the biggest thing would be to work out what should be at these urls:
<poolie> doc.b.o/  doc.b.o/latest/
<poolie> should they just redirect by default to the english versions?
<poolie> i guess the page currently on http://doc.bazaar-vcs.org/en/ should appear at the top level?
<igc> right. Or the top level can redirect there
#bzr 2009-11-06
<fullermd> igc: Hey.
<poolie> k
<igc> hi fullermd
<fullermd> igc: Do I remember right that sometime back in the Dark Ages of N months ago you had some stuff toward recursive upgrade?
<poolie> igc, which would be similar to the main web site
<igc> fullermd: I do
<igc> fullermd: there was a branch somewhere ...
<igc> but it missed the 2.0 cut and ...
<igc> fell down my list of priorities
<igc> fullermd: https://code.edge.launchpad.net/~bzr/bzr/smooth-upgrades
<fullermd> Was it particularly incomplete, or just didn't get wrung out and landed?
<igc> fullermd: the patch was almost ready for re-review IIRC
<igc> fullermd: I don't think I addressed all of poolie's internal design issues
<igc> fullermd: external design was largely ok I think
<fullermd> Cool.
<fullermd> The hope for that soon enough is one of the things holding me back from feeling able to declare "OK, time, we're moving $STUFF to 2a".
<fullermd> So, if you come up with a "nearly done stuff we should finish" list while sprinting, keep it in mind   :)
<fullermd> (I mean, I know how bored you all are, with so little to do...)
<maxb> Odd_Bloke: Could you comment on https://bugs.edge.launchpad.net/bzr/+bug/183559 - "Fix Committed" where?
<ubottu> Launchpad bug 183559 in bzr "bzr switch should have a -r option" [Undecided,Fix committed]
<bob2> maxb: is it in the "related branch"?
<maxb> Hmm.... could be.... though that doesn't correspond to my understanding of "Fix Committed"
<spiv> maxb: http://bazaar-vcs.org/BugGuidelines
<spiv> Oh, stale link.
<spiv> maxb: http://doc.bazaar-vcs.org/bzr.dev/developers/bug-handling.html
<spiv> maxb: specifically, http://doc.bazaar-vcs.org/bzr.dev/developers/bug-handling.html#bug-status
<maxb> ah. different to how ubuntu use the status. confusing :-/
<james_w> poolie1: hi, do you have the password for the udd list? (I think I'm an admin too?)
<james_w> poolie1: if so, could you send me it, I'll add it in to listadmin and so help with the moderation
 * igc lunch
<GungaDin> Hi
<GungaDin> I'm trying to merge from trunk to my branch and after a log list of changes and conflicts I get a 'bzr: ERROR : [Error 5] Access is denied", even though I have admin rights..
<GungaDin> any ideas why?
<bob2> GungaDin: on windows?  is it possible you have one of the files open in an editor or something?
<GungaDin> yup, on windows
<GungaDin> hmmm... maybe
<GungaDin> yeah
<GungaDin> good point
<poolie> spiv, igc, can you tell me again the topics you wanted to add for next week?
<poolie> i don't see them on the wiki
<spiv> poolie: the two I have are the 2.1/Ubuntu topic (which is already there), and maybe also talking about what the bzr team needs to do with the code import system
<poolie> k thanks
<poolie> i'd like you to present a bit of a summary about what's already in the UDD specs and already done
<poolie> for those who may not have read it too much
<spiv> Ok, that makes sense.
<poolie> and also to try to think of an interesting lightning talk
<poolie> doesn't have to be particularly relevant, in fact refreshingly irrelevant ++
<spiv> There's a lot of spec to wade through, and the current status of a lot of it is pretty hard to figure out.
<spiv> Hmm, irrelevant lighting talk...
<vila> hi all
<spiv> vila: good evening
<vila> hehe, last tiem you do that one for a couple of days :)
<spiv> :)
 * igc1 dinner
<guilhembi> Hello everybody. I have a question. When I'm in "bzr qlog", clicked the "Diff" button, and ticked "Complete",
<guilhembi> is there a quick way to go from diff hunk to diff hunk? My case is that the file is huge, with some changes here and there, so I hit PgDown a lot; but I still need to see the complete file, to get better context... ?
<luks> guilhembi: there is no way at the moment
<guilhembi> luks: ok, thanks.
<davidstrauss> guilhembi: Could you just use a really big context?
<bialix> Hi GaryvdM
<GaryvdM> Hi bialix
<bialix> I want to share with you quote from my today's mail
<GaryvdM> ok
<bialix> one mane wrote: "I've chose DVCS from Mercurial and Bazaar, and QBzr was the reason I've selected Bazaar"
<bialix> it's a rough translation from russian
<bialix> GaryvdM: ^
<GaryvdM> Woot!
<bialix> Indeed!
<bialix> :-)
<spiv> bialix, GaryvdM: nice :)
<bialix> hi spiv, thanks
<bialix> spiv: quick question
<stefano-k> hi, i have a question about translation of qbzr
<bialix> what is needed to add traffic reports for ftp transport?
<bialix> stefano-k: ask
<bialix> spiv: what is needed to add traffic reports for ftp transport?
<spiv> bialix: hmm
<spiv> bialix: add calls to self._report_activity everywhere the code reads or writes data I guess
<bialix> ok, I understand
<bialix> I've started to actively using ftp and want to improve it a bit
<ElMonkey> hullo
<ElMonkey> is there any way to push parts of a private repo into a public one?
<GaryvdM> bialix: Is that just for qbzr, or also in bzr cli?
<bialix> GaryvdM: um?
<GaryvdM> bialix: traffic reports for ftp transport
<bialix> ElMonkey: using fast-import-filter but it will create second branch completelly unrelated to original private one
<bialix> GaryvdM: CLI
<ElMonkey> bialix, so changes from the original private branch couldnt be pushed after the creation of the new repo?
<bialix> yep
<bialix> only by diff + patch
<bialix> or you can drop the history but preserve file-ids
<bialix> in the latter case you can cherrypick changes from original repo
<bialix> but you won't share history
<ElMonkey> hmm, tricky
<ElMonkey> the sitation is this: i have a private repo with all my projects, and i'd like to open source one of them
<ElMonkey> the thing is, that there's also some shared files between projects
<GaryvdM> ElMonkey: Are the different projects in different branches?
<ElMonkey> GaryvdM, no, its one repo
<ElMonkey> if it was different branches, i guess i wouldn't have this problem
<GaryvdM> ElMonkey A branch does not = repo
<GaryvdM> ElMonkey: you can have more than one branch in a shared repo
<ElMonkey> well, its just some folders in a repo
<GaryvdM> ElMonkey: in a branch?
<GaryvdM> ElMonkey: To check, go into the folder and type bzr info
<bialix> ElMonkey: show us output of `bzr info`
<ElMonkey> Standalone tree (format: 1.9-rich-root)
<bialix> it's a branch
<bialix> by repo in bzr usually understand shared-repo
<bialix> ElMonkey: I'd say it's a bad idea keep all your projects in the one branch
<GaryvdM> ElMonkey: maybe bzr-split does that - I'm not sure though.
<bialix> bzr-split does not filter out history
<ElMonkey> well, whats the alternative? the reason for it being so as the projects share quite a few source files
<ElMonkey> well, as things grow
<ElMonkey> well, well, well
<bialix> let me guess: you need nested trees, right?
<ElMonkey> i dont know :)
<bialix> well, if there is only few common source files then you can add them in every branch with the same file-ids and cherrypick changes
<ElMonkey> i've been trying to figure out the proper way of doing this last year, but i didnt get anywhere
<bialix> or you can extract common files in the separate branch and then merge them back to every project and therefore share them
<bialix> ElMonkey: what is your background before you switch to bzr? svn& cvs&
<bialix> ElMonkey: what is your background before you switch to bzr? svn? cvs?
<ElMonkey> cvs, then svn, in the meantime a bit of clearcase agony :)
<bialix> ElMonkey: unlike cvs bzr can't share separate files, only group of files called trees
<bialix> unlike svn bzr still has no support for equivalent of svn:externals
<ElMonkey> well, i havent really run into this problem before with the other RCSs
<bialix> the latter called nested trees in bzr
<ElMonkey> never had the need to publish just parts of something before
<GaryvdM> ElMonkey: The idea with nested trees, is that you can have a branch for proj A and a branch for proj B, and a branch for shared, at it all works nicely. Nested trees is not implemented yet, but smc-proj alternative. Note: this is something you needed in the beginning. To get there, you can use bialix's suggestion:  fast-import-filter
<bialix> scmproj
<ElMonkey> bah, i should just write a shell script that pushes source tarballs onto the server occasionally :)
<ElMonkey> thanks for the tips, though
<ElMonkey> i'll have to do a bit more research to decide what to do
<jelmer> moin
<ronny_> lifeless: ping? got a wave account by any chance
<ronny_> i'd like you to take a look at the revised distributed testing sketchup at https://wave.google.com/wave/#restored:wave:googlewave.com!w%252BezH3Z8aIB
<Tak> hmm, I don't think it's possible to link waves like that
<ronny_> Tak: works fine
<bialix> Tak: wfm
<Tak> ah - the ua check breaks it
<Tak> bialix: ???
<bialix> Tak: what?
<ronny_> wfm = works for me
<Tak> ah
<GaryvdM> bialix: You have wave?
<GaryvdM> bialix: If possible, please invite me :-)
<beuno> GaryvdM, to what address do you want the invitation?
<GaryvdM> garyvdm@gmail.com
<GaryvdM> Hi beuno
<GaryvdM> :-)
<beuno> GaryvdM, hi
<beuno> and sent
<beuno> it takes a few days sometimes to materialize
<beuno> but it's in the tubes
<GaryvdM> Thanks beuno
<beuno> GaryvdM, np. Are you going to be at UDS this time?
<GaryvdM> beuno: No :-(
<GaryvdM> beuno: Are you going to the bzr sprint?
<beuno> GaryvdM, no, I'm off tomorrow to a different sprint
<GaryvdM> I see.
<beuno> (lazr-js, Canonical's javascript library)
<bialix> GaryvdM: just yesterday I've got invitation
<bialix> GaryvdM: I'm still don't understand how to work with this thing
<bialix> when I figure out how can I made invitation I'll do
<GaryvdM> bialix: beuno has sent me an invitation.
<bialix> ah, ok, thanks beuno
<GaryvdM> bialix: I think you have to wait a while before you can send an invite.
<bialix> you need to wait several days
<bialix> before you got invitation
<bialix> I waited ~ week
<GaryvdM> ok
<bialix> it works very slow for me as it full of ajax
<bialix> approx as slow as google reader
<bialix> maybe it's firefox
 * bialix still not sure what is wave for
<GaryvdM> bialix: for bug 418471 - Do you think we should have a "?", or a "x" for the icon?
<ubottu> Launchpad bug 418471 in qbzr "treeview: will be nice to show some custom icon for deleted entries" [Wishlist,Confirmed] https://launchpad.net/bugs/418471
<GaryvdM> Or maybe trashbin
<GaryvdM> Going to go with trashbin...
<bialix> GaryvdM: I've thought about sheet of papaer and red X over it
<bialix> and similar thing for folders
<bialix> GaryvdM: sorry, I'm tired today; trashbin is ok
 * bialix gonna home
<Pegasus_RPG> hello. I'm trying to commit changes to a branch that I initially checked out using http apparently. I've imported my ssh key onto this system and logged in to launchpad with bzr launchpad-login. but it's still trying to use http. How can I get it to change to ssh without editing anything in .bzr/ ?
<lifeless> ronny_: I do
<lifeless> robert.collins
<Pegasus_RPG> ahh bzr bind is what I needed
<elroboto> help! how to setup a simple bzr repository for development, we dont need editors
<GaryvdM> elroboto: bzr init   - But I recomend that you do some reading first: http://doc.bazaar-vcs.org/latest/en/mini-tutorial/
<elroboto> thanks bro
<nyu> bzr: ERROR: Revision {[('term/i386/pc/at__keyboard.c', 'svn-v3-single1-dHJ1bmsvZ3J1YjI.:d0de0278-0dc1-4c01-8a07-af38b3205e46:trunk%2Fgrub2:2613')]} not present in "KnitVersionedFiles(_KnitGraphIndex(CombinedGraphIndex()), <bzrlib.knit._DirectPackAccess object at 0x27ca350>)".
<nyu> anyone can give me directions on how to debug this?
<nyu> note that there's no at__keyboard.c file in our reposiroty, it's at_keyboard.c (one underscore)
<beuno> nyu, have you run "bzr check" and "bzr reconcile"?
<nyu> check raises an internal error:
<nyu> bzr: ERROR: bzrlib.errors.SHA1KnitCorrupt: Knit <bzrlib.knit._VFContentMapGenerator object at 0x5a7aa90> corrupt: sha-1 of reconstructed text does not match expected sha-1. key ('svn-v4:d0de0278-0dc1-4c01-8a07-af38b3205e46:trunk/grub2:2681',) expected sha 81411fbdd0c3cdb2041adeb7761a4a16d28f8fe8 actual sha d698afceb95a6f9fe71e7462fddd4843d0d3ecb8
<nyu> what is this "svn-v*" information?
<nyu> I didn't expect anything from svn needed to be preserved
<beuno> seems bzr-svn was used
<nyu> yes
<nyu> it was
<nyu> beuno: is it feasible to attempt recovery of this repository, or is the only debugging option trying to figure out when and how it reached this state?
<beuno> nyu, I don't know much around this area of bzr
<beuno> abentley or jam may be able to help
<nyu> beuno: do you think this problem is linked to the fact bzr-svn was used?
<beuno> nyu, it could of been a faulty version of bzr-svn
<beuno> jelmer, around?
<beuno> but I'm stabbing in the dark here
<nyu> beuno: that's what we thought initially, as we were using bzr-svn 0.4.10.  but then I rebuilt the repository from scratch using 1.0.0
<nyu> and hit the same problem
<nyu> unfortunately it doesn't happen inmediately, only after a few days of using it
<beuno> nyu, what version of bzr?
<nyu> beuno: 2.0.1
<nyu> with --format=1.14-rich-root shared root
<beuno> nyu, I'd try the mailing list
<nyu> ok
<moldy> hi
<GaryvdM> Hi moldy
<lifeless> GaryvdM: did you ping me?
<GaryvdM> lifeless: no not recently.
<lifeless> kk
<lifeless> kk
<elroboto> .
<elroboto> help!! ive initilized a direcotry, and merged with the main branch, but i cant see the changes on the main branch?
<elroboto> im using the windows Gui
<elroboto> yohoo
<elroboto> HELP!!!
<elroboto> how to create a simple branch without
<elroboto> just simple push and merges
<elroboto> no editions
<elroboto> how to make a bzr tree standalone in linux?
<bob2> you make a branch with 'bzr branch'
<elroboto> ohhhhhhhhh
<elroboto> bob2:  i mean a standalone branch, i dont want to control
<bob2> not sure what you mean
<mzz> I don't understand the question
<elroboto> i just want to share , some code between webdevs
<mzz> if you're trying to create a new empty branch to start a new project in that's just "bzr init"
<mzz> if you have a branch and want others to have access to it that usually involves "bzr push"-ing it it to a location they have access to
<mzz> but the manual covers all that
<mzz> you may have to explain what you're trying to do in more detail
<elroboto> this is the scenario
<mzz> (possibly including what you've already tried and how it didn't work)
<elroboto> 1. we need a central repository
<elroboto> 2. there is 5 developers
<elroboto> they just want to share code, without control
<mzz> I don't know what "without control" means
<elroboto> for example, when we try that with Bzr windows GUI
<fullermd> mzz: Dogs and cats living together, mass hysteria.
<elroboto> it works fine
<elroboto> but when we try to store it on linux, we do "bzr init" , the changes are not reflected on the peers
<mzz> "bzr init" is not normally a thing that shows up elsewhere.
<elroboto> A. commits and pushes
<elroboto> B. pulls
<bob2> elroboto: one person does 'bzr init', once
<mzz> it is possible you're using a checkout on windows and a standalone branch elsewhere, but it is very hard to tell (even more so because I've never used that windows gui)
<elroboto> C. Merges
<bob2> elroboto: then everyone else pushes and pulls from that
<elroboto> one time somebody told me a command to create a "share" bzr repository
<mzz> so far I do not exactly understand what this thing is that works on windows and not elsewhere
<mzz> but I suspect you're clicking a button in the gui and issuing a command on linux, and those two don't do the same thing
<mzz> in which case you'll have to explain what button you're clicking
<elroboto> yeah
<mzz> (if I understand correctly so far your question is "I'm doing something in the windows gui and can't figure out how to do it on the linux commandline", but you haven't explained *what* you're doing in the windows gui in a way I can understand)
<elroboto> they dont do the same
<elroboto> exactly!
<elroboto> im doing in windows BZR init
<elroboto> and in linux im typing bzr init
<mzz> "bzr init" is not something that shows up remotely (unless you're doing it in a network share or something)
<elroboto> brb 2 hours
<mzz> so unless the windows gui is nuts I don't understand the question
<fullermd> Nor is it something that generally makes sense to do twice on one project.  I think he's confused about what he's trying to do...
<mzz> well, not having used the windows gui, my best guess is his "init" button isn't actually equivalent to "bzr init", it's a more general "get me a branch" button that can also do "bzr branch" and/or "bzr checkout"
<mzz> either that or his current branch is actually on a network share mapped by all those 5 developers, so he's only had to "bzr init" that one branch and hasn't had to branch it or check it out at all yet.
<mzz> but that's just guesswork, so lemme try to switch topics:
<mzz> I'm using bzr-builddeb and now have a bzr diff with "=== renamed directory 'oursqlx' => 'oursqlx'" in it. Does that make any sense? Is this some quirk of bzr-builddeb or can it have something to do with non-richroot vs 2a format conversions?
<fullermd> Not offhand.  You're not running on some sort of case-insensible filesystem or something?
<mzz> ext4, so no
<mwhudson> jelmer: can you look at https://answers.edge.launchpad.net/launchpad/+question/88128 ?
<mzz> the rest of the diff looks sane to me, including bzr noticing the bogus permission changes that happened. But that dir doesn't have either a rename or a permissions change I can see.
<phcoder> Hello, all. May a repo internal structure (like indexes) get corrupted because of bzr-svn? Is there a way to regenerate all indices?
<mzz> and even if it *had* a rename bzr-builddeb shouldn't have been able to see it, because it's importing a tarball.
<mzz> phcoder: I'm no expert, but did you run "bzr check" yet?
<mzz> phcoder: iirc bzr-svn also has an sqlite-based cache somewhere. Removing that cache may be reasonable, but don't take my word for that.
<nyu> it's in ~/.bazaar/svn-cache
<nyu> yeah, sometimes it helps. but not this time :-(
<phcoder> I'm bzr-checking my local repo
<phcoder> nyu: have you tried bzr reconcile on our repo?
<nyu> phcoder: nope.  the description sounded uhm.. dangerous
<phcoder> you can try it on a copy
<nyu> you're right ;-)
 * nyu tries
<phcoder>     87 inconsistent parents
<Standart> I have three machines, one is running bzr 2.0, one being the central server running 1.7 and one running 1.3. how can i push from the 2.0 machine to the server so that the 1.3 machine still can play with the rest? downgrading to 0.92 doesn't seem to work (can't downgrade to non richt-tree)?
<phcoder> is it a problem?
<nyu> bzr: ERROR: An inconsistent delta was supplied involving '<unknown>', '723@d0de0278-0dc1-4c01-8a07-af38b3205e46:trunk%2Fgrub2:'
<nyu> reason: Parent not in inventory.
<nyu> Standart: use --format when creating a shared-repo in the server
<nyu> (I think)
<phcoder> Standart: --rich-root-pack should be ok
<Standart> do i have to throw away my rich-tree branch?
<lifeless> no
<lifeless> rich-root-pack is readable by 1.0 and compatible with 2a
<Standart> ok
<phcoder> nyu: can you send me a tar.lzma of our damaged repo, perhaps my bzr is newer and can reconcile it
<lifeless> its just a lot slower
<Standart> the 1.3 server says bzr: ERROR: Unknown branch format: 'Bazaar Branch Format 7 (needs bzr 1.6)
<Standart> which format ist the best to be used with 2.0, 1.17 and 1.3?
<nyu> phcoder: the second one?
<nyu> I have both
<lifeless> Standart: rich-root-pack
<phcoder> nyu: yes
<Standart> lifeless: i thought there are different versions of that
<nyu> ok
<Standart> with --create-prefix i can push to a location that I don't have shell access to. is there a way to choose a format?
<lifeless> not on push
<lifeless> you can do this:
<lifeless> bzr init --format temp
<lifeless> cd temp
<lifeless> bzr push --create-prefix <url>
<lifeless> cd ..
<lifeless> rm -rf temp
<lifeless> bzr push --overwrite <url>
<Standart> I see. so it's always the format of the one I'm pushing from
<lifeless> Standart: converting data is slow, we try to avoid it.
<lifeless> Standart: if you can, upgrade your server to 2 - much much much faster
<Standart> i can't. don't even have shell access
<lifeless> Standart: that doesn't mean that you can't arrange for it to happen ;)
<Standart> amd i need to checkout with bzr 1.3. can't help it
<Standart> the existing repos are 0.92 but i cannot downgrade my new one, even if i wanted to, if i understand this correctly
<Standart> looks like 1.14-rich-root can be used by all my versions.
<lifeless> 2a can not be converted to 0.92 (unless you create new history - essentially a full export-import, which won't be able to be merged with)
<lifeless> Standart: 1.14-rich-root can't be used by < 1.14
<lifeless> Standart: rich-root-pack is the format you need
<Standart> lifeless: ok, seems that i converted my local repos to 1.14-rich-root and pushed it to a server that took it as rich-root-pack
<Standart> is there a format and push compatibility matrix somewhere?
<mzz> blehhhh, I just wish the world would magically upgrade to 2a already
 * mzz redoes some stuff so he can actually push it to launchpad without "different serializers" failure, hopefully
<Peng> Agreed, but I'd do many other things with magic first. Like, world hunger, or 1 Gbps fiber for everyone.
<Peng> Increase Dollhouse's ratings....
<mzz> heh
<fullermd> Also, I'd like a marshmallow-pooping unicorn.
<mzz> ok, poor wording there. Still, annoying.
<fullermd> I dunno how you can be so cruel as to want world hunger, though.
<Peng> IP over wormhole, to decrease my RTT to Launchpad. :D
<Peng> fullermd: Whoops. s/wo/ solve wo/
<mzz> I keep forgetting to check for non-richroot formats before I init repos or branches
<Standart> lifeless: thanks. everything rich-root-pack...
#bzr 2009-11-07
<stuartpb> What's the easiest way to install Bazaar on Ubuntu with feature parity to the default Windows installer (shell integration, bzr-svn)?
<Meths> aptitude install bzr-svn bzrtools  <-- You probably want something like that to pull in all you want.  Not sure about how you define shell integration and how it meets your expectations though.
<Meths> Do  'aptitude search bzr' and see what you need from the descriptions.
<stuartpb> bzr-gtk
<stuartpb> and that'll put stuff on the application menu and all?
<mzz> I do use ubuntu but I have no clue about "shell integration", sorry.
<Meths> Only if you install a gui for bzr otherwise you run bzr commands from a command line - pick a term of choice
<stuartpb> see, I installed Bazaar with Ubuntu Software manager so I have bzr and bzrtols
<mzz> bzrtools is in Recommends, so just installing bzr should pull it in by default. Might want to install bzr-svn and/or bzr-gtk too, yes (they're in Suggests)
<mzz> I'm not much of a gui person, so I don't know how software center represents Suggests)
<Meths> recommends is not depends, does not get pulled in
<mzz> recommends is not depends, but *does* get pulled in by default since, erm, checking relnotes...
<mzz> ubuntu 8.10
<stuartpb> is there a way to get bazaar integrated with thunar?
<Meths> oh, weird. Ta for info though.
<stuartpb> and does bzr-gtk come with bazaar explorer
<mzz> the most convenient way to find out may be to just install it.
<mzz> (if you don't like it you can always uninstall it again)
<stuartpb> yeah, it's doing it now
<stuartpb> but will it go under the applications menu if it gets installed?
<mzz> I have no idea, I haven't used bzr-gtk and an Applications menu at the same time.
<mzz> I get the feeling if one of the people currently active knew they would've told you already. It's probably faster to install it and find out.
<mzz> it's possible it integrates into the file manager without showing up as a standalone app in the applications menu.
<mzz> (do you actually mean "I already installed it and it's not showing up on my applications menu. Should it?")
<stuartpb> "bazaar notification" has been added to the programming submenu
<stuartpb> how do I get Bazaar stuff on my context menu?
<bob2> stuartpb: in what? nautilus?
<stuartpb> yeah
<arjenAU> ello bzr gurus
<elroboto> helo
<arjenAU> how do I upgrade the repo/branch format on a lp branch.
<mzz> stuartpb: /usr/share/doc/bzr-gtk/README.Debian claims it is currently broken
<mzz> stuartpb: (although that makes me wonder why the package still Recommends python-nautilus, bah)
<mzz> arjenAU: I don't know if it's actually the best way but there's http://doc.bazaar-vcs.org/latest/en/upgrade-guide/index.html#migrating-branches-on-launchpad
<arjenAU> mzz: cheers
<arjenAU> mzz: seems to have worked. groovy.
<arjenAU> also observing the filesystem where lp holds the branches is about 8 minutes behind real time. probably borked ntp
<bialix> fullermd: thanks for you mails in that thread
<fullermd> bialix: I do go on, don't I   :)
<bialix> Ñ Ð½Ðµ Ð¿Ð¾Ð½Ð¸Ð¼Ð°Ñ
<bialix> fullermd: now I feel like a mindless tree. I don;t understand your joke
 * bialix hides away
<fullermd> It's not really a joke, so much as a rueful reflection.
<fullermd> Someday, I hope to learn how to write a SHORT email.
<bialix> no, your e-mail was just right in size and content
<bialix> right for me
<bialix> you talk my thoughts
<bialix> I was sad to hear from luks couple of years ago almost the same: it's almost impossible to get patches in
<fullermd> I hate bringing it up, 'cuz what can you do?
<fullermd> I mean, the answer can only be "We're doing the best we can, but there are only so many hours in the day", which doesn't solve the problem but is perfectly true.
<fullermd> It's just a recipe for frustration on BOTH sides   :(
<bialix> right
<bialix> qbzr is more appealing for me therefore
<bialix> we don't need to write zillion tests for 5-lines fix
<bialix> thanks anyway
<fullermd> I'll take any excuse to write a 10,000 word essay   8-}
<bialix> :-)\
<bialix> :-)
<sjamaan> Is there an easy way to quickly go to a particular revision? (like "svn up -r xyz" in subversion)
<LarstiQ> go in what sense? `bzr revert -r revspec` most likely
<LarstiQ> or `bzr cat` for a single file at a revision, or `bzr export` for subtrees
<sjamaan> bzr revert won't commit anything, will it?
<LarstiQ> correct
<sjamaan> alright, thanks
<LarstiQ> (but if you run `bzr commit` directly after, you'll commit a new revision with the same state as the one you reverted to)
<sjamaan> Understood
<LarstiQ> which is different from svn, svn won't allow you to commit in that position
<sjamaan> Exactly
<LarstiQ> which I find bloody annoying :)
<sjamaan> You could do a reverse merge and commit that with svn, but you can't update to an old revision and commit that
 * LarstiQ nods at sjamaan 
<sjamaan> svn merge -r HEAD:oldrev .
<sjamaan> That's about the same as bzr revert -r oldrev, as I understand it
<LarstiQ> does svn merge do treeshapes?
<sjamaan> Excuse my ignorance, but what are treeshapes?
<LarstiQ> sjamaan: move, add, delete
<sjamaan> It does
<LarstiQ> ok
<LarstiQ> then yeah, pretty similar
<Kinnison> presumably you could do something like bzr checkout --lightweight -r blahfoo . ../here-at-blahfoo
<sjamaan> Ah, I suppose that would work too
<sjamaan> But it's easier to revert, since I just wanted to look at something in the old state
<sjamaan> Making a full new checkout is a bit too heavyweight for that
<Kinnison> if you just want a given file, then bzr cat may be easier
<sjamaan> mebbe
 * LarstiQ frequently uses revert for that purpose though
<SamB_XP> does qlog give you that? I forget...
<sjamaan> I was wondering about something: If you do bzr unbind, then make some changes and commit those, then bind again and run bzr update, is it supposed to clobber all your local revisions without any warning?
<sjamaan> (note I didn't first push the changes)
<SamB_XP> sjamaan: it is undesirable for it to do so
<SamB_XP> why, did it?
<sjamaan> SamB_XP: When I tried, it did so
<SamB_XP> oh :-(
<SamB_XP> well, I believe they are still in there somewhere
<LarstiQ> sjamaan: afaik it pivots them to be merged
<sjamaan> How can I find them?
<SamB_XP> LarstiQ: what do you mean "to be merged"?
<LarstiQ> SamB_XP: pending merges
<LarstiQ> sjamaan: doesn't `bzr st` list them?
<sjamaan> nope
<SamB_XP> what's that command to find loose heads in the repository ?
<SamB_XP> or, well, any heads I guess
<sjamaan> I don't know, I'm a newbie :)
<LarstiQ> SamB_XP: `bzr heads`
<LarstiQ> from bzrtools
 * SamB_XP wonders how to get Windows' file copy progress dialog to give details like transfer size, size transferred so far, and kB/s for the last few seconds ...
<SamB_XP> sjamaan: there you go
<SamB_XP> run "bzr heads"
<sjamaan> thanks
<sjamaan> I guess I need to install those tools then
<SamB_XP> you don't have bzrtools installed ?
<sjamaan> Not yet
 * SamB_XP is still confused about why those aren't part of bzr
<maxb> I've just filed a merge proposal for qbzr - is that sufficient or do I need to email someone?
<nyu> hi folks
<Kamping_Kaiser> allo
<phcoder> Hello, all. Can old bzr+ssh daemon together with new clients some of them maybe comitting by sftp lead to data corruption on server?
<nyu> and if it can, can we prevent it from bothering us by using 2a repo format?
<Kamping_Kaiser> I've not heard of that, but I'll stand by and wait for the bzr-hackers to comment
<phcoder> Second question: on server repo we have different kinds of corruption. I managed to fix most of them with bzr reconcile and some hacks in bzr code to correct corruption but 4 commits still have incorrect SHA-1. Any way to write their new digest or delete them altogether?
<Kamping_Kaiser> phcoder: perhaps `bzr push --force` (assuming you know your only overwriting 'corrupt' files)
<phcoder> Kamping_Kaiser: I'm trying to recover server copy locally. Moreover corruption in repo may stay even if all corrupted branches are deleted
<Kamping_Kaiser> phcoder: I'm going to retreat to the sideline and hope lifeless or some other bzr hacker wakes up and helps you out
<Kamping_Kaiser> hm... lifeless sorry about the ping... 3am is a bad momentfor it ...
<fullermd> If they've got incorrect SHA-1, you probably don't WANT to rewrite it.  It's way more likely that the data is corrupt than that the hash is....
<phcoder> fullermd: If repo was already damaged when it was comitted hash could be miscalculated. I will check these commits manually afterwards. Alternative is to delete them but simply deleting refering directories didn't help
<nyu> phcoder: checking corrupt commits manually isn't very reassuring wrt preventing the problem from happening again :-/
<fullermd> I'm not sure that follows at all.  The hash calculated at commit time should always match the data committed at commit time.
<phcoder> perhaps savannah is running out of free space or has HD failure
<phcoder> are svn and bzr on same server?
<nyu> phcoder: they have free space
<nyu> can be retrieved with sshfs and df
<nyu> doesn't seem to be the same server
<nyu> different IPs at least
<phcoder> bzr check reveals more potential problems. Looks like our repo is in serious trouble
<nyu> what sort of problems?
<phcoder> If I can at least fast-export in would be perhaps enough. Missing keys. I'll redecompress the backup and retry
<Kamping_Kaiser> phcoder: at the risk of (re)sticking my nose in - can you give a bit more background for the problem your experiancing?
<phcoder> We're trying to migrate to bzr. Currently we use it as a mirror of svn and to hold people and experimental branches. Every time we import all branches everything seems fine but breaks after about one week
<Kamping_Kaiser> hm. I can't bzr svn-import today sadly. I can tomorrow, but that probably won't help your testing
<nyu> svn-import?
<nyu> we were using bzr-svn
<phcoder> nyu: bzr svn-import I suppose imports all branches whereas bzr branch only one
<Kamping_Kaiser> nyu: 'bzr help svn-import
<Kamping_Kaiser> Purpose: Convert a Subversion repository to a Bazaar repository.
<phcoder> but both are part of bzr-svn
<Kamping_Kaiser> '
<nyu> ah I see
<phcoder> nyu: how do you update our bzr-svn mirror?
<Kamping_Kaiser> I don't have a bzr-svn command
<phcoder> Kamping_Kaiser: bzr-svn is a plugin, not a command
<Kamping_Kaiser> phcoder: ah right. yes, we're on the sam epage then
<phcoder> it provides bzr branch and bzr svn-import
<Kamping_Kaiser> i should really backport bzr{-svn,-git} from sid atsome point
<phcoder> Kamping_Kaiser++
<nyu> phcoder: I bzr pull; bzr push
<Kamping_Kaiser> I've been putting it off since it looks like it'll involve dependancies, but bzr-git would be helpful to me
<phcoder> Kamping_Kaiser: KeyError: ('2063@d0de0278-0dc1-4c01-8a07-af38b3205e46:trunk%2Fgrub2:commands%2Fmemrw.c', 'svn-v3-single1-dHJ1bmsvZ3J1YjI.:d0de0278-0dc1-4c01-8a07-af38b3205e46:trunk%2Fgrub2:2172')
<Kamping_Kaiser> phcoder: can you link me to the repo? I'll start to track it too
<Kamping_Kaiser> {bzr,svn} info -v
<Kamping_Kaiser> ftr
<phcoder> Kamping_Kaiser: svn.sv.gnu.org/grub/trunk/grub2
<Kamping_Kaiser> and shuld i branch or co?
<phcoder> Corrupted one is here: http://people.debian.org/~rmh/grub/bzr-backup2/
<phcoder> Kamping_Kaiser: branch
<phcoder> nyu: what if we import through git avoiding svn but still getting the same IDs this way?
<nyu> phcoder: what are those IDs for?
<phcoder> nyu: merging
<nyu> phcoder: it feels much safer to discard them
<phcoder> ok. What about using stock git-svn then and get different IDs?
<nyu> I mean, it feels much safer to operate on the higher layer above the tools that grok their own formats
<phcoder> nyu: what do you mean?
<nyu> have you read my script?
<nyu> it's very small and simple
<nyu> and from bzr POV it's like the svn never existed
<phcoder> nyu: not yet. As you know I work in another direction of possible recovery. What about fast-import/fast-export?
<nyu> what do you want to archieve?
<nyu> if this is an issue on safety, I trust my code a lot more than any other approach
<phcoder> nyu: fast-export creates a text file which is actually just a chain of patches
<nyu> how does bzr import that?
<phcoder> bzr fast-import <file>
<nyu> uhm doesn't have this option, is that a plugin?
<phcoder> it's in bzr-fastimport package
<nyu> ok let me play a bit with that
<lizard_r> Hi, I made a little program/lib with a local reposity[18 rev.] which I would like to upload to Sourceforge. I just enabled the bazaar feature. I'm on windows and I'm not sure what I made wrong, output: http://lizard.pastebin.com/m6e4430a5 - does someone know what is wrong?
<wade> Hi all, Any idea how I can troubleshoot a hang when issuing bzr pull via sftp?  I successfully pushed this branch, but when I try to pull it back down as a test, bzr just hangs after I successfully enter my password
<wade> using the latest stable versions, btw
<Kamping_Kaiser> wade: tried running with -v to get extra info?
<wade> yep..hangs too - no extra info
<Kamping_Kaiser> lizard_r: perhaps you should look on the bzr site abougt the rich formats, sf.net may be using an older veersion
<fullermd> Last I vaguely checked, SF was using something like 1.10.
<fullermd> So it's RR capable (though not 2a capable), but their scripts probably don't make a RR repo.  So you'd probably have to make the repo manually (I think you can do that on SF)
<lizard_r> yes, they use 1.10 I just checked - but what you just said is far over my head :-)
<wade> if anyone has any other ideas on how to troubleshoot this bzr pull hang, I'm all ears
<wade> oh crap...never mind....I'm an idiot - I should be running bzr branch, not bzr pull, since I'm trying to pull a new copy - however, bzr should probably give an error message, not just hang - I'll file a bug
<wade> er, branch a new copy I should say
<fullermd> It certainly shouldn't; it should exit right away with 'Not a branch'
<fullermd> (by 'should' I mean "certainly does now, pretty sure always has)
<wade> right...I've seen that before...hmm..let me try something
<fullermd> So I suspect you WERE in a branch...
<wade> hmm...you might be right - when I made sure I was in the non-branch dir I wanted to be in, I did get the "not a branch" error message
<wade> so the question is - why did it just hang when I was in a branch, and shouldn't it have given some error?
<fullermd> I doubt it was really hung.
<fullermd> It seems more likely it was doing something that took a long-arse time.
<wade> hmmm...I'll play with it and see if I can replicate - the branch in question was 3 test files with 1 line each so I'd be surprised about a long-arse operation :)
<thumper> an item for the sprint next week
<thumper> can we plz add a command to push to not stack?
<thumper> also
<thumper> if it does try to stack but fails due to different format types
<thumper> can we retry without stacking?
<thumper> stacking is decided by the client, but the server suggests
<thumper> right now we don't have a way to tell the client "no, plz don't stack"
<lifeless> thumper: file bugs please
<thumper> lifeless: I think there is at least one
<lifeless> thumper: the sprint is about prep for the next cycle, not doing individual bugs, they are easily done solo, not a good use of face-time.
<thumper> lifeless: remind me during the open spaces time
<lifeless> thumper: I'm leaving before then.
<thumper> lifeless: yeah, fair enough
<thumper> lifeless: ok
<lifeless> thumper: I will try to remind you, can't promise anything.
<sjohannes> quick question, is there a way to set bzr's executable bit for a file in win32?
<lifeless> you can using python
<lifeless> but I don't think we have a command to do it
<sjohannes> lifeless: any pointers for doing this? i've never worked with bzrlib before, so any help is appreciated
<lifeless> sjohannes: the test suite does it a few times, in the exec bit support
<lifeless> I'll dig up a reference in ~ 20 minutes for you
<sjohannes> lifeless: ok, thanks a lot
<bialix> maxb: ping
<bialix> sjohannes: pluing x-bit
<sjohannes> bialix: pardon?
<bialix> you need plugin x-bit
<bialix> to change x-bit on win32
<bialix> you wrote: "sjohannes	quick question, is there a way to set bzr's executable bit for a file in win32?" right?
<bialix> sjohannes: ^
<sjohannes> bialix: ah i see. just didn't understand the "pluing" bit :)
<bialix> sory, typo
<sjohannes> bialix: i'll have a look, thanks
<sjohannes> bialix, lifeless: the x-bit plugin works nicely. thanks for your help
<bialix> glad to hear
<maxb> bialix: hi
<bialix> maxb: hello
<bialix> maxb: I'm working on inclusion of your patch for &nbsp; in qlog
<bialix> I've changed news entry as following: "Preserving leading whitespace in the lines of the log message."
<bialix> maxb: is it ok for you?
<bialix> is it correct English?
<maxb> Nearly - s/Preserving/Preserve/
<bialix> ok
<bialix> maxb: thank you for the fix, merged now
<maxb> thanks very much for the quick response :-)
<bialix> :-/
<bialix> today there was said too much about speed of response
<bialix> pushed to trunk
<nyu> I have a /trunk/{grub,grub2} SVN repository layout.  I'm trying to convert it to Bazaar using "bzr fast-export-from-svn",
<nyu> I have a /trunk/{grub,grub2} SVN repository layout.  I'm trying to convert it to Bazaar using "bzr fast-export-from-svn", but in the output /trunk is a single branch
<nyu> and I'd rather make two branches out of it
<bialix> nyu: does svn-import does not work for you?
<nyu> bialix: is that bzr-svn?
<bialix> yep
<phcoder> bialix: we have repo corruption in bzr and bzr-svn is a possible reason
<nyu> bialix: sorry, no.  we've been trying that for 2 weeks and it corrupted out repository twice
<bialix> oh, sorry
<nyu> I want an approach that is as little intrusive as possible, and fast-import patchsets seem like a good way
<nyu> except I don't know how to split the branches
<nyu> can it be done in bzr afterwards?
<nyu> d'oh, there's a split command
<bialix> nyu: there is fast-import-filter
<bialix> split is not exactly what you want
<bialix> nyu: did you try --trunk-path option?
<bialix> see help for fast-export-from-svn
<nyu> bialix: it didn't work
<bialix> :-/
<bialix> file a bug please
<nyu> I think it doesn't like that the new "trunk" doesn't exist throughrough all repository life
<bialix> and try fast-import-filter
<nyu> is that still a bug?
<bialix> I dunno, I was unable to run fast-export-from-svn on windows
<nyu> bialix: does fast-import-filter require a SOURCE argument?  the examples in help page don't have it, but it refuses to run without it
<nyu> (bug filed)
<bialix> yes, require
<bialix> there is typo with help
<bialix> example should be: front-end | bzr fast-import-filter -i lib/xxx/ - > xxx.fi
<nyu> and I take it that SOURCE is the fast-svn-export dump?
<bialix> yes
<nyu> strange.  then I don't understand why do I get this:
<nyu> bzr: ERROR: exceptions.TypeError: cannot concatenate 'str' and 'NoneType' objects
<bialix> do you have latest version from trunk?
<bialix> pastebin full traceback
<bialix> I recall this bug was fixed recently
<nyu> bialix: no, 2.0.1
<bialix> version of fastimport plugin I mean
<nyu> http://pastebin.com/m42df5aa8
<nyu> bialix: 0.9.0~bzr243
<nyu> not sure if that 243 is meaningful or debian-made
<bialix> looks like revno
<bialix> the latest revno of fastimport trunk is 260
<bialix> can you just do: cd ~/.bazaar/plugins; bzr get lp:bzr-fastimport fastimport
<bialix> and then try fi-filter again
<nyu> sure
<nyu> bzr fast-export-from-svn svn-repo - | bzr fast-import-filter -i /trunk/grub2 - | bzr fast-import - bzr-repo
<nyu> does this look sane?
<nyu> uhm still same error
<nyu> maybe I should use bzr split?
<bialix> bzr split won't filter out the history of other branch
<bialix> if you can live with that than use
<bialix> and file bug please
<bialix> about NoneType
<nyu> bialix: maybe I can debug this, but I would need some direction
<bialix> ok, set env variable BZR_PDB=1
<bialix> and run again
<nyu> ok
<lifeless> sjohannes: if bialix's plugin works for you it will be _much_ simpler than the code wI was digging up
<bialix> nyu: wait, why you're using -i /trunk/grub2 ?
<sjohannes> lifeless: well, thank goodness it works :-P
<bialix> nyu: why not just grub2?
<nyu> bialix: I don't know
<nyu> I want /trunk/grub2 to become a branch
<bialix> if you don't use  filter and do fast-import what you have?
<nyu> I have a shared-repo with only one branch in it, called "trunk"
<nyu> which has two directories, grub and grub2
<bialix> and what's inside?
<nyu> the source trees
<bialix> ok, filter operates in the terms of these paths
<bialix> you should run filter with -i grub2
<nyu> oh, ok
<nyu> same problem.  actually, filter is supposed to work without -i or -x too, right?
<nyu> I mean, as a no-op
<bialix> I'm not sure, I'm not author, but used it successfully in the past
<bialix> try to run fast-import-info instead of filter just to check if strea is correct
<bialix> try to run fast-import-info instead of filter just to check if stream is correct
<bialix> if you know the format of git-fastimport stream you can save it to disk as export-from-svn output and check if there all ":" marks are correct
<nyu> it looks sane
<nyu> what's a parent?
<nyu> as in, parent branch?
<bialix> nyu: btw, you can try to fast-export of imported bzr trunk and try to filter it instead of svn output
<nyu> oh, but wouldn't I get the same thing?
<bialix> sometimes -- no
<bialix> parents -- it seems revision parents
<bialix> merged revisions etc
<nyu> self.parents[":" + cmd.mark] = parents
<nyu> is ":" + cmd.mark an array index?
<bialix> yes
<bialix> and error talk about cmd.mark is None
<bialix> but it supposed to be a string
<bialix> you can try to change this line this way:
<bialix> self.parents[":" + (cmd.mark or "")] = parents
<nyu> cmd is some sort of struct passed from commit_handler() right?
<bialix> passed to IMO
<nyu> I thought of that, but it seems to be hiding the real bug?
<bialix> can you print cmd
<bialix> ?
<nyu> I mean, is it acceptable that cmd.mark is empty?
<bialix> I can't say for sure
<nyu> 1 min
<nyu> bialix: http://pastebin.com/mf82ea86
<nyu> uhm... there's an empty line
<bialix> you really can compare the output of fast-export from big bzr branch with grub1 and grub2
<nyu> ok, I'll try that
<bialix> nyu: I'm looking at parser.py: ImportParser
<bialix> there is method _get_mark_if_any
<bialix> result of this method then passed as cmd.mark
<bialix> sometimes this method returns None
<nyu> oh, interesting
<nyu> what does it mean when it returns None?
<nyu> is that supposed to be tollerable?
<bialix> does your project is open-source?
<nyu> bialix: the raw repo is public, rsync -avzHS rsync://svn.savannah.gnu.org/svn/grub/ /tmp/grub.repo/
<bialix> how's big fi stream after export-from-svn?
<bialix> after gzip/zip?
<bialix> I can't rsync right now
<bialix> and I can't run fast-export-from-svn either
<nyu> hold on, compressing
<bialix> ok, looking at the code if get_mark_any returns None it push the processed line back to stream
<bialix> IMO it means it want to process it later or somehow different
<nyu> bialix: what code portion are you looking at?
<bialix> parser.py
<nyu> btw, gzip'ed repo is 237 MiB
<bialix> ImportParser
<bialix> it's a bit big :-/
<bialix> I can download it only tomorrow from work
<nyu> I guess you meant _get_mark_if_any() ?
<bialix> yep
<bialix> but strange thing is in command.py
<bialix> but strange thing is in commands.py
<bialix> CommitCommand
<bialix> there is code that checks cmd.mark for None
<nyu> oh, maybe filter_processor.py should do a similar check?
<bialix> wait
<bialix> in your patse http://pastebin.com/mf82ea86 there is line commit, after which should be a line with mark
<bialix> if I do fast-export for my testing repo I see line with mark
<bialix> you have nothing
<bialix> I really think that fast-export command over bzr branch will produce more "correct" stream
<nyu> ah yes, I was going to test that
<nyu> bialix: btw, lzma file is only 17 MiB
<bialix> this size is much better
<nyu> (tarball from svn repo)
<nyu> ah wait, you said you don't have fast-export-svn handy?
<bialix> no
<bialix> nyu: just FYI: there is 2 forms of git-fastimport streams
<bialix> one form has inline blobs
<bialix> second one is not
<bialix> fast-import plugin prefer to work with inline
<nyu> bialix: it seems that export from bzr works
<bialix> looking at your paste it seems you have the latter form
<nyu> at least, fast-import-filter won't complain
<bialix> good
<nyu> I think I can work this way.  I'll add the missing information to the bug report
<bialix> nyu: there is also fast-import-info command
<bialix> according to help this command can be used as elper
<bialix> according to help this command can be used as helper
<bialix> but it seems filter does not use this additional info
<bialix> glad you managed it to finish
<nyu> excellent, fast-import-filter worked
<nyu> bialix: I put the info in https://bugs.launchpad.net/bzr/+bug/477886
<ubottu> Launchpad bug 477886 in bzr "fast-import-filter: cannot concatenate 'str' and 'NoneType' objects" [Undecided,New]
<nyu> thanks for your assistance
<bialix> thanks for filing a bug
<jam> lifeless: I have a question about subunit. Namely, is there a way to get a nice progress bar out of "bzr selftest --subunit" ?
<jam> As far as I can tell, pqm must have been running a custom filter on it
<jam> ah, maybe "subunit2pyunit --progress" ?
<jam> that is almost spooky to see the output :)
<lifeless> jam: :)
<lifeless> -> plane
<jam> lifeless: of course, it would  be nicer if it could retain the log when run_bzr fails ... :)
<jam> lifeless: I'll be joining you in..... 6 hours
<jam> and then see you in about 30
<jam> I figured I might try to get more of the test suite passing on Windows during my copious free time now.
#bzr 2009-11-08
<wade> Hi guys...I'm suddenly having doubts about whether I use bzr correctly....If I want to operate in a distributed fashion, every time I or a team mate make a change to our feature branch, we should merge it into the mirror, then push the mirror, correct?
<wade> what happens if I push, and then he pushes without first pulling?
<jam> wade: it sort of depends how you define "mirror"
<jam> if you are both collaborating on a single branch
<jam> you can both 'just push' to the mirror
<jam> you don't have to merge
<jam> if he pushes without pulling
<jam> bzr will tell him that the branches have diverged
<jam> and he needs to merge before he can push again, etc.
<jam> you could also use checkouts, which automate some of that book-keeping
<jam> though it means that "bzr commit" will block and tell you to update
<wade> Ok...I was just getting worried that I might be blowing away his changes when I pushed
<jam> wade: we're pretty good about not letting you "blow away" anything
<jam> as long as you don't use --force or --overwrite style flags
<wade> Ok, good to know - thanks
<syncrondi> anyone able to provide insight on why I get "bzr: ERROR: unknown command "push-and-update" "?
<jam> syncrondi: because there isn't such a command?
<jam> Are you installing the "push-and-update" plugin?
<jam> I'm pretty sure it just piggy backs on regular "bzr push" anymore
<syncrondi> I've used it before on another machine.. it's a plugin?
<syncrondi> I don't remember installing a plugin to get thte capability
<jam> syncrondi: "lp:bzr-push-and-update"
<syncrondi> when I do just a push, I get bzr: ERROR: No push location known or specified.
<jam> definitely a plugin
<jam> syncrondi: for "bzr push" if you haven't told it where to push before, how would it know?
<jam> "bzr push $URL"
<jam> and then future pushes will use $URL if not given
<syncrondi> ah
<syncrondi> Hmm, it looks like the plugin is only for linux, but I definately never used it on Linux before
<jam> syncrondi: not at all
<jam> It needs access to "ssh"
<jam> though it could be updated to not have that dependency
<syncrondi> oh, ok
<jam> (and use the python 'paramiko' library)
<jam> there is an open bug on that
<syncrondi> I've been putting off installing the paramiko library
<jam> syncrondi: well, on windows you either need paramiko or ssh anyway
<jam> plink is possible, but really doesn't work well
<syncrondi> I've been using plink for a while without hitch on another system, but a friend helped me set it up
<syncrondi> Now with my other box, I've had some tough luck getting everything working
<syncrondi> bzr push seems to be working now that I've included the URL
<syncrondi> But what's the difference between that and push-and-update?
<jam> syncrondi: so the main issue is auth support for paramiko
<jam> which is... poor
<jam> but as long as you only use pageant, it should be ok
<jam> 'bzr push' will push the history changes to a remote location
<jam> but won't update a remote working tree
<jam> 'push-and-update' goes out and after pushing the history, runs "bzr update" on the remote host
<syncrondi> ok
<syncrondi> So I can just run them separately
<jam> syncrondi: well, if you *need* to have a remote working tree, and update it, yse
<jam> yes
<syncrondi> thanks jam
<jam> many use cases don't require a remote working tree
<syncrondi> What do you mean by 'don't require' ?
<jam> syncrondi: if you are sharing your code between developers
<jam> you don't need a working tree on the shared server
<jam> just the *history*
<syncrondi> It's a live site. :)
<jam> the cases for having a working tree tend to be stuff like "I want to maintain my http website on a remote server"
<jam> note that you *might* prefer the 'bzr-upload' plugin for tha
<jam> that
<syncrondi> What are the advantages of the bzr-upload?
<jam> syncrondi: many people maintaining a live site *don't* want the history copied there
<jam> in case there is a security breach in the http requests
<jam> exposing the history of the site to 3rd parties
<syncrondi> ah, ok jam.
<jam> also, bzr-upload works over things like ftp
<syncrondi> which is insecure, no?
<syncrondi> I'd rather stick with the ssh.
<jam> syncrondi: many hosting sites only let you upload via ftp
<jam> so not an option
<jam> if you are in control over the server
<jam> *I* would probably use a bzr lightweight checkout
<jam> and "ssh host; cd website; bzr update"
<syncrondi> I see
<syncrondi> You've been very helpful. Thanks jam. I'm not the only one running the show, so I've been just going with the flow so far.
<syncrondi> Hm. I'm seeing an actual update on the server side
<syncrondi> not*
<nyu> is it possible to retrieve a snapshot of a shared-repo atomically?
<syncrondi> I wouldn't be sure how to do that nyu
<syncrondi> I'm not even sure how to install the push-and-update plugin, jam
<syncrondi> I feel like a frickin' noob at this.. because I am
<jam> nyu: not easily. If it is a requirement, I would suggest staging it to another location, and then using that.
<jam> 'bzr pull' etc know how to get a stable view of the data.
<jam> Which you could emulate, but requires copying things in a specific order
<jam> (read all the branches first, then read file X, then Y, etc.)
<jam> quite a bit easier to just do:
<nyu> jam: could I then pull all branches automatically?  I know multi-pull, but AFAICT it only pulls branches I already have locally
<syncrondi> I branched the push_and_update plugin to my plugins folder, but I still get the error with unknown command.
<jam> nyu: for b in `bzr branches`; ...
<jam> syncrondi: make sure 'bzr help plugins' mentions it
<nyu> oh
<nyu> 'bzr branches' looks useful
<jam> and then it is probably just "bzr push" and it will check to see if the remote has a working tree, and if so spawn "ssh host bzr update"
<syncrondi> jam:
<syncrondi> bzr plugins doesn't mention
<nyu> jam: I see, thanks
<jam> syncrondi: where did you actually put it, and what did you call it
<jam> on linux
<jam> cd ~/.bazaar/plugins
<jam> bzr branch lp:bzr-push-and-update push_and_update
<jam> on Windows
<jam> cd %APPDATA%/Bazaar/2.0/plugins
<jam> IIRC
<syncrondi> Yeah, I just did a bzr branch https://launchpad.net/bzr-push-and-update push_and_update  on C:\Program Files\Bazaar\plugins
<syncrondi> I should put it in appdata, jam?
<lifeless> jam: working towards it
<jam> lifeless: sure. I'm also still seeing skips as failures
<lifeless> the subunit protocol branch  is most of the way there, the details api seems nice, want to get a TestCase test-code support
<lifeless> jam: land vila's branch
<lifeless> if you like - bug, uhm,
<jam> https://code.launchpad.net/~vila/bzr/419776-subunit/+merge/14413 ?
<jam> doesn't seem the right one
<jam> bug #419776
<ubottu> Launchpad bug 419776 in bzr "selftest --subunit output incompatible with --parallel=fork" [Medium,Fix committed] https://launchpad.net/bugs/419776
<jam> I thought it was *your* branch that does it
<lifeless> ye sthat one
<jam> or are you saying a branch of subunit?
<lifeless> no
<lifeless> so my branch for bzr, which is landed, fixes things for the upstream API
<lifeless> released subunit though has a bug itself, in that its serialiser doesn't have addExpectedFailure
<lifeless> *and* the downgrade logic makes that a fail not a success
<lifeless> vilas branch just changes bzr to use the same logic the next release of subunit will, to degrade in that case to success
<lifeless> my protocol branch of subunit has addExpectedFailure on the subunit serialiser
<lifeless> I may backport that to subunit trunk when I get a minute
<jam> lifeless: well, I'll submit vincent's patch, since I *did* approve it :)
<jam> as did you it seems
<lifeless> http://feeds.laughingsquid.com/~r/laughingsquid/~3/iTCZZ6YbvfE/ <- wow
<lifeless> jam: shame to hear about the flight snafu
<jam> lifeless: for those who don't get enough rock band/ etc
<jam> lifeless: thanks for your sympathy
<jam> I suppose it means I got some quality hacking done with a real power supply :0
<lifeless> :)
<lifeless> 3 minutes and I run out of free wifi apparently <>
<lifeless> you'd think, with a plane ticket they could throw in 5$ of bandwidth
<jam> lifeless: :)
<jam> you'd think the same thing about a $200/night hotel
<jam> lifeless: what is the subunit command that you can then pass to "bzr selftest --load-list" ?
<jam> ah, perhaps subunit-ls
<Peng> Stupid question: How do you make --no-strict the default when pushing? An alias?
<syncrondi> Another stupid question: How can I unlock a file that bzr locked, preventing me from doing a commit?
<syncrondi> Apparently, I'm HM
<syncrondi> xD
<Peng> "unlock"? In what way?
<syncrondi> ::    Unable to obtain lock file:///C:/Documents%20and%20Setting....
<Peng> Oh god, Windows. :P
<Peng> Pastebin the full error. If you're sure bzr isn't running, "bzr break-lock" will probably fix it, depending on the problem.
<syncrondi> held by syncrondi@host on host host[process #1712] locked 21 minutes, 27 seconds ago Will continue to try until 21:42:20, unless you press Ctrl-C If you're sure that it's not being mdified, use bzr break-lock
<syncrondi> but the break-lock doesn't work
<syncrondi> it complains that it isn't a branch
<syncrondi> wait
<syncrondi> I don't need all that jibberish after the command
<syncrondi> it was saying I needed to have some arguments, but it worked without arguments
<Peng> Yeah, "bzr break-lock" defaults to the current directory if you don't specify a path/URL. That trips people up a lot.
<syncrondi> Thanks Peng!
<Peng> :)
 * jml considers dinner plans
<fullermd> jml: I suggest eating.
<jml> *yawn*
<gour> morning
<gour> i've read that bzr's interoperability with hg is not as good as with git & svn repos...what can be done atm?
<gour> i need to keep hg repo of the project in sync, but have lot of problems using forest extension with my flakey internet (mobile 3g) connection and wonder if i could convert repo to bzr locally and somehow pull and commit from bzr?
<LarstiQ> gour: it needs more work :)
<gour> LarstiQ: anything works now?
<LarstiQ> gour: yeah, jelmer has been improving it lately I gather
<gour> LarstiQ: is it in 2.1 trunk?
<LarstiQ> gour: I'd assume it's in lp:bzr-hg
<gour> here i've 2.0.0
<gour> ahh, let check it at lp
<gour> hg's subrepos is not quite ready, hg does not have, afaik, working fast-export/import...:-/
<gour> hmm, web says: "
<gour> A plugin for bzr which provides support for Mercurial file formats. It currently allows pulling from (and eventually pushing to) hg repositories."
<LarstiQ> the description might be old, I'd look at the recent revisions / NEWS
<gour> ok, let me pull it
<gour> i've installed plugin, created new bzr repo and tried to pull from it, but get: bzr: ERROR: No module named hg.ui
<gour> i cannot see anything similar in bugs
<gour> jelmer: shall i open a ticket for the above problem?
<LarstiQ> gour: have you got all dependencies installed?
<gour> LarstiQ: hmm, i just pulled the plugin
<LarstiQ> gour: not sure if hg.ui is part of standard mercurial, or maybe version differences
<gour> LarstiQ: hg works here
<LarstiQ> gour: can you `python -c 'import hg.ui'`?
<gour> LarstiQ: ImportError: No module named hg.ui
<gour> i'm still not sure about hg.ui extension/module
<elroboto> back
<gour> LarstiQ: i.e.i believe it's due to [ui] section in my ~/.hgrc
<LarstiQ> gour: maybe, what does google say? And what happens if comment the ui section out
<gour> LarstiQ: commenting ui section does not help
<gour> otoh, "from mercurial import hg, ui" works
 * gour submitted bug-report
<gour> hmm, 'make check' for bzr-hg fails as well
<gour> hmm, this line is the problem: from bzrlib.plugins.hg.ui import ui
<gour> bze cannot find the plugin which is installed in ~/.bazaar/plugins
<gour> *bzr
<gour> but i wonder how is it that 'bzr plugins' lists the plugin?
<elroboto> hello, i want to create a bzr store, but without publishers, i want the contributors commits to be publish automatically
<elroboto> how to do that?
<gour> LarstiQ: the problem was that i did not run: python setup.py build_ext -i in plugin dir
<LarstiQ> gour: aha
<bialix> hi garyvdm
<nyu> is fast-export atomic?
<bialix> in which sense?
<nyu> hi bialix
<bialix> hi nyu
<nyu> i.e. if I fast-export from a remote repo while someone is pushing
<nyu> I assume fast-export will always obtain a consistent snapshot?
<nyu> hi phcoder
<bialix> IIUC it should keep read lock and will use only latest branch tip as of operation start
<nyu> jam said yesterday "'bzr pull' etc know how to get a stable view of the data." but didn't mention fast-export
<bialix> but there is possible quirks with repo re-packing
<bialix> nyu: without looking at the fast-export internals I'd say most likely it uses the same code as pull to get revisions from repo
<nyu> I don't understand read lock.  do you mean write lock?
<bialix> but I can't be 100% sure
<bialix> bzr has both read and write lock on internal structures
<phcoder> hello all. I fast-imported my old repo but some branches are missing because they were merged in other branches. Can I somehow create a branch from commit-id?
<nyu> to get stable reads either you use atomic test-and-set operations or you lock writes, right?  I don't understand what locking reads means
<bialix> if somebody pushes then dest repo will be write locked, therefore attempt to read lock it will fail
<nyu> ah, ok
<bialix> write lock excludes readers
<bialix> phcoder: just branch from desired revision
<nyu> shit, I think I was lectured on this less than 6 months ago.  I forgot everything
<nyu> thanks bialix, I remember now :-)
<bialix> :-)
<phcoder> phcoder@debian:~/grub2/bzr-new$ bzr branch -r phcoder@gmail.com-20091106215044-ehljkps46fa20o1s mips-all mips
<phcoder> bzr: ERROR: No namespace registered for string: u'phcoder@gmail.com-20091106215044-ehljkps46fa20o1s'
<bialix> bzr branch -r revid:phcoder@gmail.com-20091106215044-ehljkps46fa20o1s mips-all mips
<bialix> phcoder: ^
<bialix> `bzr help revisionspec` may help
<mathepic> Is there any file in the .bzr directory that gives you just the current revision? (Trying to use current revision as a dependency in the Makefile, since one of my scripts depends on the revision)
<LarstiQ> mathepic: Use `bzr revno` or `bzr version-info`
<mathepic> Yeah, but I need to know when `bzr revno` in the makefile changes.
<mathepic> oh, hmm
<LarstiQ> is that an "oh, hmm, I figured it out"? :)
<mathepic> No, its "hmm, I think I see your point"
<LarstiQ> ok
<mathepic> Would make be able to find the change in the shell output from the call `bzr revno`
<LarstiQ> you could cache it for one, and use a .PHONY target
<LarstiQ> mathepic: but maybe it's good to take a step back and look at what task you're trying to accomplish with this mechanism?
<mathepic> Generation of a header file for use in the main program
<mathepic> It uses bzr version-info to get it, but then the output of course would change when the revision changes, so it needs to be run again
 * LarstiQ waits for mathepic to come back
<phcoder> bialix: thanks. I'll look into it after restoring our experimental branch
<bialix> mathepic: is it your question on stackoverflow about Makefile and revnos?
<bialix> phcoder: looking into it? into what?
<phcoder> phcoder: into restoring my branches which were merged
<bialix> LarstiQ: hi, when and if mathepic will come back say him he had answers on his SO question
<LarstiQ> bialix: I will remember to tell him that
<bialix> here is http://stackoverflow.com/questions/1694264/how-to-make-dependency-in-makefile-so-that-target-is-built-when-bazaar-revision-c
<cody-somerville> how can I see which revision two branches diverged at?
<LarstiQ> cody-somerville: I'd use `bzr missing`
<GaryvdM> bialix: Hi - I think my network connection sorted now
<bialix> Hi GaryvdM !
<GaryvdM> bialix Any other regressions other than Bug 478239?
<ubottu> Launchpad bug 478239 in qbzr "treewidget missed checkboxes for dialogs that require them" [Critical,Fix released] https://launchpad.net/bugs/478239
<GaryvdM> bialix: Otherwise I would like to release 0.16 now.
<GaryvdM> Oh - Just noticed Bug 47827
<ubottu> Launchpad bug 47827 in vmware-player "vmware-player lintian warnings" [Medium,Invalid] https://launchpad.net/bugs/47827
<GaryvdM> I mean Bug 478277
<ubottu> Launchpad bug 478277 in qbzr "Test test_model_working_tree failed: list index out of range" [Undecided,New] https://launchpad.net/bugs/478277
<bialix> GaryvdM: I'll update by qbzr copy right now, have no more bugs off hands
<bialix> GaryvdM: what about https://bugs.launchpad.net/qbzr/+bug/475286
<ubottu> Launchpad bug 475286 in qbzr "Tools/Plugins not working - bzr: ERROR: exceptions.IndexError: tuple index out of range" [High,Confirmed]
<GaryvdM> bialix: I don't think it is a regression, but it should be easy to fix.
<bialix> it seems it's already fixed
<bialix> lemme check
<bialix> no, it's not
<bialix> I'll fix it, wait 15 mins
<GaryvdM> Cool - 478277 is going to take me a while, because I'm having a failer in that test, due to a pyqt 4.6.0 bug, so I'm going to have to upgrade to 4.6.1
<bialix> GaryvdM:  bug 475286 is not regression per se, but traceback in qbzr is bad
<ubottu> Launchpad bug 475286 in qbzr "Tools/Plugins not working - bzr: ERROR: exceptions.IndexError: tuple index out of range" [High,Confirmed] https://launchpad.net/bugs/475286
<bialix> GaryvdM: done, pushed
<bialix> cody-somerville: qlog is your friend ;-)
<nyu> how can I incorporate a file from one unrelated (no common ancestor) branch to another without losing history?
<elroboto> hello, i want to create a bzr store, but without publishers, i want the contributors commits to be publish automatically, how to do that?
<GaryvdM> nyu: Dose the other branch have file other than the one you want to import?
<GaryvdM> elroboto: I'm not sure I understand you correctly, but if you create a public place that people can push to, other people will be able to pull stright away?
<GaryvdM> elroboto: I'm not sure what you mean by "without publishers"
<bialix> nyu: fast-filter the file first, then merge filtered branch
<bialix> but you will lose liason to original history
<nyu> bialix: uhm this discards original history?
<nyu> GaryvdM: they're totally unrelated branches, with different files
<bialix> filtered history will have new revision-ids and file-ids
<nyu> GaryvdM: i.e. one project borrowing files from another
<nyu> bialix: oh, that's ok
<nyu> bialix: but it'll have whole history of the imported file?
<bialix> most likely
<nyu> ok thanks
<bialix> fast-filter can't support moves of files between directories
<bialix> otherwise it's ok
<bialix> try it
<bialix> you now almost expert in it ;-)
<nyu> hehe
<gmb> Hi.
<gmb> I might be having a case of the stupid, but I'm having trouble installing bzr 2.0 from the PPA on Hardy
<gmb> because of the following error: "bzr: Depends: python-central (>= 0.6.7) but 0.6.5ubuntu1 is installed."
<gmb> Does anyone have any advice for eliminating my stupid?
<GaryvdM> gmb: Acording to https://edge.launchpad.net/ubuntu/+source/python-central/ , hardy-updates has python-central 0.6.7
<gmb> GaryvdM: Aaargh. I have the dumb. Not only is the hardy-updates line commented out in sources.list, it actually points to feisty, not hardy. God knows what I was tripping on when I upgraded.
<gmb> Thanks for that!
<gmb> Yep, that fixed that and a number of other things. Awesome.
<gmb> GaryvdM: Thanks again :)
<GaryvdM> gmb: It's a pleasure.
<Alcmene> Hi there!
<Alcmene> Anyone available for a bit of help?
<Alcmene> Well, let's try anyway  :s
<Alcmene> Abstract: checkout permanently out of date
<Alcmene> symptoms: last part of http://osdir.com/ml/bazaar/2009-08/msg00479.html
<Alcmene> in short:
<Alcmene> inside a working repo, a checkout from another on an ftp
<Alcmene> bzr up > "tree is up to date"
<Alcmene> bzr ci --local â¦
<Alcmene> bzr ci --local â¦
<Alcmene> bzr ci > "bound branch is out of date with master branch"
<Alcmene> of course, this is not true
<Alcmene> done this twice already, no changes
<Alcmene> any ideas?
<LarstiQ> but it is
<LarstiQ> Alcmene: `bzr up` after the --local should pivot them away, but you might prefer pushing those revisions to master first
<Alcmene> I don't get it  :s
<Alcmene> I don't mean to update my working tree
<Alcmene> but the distant repo only
<Alcmene> plus, if I _do_ update, it of course reverts to the version on the server, which is the one before all my local commits
<LarstiQ> Alcmene: then just `bzr push`
<LarstiQ> (to the master)
<Alcmene> yes, ok, but why does it tell me this??
<LarstiQ> Alcmene: you're trying to commit, but your local branch is not at the same revision as the master
<LarstiQ> hence, it tells you to sort that first
<Alcmene> mmhâ¦ I get it, but it still sounds like a very strange way of telling it IMO
<Alcmene> and I'm almost sure I already did this without a problem
<LarstiQ> Alcmene: the message itself tells you to run `bzr update` and then commit, did you try that?
<Alcmene> yes!
<bialix> GaryvdM: ping
<Alcmene> but updating _reverts_ : it updates to the tip of the distatnt repo, which is the same as reverting to the last no-local commit
<LarstiQ> Alcmene: no
<LarstiQ> Alcmene: it pivots your local commits as pending merges
<Alcmene> well, how come a bzr stat after the update didn't show me _anything_ then?
 * LarstiQ tried it locally and it works exactly as advertised
<LarstiQ> Alcmene: that I don't know, but if you can give instructions on how to reproduce that I'd like to try
 * Alcmene backs up his local tree before trying it, and will tell the result in 2 minutes
<Alcmene> luckily most of the commits were merges, 'cause I would have lost a lot
<LarstiQ> all your local commits are still in your local repository
<LarstiQ> not too hard to retrieve with `bzr heads`
<Alcmene> :| wtf
<Alcmene> well, ok, I know I'll sound like an asshole right now
<Alcmene> bzr up did do the trick
<LarstiQ> why would that make you sound like an asshole?
<Alcmene> I swear it did the opposite yesterday
<Alcmene> because I have wasted your time for no reason!
<LarstiQ> hah :)
<LarstiQ> such is triaging
 * LarstiQ doesn't mind
<Alcmene> well, I must have made a mistake yesterday evening, was in a rush
<Alcmene> sorry again, thanks a lot LartstiQ
<LarstiQ> Alcmene: np :)
<bialix> GaryvdM: I've made one more last-minute-fixes commit. Now I think road for 0.16 is free
<GaryvdM> bialix: pong
<GaryvdM> was waiting for pyqt 4.6.1 to finish building
<bialix> GaryvdM: I've made couple of minor fixes for new cmd logging feature
<bialix> GaryvdM: I understand
<bialix> bzr qlog
<GaryvdM> bialix: I got my tests passing now. But I don't see Bug 478277
<ubottu> Launchpad bug 478277 in qbzr "Test test_model_working_tree failed: list index out of range" [Undecided,New] https://launchpad.net/bugs/478277
<GaryvdM> bailix: fix is simple, but will you please test it before I push to trunk.
<bialix> where is your fix/patch/branch?
<hsn> after updating to 1.18 push is pretty fast
<GaryvdM> bialix: lp:~garyvdm/qbzr/Bug478277
 * bialix branching
<bialix> hsn: you may want to thanks lifeless and spiv I guess
<bialix> GaryvdM: tests passed; please land it
<GaryvdM> cool
<lifeless> abentley: awake?
<abentley> lifeless: yep.  Good morning!
<lifeless> I'm on a demo plan from a nearby wifi hotspot - do you know details about how we;re meant to get wifi?
<lifeless> and / or breakfast?
<lifeless> I checked in late last night - semi automated, so have no clue :(
<abentley> lifeless: No wifi here.  DSL in every room.  We're on our own for breakfast.
<abentley> lifeless: I can drop in on you in, say 10 minutes if you like.
<abentley> lifeless: Or you can call me in room 50
<wade2> Hi guys...is there any way I can troubleshoot what appears to be a SSH hang with bzr?  (using a sftp URL)...I got one the other day, and now my programming colleague is getting one when trying to do a merge - he issues the merge command, it asks for the password and then it just hangs
<LarstiQ> wade2: ~/.bzr.log, possibly with some debugging flags (bzr help debug-flags)
<wade2> Ok, thanks
<RenatoSilva> does anyone has had problems using bzr in ubuntu with ntfs partitions
<mneptok> NTFS is usually mounted read-only. have you mounted the partition is question rw?
<mneptok> s/is/in/
<RenatoSilva> yes rw
<RenatoSilva> the problem is that bzr detect permission changes
<RenatoSilva> becxause of this I don't want to use it, I'm afraid of confusion
<RenatoSilva> I mean, I would like to use bzr in ubuntu, but can't becasue of this problem
<GaryvdM> RenatoSilva: I tried that the other day. It kept on telling me the x bit had change.
<GaryvdM> RenatoSilva: I ended up just branching on to a ext4 drive
<RenatoSilva> GaryvdM: I think that's it, don't want to test it now :)
<GaryvdM> RenatoSilva: Pulling and Pushing should work fine. It's just working with a Working Tree that is problematic.
<RenatoSilva> GaryvdM: I don't understand
<RenatoSilva> GaryvdM: nothing has changed, so it should not tell the contrary
<RenatoSilva> GaryvdM: I don't understand why does it consider permission changes. Do bzr store them in the metadata, the permissions?
<GaryvdM> RenatoSilva: x (execution) does not get stored by ntfs, so the linux ntfs driver just says every thing is executable.
<GaryvdM> RenatoSilva: bzr stores this because it is important for unix dev
 * RenatoSilva is going to windows to work in bzr, brb
<GaryvdM> Moring jam
<jam> morning GaryvdM
<jam> just got into Sydney
<GaryvdM> *morNing
<jam> still about 4-5 hours out from making it to the sprint
<jam> how's things with you GaryvdM?
<GaryvdM> Good
<GaryvdM> About to announce qbzr 0.16
<GaryvdM> Hi vila
<vila> hey :)
<GaryvdM> vila, jam: how is the jet lag?
<jam> hi vila
<jam> I'm usually pretty good about jet lag
<vila> hey jam !! Where are you ?
<jam> but tomorrow is going to be the real test
<jam> vila: I made it to Sydney, waiting 2hrs for my flight to BNE
<jam> then another hr flight, and an hr bus ride
<jam> plus I think another 1hr wait for the bus?
<vila> I so totally suck at jetlag :-) For the last three nights: I slept 0/4/4 hours :-/
<GaryvdM> ouch!
<jam> Given that I left my house, Friday @ 3pm, I've still got a ways to go
<vila> jam: I can't tell for the bus wait, but the trip itself is around 2hm door-to-door
<jam> :'-(
<jam> :'(
<jam> vila: it is monday, right?
<vila> jam: yeah, that sucks, I saw your mails, but rejoice, things could be worde :-)
<vila> jam: yes it is
<GaryvdM> jam: wow - That a long time
<vila> s/worde/worse/
<jam> GaryvdM: mechanical problems in Chicago caused the plane to be delayed, so I missed the flight to sydney
<jam> and there is only 1 per day
<jam> I'm currently at 48 hours of absolute travel time, and have ~6 more to go
<GaryvdM> jam: It just turned Monday for me.
<jam> a day in SF isn't terrible
<jam> but I didn't really *want* to be there
<vila> by that I mean I've been delayed myself 4 hours in London for th london->singapore flight with a 2hours wait in singapore meaning I'll miss the singapore -> brisbane flight
<GaryvdM> jam: If I want to build the windows installer without vs 2008, is it easy to disable the tbzr part?
<vila> fortunately the plane wait for us in singapore so I made it in time in brisbane just to learn that my luggage has been lost :-)
<GaryvdM> vila: Oh no
<GaryvdM> vila: that really sucks
<jam> vila: yeah, I was trying to think whether I would get luggage in Sydney if I made the flight
<jam> however, I have an email in my inbox
<jam> dated about 1hr after takeoff
<jam> saying that I had been rebooked
<jam> so they pretty much determined "you aren't making it, we're rebooking you" before the plane was anywhere close to landing
<jam> even though we made it with about 10min to space
<jam> spare
<jam> if they would have been able to actually park at the terminal
<jam> (though 10min before departure, not 10min before boarding.)
<jam> vila: anyway, /wave to everyone there for me. Discuss lots, I'll have you fill me in over dinner or something :)
<vila> hehe, yes :) They say they should deliver it in the following 24h, still a couple ones to wait and then... off to the shops for brand new clothes :)
<vila> I've yet to find the others, in fact I came here to see if they wawere connected already ")
<GaryvdM> vila: lifeless and abentley were around just now.
<vila> GaryvdM: thnks, but they don't seem to be anymore :) Well, time for some real life investigations then :)
<GaryvdM> vila:
<GaryvdM> vila: abentley wrote: Or you can call me in room 50
<jam> vila: yeah, my other problem is that Syd => BNE was a different air carrier
<jam> so if my bags got lost, they would be lost in Syd, far away from Mooloolaba
<jam> I'm sorry to hear your bags failed you this time
<jam> but hey, its sunny there, right? So you don't really need much clothing :)
<GaryvdM> lo
<GaryvdM> lol
<vila> yeah, pretty much, only the swinsuit was in the bag :)
 * vila afk, even phone reaches nobody, I really need to move that a.. of mine :)
<offby1> Ignorant, non-manual-reading noob here ... So I just did a "bzr checkout --lightweight", edited a file, and typed "bzr commit", and was surprised to see "bzr: ERROR: Cannot lock LockDir(http:// ... ): Transport operation not possible: http does not support mkdir()
<offby1> I instead expected bzr to just commit my file.
<offby1> So: does --lightweight mean something like "act like Subversion"?
<idnar> I think that's roughly accurate
<idnar> a lightweight checkout depends on the remote branch for all operations
<offby1> ah
<idnar> although bzr commit would still have failed on a regular checkout, I think
<offby1> oh really?
<idnar> but bzr commit --local would have succeeded
<bob2> normally checkouts are actually branches, so you can commit to them without access to the remote (but the change will be autopushed).  with --lightweight, it's not.
<offby1> Maybe I'm misunderstanding "commit" then.
<offby1> let's try that
<bob2> --local would have worked if it was non-lightweight
<offby1> ah.
<idnar> bzr checkout (no --lightweight) gives you a "bound branch"; committing to a bound branch is basically like committing and then pushing
<offby1> so by default bzr discourages decentralized operations?  (That's not a flame, even if it kinda sounds like one)
<idnar> bzr branch will give you an "unbound barnch"; I suspect that's what you're looking for?
<bob2> offby1: not really
<idnar> er, "unbound branch"
<offby1> I have trouble keeping all these DVCs straight :)
<offby1> "Bound Branch" sounds suspiciously like the name of a town in New Jersey
<idnar> you can use "bzr reconfigure" to switch between the different types
<offby1> (well, Bound Brook)
<offby1> idnar: oho!
<idnar> for example, in this case, it sounds like you'd want to do bzr reconfigure --tree
<idnar> which gives you an unbound branch with a working tree
<offby1> idnar: would I want "--standalone" also?
<idnar> that probably wouldn't do anything, unless you already set up a shared repository
<offby1> huh.  OK, trying --tree now.
<offby1> (Probably time for me to re-read the docs; I suspect bzr has changed significantly since I last read 'em)
 * offby1 suspects --tree is working: "iftop" shows lots of data being downloaded
<jam> GaryvdM, vila: on the plus side, 48 hours has given me time to get down to 7 test suite failures on win32
<jam> (--no-plugins)
<jam> and  I haven't run the full suite in a bit
<jam> since it takes... 2hrs to run
<GaryvdM> jam: Nice
<GaryvdM> I noticed the flood of merge requests...
<GaryvdM> jam: I'm not sure if you saw my eairler question about the windows installer?
<jam> GaryvdM: 'earlier' ? I don't remember one
<GaryvdM> jam: If I want to build the windows installer without vs 2008, is it easy to disable the tbzr part?
<jam> GaryvdM: bialix has done so
<jam> I have not tried
<GaryvdM> jam: how dissimilar is it to how you do it?
<jam> GaryvdM: do you mean completely (like with mingw) or just using 2008 Express Edition?
<jam> naoki also has a version of tbzr that doesn't need Standard edition, but is missing a couple small features
<GaryvdM> jam: I don't mind installing vs 2008 express
<jam> GaryvdM: so I would trust 2008 EE slightly more than mingw, as I do all of my bzr development with it
<jam> (mingw for python2.5, though)
<jam> I don't know what bialix did
<jam> you might try grabbing lp:bzr-windows-installers
<GaryvdM> jam: I would like to help with that for releases, but I want to familiarise my self with the process first.
<jam> and see if you can get around the TBZR configuration steps in
<GaryvdM> jam: will do
<jam> tools/win32/buildout-templates/bin/build....bat.in
<jam> GaryvdM: so at the moment, I connect to our shared Windows host, and run "make PYTHON=/cygdrive/c/Python25/python"
<jam> I'm considering getting rid of make completely thouh
<jam> though
<jam> as it is the only step that needs it
<jam> and all it does is run some bootstrapping commands
<GaryvdM> ok
<jam> Our build routines have a lot of unnecessary dependencies, etc.
<jam> like 'cogapp'
<jam> GaryvdM: you may also want to check out: lp:///~jameinel/bzr/windows-setup
<jam> which has a new doc file
<jam> where I'm outlining what it takes for me to set up the EC2 instance
<jam> there are some fiddly bits
<GaryvdM> ok - cool
<jam> like hacking distutils for python2.4
<jam> but it outlines dependencies, etc.
<jam> and 'setuptools' does help for a lot of things
<jam> note that we don't build on EC2 yet, though,  so the doc is probably incomplete
<jam> I feel like we're pretty close
<jam> only really missing VS 2008 Standard
<jam> GaryvdM: at that point, building could be "start an instance of this EC2 snapshot, connect, run build, copy the installers"
<jam> decisions decisions
<jam> I'm hungry
<jam> but so is my laptop
<jam> ...
<GaryvdM> jam: I would choose food!
<visik7> http://planet.bazaar-vcs.org/ generate a broken feed
<visik7> the Item inside the feed haven't a link
<visik7> 		<link href=""/>
<visik7> the atom feed
<visik7> also the rss 2 and 1
<jam> GaryvdM: well, I guess I'll see you in a few hours then. I'm off to forage
<GaryvdM> visik7: The main html page is also missing like to the posts. :-(
<visik7> yep
<jam> GaryvdM: you can get there from the User link
<jam> but yeah, the links are wrong for wordpress feeds
<GaryvdM> jam: I'll be in bed then - so good night.
<visik7> wordpress ?
<vila> jam: the meeting room # is 63, just in case. See you later
<jam> thanks vila
<GaryvdM> Another bug with our planet (or the bzr dev blog) is that it cuts the posts from the bzr dev blog short.
<GaryvdM> Woot qbzr 0.16 finally out!
#bzr 2010-11-08
<peitschie> NET||abuse: you said you have a branch on your local machine... is that a branch or a checkout?
<NET||abuse> branch
<peitschie> NET||abuse: did you do a pull or merge on your local branch to try and get the changes from the server branch?
<NET||abuse> pull
<spiv> vila: https://bugs.launchpad.net/bzr/+bug/672382
<ubot5> Launchpad bug 672382 in Bazaar "bzr config output for list values is ugly (affected: 1, heat: 6)" [Medium,Confirmed]
<poolie> hi all
<spiv> poolie: hey, welcome back!
<poolie> hi there
<poolie> it's good to be back; those were not the smoothest flights i ever had
<spiv> I imagine Qantas is pretty chaotic atm.
<poolie> very
<poolie> there were something like 10 staff deadheading on our flight
<poolie> i guess they are moving a lot of people and equipment around to try to cope; the a380s probably carry nearly twice what the 747s do
<lifeless> poolie: lol - boeing considered a 650seat 747
<lifeless> poolie: the 400ER 3-class seats 416 according to  http://en.wikipedia.org/wiki/Boeing_747
<lifeless> poolie: and the A380 450
<lifeless> (from adding the numbers in http://www.seatguru.com/airlines/Qantas_Airways/Qantas_Airways_Airbus_A380.php)
<poolie> ok, and the a380 is somewhere around 650?
<poolie> ah, so not such a big difference
<poolie> i guess the qf a380s have a lot of business class seats
<lifeless> 72!
<lifeless> http://www.qantas.com.au/travel/airlines/a380/global/en agrees with the figures
<poolie> on my flight across they realocated some business seats to premium class, and some premium seats to economy
<lifeless> you were scheduled on an a380 flight ?
<poolie> on the way back i was meant to be on an a380 from lax-syd
<lifeless> nice
<poolie> i eventually flew on a 747 because all their a380s are grounded
<poolie> it was very chaotic
<poolie> some people had already been waiting around LA for three days
<lifeless> http://www.nzherald.co.nz/business/news/article.cfm?c_id=3&objectid=10686109
<lifeless> emirates seem to have an excellent deal there
<lifeless> (if you're paying in that bracket)
<poolie> i think this weekend is a great demonstration that you can pay 5 figures for a 1st class ticket and still be stuffed around for hours
<lifeless> for sure
<lifeless> as far as I'm concerned its all about the sleeping
<poolie> perhaps slightly more considerately, but they still have to stand around in the gate lounge wondering if they will ever leave
<poolie> me too
<lifeless> sleeping and power
<lifeless> and air NZ have power in economy ;)
<poolie> i used points to get premium to sfo on the way across, and ended up getting a business physical seat
<poolie> (with premium-grade food etc)
<poolie> and that was brilliant
<lifeless> poolie: -lol- nice
<lifeless> I'm surprised they bothered splitting your menu our
<lifeless> out
<spiv> poolie: hurrah!
<lifeless> ok, afkish
<poolie> i think they have semipermanently reallocated some rows to other classes
<poolie> hugh got a premium seat without technically being upgraded
<poolie> anyhow i'm just catching up on bills, mail stuff
<poolie> ping me if there's anything urgent
<spiv> *nod*
<vila> hi all !
* 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 | Release Manager: vila | 2.3b3 has gone gold, time to build the installers !  | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
 * KombuchaKip is unsure why his client randomly decided to log himself into #bzr
<gthorslund> hi vila!
<vila> _o/
<poolie> hello vila
<vila> poolie: hey !
<poolie> how are things with you?
<vila> fine ! A large plate for the week but I'm hungry :-P
<vila> pp'ing, releasing 2.3b3, more conflict resolution, bzr config bugs, plenty of fun ahead :)
<poolie> cool :)
<poolie> i've seen some of this
<poolie> the conflict features sound good
<poolie> it seesm like it's more in the way of user feedback than bugs as such?
<vila> hmm, right, the implementation is incomplete so that first triggered a bug, but that's still incomplete. I think I can implement --prefer-this/--prefer-other/--take-both quite easily now (which is why I didn't implement --take-this/--take-other for text conflicts in the first place)
<vila> deep down though, the bug is revealing a hole in the test coverage (big surprise :-)
<vila> oh, and I'd like to switch to sphinx for good too (bug I'm not sure I will be able to tackle this one *this* week ;)
<fullermd> Getting lazy in your old age or somethin'?   :p
<vila> hehe
<vila> my age always seem to inversely proportional to the fun I have, or something ;)
<fullermd> Well, at least you spend less on bail money  ;)
<vila> oh, and I'd like to implement 'bzr gardener pull'  which should allow to mirror a set of branches with a single command
<poolie> that would be kind of nice
<poolie> it'd be better if it could get unified with other things that deal with sets of branches, like colo
<poolie> i may package that this week, if max and jelmer haven't already
<vila> well, there are a couple of long term ideas I'd like to implement there (colo and looms support included), so I'd prefer to keep it separated for now
<poolie> vila did john tell you anything much about uds?
<poolie> it was a good trip
<poolie> (well, the travel kinda sucked, but the meetings were good)
<vila> poolie: not that much, he seem pretty busy on other subjects these days...
<GaryvdM> Hi all
<poolie> when i get my thoughts in order i'll send an update
<vila> poolie: and I couldn't find the time to track UDS
<vila> poolie: cool
<poolie> i feel a bit more convinced we should focus together on a smaller set of topics
<vila> GaryvdM: hey !
<GaryvdM> vila: I should be able to build windows installers tonight
<poolie> and set them as goals for 2.3
<poolie> hi gary
<vila> GaryvdM: great !
<vila> poolie: my foci for 2.3 are conflict resolution, config, sphinx, automated installer build, nightlies, I'll stop there ;)
<jelmer> mwhudson: Did you manage to figure out what was wrong with the twisted branch?
<jelmer> 'morning vila, poolie, GaryvdM
<GaryvdM> Hi jelmer
<vila> there is certainly work to do on tree transform, in-memory trees for tests for which I may find simple steps to progress
<vila> jelmer: _o/
<poolie> hi there jelmer
<vila> poolie: in-memory trees is something I may start playing with in bzr-gardener where it will be easy to measure performance gains
<poolie> vila, i think those are all good things (and they're pretty much what i thought you were doing)
<vila> poolie: better ancestry graphs handling is a bit more work but again bzr-gardener would be a good sand box
<poolie> but i wonder if we should either get more people onto them too, or set specific targets for 2.3
<vila> poolie: I agree with the feeling but I haven't yet found the right means :-}
<poolie> generally speaking i'm not a big fan of putting time into estimation when you could just spend it doing things, but...
<vila> poolie: I have a bunch of notes about the next generation config I should submit (noted in my TODO) but it's still too much brain dump so far
<vila> poolie: yeah, it's even harder if you try to do time estimates if you don't do the work yourself
<vila> meh
<vila> it's even harder to do reliable time estimates for things you don't do yourself
<fullermd> That's never stopped my clients from telling me how long things should take...
<vila> hehe, funny, I explained that recently: first you estimate how long it will take, then the sales guy decides how much it will sell it and when the whole price is decided, a new schedule is deduced
<vila> somehow the sales guy always shorten the delay instead of the unit price, go figure why most projects are behind schedule after that...
<spiv> fullermd: perhaps the deal should be "you can tell me how long it will take if I can then tell you what the 'per-hour' rate will be"
<vila> spiv: oh, you *can* say that before the price is fixed, everybody always agree at this point :)
<fullermd> I was talking with this guy I work with the other week about our respective current projects, both of which are wildly beyond their original conceptions in every way.
<fullermd> Him: After this, I'm going to feel no shame at all about turning in astronomical estimates in the future.
<fullermd> Me: I said that the last 6 projects.  I've learned that I suck at astronomy.
<vila> fullermd: trivial details we don't want to hear about, what we care is: is is still the same price and the same delay, that's what you signed
<fullermd> Oh sure.  It's just not the same project anymore   :)
<vila> Me: but you said you wanted 'X' not half of the alphabet ! Them: don't start with the details again :)
<vila> poolie: do you have any pending mail for contributor agreements ?
<poolie> meaning new submissions?
<vila> yup
<poolie> from tzeentch?
<vila> exactly
<vila> ping losa, any news or feedback about rt #41340 ?
<vila> Does anyone know the IRC nick for nmb ?
<vila> aka Neil Martinsen-Burrell
<vila> poolie, nmb: Am I nitpicking too much if I prefer check_output=True over blank_output_matches_anything=False in  https://code.edge.launchpad.net/~nmb/bzr/662509-ignore-blanks/+merge/38889 ?
<vila> there is a slight ambiguity there that I fear will come back haunt us later...
<poolie> vila, i don't seem to have a mail about that from tzeentch
<poolie> i should go soon
<GaryvdM> vila: it seems he does use 'nmb' - see http://irclogs.ubuntu.com/2008/08/26/%23bzr.html
<vila> poolie: ok, I'll ping him via the review again then
<vila> GaryvdM: great, thanks
<poolie> to me 'check_output' doesn't make it so clear that this is specifically about the handling of blank output
<poolie> also i think generally if there's a varargs option that defaults to off, it's better to have the non-default state be thing=True
<vila> ok, then how about *empty*_output_matches_anything instead of blank_output_matches_anything
<vila> which is really the itching part
<vila> I still need to implement it for the test-script command anyway so I'm not asking nmb to do it
<poolie> so the difference between 'empty' and 'blank' is key?
<vila> poolie: well, 'key' may be a bit strong, but 'blank' in my mind means that a blank line is allowed which isn't true
<poolie> true
<poolie> ok, so s/blank/empty/ would be fine with me
<poolie> or even s//null
<vila> k
<vila> so I'll make a submission with this tweak and implement it for test-script in a superseding submission
<poolie> ok
<poolie> so it's good night from me...
<jbowtie> Just released bzr-tfs 0.3.0, with TFS 2010 and tfs.codeplex.com support
<jelmer> jbowtie: \o/
<GaryvdM> Bla - no python2.4/2.5 in lucid/mavrick
 * GaryvdM starts building karmic vm...
<vila> GaryvdM: err, I thought you can still install 2.4/2.5 in lucid no ?
<GaryvdM> vila: you can build from source, but you can't apt-get install
<GaryvdM> https://launchpad.net/ubuntu/+source/python2.5 - no lucid/maverick
<vila> GaryvdM: my bad, you're right
<vila> GaryvdM: I knew I had a VM for that, just misremember lucid instead of karmic ;)
<fullermd> All those adjectives sound alike to me  ;p
<maxb> GaryvdM: https://launchpad.net/~maxb/+archive/preserved may help for 2.5/lucid
<mgz> jbowtie: you should make a post in that IronPython vcs thread
<mgz> right, I'm off out.
<GaryvdM> maxb: Thanks.
 * GaryvdM waves to mgz
<vila> ping losa, any news or feedback about rt #41340 ?
<vila> mgz: rats, I missed you, ping me when you're back
<vila> ping LOSA
<vila> ping losa
<Chex> vila: good morning there
<vila> Chex: good morning !
<vila> Chex:  any news or feedback about rt #41340 ?
<Chex> vila: I am working on clearing a backlog of LOSA requests, give me a bit and  I will get back to you
<vila> Chex: sure
<elmo> hey, how do I get a specific branch using bzr-git?
<jelmer> elmo: hi
<elmo> bzr: ERROR: The repository you are fetching from contains submodules. To continue, upgrade your Bazaar repository to a format that supports nested trees, such as 'development-subtree'.
<jelmer> elmo: there's no way to do that at the moment (bzr lacks the UI to specify non-head branches), although you can import all branches using "bzr git-import"
<elmo> also, ^-- what?
<elmo> jelmer: ok
<elmo> I don't think i want to import all branches, that'd probably be rude
<jelmer> elmo: your repository contains git submodules, which can not be mapped to anything in bzr yet
<elmo> I guess I'll just have to face the music^Wgit
<jelmer> elmo: "git clone" will fetch all branches too, so I don't think it would too rude to fetch all branches
<jelmer> elmo: but yeah, for the moment you don't really have an alternative to using git if there are submodules.
<quicksilver> vila: are you an ediff expert?
<vila> quicksilver: ask your question, we'll see ;)
<quicksilver> vila: I had a conflict which had more 'regions' that it should have
<quicksilver> vila: two entirely different changes, coincidentally, shared a common line in the middle.
<vila> weird but better than the opposite no ?
<quicksilver> vila: I wanted to tell ediff "treat these two differences as one big difference"
<quicksilver> so that I could then press the button which means 'keep both'
<vila> why don't just you do it twice ?
<vila> quicksilver: you know you can edit the regions too and then ask ediff to keep whatever you want
<vila> ha no, you mean they shouldn't overlap the way they are displayed ?
<quicksilver> vila: takes a moment to explain.
<quicksilver> vila: tree A has "{preA}{common}{postA}"; tree B has "{preB}{common}{postB}"
<quicksilver> vila: correct resolution is "{preA}{common}{postA} {preB}{common}{postB}"
<quicksilver> vila: if I press "keep both" twice, I will get lines all interleave
<quicksilver> "{preA}{preB}{common}{postA}{postB}"
<quicksilver> vila: see?
<vila> yeah, so you need to edit manually then
<quicksilver> if I could say "treat this as one difference"
<quicksilver> then "keep both" would be the right thing.
 * vila nods
<vila> does it occur frequently ?
<quicksilver> in fact {common} was "my $self=shift;" which is a very common line in perl.
<quicksilver> likely to occur at the beginning of many functions.
<vila> yeah, as do '{' and such :-/
<quicksilver> yes, that would be another obvious example
<quicksilver> (although I've never had it happen with '{' I don't think)
<vila> weak point in the diff algorithm...
 * quicksilver nods
<LeoNerd> I've often wanted with diff to "pin" two lines, to say that a specific line on each side was the "same" line
<quicksilver> this is the first time I remember it happening exactly like this.
<vila> pretty rare given the few feedback we get on such cases
<quicksilver> vila: funnily enough I switched from emacs to Apple's Filemerge.app to resolve this one.
<quicksilver> and Filemerge did the right thing anyway.
<quicksilver> no idea why. It must have some heuristics for combining nearby regions.
<vila> but the conflicts were generated by bzr right ?
<quicksilver> yes.
<quicksilver> I gave filemerge all four files file{,.BASE,.OTHER,.THIS}
<quicksilver> and it worked it out.
<vila> so patiencediff, the algo we use, is *generally* better, partly because it found this common line :-/
<quicksilver> ;)
<vila> so Filemerge certainly use a different algorithm and recalculate the conflicts from scratch ignoring bzr proposals
<vila> I don't think we have an easy way to change the diff algo used by merge
<vila> there are discussions about that though
 * quicksilver nods
<quicksilver> I don't often get conflicts which annoy me
<quicksilver> but then again, we don't often let branches diverge all that far
<quicksilver> this was a particularly long-lived, far-diverged branch.
<vila> you can try 'bzr remerge <file>' with various options (but keep a copy of your file with your conflict resolution, remerge will destroy them)
<mgz> vila ping, but I'm only in for an hour.
<vila> mgz: ok, I wanted to ask about your connection hook mp
<mgz> goforit.
<vila> mgz: I think you should put it back in NeedsReview state so we can ping spiv :)
<mgz> that sounds reasonable.
<vila> I thought about it a bit more and I'm pretty sure we never reconnect because most of the time bzr+ssh is used and ssh never drops connections (or at least *I* never experimented that nor have I heard about such cases)
<vila> so until reconnect is implemented for smart mediums, we can have two hooks, one for smart medium and one for the other transports
<vila> they don't have to have the same signature at least to start with
<mgz> sounds like it would work.
<mgz> how much are we worried about burdening our future selves with interfaces we don't want any more?
<vila> even if not perfect, that would allow progress in the right direction
<vila> well, I don't know, but most probably at connection time you want to know the url and whatever info you can can gather about the client which is not much
<quicksilver> vila: hmm, right.
<quicksilver> vila: "weave" does a better job, for my needs, for this specific case
<quicksilver> vila: what I mean is that 'weave' treats it as one big difference region
<quicksilver> so 'keep both' is the right thing
<vila> quicksilver: honestly no idea, but that the one I would try first
 * quicksilver nods
<quicksilver> thanks
<quicksilver> ah no, it did something odd
<quicksilver> it took into account my local changes already
<quicksilver> hmm
<quicksilver> I think I needed to back out my changes before remerging.
<vila> quicksilver: it is supposed to do a better job for highly diverged branches
<vila> quicksilver: err, what ? remerge redo the merge, it's not supposed to do that on top of your modifications
<quicksilver> vila: I had already resolved the conflict
<quicksilver> it appeared to take advante of my current file
<quicksilver> the stuff in "TREE" contained the lines that, in fact, were never in "TREE"
<quicksilver> (they were only present in OTHER, but they were present in my locally resolved copy of course)
 * vila scratches head
<vila> quicksilver: make a backup, then 'bzr revert <file>' 'bzr remerge --merge-type weave <file'
<vila> >
<quicksilver> vila: OK, expected result now.
<quicksilver> vila: amusingly, smerge-ediff then "undoes" that improvment by automatically refining the diff when you enter ediff ;P
<vila> :)
<abentley> jam, james_w: recipe builds of lp:qtwebkit are causing problems because branching lp:qtwebit is taking lots of memory during the fetch.  My machine is up to 1G so far.
<james_w> abentley, is this what was the immediate cause of the rollback of lp-buildd during UDS?
<abentley> james_w: it seems likely.
<abentley> james_w: Our logging isn't very good, so I can't be sure about the precise cause.
<james_w> ok
<abentley> bigjools believes that the large memory consumption is causing excessive swapping, which reduces responsiveness, which breaks other builders because we're doing synchronous polling.
<james_w> abentley, I don't think it's a bzr-builder problem exactly? Just fetching with bzr shows the high memory usage?
<jam> james_w: my direct test showed about 1gb for a "bzr branch"
<jam> it is just a huge branch
<jam> wide and deep
<jam> (lots of files, lots of history)
<abentley> james_w: yes, but maybe we can avoid the problem in bzr-builder.
<jam> abentley: we killed the build earlier, not sure what to do right now
<abentley> jam: VmPeak:	 1487216 kB here.
<jam> abentley: 64bit machine?
<jam> (I was testing on 32)
<abentley> jam, no, 32.
<abentley> jam, AIUI 1G is the max physical memory we can hope for.
<jam> abentley: anyway it is arguably a bzrlib problem, but we don't have any quick-and-fast answers there
<jam> I cut it in half for bzr 2.2, but large branches still take a lot of memory
<jam> it is mostly the CHK stuff that is the problem
<abentley> jam, Okay, I wasn't sure what the status was.  Thanks.
<abentley> james_w: would it be reasonable to do lightweight checkouts instead of copying the branch?
<james_w> abentley, we could if we analyze the recipe to check if we will do a commit as we build it
<abentley> james_w: How do we determine whether we'll do a commit?
<james_w> abentley, I think commits are just done after merges currently, but I can't remember for sure
<abentley> james_w: they are done so that subsequent merges can use the correct parent information?
<james_w> abentley, yes
<james_w> nest-part as well now
<james_w> so pretty much every recipe will commit
<abentley> james_w: Okay, maybe stacked branches instead of lightweight checkouts?
<james_w> yes, that would work
<james_w> will that cut down memory usage in this case?
<abentley> james_w: Okay, I'll see if that actually cuts down memory usage.
<james_w> heh :-)
<jam> james_w, abentley: Except for the current bug that we refuse to commit in a stacked branch because of issues with stacking and basis inventories
<james_w> ah
<abentley> jam, doh.
<abentley> james_w: btw, nest-part is a partial merge, so its parent information should not be recorded.
<james_w> abentley, I assume that is taken care of
<abentley> james_w: Sorry, what do you mean by "nest-part as well now"?
<james_w> abentley, nest-part does a commit after doing the work
<abentley> james_w: I can understand that merge would do a commit after doing the work in order to allow subsequent merges to use the correct parent information.  Since nest-part cannot introduce parent information, why does it do a commit?
<james_w> abentley, I don't know
<mwhudson> jelmer: nothing more than was discussed here
<BasicOSX> bzr branch remote only gives me the .bzr directory, drawing a blank on how to get the actual files to work on. Anyone help me?
<lifeless> you've got a local notrees shared repo
<lifeless> 'bzr checkout .' will populate a tree on a branch
<jam> mwhudson: sorry about the email spam. I normally don't re-use branches, does it send 1 email per mainline rev?
<mwhudson> jam: it's ok, i can ignore email pretty effectively :)
<mwhudson> and yeah, one mail per rev
<jam> mwhudson: do you know if there is a decent way to check if a daemon has exited? (Namely, something that is not a child so you can't waitpid() on it)
<mwhudson> jam: not really, you can send the "signal" 0 to it if you had the pid and interpret the result
<jam> mwhudson: this is for the test suite. the mthaddon
<jam> noted that we needed a pid file
<jam> so that indicated I should be daemonizing
<jam> and I wanted to start and stop such a thing cleanly
<jam> and have the test suite wait for it to exit
<jam> but... not very easy to get right, from what I can tell
<exarkun> If you rely on PIDs, then there's race conditions
<jam> exarkun: there is, but I'm not worried about spawning 32k processes in the meantime
<exarkun> If the daemon is listening on a unix socket, then connect attempts to that socket will begin to fail after it exits
<exarkun> jam: It's not just processes.
<exarkun> Maybe it's just as unlikely to have a TID collision, but I don't know how TIDs are allocated.
<jam> mwhudson: I don't remember if you're a vim or emacs guy. Any chance you know about pyflakes + vim?
<mwhudson> jam: i've been using emacs for ~one third of my life now :-)
<mwhudson> jam: for the daemons, there is some hair in the launchpad code base for this already
<mwhudson> jam: lifeless has been working on it recently, i think there is a librarianfixture somewhere you could maybe crib from
<jam> mwhudson: I'm not sure if that is a long time or not :)
<mwhudson> although that might be oriented around twisted daemons, come to think of it
<jam> mwhudson: I went with a simple loop around os.kill(..., 0) and trapping ESRCH
<jam> mwhudson: mind if I nominate you to review the updated patch?
<mwhudson> jam: no
<jam> mwhudson: https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/40386
<jam> I don't know the specific urgency
<jam> I can't deploy to qastaging until that is fixed
<jam> but the l-o-s-
<jam> are out-of-town this week
<jam> so I may not be able to anyway,
<mwhudson> i really hope there's some library code somewhere you could have used rather than writing all that from scratch :/
<mwhudson> lifeless: hi
<lifeless> hi
<mwhudson> lifeless: i know you've been working on external process stuff for tests recently, can you look at https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/40386 ?
<peitschie> mornin everybody :)
<mwhudson> lifeless: and see if you know if there is library code for any of this?
<lifeless> there is in twistd
<mwhudson> yeah
<mwhudson> i guess that's a "no" then really
<jam> mwhudson: well the fork-a-daemon code was taken from a "python daemon" search and tweaked for my use case
<jam> so I didn't have to write it completely manually
<lifeless> mwhudson: that glue isn't what I've been working on; though I'd certainly want a Fixture wrapping it.
<lifeless> it would be nice to have bin/run know about it too
<mwhudson> bin/run runs the service already, but not as a daemon
<jam> lifeless: yeah, bin/run and runlaunchpad.py know how to do it, but that isn't how they run things in production
<jam> just one of the pain points for this experiment.
<mwhudson> jam: might it be better to wait for the daemon to respond to hello than to write its pid file?
<jam> mwhudson: I'm not sure i understand
<mwhudson> jam: in TestCaseWithLPForkingServiceDaemon._start_subprocess
<jam> are you saying the service shouldn't write its own pid file until it gets a request?
<mwhudson> jam: no, i'm saying the test helper should wait until a request gets a response
<jam> mwhudson: fair point, anything else?
<millun> hi guys
<millun> can i ask something?
<millun> i've pushed a branch up on an FTP account
<millun> what do i do now? (in bzr explorer)
<jam> mwhudson: I need the pid for other reasons, but I could wait for hello and then check the file
<millun> when i try to checkout - bzr explorer asks me like 3 times about the password
<mwhudson> jam: it just seems that there is a tiny possibility of a race
<mwhudson> with the current code
<jam> millun: I believe the recommendation is to use a full branch and not to use a lightweight checkout for a remote branch
<jam> mwhudson: where?
<jam> I don't doubt it
<jam> you can't use the normal "waitpid()" sort of tools
<mwhudson> jam: just the thing we were talking about already
<mwhudson> the daemon writes this pid before it listens on the socket
<millun> jam,
<millun> jam i thought at first that i need to checkout becAuse branching offered me shared repository while i need colocated
<millun> right?
<spiv> 'write pid file' and 'service is ready' aren't quite the same thing.
<jam> millun: if you need collocated, you still want a local branch to checkout
<poolie> hi mwhudson, jam
<poolie> spiv
<jam> spiv: well, it could be, it depends how I write the code :)
<millun> is collocated already a property of the branch? or it matters from user to user
<jam> millun: layout is a property of the user
<jam> well, location
<millun> Bind new branch to parent location? (should i check this?
<millun> i am using colocated branches in /Var/www/projectname
<GaryvdM> millun: A work arround to the password problem is to put the password in authentication.conf (Settings -> Credentials in bzr explorer) http://doc.bazaar.canonical.com/latest/en/user-reference/configuration-help.html#the-authentication-configuration-file-authentication-conf
<GaryvdM> millun: I'm working on making bzr explorer/qbzr keep it connections open, so that it does not have to ask for the password so often, but this is going to take a while...
<poolie> hi there GaryvdM
<GaryvdM> Hi poolie
<mwhudson> jam: i asked for a couple of small changes
<jam> mwhudson: I was pretty sure that you need setsid() to guarantee you'll disconnect from the terminal
<mwhudson> jam: ok
<jam> mwhudson: http://www.itp.uzh.ch/~dpotter/howto/daemonize
<millun> cool GaryvdM
<millun> jam: so i need to create a shared repo in /var/www/ and branch to /var/www/projectname. instead of /var/www/projectname/trunk
<jam> btw, hi poolie, nice to you have you back around and online
<poolie> thanks, it's good to be back
<poolie> we should send some news from uds while it's relatviely fresh
<glyph> Hello!
<millun> does it make any sense?
<glyph> I have recently discovered that the twistedmatrix.com bzr mirror has some old revisions that were generated with an earlier version of bzr-svn ("v3" in revids, I don't know what version that corresponds to)
<glyph> and this causes problems
<glyph> I am wondering how I should go about fixing this
<glyph> or rather, what the suggested 'best practice' (if there is such a thing) for dealing with data which is similarly not-quite-corrupt-but-still-problematic
<jam> millun: I personally don't know the 'colocated' style that bzr-explorer mentions very well.
<spiv> glyph: mwhudson looked at this yesterday
<GaryvdM> glyph: Hello. I saw in my logs that you were looking at the fonts in qbzr. I've landed a patch in qbzr trunk to have the mono space font defined in one place.
<jam> and I'm not sure whether you are saying it is your personal need for where it goes, or whether you are asking if it is how bzr-explorer wants it
<glyph> GaryvdM: Yay.  Is it a place where I can customize it? :)
<spiv> glyph: it appears to be more that the svn repo itself contains some revisions stamped with v3 revids (on trunk even)
<glyph> spiv: oh, crap :(
<glyph> wait a second
<glyph> is that actually a problem?
<GaryvdM> glyph: It now also tries to use "Monospace" before "Courier New"
<spiv> glyph: well!
<glyph> if they're stamped as such, presumably everyone will agree on the revid and there won't be an issue.
<spiv> glyph: so bzr-svn presumably is helpfully preserving the v3-ness of revs before the latest rev stamped that
<glyph> GaryvdM: even better
<glyph> spiv: except sometimes when it isn't?
<spiv> And assuming the better v4 format for later revs
<jam> mwhudson: due to layering, I went with "wait for the socket to exist" rather than "wait for a message on the socket". Is that sufficient for you?
<jam> at that point you can try to connect at least.
<jelmer> glyph: I'm trying to reproduce the issue here, but it's taking a very long time to pull all revisions down
<mwhudson> jam: yeah
<spiv> glyph: but if you have an old branch from before that point it'll be v3.  Or something.
<glyph> jelmer: well, that's the bug, innit ;)
<glyph> spiv: Oh.  If I have an old branch from before that point it will pull it down *as v4*, because since there are new stamped revs it will just assume that branch should be the newest, goodest thing.
<jelmer> glyph: not necessarily, I'm not sure if there's a good reason one branch is a different mapping than the other
<glyph> ahem
<spiv> glyph: jelmer is about 100x more of an authority on this than me of course
<glyph> _no_ stamped revs
<jam> mwhudson: k, pushed, and ready for your re-review
<glyph> in that branch's history.
<spiv> glyph: btw, r23001 in svn trunk
<GaryvdM> glyph: No customization yet   - I would like to have code to get your desktop setting. I cant find a way to do this, so I may end up coding a version for gnone, kde, mac.
<jam> mwhudson: my EOD. but I'll respond to anything tonight/tomorrow if you have any more feedback
<GaryvdM> * I cant find a way to do this with qt...
<jam> I get to take my son to "soccer" practice (for 3yr old) should be a lot of fun
<mwhudson> jam: ok, i guess i'll throw it at ec2 land :-)
<spiv> glyph: I'm honestly not sure at all
<glyph> spiv: That's the behavior I'm seeing.
<glyph> Looking at the local bzr log of these branches I've got.
<glyph> So, probably the best thing to do practically speaking for this branch would be to destructively rebase the branch using svn ('merge forward') and then just start over
<spiv> glyph: my wild guess is... probably?
<glyph> it's only got one revision in it anyway, and desperately needs to be updated to be more current with trunk, so there's not a lot to lose :)
<glyph> spiv: so, thanks for the explanation of the preserving-the-v3-ness based on revision order in SVN, that was a key clue :)
<glyph> exarkun: you may be interested in that discussion in case you do some old twisted branches with bzr
<exarkun> I'm less interested in discussion and more interested in tools that work
<spiv> glyph: well, thank mwhudson more than me :)
<spiv> exarkun: here's the short form, as I understand:
<spiv> exarkun: land your branches faster and there'd be no problem :P
<glyph> exarkun: oh.  #git, in that case, I guess? :P
<exarkun> glyph: oh man.  you said it, not me.
<spiv> I'm sure jelmer will figure out how to make it work better, though.
<glyph> exarkun: "If you're working with a very old branch, merge it forward in SVN first, to avoid this problem."
<glyph> I can be more specific than that, with a precise revision number, but that's a good rule of thumb.  Maybe that's what spiv meant by 'r23001'?
<mwhudson> radix committed something to trunk with bzr
<radix> what
<radix> what
<exarkun> radix: why do you always break everything
<radix> what
<glyph> radix: yeah man what the hell is your problem
<radix> did I break something like three years ago
<radix> is that what this is about
<glyph> radix: don't worry, dash would have broken it if you hadn't.
<mwhudson> and yeah, svn 23001 was it
 * jelmer wonders if he should phase out file property-based bzr-svn metadata
<GaryvdM> Good night all zzzzzz
#bzr 2010-11-09
<stewart> hi! i'm using bzrlib to write a script that iterates through a sequence of revisions and applies them to a different tree. I'm using show_diff_trees to extract a patch, but I need to skip over merge revisions so I don't end up trying to do work twice. how do i work out if a revision is a merge revision?
<spiv> stewart: look at the parents of the revision
<spiv> merge revisions have >1 parent revision
<lifeless> stewart: you could use use bzr-rewrite ;)
<stewart> spiv, ahh..
<stewart> lifeless, haven't been able to get it even to remotely work for my branches.
<stewart> lifeless, plus, i need to apply transformations :)
<lifeless> stewart: its designed to do that
<stewart> lifeless, because regex over patches is an excellent idea :)
<lifeless> its not entirely fleshed out, but thats the intent
<spiv> But I agree with lifeless that this is something that bzr-rewrite ought to support.
<spiv> (even though I can totally believe it's not quite there yet)
<stewart> i couldn't get it to apply just a few revisions :)
<spiv> stewart: you tried 'bzr replay -r N..M -d TARGET FROM_BRANCH'?
<stewart> spiv, IIRC (was a few weeks ago), yes. needs mapping of paths thoguh.
<stewart> oh wow... i'm now blowing up when iterating through revisions that have been merged from another repository... doh.
<spiv> Hmm, in theory that should already support arbitrary transformations too, via --merge-type, if you implement a plugin that provides the transformation you want as a new merge type...
<spiv> (A fairly cumbersome way to do it, obviously)
<vila> hi all
<fullermd> What?!  You just said that yesterday!
<vila> hmm, then today is another day. QED.
<fullermd> I can't deal with another day.  I haven't even reconciled myself to yesterday yet.
<jelmer> 'morning vila, fullermd
<jelmer> fullermd: hey, aren't you in the US?
<jelmer> hmm, maybe that was another fullermd
<fullermd> Oh god, there are two of me?!
<fullermd> I am, yes.
<jelmer> fullermd: isn't it the middle of the night for you then?
<fullermd> Well, not for _me_.  Maybe for the other losers in my TZ, but that's their own fault for not synchronizing with the One True Time (i.e., mine).
<vila> jelmer: that's because you're often up at this hour :) But fullermd don't sleep anyway
<vila> doesn't, grr ttoyyops
<fullermd> Sleep is for wimps.
<fullermd> Happy, healthy, well-rested wimps.  But wimps nonetheless.
<jelmer> vila: Heh, perhaps :-) I guess it's not yet midnight on the west coast
<fullermd> I'm in the same TZ as jam.  0119 now.
 * jelmer is slowly transforming from a student into a civilian
<fullermd> Way better time to get work done than at 1319.  People call me then.
<jelmer> heh, fair enough :-)
<vila> fullermd: you'd better unplug the phone once and for all
<fullermd> I tried that once.  Eventually somebody actually physically came by.  That's way worse  ;)
<jelmer> vila: bzr 2.3b3 uploaded to unstable
<poolie> hi jelmer, vila
<vila> jelmer: cool
<vila> poolie: hey !
<jelmer> 'evening poolie!
<GaryvdM> Morning all
<vila> . o O ( GaryvdM is following fullermd into the never-sleeping land...)
<vila> GaryvdM: hey !
<GaryvdM> Hey
<fullermd> Individually, we are merely groggy and harassed.  But together, we are a force to b...zzzzzzzz...
<GaryvdM> My sleep habbits are much better than when I was at the ice rink. I often woked till 6am. Now I only work to 1:30 am..
<vila> ping LOSA, any news or feedback about rt #41340
<vila> jelmer: I can't see 2.3b3 with `rmadison -u debian bzr` . Is there some lag or something failed ?
<jelmer> vila: it usually takes a while before it's processed. I believe the publishing happens 4 times a day at the moment.
<vila> jelmer: ok, so lag it is, thanks
<bob2> iirc rmadison depends on the mirror pulse
<jelmer> vila: http://packages.qa.debian.org/b/bzr.html is up to date
* 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 | Release Manager: vila | 2.3b3 has been released  | work on bzr: http://webapps.ubuntu.com/employment/canonical_BSE/
<vila> ping LOSA, any news or feedback about rt #41340
<GaryvdM> jelmer_ : I'm getting this error with my bzr 2.3b3 build: http://pastebin.ubuntu.com/528719/  I'm not sure where to start looking for the problem. Any pointers?
<jelmer_> GaryvdM: no idea, sorry
<GaryvdM> Ok
<GaryvdM> jelmer_: I figured out the issue. The installer was including a "SHFOLDER.dll". Removing this fixed it. Really odd.
<jelmer_> GaryvdM, hmmok
<jam> GaryvdM: fairly often you can get system dlls that aren't properly marked, and thus py2exe doesn't filter them out automatically
<jam> there is a decent sized list of ones we've found so far :)
<vila> GaryvdM: approved
<GaryvdM> Hi jam
<GaryvdM> vila: Thanks - I'll land
<GaryvdM> vila: I'm trying to run bzr selftest with my windows installer, but it seems to just hang.
<GaryvdM> I'm not sure if it is something wrong with my installer, or an existing problem.
<vila> GaryvdM: unheard of, we are at 4 or 5 failures on babune
<vila> GaryvdM: try with -v to see which one is hanging
<GaryvdM> vila: ok
<vila> GaryvdM: and --no-plugins :)
<GaryvdM> vila: blackbox.test_breakin.TestBreakin.test_breakin_harder
 * GaryvdM goes to read test
<vila> GaryvdM: forget it, it's blacklisted on babune
<GaryvdM> Oh
<GaryvdM> vila: how can I see you blacklist?
<vila> GaryvdM: or rather, try running with -x 'TestBreakin'
<vila> GaryvdM: and then file  a bug about it
<vila> or check for duplicate, I've lost steam fighting its failures :-/
<GaryvdM> vila: ok
<jam> GaryvdM: AIUI, the issue is that signals and threads don't get along, and our test suite still leaks threads
<jam> if you run the breakin tests by themselves, they work fine
<GaryvdM> Oh
<jam> trying to confirm now
<jam> Ran 3 tests in 6.681s
<jam> GaryvdM: so they work here, but I won't guarantee they work w the installer, etc. I also just ran "bzr selftest -s bb" and it seems to be passing
<jam> so I don't really know how to get the bad interaction that causes them to hang and fail
<jam> it may also be one of the "you have to have more than one processor" side effects, etc.
<jam> I got the win32 test suite to pass without skipping on multi-processor machines a while ago (could have bit rotted), but vila was convinced we needed it to always pass on single-cpu machines, so put in the extra effort for that
<jam> and multi-core machines seem to have fewer bugs wrt threading (at least fewer deadlocks, etc)
<vila> jam: meh, we're not supposed to leak threads anymore (except for the paramiko ones and even there..)
<jam> vila: good to hear
<jam> though still "bzr selftest -s bb" passes cleanly here (or everything has passed in the last 4m which should include breakin tests)
<vila> that's the problem with transient failures in tests, they pass in some places...
<jam> vila: IME breakin fails reliably for some people, but succeeds reliably for me
<jam> FAILED (errors=1, known_failure_count=2)
<jam> 135 tests skipped
<vila> jam: but whether or not multi-core machines has less bugs, it would be nice to have TestBreakin passing everywhere since it's our guarantee that C-\ works
<jam> And a failure while reporting about a missing feature...
<vila> jam: file a bug, these are hard to track otherwise
<jam> vila: I wouldn't be surprised if it is a testtools issue, I'm still at 0.9.3
<jam> I don't really feel like fighting with that
<vila> jam: don't fight, file :)
<jam> filed bug #673128
<ubot5> Launchpad bug 673128 in Bazaar "Traceback while reporting missing feature (affected: 1, heat: 6)" [Low,Confirmed] https://launchpad.net/bugs/673128
<sakura13> good evening
<sakura13> i have a problem with bazaar how can i setup a webserver for it that my workers can use the same files for our project
<GaryvdM> sakura13: hi. What OS? Why does is have to be a webserver, and not some other file share?
<Peng> Assuming nothing has gone horribly wrong in the six months I haven't been paying attention: You don't have to do much setup. Just dump the .bzr directory somewhere a web server can serve the files.
<sakura13> GaryvdM:  wait a sec my project leaders comes in few secs
<Peng> You *can* set up the smart server program, but it's not necessary. It just makes things faster.
<sakura13> Peng: moment pls project and server owner comes in few secs
<GaryvdM> Peng: non smart http is read only.
<Peng> GaryvdM: Oh, err, good point. Peng hasn't slept much.
<Peng> Then, add SSH or SFTP for that! :P
<GaryvdM> vila: oh boy - I've got some bug logging to do. 5345/28465 tests run, and allready 104 fails
<sakura13> Swonline: hi
<92AABIV95> Hi, is anyone aware of a command or plugin that will let me list revisions with or by their size? Basically, I'm trying to identify a revision that introduced a really large amount of stuff that was subsequently deleted so I can attempt to get rid of them.
<Swonline> How do I set up a server?
<vila> GaryvdM: if you're running from bzr.exe you may be the first one :-/
<vila> GaryvdM: don't let it come in the way of releasing, I don't think these are *new* failures
<sakura13> vila: GaryvdM its my project leader he want setup the server for our project with bazaar
<GaryvdM> Swonline, sakura13: A bzr smart server is not needed to host a bazaar branch. What OS is you server?
<vila> GaryvdM: but it will be good to fix them nevertheless (probably by skipping)
<Swonline> windows
<GaryvdM> Swonline, sakura13: The easiest is to create a window file share.
<Swonline> how to?
<sakura13> GaryvdM: hmm did it worked without server that we can make a networkhardrive
<sakura13> GaryvdM: on our pc
<GaryvdM> Swonline, sakura13: bzr init \\server\share\proj-name
<sakura13> i use atm bazaar explorer
<sakura13> ok if i made a branch
<sakura13> and upload it with ftp to my server
<sakura13> and give the workers the path to the branch
<sakura13> will bazaar open it can work with it
<sakura13> ?
<Peng> FTP is a rather awful protocol.
<Peng> Well, plus the implementations tend to be rather awful.
<sakura13> yes i know but i dont have ssh acces
<GaryvdM> sakura13: Yes - you can upload your branch to the server with bzr push ftp://server/yourbranchname (or a windows file share with bzr push \\server\share\proj-name)
<Peng> My condolences.
<sakura13> GaryvdM: hmm and what type of branch did we need to share files and so on
<sakura13> GaryvdM:  i have used before p4 thats my problem :)
<GaryvdM> What type of branch: Any bzr branch
<sakura13> GaryvdM:  i have here different work modules colcated, feature, plain and shared branch
<GaryvdM> sakura13: You probably want a shared repository
<GaryvdM> sakura13: But plain branch is  fine
<sakura13> GaryvdM:  and what is the diffrent of a branch and a plain
<Peng> Branches in shared repositories share their data. It's more efficient.
<Peng> But there's no functional difference. It's just faster and less disk-intensive.
<Peng> Well, plus it makes complicated auth a pain since everybody needs to be able to write to the repo...
<sakura13> becuase we must have merge files, work on the same files and so n
<GaryvdM> sakura13: Can I recommend that you go though http://doc.bazaar.canonical.com/latest/en/mini-tutorial/ - I'm sure things will be a lot clearer afterwards.
<sakura13> damn if i open my ftp bzr it crash
<sakura13> -.-
<Peng> What? If bzr crashes, paste the traceback at http://paste.ubuntu.com/ . Or the URL if you have that helper thingy enabled.
<sakura13> i dont use command line on windows
<sakura13> i use atm the gui
<sakura13> and dont see any debug
<sakura13> but i try now with bazzar on cmd i hate windows cmd but ok
<sakura13> hmm but one thing i dont understand
<sakura13> if i change some files with bazaar
<sakura13> to example i put a new file on it
<sakura13> ahh its ok
<GaryvdM> sakura13: http://doc.bazaar.canonical.com/explorer/en/guide/processes/starting_a_project.html <- explains the different branch types you saw.
<GaryvdM> If you select "Feature branches" it creates a shared repo, and a trunk branch for you. (I just learnt that...)
<GaryvdM> So that's the recommended.
<GaryvdM> You would then create you feature branches in the shares repo.
<GaryvdM> Night all.
<sakura13> k thx
<eridu> I have gpg_signing_command = false in my ~/bazaar/bazaar.conf, and gpg-signing still works. what's going on? I'm using v2.2.1 (in Ubuntu 10.10)
<eridu> (I know signing works because I see the "You need a password..." message in my terminal when I run bzr ci)
<bob2> branch-specific bazar.conf?
<eridu> nope, global
<eridu> it was my fault
<eridu> I set gpg_signing_commmand by accident
<eridu> what's especially ironic is that I tested setting gpg_signing_asdfcommand to see if bzr would give me an "invalid configuration key"-type error, and it didn't, but I still was change-blind
<poolie> hi all, hi bob2
<bob2> 'morning
<Silasle> Is there some guide to register you whit bzr (on launchpad)?
<maxb> `bzr help launchpad-login`
<Silasle> And then?
<maxb> and then what?
<Silasle> Dont i need some ssh keys?
<maxb> yes
<Silasle> How do i create them
<Peng> THere's nothing LP-specific about creating SSH keys, although I think they have some guides anyway.
<maxb> I have no idea where there might be a pleasant tutorial for this sort of stuff, sorry. I learn it so long ago that it's fairly alien to explain for me
<Silasle> Ok, i found the guide
<Silasle> launchpad-login and ssh keys is everything i need?
<Silasle> Ok, thanks
<jam> poolie: hey, are you online already? /wave
<poolie> hi jam, i am
<mgz> jam, is the bug 673128 about the UnicodeDecodeError? I marked it as a dupe of the testtools bug I fixed to start with, but I'm not sure you didn't mean something else.
<ubot5> Launchpad bug 673128 in Bazaar "Traceback while reporting missing feature (affected: 1, heat: 6)" [Low,Confirmed] https://launchpad.net/bugs/673128
<jam> mgz: Well, I got the failure during the "XX tests skipped due to ..." section
<jam> not while actually running the tests
<jam> It may be due to testtools
<jam> vila said "don't think, just file"
<mgz> I agree with the sentiment, I'm just having trouble understanding the bug. :)
<mgz> that traceback certainly doesn't come from the printing-skip-reasons phase. perhaps some kind of stream buffering thing?
<jam> mgz: it would be a very strange buffering.
<mgz> oh, wait, I know
<jam> It definitely happens after the "10 tests skipped by 'foo'" has been reported
<mgz> it's just bzrlib being helpful and printing out the error that broke it at the end
<jam> but before the missing "unicode" feature is reported (or something like that)
<mgz> for whatever reason you didn't get any more skip things listed.
<mgz> anyway, upgrade and bug with bother you no more.
<mgz> and you'll also be able to write tests that deal with unicode things.
<spiv> Silasle: https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
<Silasle> spiv, Thanks but i'm already done :)
<poolie> mkanat, hi?
<poolie> hello emmajane!
<emmajane> poolie, ola!
<lifeless> sladen: actually, hi here.
<sladen> lifeless: and here!
<lifeless> hi
<lifeless> so you seem to be filing a large number of bugs which seem like first-impressions issues, not functional problems.
<lifeless> and particularly biased towards folk with existing muscle memory
<lifeless> this doesn't seem like a particularly useful way to address whatever use case you're working on : consider what would happen if you filed bugs on dpkg that it doesn't support apts options, or on rpm that it doesn't support dpkg's options.
<lifeless> sladen: so I thought I'd try to engage you in a higher level discussion
<sladen> lifeless: yup, I've been chating to poolie in the background over this
<poolie> sladen, perhaps we should just talk here
<poolie> lifeless, yes i was just making the same point
<poolie> people who want _exactly_ the git ui, byte for byte and bug for bug, are unlikely to ever be satisfied by bzr
<poolie> on the other hand bugs about things that are missing features, or that are inconsistent within bzr on its own right, are worth noting
<sladen> the general background is being (forced?) to start using bzr where for I had been using git for the last few
<poolie> if i can draw another analogy
<poolie> people file a bunch of bugs about ubuntu being different to mac os, or to windows
<poolie> there may be a good point behind them but they are not generally very productive bugs ime
<sladen> so "bzr commit -a" falls into that category
<sladen> others, like bzr diff blocking whilst writing a bzr commit are workflow blockers
<sladen> and still others (bzr pager by default) are out-standing issues from before I ever used git
<sladen> it's just that (in the latter case), having used something else, it confirms the original issue
<lifeless> sladen: so some of this is perspective
<lifeless> sladen: for instance, the pager thing really should be fixed in your shell.
<lifeless> sladen: its nuts to change every single tool to do its own pagination
<sladen> lifeless: and that may ever well be a good point
<sladen> lifeless: (but doesn't help get the reported issue fixed)
<sladen> s/ever/very/
<lifeless> sladen: well, part of it is whether its a good idea or not
<lifeless> sladen: the reported issue can be viewed in a few lights - concretely, I /loathe/ gits auto pagination stuff.
<lifeless> it invariably gets in my way when I use git.
<sladen> lifeless: yup, and you're a poweruser, and can disable it
<sladen> lifeless: it's not a use-case I'm interested in
<lifeless> sladen: non powerusers can use GUI's
<lifeless> sladen: if you want to get into an argument on that angle
<lifeless> but I don't think an argument is a good way to move forward
<lifeless> we want bzr to be joyful to use for as many people as possible
<sladen> lifeless: yup, and there are plenty of choices for dvcs so people vote with their feet
<sladen> lifeless: the question is, why did we, with a one year headstart, end up with less user-base than other dvcsen
<lifeless> sladen: s/one year/2 months/
<poolie> sladen, that's more of what I would call a 'beer question' than a 9am in the morning question
<poolie> i realize you're in a different tz
<poolie> at the moment i'm more interested in what we can best do this week and in the next few months
<poolie> taking into account mistakes we might have made in the past
<poolie> one of them was making it too hard to get patches in, and i think that is now a lot better (i'd welcome evidence to the contrary)
<sladen> I don't think there are mistakes, were are where we are because of how things unfolded, and wouldn't be otherwise
<sladen> just as, on the desktop we are where we are
<poolie> another was not being systematic about performance, and that is somewhat better now, though not ideal
<sladen> speed and illusions of interactivity are not the same---an iPhone draws pretty zooming windows with the GPU while the application takes 1-2 seconds to starts up on the CPU
<poolie> sure
<sladen> the conversation (feels) uncomfortably confrontation---which is why I'm being hesitant
<poolie> bzr with progress bars on certainly feels different to without
<sladen> it's not something I wish for, but it 9am or midnight
<poolie> (though again, the progress bars are not perfect in either coverage or implementation)
<poolie> no, me either, and i don't want to be defensive
* poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | Release Manager: vila | 2.3b3 has been released
<lifeless> one thing I think in particular rubs about bugs that reference the git UI
<lifeless> nearly -everyone- I know, including git afficiondos, dislikes the git UI
<lifeless> I'd much rather see 'Foo was confusing, I looked on the web, in the help, and finally found an answer in the corner of ...' - thats a symptom we can definitely work on to improve.
<lifeless> Adding to that that git does X, svn does Y, hg does Z can be good inspiration to fix it.
<lifeless> but the actual /problem/ encountered is squarely and clearly focused on defects in bzr, not on comparisons which are rather more subjective.
<sladen> lifeless: I agree, I've tried to use the wording "other dvcs" and not being specific about it
<sladen> lifeless: this issues are all (I think) about usability---if usability is accepted as a defect in bzr, then that matches the spirit in which the bugs were reported
<lifeless> sladen: usability is very much a defect
<lifeless> blah, take that in the spirit intended
<poolie> i think the reports are fine
<poolie> in spirit
<poolie> i agree with robert that saying "there is this problem, other people have done X" is kind of grounding it better
<poolie> responses to bugs that suggest workarounds often make me uncomfortable
<poolie> it's one thing to say "thanks, that is a bug, in the interim until we fix it you can do Y"
<poolie> it's much less good to give the impression that because a workaround is possible we're denying there's a bug
<sladen> +1
<peitschie> (mornin sladen, poolie, lifeless and all you other lurkers :)  )
<sladen> good morning poolie
<poolie> hi there
<sladen> peitschie even
<peitschie> :)
<jbowtie> Hello, also welcome back, poolie
<peitschie> hi jbowtie
<jbowtie> My email inbox is unusually full of bug activity this week.
<jbowtie> Oh, right, UDS.
<jbowtie> poolie, did you finally hire a BSE? (noticed that ad is gone from IRC topic) Congrats.
<poolie> jbowtie, we did
<poolie> i'll send a mail
<jbowtie> I have to say the new release of bzr-tfs seems to be much better integrated, those per-foreign-vcs tests are very helpful.
<poolie> excellent
<maxb> hmm. the clearing of progress displays seems to have regressed again
<maxb> "Pulling /home/maxb/wc/bzr/udd/trunk from bzr+ssh://bazaar.launchpad.net/~udd/udd/import-scripts/shing stream" says my multi-pull
#bzr 2010-11-10
 * spiv is reviewing https://code.launchpad.net/~maxb/bzr/2.2-close-ssh-subprocess-socket/+merge/40493
<maxb> thanks :-)
<dcoles_> Should all version 2 merge directives have a target_branch inside the header of the merge directive?
<dcoles_> Just about to open a bug since Bazaar crashes when the target_branch is missing.
<spiv> dcoles_: if it's a crash that produces a traceback, then it's definitely a bug even if that's not valid
<dcoles_> spiv: Right-o. Just opened bug #673344
<ubot5> Bug 673344 on http://launchpad.net/bugs/673344 is private
<dcoles_> Can't seem to find the merge directive spec in the dev docs.
<spiv> Yes, I can't find a description of the format (other than the code that implements it) at a glance either.
<spiv> I might not be looking hard enough.
<spiv> There's at least some code that appears to expect that the target_branch field may not be present.
<dcoles_> I can't imagine it being too important. From my own merge directives it just seems to contain the local checkout that it was branched off.
<dcoles_> target_branch: file:///home/dcoles/Documents/Projects/plagiarism\
<dcoles_> Whoops.
<dcoles_> Either way, that target_branch wouldn't have made sense to the person who received it (since it's a local directory)
<spiv> Well, if you configure a public_location for your local branches it'll use thta
<dcoles_> Aye. That might have been the cause. His version of bazaar must have just dropped the location.
<spiv> Is there any particular reason that bug report is private?
<dcoles_> Not really. Unless I bumped a 'private' checkbox somewhere (I went via apport)...
<lifeless> apport files all bugs as private
<lifeless> until vetted for confidential data (which the apport retracer does for ones in ubuntu itself)
<spiv> I should have asked, do you mind if we make that report public? :)
<dcoles_> Yeah. It's fine. I just un-privated it myself.
<dcoles_> Looks like nothing but Python and Bazaar stuff.
<dcoles_> ... And Google has already indexed the bug...
<dcoles_> Seems to have gone AWOL in the current docs, but http://doc.bazaar.canonical.com/bzr.2.0rc2-html/developers/bundle-format4.html
<GaryvdM> Morning
<spiv> Hmm, I'm increasingly wanting to use tribunal to read bzr test output I think.
<spiv> So that I don't have to wade through masses of bzr log output in test failures by default (but so that the log output will still be there when I need it).
<poolie> spiv, well, you should use it!
<poolie> :)
<poolie> it does work
<poolie> there are many other features that would be nice, but we can add them over time...
<spiv> poolie: the problem is I'd feel compelled to dust off my half-done patches for it first ;)
<poolie> this is a problem? :)
<spiv> Not in the long run :)
<GaryvdM> I'm digging arround the code for loggerhead. I'm trying to find what would be the equivalent to routes.py in a pylons.
<GaryvdM> i.e. where does it decide what controller to use?
<GaryvdM> Ah - apps.branch.BranchWSGIApp.controllers_dict
<mkanat> GaryvdM: I'm a loggerhead guy if you have other general questions.
<GaryvdM> mkanat: I'm want to try use my loggraphviz code from qlog in loggerhead
<mkanat> GaryvdM: Okay. That does a dot graph of revisions, or something?
<GaryvdM> mkanat: Yes - a graph visualisation, but it does no use dot format. -  screen shot: http://qbzr.googlegroups.com/web/gtk_qlog.png
<mkanat> GaryvdM: Oh yeah, I've seen that, that's really slick.
<GaryvdM> mkanat: You can also collapse/expand revisions
<mkanat> GaryvdM: That would be quite a trick to do in HTML, I'd think.
<GaryvdM> mkanat: I need to cache a object in memory. There would be one per branch, and it would be valid until the branch tip changes.
<mkanat> GaryvdM: Ah, we already have a revision graph cache.
<mkanat> GaryvdM: It's in loggerhead.history, as I recall.
<GaryvdM> mkanat: According to the doc string, it only lives for the length of a request.
<mkanat> GaryvdM: No, it is persistent.
<mkanat> GaryvdM: At least, if you're using the right graph cache.
<GaryvdM> Oh
<mkanat> GaryvdM: The History object only lasts one request, but the actual graph cache is the lru_cache.
<poolie> hi all
<mkanat> Hey poolie.
<GaryvdM> Hi poolie
<poolie> i need to go in a sec
<poolie> but, mkanat, can you let me know some time what happens next with loggerhead on codebrowse?
<poolie> and/or talk to jam about it?
<mkanat> jam: Yeah, I need to go back and look at what we need to fix in loggerhead itself before we can put it behind haproxy.
<poolie> that would be good
<mkanat> I mean, poolie, not jam. :-)
<poolie> i guessed :)
<mkanat> poolie: Yeah, I think I explained it briefly to lifeless by email, I have to go back and see what I was thinking the problems were when we talked about it.
<poolie> you could perhaps just forward that to launchpad-dev?
<poolie> oops, got to go, may be back tonight
<spiv> poolie: g'night!
<GaryvdM> mkanat: The object I want to cache is an instance of this object: http://bazaar.launchpad.net/~garyvdm/bzr/loggraphviz/annotate/head%3A/bzrlib/loggraphviz.py#L134
<mkanat> GaryvdM: I think that all the heavy lifting that that object does can be done by the existing revision graph cache.
<mkanat> GaryvdM: Loggerhead currently has serious memory-usage problems, so adding a second cache would not be a good idea (it would never go on Launchpad, for example).
<GaryvdM> mkanat: Sure - That why I'm trying to get a good understanding of the existing infrastructure first.
<mkanat> GaryvdM: Okay, cool. :-)
<GaryvdM> mkanat: Does lp run lp:loggerhead, or some other branch?
<mkanat> GaryvdM: lp runs launchpad-loggerhead, which is a wrapper around normal loggerhead. (A whole separate project.)
<mkanat> GaryvdM: But essentially yes, lp runs the trunk branch of loggerhead.
<mkanat> (With a few differences in deployment and so on.)
<lifeless> mkanat: we're now running two parallel instances
<mkanat> lifeless: Oh, that actually happened?
<lifeless> yeah
<lifeless> we haven't trimmed the worker count yet
<mkanat> lifeless: Okay. Is it working or is it killing the server with OOMs?
<lifeless> working AFAIK
<mkanat> lifeless: Okay. I suppose I'll have to ask spm, too.
<lifeless> if you want details ;)
<lifeless> the driver for the work so far was being able to do no downtime deployments
<mkanat> lifeless: Ah, okay.
<mkanat> lifeless: I'll ask spm if there have still been any stability issues.
<vila> hi all !
<vila> ping LOSA, can we have some feedback (or even better a fix) about rt #41340
<Sakura13> any german out there?
<lifeless> vila: the losas have asked that we ping on the internal launchpad-ops channel by preference
<vila> lifeless: thx for th info
<lifeless> vila: it was in flacostes meeting minutes a week or two back
<vila> lifeless: I don't think I've seen such a thing :-/
<lifeless> vila: you may wish to subscribe to the launchpad list[s] - including canonical-launchpad
<vila> lifeless: just when I was almost keeping up with my flood ? :-/
<stefanlsd> Hi guys, im doing a UDD merge and it looks like in debian revision they uploaded with a .pc directory. This is problematic now as this quilt stuff is applied. Any advice?
<jelmer_> stefanlsd: You might want to ask Barry, he was dealing with this problem earlier as well.
<maxb> stefanlsd: The presence of the .pc in the branch is actually the current standard
<maxb> It's not a very good standard, IMO, but it's what dpkg-source does
<jelmer> it'd be great if we could turn those patches into quilt threads or something..
<maxb> The storage of the debian patches applied in the branch goes hand-in-hand with using v3 source packages
<stefanlsd> maxb: my understanding was that its quilt running that generates it. so during debuild for example it will apply, build and then remove it?
<maxb> quite what you are supposed to do in an UDD merge scenario with the .pc directory is something I'm not really certain, as the only correct option is hideously painful
<stefanlsd> maxb: well, in this case the .pc directory was introduced by debian a while ago. i removed the .pc directory and doing the merge and build, it fails to apply, as its already applied
<stefanlsd> maybe i should leave it there and not remove it... (checks)
<stefanlsd> as a side note - running bzr remerge --weave leaves me with .OTHER.OTHER (running it again gives me) .OTHER.OTHER.OTHER (not sure if this is working as designed...)
<maxb> Well, the "correct" thing to do would be to leave the .pc directory in place, *including* updating its cached copy of modified upstream files. But that's really messy and breaks the UDD story as being a nice way to merge things
<maxb> I think some more thought needs to be given to what the UDD importer actually commits to the the import branches for v3 source packages
<maxb> hmm, I need to grab lunch. afk
<jam> mgz: if you care, I upgraded to testools 0.9.7 and it gives me a valid unicode failure, which is still odd, but at least it doesn't die.
<jam> ah, it is failing during the cleanup phase, which is strange, but does explain some of the earlier issues
<vila> jam: I'm not there anymore but I haven't managed to get in touch with a losa, may be you can ping Chex in #launchpad-ops so we get at least a bit of feedback about testtools on pqm ?
<jam> vila: k, I haven't seen Chex yet today (I have other questions for him as well). Do you have an rt for it?
<vila> jam: 41340 the one you commented on
<GaryvdM> \o/ Graphviz for loggerhead : http://imagebin.ca/img/yJm8tLH.png  <-work in progress.
<jam> GaryvdM: pretty. Though I'd really like it to collapse by default :)
<GaryvdM> jam: Yes, work in progress. :-) Look at the url - I've manually expanded 428.1.*
<maxb> Hmm, 0.9.7. ~bzr PPA needs an update
<gthorslund> morning stewart!
<mgz> ha, swapped lifeless for jelmer. happiness all round?
<mgz> jam: goodie. do you want to make the bug about the cleanup failure, or should I redupe it again?
<jam> mgz: the cleanup failure was already a bug, but I just get a regular traceback now, so feel free to just mark it a dupe
<mgz> maxb: you might want to not bother till 0.9.8 as 0.9.7 has some platform/version compat issues.
<maxb> What's the likelyhood of bzr wanting to depend on testtools >= 0.9.4 in the medium-term future, if anyone knows?
<mgz> jam: cool. what's the number for the cleanup failure?
<mgz> maxb: https://code.launchpad.net/~gz/bzr/require_testtools_0.9.5_for_selftest/+merge/35144
<jam> maxb: AIUI we need 0.9.5 for some unicode failures
<maxb> Oh. It's just people are talking about updating testtools on bzr's PQM, so I figured an up to date deb would be good
<jam> so... high but paused waiting for sysadmins to upgrade pqm
<jam> maxb: I thought there was one?
<maxb> 0.9.6, not .7
<jam> well, >0.9.5 is good, .7 would be nice :)
<jam> vila: what happened with all of the double mp requests?
<maxb> lifeless: Are you OK with uploading a newer one to Debian unstable? Once that require_testtools_0.9.5_for_selftest MP lands, we're going to need it to update bzr there
<jam> lifeless is away today
<jam> and tomorrow, IIRC
<maxb> I spy him talking in other channels right now :-)
<jam> (he may answer anyway, but he is officially on leave)
<mgz> debian's still in freeze which is a little annoying.
<maxb> mgz: Are those issues in 0.9.7 you refer to sufficient that bzr's PQM might want to prefer 0.9.6 over 0.9.7? In which case I should *not* update the ~bzr PPA for now
<GaryvdM> http://imagebin.ca/view/gNbLSX.html - better layout - One of the reasons I love working on graphical things, is it's easy to show others your progress :-)
<GaryvdM> +colors
<mgz> possibly not an issue for ubuntu? should be okay for all python versions and the testsuite not running without extra python packages might not hurt.
<mgz> https://launchpad.net/testtools/+milestone/next <- what's pending.
<maxb> mm, sounds like a release is needed :-)
<vila> jam: wrong ordering of my loom threads to start with, then a after-thought about working around lp limitations, then one forgotten push, sry about the noise, the activereviews page looked fine in the end
<jam> vila: probably, though I primarily review via my email :)
<vila> jam: long story short: I try to make my proposals easier to review by trying new workflows so I uncover bugs
<vila> jam: then make sure to start with the latest ones you received and check the pre-requisite branches to review in the right order ;)
<vila> mgz: Hey !
<lifeless> maxb: I think we need a release
<lifeless> maxb: I've uploaded python-fixtures, its in NEW
<lifeless> maxb: it would be nice to recommends: that for the next testtools upload.
<rittyan> Hello. Version is 2.1.0. bzr fast-export gives "Unable load library fastimport". Any ideas on how to make it work?
<rittyan> s/Unable load/Unable to import/
<GaryvdM> rittyan: Is this on windows, installed with the standalone installer
<GaryvdM> ?
<rittyan> it is on ubuntu, installed via apt-get
<GaryvdM> rittyan: I did apt-get install bzr-fastimport; bzr fast-export MYBRANCH. It worked fine.  From you bzr version, I assume you are on lucid?
<rittyan> the server is on hardy :-( downloading fresh bzr onto my macosx, then will DL repo and try it on my notebook
<GaryvdM> Sorry about asking if you use windows :-p - I was working on the windows installer last night, an fastimport is broken, so I jump to conclusions...
<rittyan> yes that's fine
<rittyan> I don't find it offending
<rittyan> more offending is where my current project is, now, but it won't be long (until fastexport is broken in new version too)
<rittyan> (nvm)
<GaryvdM> rittyan: What version of bzr-fastimport do you have on the hardy box?
<rittyan> latest checked out from launchpad
<GaryvdM> Installed by putting into ~/.bazaar/plugins/?
<GaryvdM> I think you also need do bzr branch lp:python-fastimport; cd python-fastimport; sudo ./setup.py install
<GaryvdM> Not 100% sure though.
<GaryvdM> rittyan: ^
<rittyan> I am not sure either
<maxb> That sounds right to me
<rittyan> still doesn't work
<maxb> Alternatively, if you want to not install python-fastimport globally, you can make it work by checking it out to (say) ~/.bazaar/python-fastimport, and creating a tiny bzr plugin that adds it to your python path when running bzr
<rittyan> to be honest i don't want to pollute my machine
<rittyan> though i just did and it still doesn't work, ok
<rittyan> will try locally when dl will finish
<maxb> Me too. The way I install extra libraries for bzr plugins is to have a ~/.bazaar/plugins/AAAuselibs.py file which contains import sys; sys.path.insert(0, '/path/to/extra/libs')
<rittyan> my 20mbit provider is down again so i am using gprs, extra$ for speed slower than staying still :(
<rittyan> 8 min left
<poolie> hi jam, all
<jam> hi poolie
<poolie> i was actually online, but on the phone etc
<poolie> howÂ was your day?
<jam> poolie: pretty good
<jam> still waiting on movement from a  l-osa
<jam> but I guess they had some critical launchpad regressions etc
<jam> found a memory structure that I'm happy with for the groupcompress packing code
<poolie> waiting for movement as far as getting the server started?
<jam> right
<jam> I need one of them to start it, and update the production configs so I can actually test it
<poolie> well, keep pushing i guess
<kiko> found this in an internal linaro wikipage comment from an engineer "* bzr doesn't like long (>1GB) checkouts - need to fetch in chunks (bzr get -r number)"
<kiko> that's pretty weird -- is it possibly true though?
<james_w> kiko, if it is interrupted you have to start from the beginning, using the incremental approach avoids that problem. That may be what they are referring to
<kiko> james_w, I think it was a perf issue though -- it's davidgiluk's page
<james_w> kiko, also possible, but I haven't really heard reports of that
<jam> kiko: also depends how you define "doesn't like". You can checkout 'bzr lp:qtwebkit' which is about 1.7GB, but we'll use about 1GB+ of RAM to do so.
<kiko> jam, I think that's a good definition of "doesn't like" :)
<kiko> jam, does this get better soon? :)
<jam> kiko: no current focus on pushing the peak memory down. 2.2 is about 2-3x better than 2.0 in this regard, but I haven't come back to address it again
<jam> (iow, 2.0 would take more like 2+GB to copy it)
<kiko> jam, okay, thanks. tough for people working on gcc-linaro, just that
<kiko> but I guess I can buy them more ram as a gift ;)
<mkanat> kiko: It also may be that they're using a 32-bit OS.
<mkanat> kiko: So they can't address more than 2GB per process.
<mwhudson> kiko: it's a bug in the ssh server we use
<mwhudson> STOP SPECULATING EVERYONE
<mwhudson> :-)
<wam> I'm googling for about 2 hours now. How can I integrate/use bzr smart server so that I can commit/push to it? I'd like to use redmine and the repository on the redmine server. I think, redmine has nothing to do with it, because all I need is a smartserver that authenticates against sql. Any hints or URLs?
<mkanat> wam: You could just use SSH and have some PAM module do the authentication.
<wam> mkanat: then I have shell access for every user, righ?
<kiko> mwhudson, oh really?
<kiko> mkanat!
<mwhudson> kiko: yes
<kiko> mwhudson, what's the fix? :)
<mkanat> Hey kiko!
<mwhudson> kiko: hard :( http://twistedmatrix.com/trac/ticket/4395
<mkanat> wam: You don't have to--you could make "bzr serve" their shell.
<mkanat> wam: Or something like that. We do something like that for bzr.mozilla.org.
<wam> mkanat: sounds promising. Do you have any docs for that or should I just read the help?
<mkanat> wam: I don't have any docs personally on the Mozilla setup, no.
<kiko> mwhudson, why does that kick in when the checkout is over 1gb?
<mwhudson> kiko: because the openssh client by default rekeys the connection after 1 gig of traffic
<kiko> gotcha
<mkanat> kiko: So they could do their checkouts over bzr:// if they have it.
<mwhudson> it's launchpad, so that'd be a no
<mkanat> mwhudson: Ahh.
<kiko> indeed
<kiko> mwhudson, can we contract somebody to fix the issue?
<kiko> i.e. please :)
<kiko> I want to avoid any additional bad press we get because of all things a bug in CONCH!!
<kiko> (who's ousado btw)
<mwhudson> kiko: probably
<GaryvdM> mkanat: I made some good progress on adding graphviz to loggerhead: http://imagebin.ca/view/gNbLSX.html
<kiko> mwhudson, how can I help get that ball rolling?
<mwhudson> kiko: i could probably fix it given enough time so you could try going through the infrastructure process
<kiko> mwhudson, I'd rather we contracted somebody else, you're too expensive
<mkanat> GaryvdM: Hey, that looks pretty awesome!
<kiko> GaryvdM, hah, that looks so cool
<mkanat> GaryvdM: Are you just going to make it an option of the normal changes controller?
<mwhudson> GaryvdM: cool
<GaryvdM> mkanat: At the moment I have made a new controller, but I don't mind either way.
<GaryvdM> Good night all.
<mkanat> GaryvdM: Night!
<poolie> mwhudson: we should mention the bzr lp bug there
<poolie> hi kiko, mkanat
<mkanat> Hey poolie.
<mwhudson> poolie: yes, i guess so
<poolie> kiko: so would this be your top item for linaro/udd/bzr?
<kiko> poolie, well, linaro uses bzr heavily for gcc, and whatever causes problems for them I need to pay attention to, as it hasn't been a decision without detractors
<kiko> poolie, I'd be happy to help pay for a contract to get that bug fixed and rolled out
<poolie> k, thanks for raising ti
<poolie> *it
<kiko> poolie, cool, keep me posted on any progress
<poolie> mwhudson, jml, do we know any obvious contractors to do it? i could just ask in #twisted...
<jml> poolie: exarkun.
 * poolie looks for the lp bug
<mwhudson> poolie: i'm not sure there is an lp bug, in fact
<poolie> bug 556132
<ubot5> Launchpad bug 556132 in Launchpad Bazaar Integration "bzr: ERROR: paramiko.SSHException: (affected: 1, heat: 1)" [Medium,Triaged] https://launchpad.net/bugs/556132
<poolie> mkanat: hi?
<mkanat> poolie: hi
#bzr 2010-11-11
<poolie> mkanat: i messaged you
<_habnabit> dash, okay, so I'm trying to figure out how to tell bzr about the svn merges that were done in the past. Do you know what svn prop it's supposed to be looking at?
<dash> _habnabit: svn:mergeinfo i think.
<_habnabit> I have `svn:mergeinfo` set, and it contains accurate infofmation.
<_habnabit> Well.
<_habnabit> Let me double-check the latter bit.
<_habnabit> Does svn:mergeinfo describe merges *into* the branch it's set on?
<dash> I forget.
<dash> I haven't done merges without bzr-svn
<_habnabit> Lucky. :(
<_habnabit> I should've done that from the beginning.
<_habnabit> This is a mess.
<maxb> _habnabit: Your problem is a tricky one. bzr-svn does not directly support it
<_habnabit> Ah, balls.
<_habnabit> What is bzr-svn looking for?
<maxb> Whilst bzr-svn will write svn:mergeinfo for svn to consume, it won't read it
<maxb> bzr-svn looks for its own properties, or (I think) svk's style of merge metadata
<dash> oh snap, svk.
 * _habnabit grumbles.
<_habnabit> I'm sure someone's done this before.
<maxb> I believe the reason for doing so is that it was deemed overly complex to extract which elements of svn:mergeinfo relate to whole-tree merges, vs individual file ones.
<maxb> I'm not sure I agree with that
<_habnabit> Ah.
<maxb> Especially since having started to work with svn:mergeinfo at my work, we've settled on avoiding subtree mergeinfo whereever possible
<maxb> I have explored how to deceive bzr-svn into reading merges a little, but I never really got the procedure working for real
<_habnabit> Lordy this is just a horrible mess. If I'd been using bzr-svn from the beginning, or we were using svn 1.5, this would be so much easier.
<maxb> I think I'd probably attempt to investigate what form svk merge properties take
<maxb> I don't think 1.5 would help
<_habnabit> 1.5 has merge tracking.
<_habnabit> I just need some way of doing merges that isn't svnmerge.
<_habnabit> bzr-svn worked well in the past.
<_habnabit> (For other projects.)
<maxb> 1.5 has merge tracking, but not in a way which integrates with bzr-svn
<_habnabit> Right.
<_habnabit> I'm just using bzr as an svn client right now.
<mkanat> mwhudson or thumper: Is there anything special I should know about doing a new stable release of loggerhead?
<maxb> Ah. I have never tried that. I usually branch from svn into a native bzr branch and work there
<_habnabit> Yeah, unfortunately that's not possible.
<mwhudson> mkanat: not that i know of
<mkanat> mwhudson: Okay, cool.
<_habnabit> Basically my work is horrible, horrible, horrible, and I'm cleaning up my predecessors' messes.
<_habnabit> Somehow, someone broke svnmerge.
<_habnabit> I'm looking at using svk now.
<maxb> I strongly advise against using svk
<maxb> But svk's metadata might be a way to dupe bzr-svn into seeing merges
<mkanat> I think svk is a dead project, from what I've heard.
<maxb> Very dead
<_habnabit> Right, that's what I'm hoping.
<maxb> https://launchpad.net/~bzr-beta-ppa/+archive/ppa/+packages?field.name_filter=bzr-pqm&field.status_filter=published&field.series_filter= I wonder if anyone has any thoughts on these weird bzr-pqm build failures?
<maxb> oh, it's not that deep, it's just launchpadlib versions
<lifeless> maxb: did you see my reply?
<maxb> About testtools? Yes. So I guess I should update my MP for 0.9.7, unless 0.9.8 is going to happen ASAP
<lifeless> your mp ?
<lifeless> maxb: if its a packaging one, I would say don't bother
<maxb> ok
<lifeless> I generally do the merge-upstream dance as part of cutting upstream releases.
<mkanat> Hey, I think I need to be given permissions to commit to the loggerhead-team repositories.
<mkanat> [mkanat@es-compy 1.18]$ bzr push lp:loggerhead/1.18 --use-existing-dir
<mkanat> bzr: ERROR: Permission denied: "+branch/loggerhead/1.18/"
<mkanat> poolie, or thumper?
<mkanat> Or perhaps jam.
<poolie> hi mkanat
<poolie> maybe you're not in the right team?
<mkanat> poolie: I'm in loggerhead-team. Maybe I need to be in another team?
<poolie> hm, i'm not sure
<spiv> That branch appears to be owned by loggerhead-team.
<spiv> And created by mkanat!
<mkanat> Indeed.
 * thumper looks
<spiv> So I think this is one for thumper...
<mkanat> Maybe I have to push to the full URL?
<mkanat> Or at least, the ~loggerhead-team URL.
<thumper> mkanat: you "shouldn't" have to
<mkanat> Now it's just hanging, so I'm guessing it might be working.
<poolie> hm :)
<poolie> and now?
<mkanat> Yeah, just hanging.
<mkanat> No matter which URL I use.
<poolie> try running with -Dhpss and look in the log
<mkanat> Okay.
<spiv> mkanat: hmm...
<spiv> mkanat: If it's hanging, then I think it's a known bug, I'll dig up the number
<mkanat> Stops at:
<mkanat> 7.541  hpss call:   'BzrDir.open_branchV3', '+branch/loggerhead/1.18/'
<mkanat> 7.541               (to bzr+ssh://bazaar.launchpad.net/%2Bbranch/loggerhead/1.18
<mkanat> And then starts doing:
<mkanat> Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
<spiv> mkanat: https://bugs.launchpad.net/launchpad-code/+bug/668176
<ubot5> Launchpad bug 668176 in Launchpad Bazaar Integration "lp-serve infinite loop on bzr branch/push development focus is empty bzrdir with "maximum recursion depth exceeded in __subclasscheck__" (affected: 3, heat: 14)" [Undecided,Confirmed]
<mkanat> spiv: Yep, sounds like my issue.
<mkanat> spiv: So I'm taking it that that fix hasn't been rolled out yet?
<spiv> So far I think the launchpad-code team are planning to wait for bzr 2.2.2 to be released before deploying the fix.
<mkanat> spiv: Okay...so nobody can push new branches until that happens?
<spiv> No, it only affects some slightly odd situations.
<spiv> Like ones where you need to use --use-existing-dir, I think?
<mkanat> Okay. So I'll delete the branch and try again.
<spiv> Perhaps a side-effect of your earlier permission denied problem is creating that sort of situation?
<mkanat> spiv: Yeah, that sounds very possible.
<mkanat> Okay, that worked. :-)
<mkanat> Thanks spiv. :-)
<mkanat> I still got the __subclasscheck__ warning, but it pushed.
<spiv> What caused that permission denied anyway?
<mkanat> spiv: I don't know--poolie, did you change something?
<spiv> mkanat: huh, interesting.
<mkanat> spiv: Oh, wait, maybe it wasn't related to that push, because I'm still getting the messages from somewhere in my console.
<spiv> mkanat: oh, the old ssh connection may still be alive.  You may as well kill it.
<mkanat> Yeah, I just did that.
<mkanat> I'm surprised it didn't get some signal when bzr died.
<spiv> There's a reason why it doesn't, but I forget what it is.
<mkanat> Okay.
<mkanat> Maybe because it's part of a critical section or something?
<spiv> No, I think it's just some vexing aspect of how child processes and python interact, or something like that.
<mkanat> Ah, I recall something about that, yeah.
<poolie> mkanat: i sent a amil with the list of items from our conversation; you can reply if you want to add more
<mkanat> poolie: Okay, cool.
<poolie> mkanat: hi, thanks
<poolie> for the reply
<mkanat> poolie: Yeah, no problem. :-)
<mkanat> Okay, this may sound silly, but I've never had to do this...is there a way to cherrypick a single revision from a branch and merge it?
<poolie> not in a single command
<poolie> though it would be good to add that
<poolie> but basically just 'bzr merge -c REV_SPEC BRANCH && bzr commit'
<mkanat> Yeah, basically, jelmer added an info.py file to trunk on loggerhead, and we should add that to the branch, too.
<mkanat> poolie: But that doesn't keep the revision metadata.
<mkanat> poolie: So it looks like they're separate revisions when you go to merge again, later.
<mkanat> poolie: But that's the only way?
<poolie> i'm afraid so; tracking them is not implemented yet
<mkanat> poolie: Okay. :-(
<mkanat> (We have this problem in a big way in the Bugzilla Project, too.)
<_habnabit> Is there a way to automatically resolve conflicts? I was trying to use resolve --action=take-other, but it doesn't seem to do anything.
<_habnabit> This is with bzr 2.3b4.
<_habnabit> It doesn't remove the conflicted status, and it doesn't change the contents of the file.
<poolie> _habnabit: hm, that seems like a bug then
<poolie> that is what it's supposed to do
<poolie> you may need to give the file name?
<_habnabit> I did.
<_habnabit> 0 exit code, no output at all even with -v.
<poolie> please file a bug tagged 'conflicts'?
<_habnabit> Oh, another thing that seems odd.
<_habnabit> bzrlib is complaining that its version is wrong, when both bzr and bzrlib are 2.3dev4.
<_habnabit> It says '... is version (2, 3, 0, 'dev', 4)'
<_habnabit> Aaaand 'bzr version' says 'Bazaar (bzr) 2.3.0dev4'
<spiv> _habnabit: I wonder if https://code.edge.launchpad.net/~vila/bzr/638451-malformed/+merge/40567 addresses your conflict problem?
<_habnabit> Oh, never mind, that latter issue is me running the wrong bzr binary.
<_habnabit> Looking at that ticket, though.
<_habnabit> spiv, no, but it does something completely different!
<_habnabit> Now I get an InvalidEntryName exception.
<spiv> _habnabit: huh.  Sounds like useful feedback to add to that merge proposal, at least :)
<_habnabit> I just think it's odd that it's taken this long to add!
<spiv> take-other etc are fairly new.
<_habnabit> Yes that's what I think is odd.
<spiv> Well, it just automates something you can do manually.  It mainly cuts out some tedium.
<poolie> hi spiv
<_habnabit> Is there a way to see which revisions would be merged by bzr merge, without doing the merge?
<fullermd> 'missing' will tell you which revs each side has that the other doesn't, so you can tell from that.
<_habnabit> Oh, great.
<_habnabit> This reminds me of another thing. Is there a way to mark revisions as 'plz to not merge ever'
<mkanat> poolie: Okay, release pretty much done. Is there anywhere else I should announce it besides the bazaar list and on Launchpad itself?
<mkanat> s/itself//
<dash> _habnabit: Sort of
<jam> _habnabit: bzr merge; bzr revert .; bzr commit -m "merging without adding the changes"
<dash> yeah that.
<_habnabit> Aha okay.
<jam> the '.' in revert is significant
<jam> it says revert the content, but leave the merge as pending
<fullermd> That still _merges_ it, so it's in the history.  But the changes it made aren't in the current (and presumably future) revs.
<_habnabit> Great, that should do exactly what I want.
<fullermd> So if you don't want to merge it because it contains code you just don't want to use, that's OK.
<fullermd> But if you don't want to merge because it has stuff you don't want to be available (IP reasons, giant files, etc), it doesn't work so well.
<fullermd> It also means that if you ever merge that branch back into the branch those changes were on, they'll disappear there too.  So if you ping-pong between the branches much, it gets ugly.
<_habnabit> I'm using bzr-svn, and it doesn't recognize any merges as having happened.
<_habnabit> So this *should* make it think that the merges happened, I think.
<poolie> mkanat: you could tweet about it?
<mkanat> poolie: Sure, will do now.
<poolie> cool
<poolie> i'm really  glad we got this rolling again :)
<mkanat> poolie: Yeah, me too!
<mkanat> poolie: Okay, tweeted.
<poolie> abentley: congrats!
<abentley> poolie: :-)
<abentley> poolie: are you aware of any tools that automate releasing bzr plugins via Launchpad?
<poolie> i'm not
<abentley> poolie: It seems like we should have written something like that by now.  What do you think of "The Kraken" as a name?
<poolie> sure
<poolie> there are some scripts in bzr/tools
<poolie> and i think something slightly related in hydrazine, to do uploads
<abentley> You mean hydrazine uploading the tarballs?
<mkanat> abentley: How does pipeline relate to loom?
<abentley> mkanat: pipeline is what I wrote when I found looms frustrating to use.
<mkanat> abentley: Cool. I've found them frustrating as well, sometimes.
<abentley> mkanat: They don't introduce any new concepts like threads.  A pipeline is just an ordered list of branches.
<mkanat> abentley: Okay. Are they colocated?
<abentley> mkanat: They don't overload the meaning of push, either.  Instead there's a new sync-pipeline command.
<abentley> mkanat: No, they're just sibling branches by default.
<mkanat> abentley: Okay. I suppose I could just try it out instead of asking you. :-)
<abentley>  mkanat: They could be combined with colocated stuff, but I haven't done that yet.
<mkanat> abentley: Okay.
<mkanat> I found a few things particularly confusing or difficult about looms. Like trying to remember which directory I had which loom set in, for one.
<mkanat> And then that they would permanently loomify your branch.
<mkanat> And then certain weird and unexpected things about moving up or down threads.
<abentley> mkanat: Right.  With pipelines, the format is always a standard Bazaar format.
<mkanat> Coo..
<mkanat> *Cool.
<abentley> mkanat: You can switch between pipes with the normal bzr switch command, or with "switch-pipe" which will auto-shelve your uncommitted changes.
<mkanat> Sweet.
<abentley> mkanat: The weird up-thread behaviour is a separate "pump" command in bzr-pipeline.
<jtv> I guess my repo is broken; see bug 673439.  Could anyone help me get back on my feet again?
<ubot5> Bug 673439 on http://launchpad.net/bugs/673439 is private
<jtv> Thank you ubot
<lifeless> abentley: switch in looms doesn't do up-thread either, fwiw
<jtv> spiv: last time you fixed me up IIRCâ¦ would you mind doing it again?  :)  Can I just remove the broken file?
<jtv> Got matching cix, iix, rix, six, and tix files all empty.
<jtv> lifeless: I hear you're pretty good with bzrâ¦ if I have a tuple of empty cix, iix, rix, six, and tix files in my repo, can I just delete them or something along those lines?
<jtv> (imagine a smiley after that first sentence)
<lifeless> uhm
<lifeless> so that means you had a system crash without the content getting flushed
<lifeless> the canonical answer is restore from backup
<spiv> jtv: hi
<lifeless> you may be able to rollback a single transaction if there is a .old pack-names file
<jtv> hi spiv
<lifeless> jtv: however I'm being called to the kitchen... and I'm not working today so I have no excuse :)
<glyph> https://bugs.launchpad.net/bzr/+bug/673884
<ubot5> Launchpad bug 673884 in Bazaar "dpush ends up in a broken state if it encounters a network problem (affected: 1, heat: 6)" [Undecided,New]
<spiv> lifeless's advice is (of course) good.  If there isn't an old pack-names file you may be able to recover by cutting the broken pack out of pack-names.
<jtv> lifeless: backup, you say?  Physically out of reach for the foreseeable future.  :-(
<spiv> glyph: https://code.edge.launchpad.net/~maxb/bzr/2.2-close-ssh-subprocess-socket/+merge/40493
<abentley> lifeless: true, but AIUI mkanat finds up-thread vs down-thread confusing, and pipelines doesn't have that kind of quasi-similar command.
<glyph> spiv: is that a fix for it?
<spiv> glyph: oh, dpush, not dput :)
<glyph> gah what's dput
<mkanat> abentley: I don't know if I find that confusing, actually.
<spiv> glyph: a debian package archive thing, forget I mentioned it!
<dash> not a bzr command. :)
<mkanat> abentley: up-thread and down-thread as concepts are fine, it's that sometimes I want to switch between looms without all the merge craziness.
 * spiv looks more closely
<glyph> spiv: It's a pretty obvious bug, sorry for the somewhat obtuse description.
<mkanat> abentley: Or I want to switch all the way down in one command.
<abentley>  mkanat: so, you can always do both those things.
<spiv> glyph: yeah, that looks like a reasonable bug to me.
<mkanat> abentley: Also, when I push some of the lower threads into the repository but not the upper ones, the combine-thread functionality is annoying, often.
<glyph> spiv: As bzr bugs are wont to do, it showed up immediately in the middle of trying to demonstrate to a co-worker why bzr is great :(
<abentley> mkanat: you do down-thread [THREAD]
<abentley> mkanat: even if the thread you want to switch to is higher.
<spiv> glyph: and probably fairly easy to make better in many cases (and maybe even not too hard to make good in tricky cases, like e.g. local system crash/power drop during dpush).
<spiv> glyph: s/bzr/all software/ ;)
<glyph> spiv: yeah.  thanks :)
<glyph> spiv: I am planning to use dpush increasingly heavily, so it'd be great if it worked right :)
<glyph> In the meanwhile, is there any sensible way to do a cherry-pick which preserves log messages?
<spiv> glyph: use rebase to do the cherrypick, maybe?  :/
 * spiv hmms
<glyph> spiv: is that a thing you can do?
<glyph> spiv: That was actually my first thought.
<spiv> glyph: another option would be to write a plugin to add a log format that output the commit message (and only the commit message), and then you could do "bzr merge -c NNN && bzr log --format=msg-only > commit.msg && bzr ci -F commit.msg"
<lifeless> mkanat: in a loom you can use 'switch'
<spiv> glyph: (or abuse the existing xmloutput plugin or something like that for the same purpose)
<lifeless> mkanat: to avoid all that
<mkanat> lifeless: Ah, okay.
<lifeless> switch thread-name
<lifeless> mkanat: could you file bugs though where things are unclear
<lifeless> mkanat: including what it is about combine-thread thats annoying
<mkanat> lifeless: Yeah, if I can quite figure out what I don't like, I will.
<glyph> spiv: while that would be useful, I was hoping not to write that shell for-loop for every revision :)
<lifeless> mkanat: even if you don't have that figured out
<lifeless> mkanat: bug reports are about symptoms, not answers.
<spiv> glyph: *nod*
<spiv> glyph: rebase may be the right tool here, but it's just not something I've used much at all so I don't know the limitations and nitty gritty details of using it for stuff like this.
<spiv> lifeless: I know you aren't here
<spiv> lifeless: but you may be interested to know that doing working on making branch etc fetch all the tags as well as the tip is pushing me towards other improvements that have the side-effect of chipping off a few hpss round trips.
<glyph> spiv: thanks for the classification
<A117> bazaar explorer failed to run on XP
<A117> any help plz?
<spiv> A117: please file a bug at <https://bugs.launchpad.net/bzr>.  Hopefully someone that knows more than me about bzr-explorer and/or XP will be able to help you here too.
<spiv> A117: also, give a bit more detail about your problem... in what way did it fail?  What were you trying to do when it failed?  What installer did you use?
<A117> instaler for windows. error message is bzr
<A117> CreateProcess failed; code 2
<lifeless> spiv: thats great
<lifeless> spiv: there's stuff in loom that badly needs your love in the same way
<lifeless> spiv: using the same multi head improvements
<lifeless> spiv: I had the idea of having a get_refs() call to find out what heads to fetch
<spiv> lifeless: yeah, it'd be nice to give loom some love... I should make some time.
<lifeless> spiv: I hear udd would cover it
<lifeless> :)
<spiv> :)
<GaryvdM> Morning all.
<GaryvdM> Bla- Just missed A117
<peitschie> (a very late hiya GaryvdM :)  )
<stefanlsd> hihi
<GaryvdM> Hi stefanlsd
<stefanlsd> Anyone familiar with bzr merge-package and what happens with the debian/changelog. seems like its ignored?
<maxb> stefanlsd: Ignored? No, but it is processed with a custom merge tool that understands the format of debian/changelog entries and sometimes does things rather differently to what you might expect if you were expecting a textual merge
<stefanlsd> maxb: aah ok. yeah, i actually see it was more intellegent than i expected. thanks
<figure002> hello! I'd like to use parts of the text in http://doc.bazaar.canonical.com/bzr.2.1/developers/HACKING.html for my own Sphinx documentation, is this allowed?
<james_w> figure002, it should be, but I can't remember what license it is under
<figure002> ok, and if it is allowed, can someone tell me how to give the credit?
<vila> figure002: in what context do you want to re-use it ? (Keeping in mind that GPL is more about distribution than use)
<figure002> vila: i'm developing a python app for analyzing biological data for a small biological company. i'd like to use parts of that documentation for the Developer Guide of my application.
<vila> figure002: so you intend to distribute the result ? Undr which license ?
<vila> figure002: We're talking about distributing your developer guide here
<figure002> vila: the app is GPL3, so i would use the same licence for its documentation
<vila> ha, if it's GPL I see no objections on principle, now the differences between v2 and v3 are... way beyond my legal knowledge :)
<vila> you could try to get in touch with poolie (see https://launchpad.net/~mbp), but I think it's ok
<figure002> vila: haha, also, i mailed Canonical a few minutes ago about this
<vila> figure002: even better
<vila> figure002: nice of you to do that anyway :)
<figure002> vila: so according to you, that documentation is licensed under GPL also?
<figure002> vila: :)
<vila> figure002: honestly, I don't remember. There have been discussions about which license should be used but I don't remember the specifics, I'm 75% sure it is GPLv2 though
<figure002> vila: ok
<vila> figure002: see bug #433734
<ubot5> Launchpad bug 433734 in Bazaar "documentation doesn't make its licence terms clear (affected: 2, heat: 0)" [High,Confirmed] https://launchpad.net/bugs/433734
<vila> argh urgh too late he left :(
<vila> mgz: ping, I'm finally reviewing lp:~gz/bzr/cleanup_testcases_by_collection_613247 again
<vila> mgz: far cleaner than I remember overall !
<vila> mgz: running it locally with --parallel=fork I have a *huge* number of uncollected test cases (still running)
<vila> mgz: it's also running on babune as http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-all/98/aggregatedTestReport/ so you'll get a bunch to eat ;)
<vila> mgz: more than 11000 uncollected, surely this is a shallow thing, any subset I could try to focus ?
<vila> mgz: right, it looks like *all* tests are uncollected
<vila> bah, and the babune run seems to be exhibiting yet another subunit stream leak :(
<vila> mgz: I'll abort the babune runs, forget about them
<vila> mgz: ha right, the local run finished, 7 failures, all in bzrlib.tests.test_selftest.TestUncollectedWarnings
<vila> mgz: re-running without --parallel seems to exhibit the same behaviour :-/
<vila> only slower :)
<vila> mgz: ./bzr selftest -s  bzrlib.tests.test_selftest.TestUncollectedWarnings => 7 failures
<vila> ok, so I'm definitely speaking alone tonight, I'm going to copy that to the mp instead :)
<GaryvdM> vila: some of us are listening :-) Unfortunately I can't add much to the discussion.
 * fullermd isn't listening, if that helps   :)
<vila> :-D
<lifeless> mgz: shiny new in testtools ;)
<vila> lifeless: s/propogate/propagate/ no ? (at least 4 occurrences), raises_value_error is cute, make_error is brilliant and deserves a comment, hehe game of the day: make test_KeyboardInterrupt_matched fail :D
<lifeless> vila: interesting... python 2.4 I bet ?
<vila> lifeless: no no it succeeds, no problem but *how* can you make it fail ?
<lifeless> if you revert a few commits, and put the test back in, it will fail
<vila> if you type ctrl-C at the right time too ;)
<lifeless> no
<lifeless> there are two cases
<lifeless> either you trigger k-i within the block its expected
<lifeless> in which case (sadly) it will be ignored
<lifeless> or you trigger it outside it, in which case it will propagate :)
<lifeless> and the test run will abort
<vila> ah right, silly me, if you catch *my* k-i you will won't trigger yours, but one is still happening, rats, too bad ;)
<vila> s/will//
<vila> lifeless: I wish our stable ppa was used in the pqm chroot so we can rely on updating pqm when updating our stable ppa (which should be fine since it's our best validated bzr version after all), that would ensures a broad and correct deployment of testtools...
<lifeless> why don't you do that then ?
<lifeless> or something analogous
<vila> what more can I do than adding my last comment on rt 41340 ?
<vila> lifeless: you mean by using a private testtools updated by the makefile ?
<lifeless> no
<vila> then what ?
<lifeless> have a ppa with the stuff in it that gets used.
<lifeless> e.g. the CAT ppa, perhaps.
<vila> CAT ? url ?
<lifeless> I don't have it offhand
<lifeless> is the sysadmins ppa
<vila> meh, why would I have more control an this than on pqm which currently is == 0 ?
<vila> s/an/on/
<lifeless> You could have its contents auto deployed to pqm
<lifeless> or a dedicated ppa
<lifeless> I dunno, I'm offering suggestions.
<lifeless> I think you'll find they deploy testtools from the CAT ppa anyhow
<vila> but why isn't our stable ppa valid for that ?
<vila> ha, that's interesting then
<lifeless> vila: I don't know - have you discussed this with tom ?
<vila> hmm, at least using our private one could serve as a temporary workaround
<vila> lifeless: no, I'm asking for feedback but Chex told me the losas are in a degraded mode these days
<lifeless> this week for sure
<lifeless> hol-i-days
<vila> geez, yeah, Valentine told me today was one here... and that was why she was a t home (ooooooops :)
<poolie> hi jam, spiv
<spiv> Hi poolie
<poolie> i'm going out to give blood in a bit, will be back later
<poolie> then i'm going to see about finishing my outstanding branches and graphing packages built from branches
<spiv> I'm going to keep working on fetching all tags as well as tip when doing e.g. 'bzr branch'.  There's an incremental step towards that, fixing sprout to open & lock branches/repos once, that I have passing tests but want to polish.
<poolie> k
<poolie> i liked seeing the hpss ratchet go down
<poolie> and locking just once would be very nice
<poolie> ok, biab
<spiv> I also need to figure out what to do with <https://code.launchpad.net/~spiv/bzr/checkout-tags-propagation-603395-2.2/+merge/40406>, perhaps just landing on trunk and not 2.2 is the way forward for that.
<spiv> Yeah, the fix to sprout knocks one of the hpss ratchets down by another two calls :)
#bzr 2010-11-12
<spiv> Oh, hmm, and I should probably take a look at https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/674091
<ubot5> Launchpad bug 674091 in bzr (Ubuntu) "bzr crashed with ErrorFromSmartServer (We are missing inventories for revisions) (affected: 1, heat: 12)" [Undecided,New]
<mkanat_> Is it OK for me to fix trivial bugs by committing directly to an LP branch of loggerhead, or should I still do a merge proposal?
<mkanat> Just going to do it.
<nule> hi all
<nule> quick question if anybody has a second
<nule> i'm converting a number of open-source projects to bzr from svn and I wondered if there was a way using svn-import to include a number of projects into what should really be one repo - they're currently all seperate svn repos
<nule> seems like it always inits a new bzr repo with the import
<nule> stepping away for a few, but i'll hang out for a bit if anybody has some ideas - might just not worry about history in the new repo
<nule> thanks
<mwhudson> nule: repositories are boring in some sense in bzr; they're just bags of revisions, an optimization to avoid storing the same revision more than once
<mwhudson> nule: as branches from separate repos won't share revisions, there's no real point to putting them in the same repo
<mwhudson> (nothing stopping you doing that after the fact)
<maxb> nule: It would be interesting to have the specific example of the projects that you want to combine, and would make it easier to offer advice
<nule> and i'm back, thanks mwhudson and maxb
<nule> I have a bunch of libraries and utilities that depend on those libraries
<nule> right now building them depends on having them checked out relative to one another for the paths to work, and since they're not that huge i though it'd make more sense to essentially have them all in one big project
<nule> here are two of the actual projects: https://svn.thot.us/svn/nule.org_LightHl7Lib/ and https://svn.thot.us/svn/nule.org_IntegrateClientLib/
<maxb> nule: OK, the important question you need to ask yourself is: Does it make sense for the combined tree to ALWAYS be checked out, branched, tagged, released as a single unit from now on?
<maxb> If the answer is no, you don't want to meld them into a single bzr branch
<mwhudson> what's the plugin for this sort of thing, bzr-scmproj?
<nule> good advice, maxb, my thoughts are that it's not that "expensive" to check them all out (they're not huge) and then I could include an ant and properties file in the root that would vastly simplify building and bundling new builds for distribution
<nule> i'm using bzr-svn for this, mwhudson
<spiv> nule: they aren't mutually exclusive plugins :)
<maxb> nule: bzr-scmproj is a plugin that has something to do with aggregating multiple bzr branches into a combined work area
<nule> spiv: i had considered that after i hit enter :)
<fullermd> nule: So, the nice thing about a VCS is the ability to undo stuff later.  But one thing that's very difficult to undo is putting things together in a single branch; breaking them out separate later on requires messy and heroic measures.
<maxb> nule: OK, different question - does it make sense for the entire tree to have a single version number when you release it - *always* ? Do your projects currently have separately managed version numbers? If so, are you prepared to change that?
<nule> those are both good points
<maxb> If you feel that it is meaningful to sometimes release some subset of projects separately from the whole tree, that's a good indication that a single monolithic bzr branch is the wrong approach
<fullermd> This is a place where bzr-think and svn-think differ; what things you really _need_ to decide before you start.
<maxb> Instead, there are things like bzr-scmproj (and, I think other related plugins) that can assist with working on a forest of branches in a specific layout, instead of making a single branch
<nule> i will definitely investigate bzr-scmproj to see if it solves my most pressing needs
<maxb> Unfortunately, I have no experience with these forest of branches plugins, so I cannot advise on them
<nule> right now i drag my feet on new releases because making sure I'm releasing everything with a consistent (and working) set of libraries is very timeconsuming
<nule> in that sense having a unified build number would be lovely
<nule> but you're right that while I need to rebuild * if the lowest library changes, I don't if the highest application changes
<fullermd> One good signpost is that if those libraries are ever used (or ever to be used) by something other than this project, that's a good sign they should be separate.
<nule> definitely good things to think about, there's no real reason I suppose that i can't have a separate build project at the same level as the others to facilitate my release process
<nule> "process", more like mayhem right now
<fullermd> Another point is that what I said above about _splitting_ branches doesn't apply to _combining_ branches.  You can combine two branches into one easily.
<fullermd> Just once they're together, breaking them apart is very difficult.
<nule> i definitely see that, fullermd, you're going to lose history no matter what at that point
<nule> good stuff to think about, all, appreciate the advice
<fullermd> So you can start with them separate, and if you decide later on they should all be jumbled together, it's just a few quick, easy, history-preserving operations to roll them up.
<poolie> jam, don't suppose you're still up?
<jam> poolie: indeed I am
<jdobrien> I accidentially deleted a directory which had a lot of edited files. How can I recover the directory without reverting all the changes I made?
<poolie> a lot of uncommitted edits?
<poolie> you probably need to look at using an OS-level undelete tool
<jdobrien> poolie, yes ...refactoring
<poolie> sorry, bzr won't have had a chance to store the files if you don't commit them
<poolie> there is discussion of 'bzr rm' etc optionally moving things to a trash directory, but we don't do that at the moment
<poolie> i have rdiff-backup setup to run every couple of hours :/
<jdobrien> ok
<jdobrien> i got lucky
<spiv> Well, 'bzr rm' by default will backup files that changed since the last commit to *.~1~ or whatever, so bzr itself is pretty safe by default.
<jdobrien> i didn't bzr rm
<spiv> But there's not much bzr can do about other tools deleting files.
<jdobrien> yeah...fortunately this tool let me undo it
<jdobrien> it was a silly mouse slip
<spiv> That is fortunate.
<jdobrien> yes
<spiv> It's so much nicer using tools that let you undo mistakes.
<jdobrien> i can't believe i made all these edits without a commit..i usually am really good about that
<spiv> jdobrien: no-one is perfect :)
<jdobrien> especially after 1am
<spiv> Hehe.
<jdobrien> bzr commit ... and bed
<jdobrien> thx all
<spiv> Wow ControlDir.sprout is ugly.  After several rounds of refactoring it in this branch it it still alarmingly long and complex.
<spiv> Hmm, I'm getting failures in bb.test_outside_wt with trunk.
<spiv> But it's 6pm Friday, so I guess I'll just file a bug instead of figure it out :/
<vila> hi all
<vila> spiv: which file between bb and test_outside ?
<vila> oh, it *is* a file 8-)
<spiv> vila: https://bugs.launchpad.net/bzr/+bug/674373
<ubot5> Launchpad bug 674373 in Bazaar "test_outside_wt failures on trunk (affected: 1, heat: 6)" [Critical,Confirmed]
<vila> on a pristine trunk ??? wow
<spiv> vila: the good news about that bug for me is that it's not the patch I'm working on that is breaking the test suite ;)
<spiv> vila: yeah, hence why I jumped straight for Critical
<vila> indeed
<vila> checking locally
<spiv> Hopefully nice and shallow.
<vila> wild guess: you're sure you didn't create a repo in /tmp by some weird side-effect ?
<spiv> Still occurs with total --no-plugins
<spiv> vila: it's possible!
<spiv> Hey look at that.
<spiv> vila: well done, that was it
<vila> pfew, good :)
<spiv> vila: it would be good to isolate the test suite from that sort of strange environment :)
<spiv> I'll update the bug
<vila> spiv: like... by switching to in-memory file systems ? :-D
<spiv> vila: well, the usual TestCaseInTempDir would probably do in this case.
<spiv> But I haven't looked closely, being post 6pm Friday :)
<vila> spiv: well, despite having a safety net, there will always be tests that want to check that they don't find a repo up in the hierarchy, which we can't isolate properly by definition
<vila> well, "can't" because we use an external resource which is the '/' filesystem
<spiv> vila: the empty unshared bzr repo created by InTempDir takes care of that
<spiv> But there may be something special about this test and /
<spiv> Anyway, EOD for me.
<vila> spiv: nope, it *is* a repo, some tests want no repo at all
<vila> spiv: yeah, enjoy your week-end
<poolie> hi there vila, how are things with you?
<poolie> i might finish up too
<poolie> barely any code this week :/
<vila> spiv: and to peace your mind: full test suite pass here
<spiv> vila: at worst it could be a feature test
<spiv> vila: self.requireFeature(NoRepoBetweenMeAndRoot) ;)
<fullermd> Just start out the test with `rm -rf /`...
<vila> poolie: fine, I'm becoming impatient to have an updated testtools on pqm to clear up mgz patches that are in the active queue for far too long :-/
<vila> spiv: sure, they will always be skipped, no failures ;)
<vila> fullermd: really ? Let me try that....
<fullermd> Mwahaha.  My plan progresse....   bah.
<vila> :D
<vila> poolie: so, things are fine :)
<spiv> Ok, really done now.  Hopefully I'll finish slaying the sprout monster on Monday!
<vila> poolie: a couple of pending mps waiting for reviews but I still have more to work on
<poolie> spiv, feel free to clean up sprout too :)
<poolie> i'm meant to be pilot next week
<vila> poolie: there is an interesting discussion about configs in https://code.edge.launchpad.net/~doxxx/bzr/mergetools/+merge/38663 that should help me progress by identifying the next easy steps
<vila> poolie: well, easy is a  bit optimistic but manageable steps at least
<spiv> poolie: yes, that's basically where I've spent a large chunk of today
<poolie> i skimmed the mail very briefly
<poolie> \o/
<poolie> i'll try to look at that next
<vila> 1) interpolation with {option} syntax
<vila> 2) sections in bazaar.conf
<poolie> ok
<poolie> actually s is home so i might go now...
<vila> but first I should submit my braindump for feedback, I think I'm pretty close to a definition that addresses the main compatibility issues I was fighting with
<vila> ok
<vila> poolie: let's try to talk a bit on monday
<poolie> ok, good night
<vila> AFK maybe ? :)
<mgz> vila: sorry, the ol' unpushed to lp problem
<vila> mgz: hey !
<vila> mgz: for the uncollected tests ?
<mgz> yup, those failures.
<vila> mgz: ok, pulling and retry time it is then !
<mgz> I left the tip on lp in a borked state, will add my local changes.
<vila> I'm sorry for your other patches :( I keep pinging losas to no avail :(
<vila> hmm, branches diverged
<mgz> hm, just a sec, need to commit some local changes too
<vila> ok, ping when it's done
<mgz> was trying to find a spare evening to try out a version along the lines of what spiv was asking for
<mgz> okay, push done
<vila> grr, stupid setup, I know it's based lp:bzr, I do that for be able to review with -rsubmit:, but when I then ask for pull-v ,just FDWIM and pull from the mp branch !
<vila> interesting, far more typos when I'm angry...
<vila> ooops, did I say that publicly ? :D
<fullermd> Rellay?  I hand't noticed...
<mgz> you're a talented snarker, fullermd.
<vila> . o O (That's it ! He put *me* in his triggers ! They say I'm paranoid...)
<fullermd> I gotta stick with my strengths...
<fullermd> They say?  Who say?  Are they watching you?  How do they know that?!
<vila> . o O (And why did I put mgz's mp into WIP, where is it now ??)
<mgz> https://code.launchpad.net/~gz/bzr/cleanup_testcases_by_collection_613247/+merge/38999
<vila> ha thanks :) Did *you* put it back to NeedsReview or should I blame... fullermd !
<fullermd> Me?  I couldn't possibly have done it.  I was busy robbing a bank when that happ...  wait.  Wrong alibi...
<vila> *MY* bank !
<fullermd> Oh.  That would explain why I didn't get anything out of 'em...
<mgz> you never marked it WIP by my email log.
<vila> mgz: ha, that should explain it then :)
<mgz> which is probably a good thing, doing the new-giant-diff-by-email too often gets tiring on the thread
<vila> still a lot of uncollected
<mgz> I've lost all track of Gordon's mergetools branch
<vila> trying --parallel first to see
<vila> mgz: I convinced him to split it up to ease review
<mgz> lots as in thousands -> update testtools, lots as in hundreds -> list please
<vila> 5000 so far, checking testtools
<mgz> there are various tests that don't run or run differently on this box, and I've not tried it on my nix one as it'd probably take years to complete a full test run
<vila> revno 129 missing only one from jml about deferred tests, unrelated right ?
<vila> ha damn, I should retry the subset first
<vila> --parallel almost finished
<vila> ok, so success for the full run, but all tests uncollected
<vila> well I didn't check the 26748 ones but my buffer contains 26780 lines so that should be closed
<vila> s/d//
<vila> s/d$//
<vila> grep -n Uncollected test| wc -l => 26751 :)
<mgz> harumph.
<vila> mgz: could *you* try to upgrade testtools ?
<vila> . o O (If I'm right he won't be happy :-/)
<mgz> I did after Robert merged that change, and didn't think I saw anything else dangerous go past, but will do.
<mgz> nope, looks good here. will just test that it's not related to the command line given.
<mgz> hm, some new doctest progress bar junk, but fine otherwise.
<vila> less uncollected test cases with --parallel
<vila> ~100/600 so far
<mgz> it sounds to me a lot like the testtools patch isn't there for whatever reason
<vila> :-(
<mgz> I'll try this on my nix box to rule that out as an issue thoug
<vila> I just checked I'm using trunk
<vila> testtools trunk that is
<vila> ~300/4000
<breakfast> hi all
<breakfast> i've been trying to figure out how to make "bzr diff --using=diff" the default behavior, so that when i call "bzr diff" without --using it still does that by default. can you point me to a resource that explains how to do that?
<mgz> `bzr help alias`
<breakfast> thank you
<vila> ~1200/11000
<mgz> that's sounding more possible. hopefully this'll finish branching in a sec and I can try here
<mgz> seems to be taking about a minute for each hundred at 7000/13750 though...
<vila> mgz: huh, what are you branching ?
<mgz> bzr.
<vila> oh, on an out-of-date system you mean /
<vila> ?
<vila> (which implies an old bzr too of course)
<vila> mgz: download a recent one first :D
 * vila duck
<mgz> should be reasonably recent, no way I'd use the lenny bzr.
<mgz> but it's a very memory-constrained box.
<mgz> probably should have used smart server this time, but I couldn't branch bzr *at all* initially with the smart server.
<mgz> as this is just updating the shared repo, it probably wouldn't die.
<vila> mgz: no way to branch from your local box ?
<mgz> well, scp.
<vila> if you're cautious and clean up afterwards, that should work
<vila> oh, you meant wt or branch ?
<mgz> I'm trying to branch, but giving in and copying the wt is what I'd fall back to.
<mgz> this is why I seldom try and run selftest on that box though :)
<mgz> ooo, estimate jumped from 8500 to Done
<mgz> will it actually finish?
<mgz> go go little box.
<vila> http://paste.ubuntu.com/530767/
<vila> so roughly 1800 uncollected tests
<mgz> thanks!
<mgz> hm... looks funky.
<vila> as in ?
<mgz> at a guess from the test names, one think that creates a cycle on a nix osutils unicode path
<mgz> s/think/thing/
<vila> the bzrlib.tests.test_conflicts.TestResolveContentsConflict series don't involve unicode AFAIR
<mgz> hmph, and I don't get these problems on my nix both.
<mgz> *box.
<vila> hmm, angry huh :)
<mgz> so, theory #2: you have a plugin that breaks things.
<vila> nope, BZR_PLUGIN_PATH in effect
<vila> oh, loom ?
<mgz> Uncollected test case: bzrlib.plugins.loom.tests.test_tree.TestTreeDecorator.test_up_not_merged
<mgz> right.
<fullermd> Yeah, loom could warp things.
<vila> nope
<mgz> a weaving joke.
<vila> .. passing above my head ;-/
 * fullermd will be here all week...   don't forget to tip your waitress!
<vila> and same result with --no-plugins
<mgz> what's different ;_;
<mgz> 2.5.2 rather than 2.6.6 perhaps, but that's not much of a theory.
<mgz> and 2.7 trunk works fine for me here, so would need to be some other factor as well.
<mgz> 2 from 225 on my nix box so far, and you don't get either.
<mgz> okay, thanks for your help vila, I'll poke around a bit and see what I can work out.
<vila> -s bb.test_conflicts 8 tests 8 uncollected
<vila> mgz: well, if you can't reproduce what will you do ? :-/ Any idea where *I* can poke ?
<vila> ./bzr --no-plugins selftest -v -s bb.test_conflicts.TestConflict 3 test/ 3 uncollected
<vila> but hmm, bb may not be the easiest
<mgz> not only can I not repo your list, but I'm getting a different one.
<mgz> none of bb.test_filesystem_cicp.TestMove gets collected on my nix run
<vila> get uncollected you mean ?
<mgz> right.
<vila> do we have some tests in common ?
<mgz> none so far.
<mgz> oh, maybe three dpush ones?
 * mgz checks
<mgz> I've got an unholy memory crawling function that helps a little, but basically just want to see what's pointing at the test when it should be dead.
<mgz> sticking a breakpoint on the "Uncollected" print and using gc.get_referrers works
<vila> get_referrers(case) ?
<mgz> yup.
<vila> http://paste.ubuntu.com/530772/
<mgz> it's often something unhelpful, like a frame, or a cell
<mgz> ...or a dict
<mgz> that's probably the:
<vila> a frame is part of the calling stack right ?
<mgz> <bound method TestConflicts._run_setup
<mgz> ^right
<mgz> but I should be able to repo bound method cycles...
 * mgz looks at the case
<mgz> where's it coming from...
<vila> grep says: testtools deferredruntest.py
<vila> which should be totally unrelated to bzr >-/
<vila> ha !
<vila> deferredruntests.py depends on twisted which I bet you don't have installed
<vila> mgz: python -c 'import twisted'
<mgz> I do, but probably not the same version.
<mgz> I've got 8.1.0
<vila> python -c 'from twisted.internet import defer
<vila> from twisted.python import log
<vila> from twisted.trial.unittest import _LogObserver
<vila> '
<mgz> I'll put twisted on my nix box and see if I can then get your list.
<vila> 10.1.0-2 for python-twisted
<mgz> and look at the derferred stuff again, don't really see why bzr cases should be involved with that at all
<mgz> ^thanks
<vila> err python-twisted-bin
<vila> me neither, but I chased your _run_setup pointer :) I have no idea if this was relevant ;)
<mgz> wait wait, what was it you said earlier...
<mgz> <vila> revno 129 missing only one from jml about deferred tests, unrelated right ?
 * mgz checks that rev
<vila> of course that why I grepped testtools
<mgz> ooo, and I just got per_branch collection failures.
<mgz> so that's tractable at least.
<vila> mgz: does that mean you can progress from there ?
<mgz> okay, rev 130 may well fix some of those bb issues
<mgz> and I've got some other things to look at too.
<vila> -s bb.test_conflicts 8 uncollected still (I pulled it circa 17:14
<vila> i.e. 30 minutes ago
<mgz> gra.
<mgz> okay, was probably a red herring. twisted shouldn't be involved.
<vila> looking at -s bt.test_version_info 4 uncollected out of 8 tests which seem to be the simplest of the lot
<vila> gc_referrers mentions <bound method TestVersionInfo._run_test_method of <bzrlib.tests.test_version_info.TestVersionInfo.test_custom_version_text id=0x21edbd0>>,
<vila> also from testtools :-/
<mgz> if there are also lots of frames like before, it's probably from a exception raised there.
<mgz> I think I just need to look more closely at the recent testtools changes.
<vila> ok
<vila> Just a remark though, this itches again about innocent devs introducing cycles which.... sounds wrong
<mgz> well, this is mostly test structural stuff which needs to be right, otherwise we risk leaking the world which is what broke me in the first place
<mgz> but I agree that avoiding that without also burdening normal test contributors looks... challenging
<vila> may be I still need to be lectured on the cycle topic... so, again, if you could send some failing tests like we tried to find some time ago, this could help me
<mgz> testtools rev 129 I'm looking at now and could be problematic
<vila> would you like me to revert to 0.9.7 instead ? (But that would still not explain why we get different failures)
<mgz> if you want a vanilla cycle, the definition of bzrlib.errors.HookFailed.__init__
<mgz> ^thinking about it, I never updated the testtools on my nix box, just this one.
<vila> mgz: 0.9.7 : some failures for test_vesion_info
<vila> same
<mgz> I've had failures in test_version_info for ever
<vila> about uncollected ?
<mgz> no, actual failures.
<vila> meh
<mgz> it looks outside its tempdir
<vila> argh, use a real wt
<mgz> are you on bt or bb for that?
<vila> bt
<vila> 10 tests 4 uncollected
<mgz> hm, I'm clean on that, except on windows:
<mgz> While running: bzrlib.tests.test_version_info.TestVersionInfo.test_python_version
<mgz> Unable to remove testing dir ersionInfo.test_python_version
<vila> ETOOMANYBUGS :(
<mgz> yeah.
<vila> so back to my earlier suggestion there I think: can you make this control conditional so we can land something that helps you ?
<mgz> okay, looking at the source, I see potential problems
<mgz> but... I'm not seeing the fallout
<mgz> so, I'll fiddle.
<mgz> but yeah, I could make this a -E flag for landing.
<vila> ... one more on the pile waiting for testtools that is :-(
<mgz> the other option is what spiv said and only doing once generic warning at the end, but this means it's more likely a change will totally break me later.
<vila> nah, I didn't want to say that !
<vila> not at the end the week :-/
<vila> mgz: as opposed to still not un-breaking you until this lands you mean ?
<mgz> well, with the flag it wouldn't even need the pqm update... if I version check in the new tests
<vila> my problem with mps that took too long to land is that a lot of energy is lost without positive feedback for the submitter
<mgz> yeah, and it's hard for all involved to hold the review in their head
<vila> well, lp helps a lot there, I was thinking about keeping the patch up-to-date
<vila> so, about HookFailed, the bactrace includes references to the test instance so storing it as an attribute creates the cycle right ?
<vila> why not just clearing the backtrace and keeping only the class and the exception object then ?
<mgz> yup.
<mgz> right, that would be fine.
<vila> mgz: trying to find alternate ways, not rebutting your approach here
<mgz> in that particular case, not only is storing exc_info not needed, but the whole exception class could probably now be deleted
<vila> at least that could be explained to all devs and *can* be avoided
<mgz> I think these things are generally easy to avoid like that, the problem is just that if it's not the person writing the code that notices
<vila> right, so we need some better cycle detection
<mgz> and mostly it's obscure and shouldn't really matter, so just allowing the cycle would be an option... bar the fact that then a change that leaks thousands of tests goes unnoticed till my machine starts swapping
<mgz> so, it's lots of total trivia, to be able to avoid the occasional thing that really hurts
<vila> mgz, well, I could add a low-memory slave on babune or add a run with ulimit or something
<mgz> would be nice to just ulimit the lot of ~200MB
<vila> wow
<mgz> the suite runs within ~100MB with this branch
<vila> Wow
<vila> my slaves are ~2GB to allow --parallel because I never had the time to check whether this was needed
<vila> except freebsd that is 4G, but I blame fullermd here
 * fullermd . o O ( One more blame, and I get a bingo! )
<vila> truth is fullermd can also write some nice docs and do some nice reviews :D
<mgz> parallel does complicate things a little, as python eats cows, but 200 * fork should be more than enough
<fullermd> Ack!  Be careful!  You say things like that, next thing you know I'm a productive and useful member of the community.  Then it's nothing but work, work, work, all the time   :(
<vila> hmm, and --parallel doesn't provide any means to let subprocess reports more data to the spawner like how much memory they consume
<vila> mgz: hehe crossed on the wire, we're talking about two different things, giving Gs to slaves is not a problem, *checking* what is consumed is what I was after ;)
<vila> fullermd: I'm not holding my breath (shouldn't count as a blame right ?) :-P
<mgz> RUSAGE_CHILDREN should work.
<mgz> and wait4.
<vila> oh yeah
<vila> especially if we don't care *too* much about being overly precise
<vila> mgz: should we file a bug about implementing this for selftest ?
<mgz> well, you have to hack subprocess is the pain
<vila> mgz: or should we just keep discussing it ? (I'm about to EOD with a headache due to paint odors :-/)
<vila> ordors ? smells ?
<exarkun> fumes
<vila> right odor is in my dict
<mgz> exarkun has the common idiom
<vila> fumes is likely to be more precise yeah
<mgz> hm, wouldn't need hackage just for --parallel=fork
<vila> exarkun: thks, appreciated (still along way to go to be fluent there :)
<mgz> but do get outside before you expire from lack of oxygen vila, I'll continue playing
<vila> ok
<exarkun> vila: :)
<vila> fullermd: my last remark was truly a joke to make you fail your bingo (just realized it could me mis-interpreted)
 * vila really off
<GaryvdM> Hi mgz
<mgz> hey GaryvdM
<GaryvdM> Hay - I'm very excited about this. Take a look at http://198.54.202.195/
<lifeless> mgz: hi
<GaryvdM> Hi lifeless
<lifeless> GaryvdM: hi
<mgz> will this be more exciting qlog-online stuff when it loads?
<mgz> hey lifeless.
<GaryvdM> mgz: yes - Is my router not setup correctly?
<lifeless> mgz: curious what you think of the latest testtools changes
<mgz> just doing tracert now...
<mgz> hm, I arrive, but at wblv-ip-pcache-5-vif1.telkom-ipnet.co.za
<GaryvdM> Ah - I think that is a proxy. Try http://41.242.164.81/
<mgz> I need to go over the last few revs still lifeless, but the raises matcher I'm a little concerned about
<mgz> it's potentially good as it can solve the thing where you need the exception returned to check extra aspects of it
<mgz> and also my expectError thing.
<mgz> I think? With Not at least.
<mgz> would still be confusing to spell.
<mgz> that's pretty fancy Gary. I've got some wrapping-related spacing issues, but can possibly think of a cunning svg hack that'll make life easier there.
<GaryvdM> Yes - I can figure out how to tell the svg to layout relative to the hight of the table row with out javascript
<GaryvdM> *can't
<GaryvdM> mgz: what hack?
<mgz> well, you can stretch the image rather than setting a height in px, which would also make your nice circles oval
<mgz> so you'd then need to do something else there as well.
<mgz> ideally you'd not be breaking the lines up into bits, but laying a complete graph over the table would be complicated
<GaryvdM> Yes
<GaryvdM> Anyway - I'm quite excited about it :-)
<GaryvdM> lifeless: Did you take a look?
<lifeless> its shiny
<lifeless> a little slow
<GaryvdM> lifeless: Probably my bandwidth.
<mgz> having js disabled makes life so much nicer :)
<GaryvdM> mgz: I could have one svg element for then dot, and one for the lines, so that I can size then lines separately from then dots. But there is not a way to make a img/svg hight=100% in a table row :-(
<GaryvdM> Without js
<mgz> hm, I think I had one...
 * mgz checks his note
<mgz> s
<mgz> http://float.endofinternet.org/progress/shader.xml
<mgz> browsers certainly have some issues, at any rate :)
<GaryvdM> Hi mkanat. Take a look at http://41.242.164.81/ :-)
<mkanat> GaryvdM: OH COOL!!
<GaryvdM> :-)
<mkanat> Wow that is awesome.
<mkanat> GaryvdM: It doesn't do any work until I click on a +, right?
<mkanat> GaryvdM: I mean, any extra work.
<GaryvdM> Well - It has to load the whole graph on first load, but it caches it.
<mkanat> GaryvdM: That's no different from what we do now, though, is it?
<GaryvdM> To recalculate a new layout is very quick.
<mkanat> GaryvdM: We can't have any performance or memory-use regressions in loggerhead right now--Launchpad won't be able to live through it.
<GaryvdM> mkanat: Sure - I understand that.
<mgz> lifeless: so, I don't like that assertRaises becomes assertThat + lambda, but apart from that it all seems reasonable.
<mgz> really it's a python problem that it's hard to write declarative code prettily.
<GaryvdM> mkanat:  I do have alot of overlap of what is cached, and so I need to do some work there.
<mgz> mostly assertThat seems like extra typing and worse error messages so far to me.
<mkanat> GaryvdM: Okay.
<mkanat> GaryvdM: But the UI looks very cool.
<GaryvdM> mkanat: Are you using history_db on launchpad yet?
<mkanat> GaryvdM: Not on Launchpad, no.
<mkanat> GaryvdM: Are you using history_db for your work?
<GaryvdM> mkanat: No - It dose not help much if you still have to load the whole graph.
<mkanat> GaryvdM: I'm pretty sure that that's its purpose.
<mkanat> GaryvdM: Is to cache the graph.
<GaryvdM> mkanat: If I can get my code to work with only portions of the graph, the using it would help.
<lifeless> mgz: hmm, I find the errors better
<mgz> I'll paste you an example ina sec...
<mgz> I think the problem is generally that assertThat is less specific so knows less about what can safely be ignored, unlike the old function versions
<lifeless> mgz: really? the reverse seems true to me
<lifeless> the matchers can be very specific
<lifeless> mgz: or do you just mean how far up the stack trace goes?
<mkanat> GaryvdM: Okay.
<mkanat> GaryvdM: Perhaps by making it walk the graph when the + is clicked?
<GaryvdM> mkanat: Yes
<mkanat> GaryvdM: Okay. :-)
<mgz> lifeless: example -> http://paste.ubuntu.com/530860/
<GaryvdM> mkanat: Do you have any methods that you use to benchmark the memory usage?
<mkanat> GaryvdM: Well, to figure out what's actually using memory, I use meliae. But otherwise, I just run load tests on it and see how big it gets, usually using a bunch of copies of the launchpad-itself branch.
<lifeless> mgz: so, there are two differences
<lifeless> mgz: one is the stack - I like the full stack (because I work on the test code itself)
<GaryvdM> mkanat: ok
<lifeless> mgz: the other is the formatting, which seems pretty much a wash in this case
<mgz> the first there is duplicative
<exarkun> The latter formatting is better.
<mgz> you get 'text/x-c++src' and None twice, and it's not really any clearer what's up.
<exarkun> It's easier to read and lets you copy/paste into a repl
<mgz> it does tell you (or should do if the test is written right) which is the result and which is the expected, but is much more verbose
<lifeless> exarkun: the assignment 'a =' is useful for you?
<exarkun> lifeless: yes
<exarkun> when the values are more complicated and it's not obvious how they differ
<exarkun> although I'd rather the output highlight where the differences are so I don't have to grope around to find it myself ;)
<lifeless> exarkun: right, thats the point of the interface actually.
<lifeless> exarkun: have you seen what soupmatchers does?
<exarkun> no
<lifeless> it looks for the difference and shows it
<lifeless> not as a diff, but semantically.
<exarkun> lifeless: but I just want to use assertEquals
<mgz> lifeless: so I get the theoretical benefits of assertThat style, but at the moment I mostly see the downsides in practice
<mgz> they're small, but could do with some polishing love.
<mkanat> abentley: You know what else I don't like about looms? I actually don't like having to write commit messages every time I commit to a thread.
<abentley> mkanat: you mean a normal commit?  Or "record"?
<mkanat> abentley: I mean an actual commit, like when I'm working on a loom.
<mkanat> abentley: Since I have to commit in order to switch threads.
<lifeless> mkanat: you do ?
<mkanat> abentley: And I have to commit to make a new thread on top of this one.
<mkanat> lifeless: Yes.
<mkanat> bzr down-thread upstream
<mkanat> bzr: ERROR: Working tree has uncommitted changes.
<abentley> mkanat: Well,  you *could* shelve them.
<lifeless> mkanat: what does [bzr switch upstream' say?
<lifeless> mkanat: its meant to carry changes across for you.
<mkanat> lifeless: I want this working tree to stay with this thread.
<lifeless> mkanat: then yes, shelve or commit is appropriate.
<mkanat> lifeless: I had no need or desire to commit to the thread, I just wanted to back and update upstream to the actual current upstream.
<lifeless> mkanat: aaron's shelve-in-developing-patch-context is very nice in this regard.
<mkanat> lifeless: I'm not familiar with that.
<lifeless> mkanat: pipelines have a shelve context in the 'thread' equivalent (in the branch, a single pipe)
<mkanat> lifeless: Ah, yeah.
<lifeless> this is something that would benefit looms too, poolie has some ideas on unifying the should-be-common aspects of pipelines and looms
<lifeless> pipelines have much more polish
<mkanat> Cool. One thing that I really would like is a simpler path to do "rebase to upstream and delete all the threads that are now identical to upstream".
<lifeless> mkanat: I think loom prompts you for that doesn' it?
<lifeless> mkanat: whats your loom version
<mkanat> lifeless: 2.1
<mkanat> I can try updating.
<lifeless> thats your problem
<lifeless> 2.1 won't even push properly to launchpad
<mkanat> Okay. Will trunk work with bzr 2.1.1?
<lifeless> should do
<mkanat> Okay.
<abentley> mkanat: I'm not a fan of rebase, but I'd be happy to make "bzr remove-pipe --auto" remove pipes that have been merged.
<mkanat> abentley: I was using "rebase" in the loose sense, not in the sense of the command.
<mkanat> abentley: That sounds like a good solution.
<mkanat> I think I may start using pipelines in looms. Another example of a bad situation is when I screw up upstream somehow, and then up-thread.
<mkanat> Then it's very difficult to go back and fix upstream.
<mkanat> Okay, loom trunk is broken in some way that I do not now want to spend time debugging.
<mkanat> AttributeError: type object 'InterLoomBranch' has no attribute 'unwrap_format'
<abentley> mkanat: You could use looms in pipelines, but I don't recommend it.  Your head could explode.
<mkanat> abentley: Hahahaha.
<mkanat> abentley: I meant "instead of".
<dash> you got your tubes in my loom!
<mkanat> Just typed "in" by accident.
<mkanat> It's not a trunk, it's more like a series of looms.
<abentley> mkanat: Ah.
<mkanat> BTW, the Internets ^^^^^
<mkanat> Oh, and heaven forbid that what gets checked into upstream is slightly different than what was in your loom.
<mkanat> Then you're in for a fun time called "re-creating every thread".
<mkanat> (Or a separate fun time called "resolving spurious conflicts in every thread".)
<lifeless> mkanat: I don't see how that is different in looms vs pipelines
<mkanat> lifeless: I haven't used pipelines yet.
<lifeless> (either of the upstream workflows you describe)
<mkanat> lifeless: Yesterday you wanted me to say what I didn't like about looms, and I'm using them in actual practice right now, so I figured I'd just mention what I was running into.
<lifeless> mkanat: I value the feedback
<lifeless> mkanat: better if you file bugs :)
<mkanat> lifeless: Okay.
<lifeless> mkanat: I'm just noting that the specific workflow I don't see a different in loom vs pipelines
<mkanat> lifeless: Okay.
<lifeless> mkanat: particularly for that unwrap_format error
 * mkanat nods.
<GaryvdM> mgz: I've now separated the nodes and lines. But I can't get it to link the height of the svg to the height of the row.
<GaryvdM> mgz: I'm not sure which part of that page you sent me I should be looking at?
 * GaryvdM has another idea to try...
<ovnicraft> hi folks, what this means bzr: ERROR: [Errno 1] Operation not permitted: 'some_file' ?
<poolie> probably you don't have permission to write to it
<EdWyse_Office> Is there any way to fix this error: http://bzr.pastebin.com/RpbtF5gt
<ovnicraft> poolie, there is anyway to commit ignoring conflicts
<GaryvdM> mgz: Got it working \o/
<poolie> ovnicraft, sorry, not at the moment
<poolie> EdWyse_Office, that looks like a bug that we fixed in a recent release, are you on the most current one?
<GaryvdM> Hi poolie. Check this out http://41.242.164.81/ :-)
<ovnicraft> poolie, i was researching about multi-branch support is that in your roadmap?
<EdWyse_Office> 2.1.1-4 from the epel repo.
<GaryvdM> ovnicraft: Are you maybe think of colocated branches? i.e. having more than one branch in a folder?
<GaryvdM> *thinking
<EdWyse_Office> It looks like it was the image that was messed up somehow. I was able to fix it be reverting that file (which hadn't been changed or added) and committing.
<ovnicraft> GaryvdM, yes
<GaryvdM> ovnicraft: There is a plugin: bzr-colo
<ovnicraft> GaryvdM, yes but we need support in lp
<GaryvdM> Goodnight all
<mgz> night Gary, well done for getting the svg joined up.
<awilkins> How long does it usually take after you upload sources to a PPA for them to show up?
<awilkins> And does it still work if the sources are not part of the distribution?
<poolie> awilkins, normally you will at least see them being queued to build within a few minutes
<poolie> you should get an 'accepted' email
<poolie> the time for them to actually build varies a lot depending on lead
<poolie> *load
<poolie> what do you mean by 'not part of the distribution'?
<poolie> it's fine to build packages that are not already in ubuntu
<awilkins> poolie, Aha, rejected email
<awilkins> That's what I get for not keeping a notifier open
<awilkins> This packing malarkey really needs clearer docs or tools, but I do appreciate it's not exactly simple
<mgz> lifeless: testtools r128.1.6 is problematic, it's not valid Python 3 syntax and stores an exc_info in locals. I think examining the premise that it should be possible to assert non-Exception subclasses should be re-examined.
<lifeless> mgz: grah. sory
<lifeless> mgz: uhm, we can fix the locals thing
<mgz> yeah, I'm more worried about Python 3
<lifeless> we can't self host on this without the facility though
<mgz> I think the only way of reraising with a stored traceback there is setting in on the exception instance
<mgz> which is All New so... can't also work for pythons people actually use
<mgz> both KeyboardInterrupt and SystemExit can be raised outside the control of the thread running tests, so you can't ever write a proper unittest for raising one
<mgz> this is admittedly a pretty academic objection.
<mgz> ...maybe I should be in the testtools review group... though not sure I'd have had time to look at this before today anyway
<mgz> hm, not coming up with any genius ideas for different spelling keeping the current semantic
<mgz> (it's wrong on Python 2.4 too, but that's probably less important)
<poolie> awilkins, i agree
<poolie> hi mgz
<mgz> hey poolie
<mgz> I shall file some bugs lifeless. Think this is a good change, just wants some more minor pokes.
<lifeless> mgz: we'd be delighted to have you as a reviewer/committer
<mgz> the thought of fixing the expectError case particularly interests me, especially as we've got some backwards expectFailure/assertRaises currently.
<poolie> mgz: ?
<lifeless> mgz: we have a fairly nonblocking review process, trying to keep things agile
<awilkins> Darn. Only the "dev" package has the library in it. Something is wrong there....
<mgz> it's a good thing, and jml has also put out some feelers on wider version testing as testtools tries to have such a wide support net
<mgz> (which would help prevent releasing with 2.4/3 borked)
<mgz> poolie: I was thinking of -> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/bzrlib/tests/per_workingtree/test_smart_add.py#L304
<mgz> which is hard to read, but makes an unexpected success
<mgz> have a branch fixing that silence problem, but spelling the intention of that test correctly is currently hard, and Robert just added some new fancy to testtools that should make it possible in future.
#bzr 2010-11-13
<_habnabit> I'm kinda uncertain as to what a criss-cross merge is in bzr, and how to avoid them.
<_habnabit> I have a star topology, like it describes, but I do frequent merges from trunk to the feature branches.
<_habnabit> Is this something I should avoid, or approach in a different way?
<mtaylor> getting zope tracebacks pushing new branch to launchpad...
<mtaylor> _habnabit: criss-cross merge isn't necessarily bad
<_habnabit> So I shouldn't worry about it?
<lifeless> mtaylor: you just had a traceback ?
<mtaylor> lifeless: yes
<mtaylor> lifeless: http://paste.drizzle.org/show/165/
<mtaylor> lifeless: oh - I see the status in #launchpad ... hrm
<poolie> _habnabit, no, don't worry about it
<_habnabit> Also, the documentation says that bzr svn-import is resumable, but it's not clear *how* you resume it.
<poolie> i would assume you run it again with the same arguments?
<_habnabit> Well. I did make changes to the working trees between invocations.
<_habnabit> Maybe it's just that my changes were clobbered.
<_habnabit> Okay here is my full problem. I'm trying to import a subversion repository into bzr, but I'm also trying to fix svnmerge.py fucking up.
<_habnabit> We only *just* discovered that it's been behaving... oddly ever since we started using it, but it wasn't obvious until just now.
<poolie> hm
<poolie> i'm not sure but i suspect it will not notice changes you make in the wt
<_habnabit> My first thought was to go through and replay the merges incrementally as I import from svn.
<_habnabit> Is there a tool I'm just not aware of that tracks svn mergeinfo when importing into bzr?
<_habnabit> I tried tailor and svn2bzr first, but they both choked in interesting and different ways.
<poolie> i don't know, sorry - i suggest you ask on the list
<_habnabit> man svn is so miserable. :(
<_habnabit> Is there a way to transmit an entire shared repository over a network somehow?
<_habnabit> I mean there seems to be no equivalent of pull or branch for shared repositories.
<bob2> there's a couple of plugins
<bob2> multi-pull in bzrtools
<bob2> and repo-push
<_habnabit> I tried multi-pull.
<_habnabit> Oh.
<_habnabit> repo-push seems to be what I want.
<_habnabit> I'm trying to figure out what the best way to serve this repository is. My coworkers are stubborn windows users who would actively resist using something like pageant, so ssh isn't really an option.
<_habnabit> Maybe just `bzr serve` ?
<vila> _habnabit: 'bzr serve' is an option but you don't want to have it exposed outside of your intranet.
<_habnabit> Is there anything else I'm forgetting?
<_habnabit> Like, can bzr serve over webdav?
<vila> _habnabit: ssh is really the preferred option these days and some documentation have been written recently specifically to make it easy for windows users
<vila> _habnabit: oh, no, just bzr server is enough you don't need webdav at all
<vila> s/server/serve/
<_habnabit> Yeah, I know it's easy; I've set it up on my own windows box.
<_habnabit> But my coworkers are terrible and I'm trying to incrementally make them less terrible.
<vila> _habnabit: then it's better to *not* provide any file system level support
<_habnabit> What do you mean?
<vila> _habnabit: otherwise you will quickly get people trying to handle working trees on the server instead of just branches
<_habnabit> Oh, well, yes. I'll be able to beat them into submission on those kinds of matters.
<vila> and this open several can of worms you don't eant to deal with
<vila> s/eant/want/
<vila> _habnabit: https://code.launchpad.net/~adam-delvecchio/bzr/662448-sshkey-doc/+merge/38682 is what I was referring to
 * _habnabit looks.
<vila> _habnabit: feel free to add your feedback there, this is still worked on and you have the timely opportunity to explain how it helped with your co-workers (or not)
<barjac> Hello - I simply need to checkout a branch and then keep it updated from time to time. I check out with :-
<barjac> bzr branch http://bzr.savannah.gnu.org/r/grub/trunk/grub which creates ~/grub
<lifeless> that gives you a new distinct branch - you can then use 'pull' to copy new revisions across to it
<barjac> To update I use :- bzr update from within ~/grub but it says it is up to date at a revision way behind the server
<barjac> What am I doing wrong?
<barjac> lifeless: Ah! thanks I will try that - bzr man is a bit cryptic :-(
<lifeless> :(
<lifeless> hope it helps
<barjac> lifeless: Yep that does it! Thanks for your speedy help :-)
<lifeless> my pleasure
<jderose> Bit disappointed people.canonical.com/~ianc has been removed. Does Ian's  Community-Agile Software Guidance essay have a new permanent home anywhere?
<jderose> Pretty important part of Ian's legacy, IHMO
#bzr 2010-11-14
<dwg_> Paragraphs don't show up properly for me (e.g. http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/add-help.html). There's no spacing between paragraphs, which makes it hard to read. How would I go about setting up a server to see what might need to change to clean things up?
<dwg_> I've got the bzr repo from launchpad and can see the help information in builtins.py, so I think I need information about how the whole documentation build and test works.
<poolie> dwg_, running 'make docs-sphinx' should show you the output
<poolie> you may need to fix doc_generate/something
<poolie> then please push your branch to launchpad and propose it for merge
<dwg_> make docs-sphinx at least does something, so that ought to get me started. thanks!
<quotemstr> Why the hell is bzr telling me about text conflicts in files *I DIDN'T CHANGE*?
<quotemstr> I have a copy of the Emacs trunk. I last updated it --- hrm, maybe a month ago?
<peitschie> mornin all :)
<KombuchaKip> Hey folks. I'm about to create a branch on my launchpad page, and I'm a little confused on what to call it. Should one call it the project name, dev, trunk, mainline, branch, or what? The UI seems a little confusing to me.
<blueglasses> hi
<blueglasses> i've made some changes on a python file, how do I upload it to launchpad?
<blueglasses> I already have the thing called trunk visible
<blueglasses> and I have some testing files there
<spiv> KombuchaKip: 'trunk' is a reasonable default.  It doesn't matter much.  You can rename it later (at the cost of breaking the old URL, of course).
<KombuchaKip> spiv: Thanks.
<blueglasses> I forgot the command sequence to upload my changes
<spiv> blueglasses: usually "bzr commit" followed by "bzr push".
<blueglasses> trying...
<KombuchaKip> spiv: What does Launchpad mean when they refer to the "trunk series"?
<blueglasses> commit opened nano
<blueglasses> is this expected?
<mgz> you get to type in what your change does.
<mgz> so people looking at the log know what you were up to.
<blueglasses> do I have to follow rules to comment on the commit?
<blueglasses> eg, is there a all people do this thing when typing what my change does?
<blueglasses> or is it freestyle?
<mgz> depends on the project, but this is publicly visible
<spiv> blueglasses: it's a place for you to describe/summarise the changes, so that people (including yourself) can look at just that message (via e.g. "bzr log") rather than having to look at the exact changes.  It's freestyle.
<mgz> when in doubt, try and do the same kind of thing you see others doing when you look at the existing commit messages in the log
<mgz> ...is there not a "My First Contribution" guide on launchpad somewhere?
<spiv> KombuchaKip: perhaps better to ask in #launchpad.  https://help.launchpad.net/Projects/SeriesMilestonesReleases may help.
<KombuchaKip> spiv: Thanks spiv. I didn't realize there was a channel.
<spiv> KombuchaKip: not a problem.
<blueglasses> thank you
<blueglasses> how do i configure the project branch in lauchpad? it says the word for my project is too small
<blueglasses> but its already there...
<blueglasses> its called story
<mgz> is launchpad lagging behind on the bzr branch a known issue?
<mgz> I can branch spiv's r5538 but the latest rev on the web page is 5537 and the +activereviews page hasn't twigged it's already been merged.
<poolie> mgz, it might be related to an issue with the branch scanner on the weekend
<poolie> mwhudson: what do you think?
#bzr 2011-11-07
<poolie> oh ok thanks
<poolie> jelmer, of course we don't need to verify every bug, just make sure it's not broken
<meth> can i do conditional commits ?
<meth> or a patch commit you might call it
<poolie> meth, what do you mean?
<meth> git add -p
<meth> would like that
<poolie> try bzr-interactive
<poolie> https://launchpad.net/bzr-interactive
<meth> cool
<BlindWolf8> anyone alive in here?
<spiv> Often!
<BlindWolf8> hi spiv!
<BlindWolf8> your name looks familiar :-)
<BlindWolf8> do you have time to field a bazaar question for me?
<spiv> BlindWolf8: depends on how hard it is ;)
<spiv> BlindWolf8: in general it's best to just ask your question, lots of folks are usually quiet but check the scrollback periodically and might answer
<BlindWolf8> spiv: well, I always try and be polite
<BlindWolf8> people giving fre support and all
<spiv> This channel is here to talk about bzr :)
<BlindWolf8> *free
<BlindWolf8> OK, so...here's the deal...
<spiv> You're quite welcome to just pop in and say "hi, I'm having X problem..." :)
<BlindWolf8> I have a server...running Ubuntu 11.10
<BlindWolf8> bzr is installed on it via the PPA
<BlindWolf8> bzr 2.4.2 is on all the clients and the server
<BlindWolf8> putty 0.61 is installed on all clients
<BlindWolf8> clients are all windows boxes
<BlindWolf8> clients gave me public keys to pop on the server and use pagent to authenticate
<BlindWolf8> I have the command for bzr_ssh_path_limiter listed in the auithorized_keys file
<BlindWolf8> on the first line of the keys file, it goes <command for bzr_ssh_path_limiter> <ssh key>
<BlindWolf8> all other lines are simply public keys
<BlindWolf8> first, I am assuming that just the first line is supposed to have the bzr_ssh_path_limiter command?
<BlindWolf8> I have done various tests on my end and I am able to pull files from the server no problem, but none of the other people I work with can
<spiv> If you only want the first key to use the bzr_ssh_path_limiter
<spiv> Each line is independent of the others, read the authorized_keys man page that comes with OpenSSH for the exact details.
<BlindWolf8> ah........
<BlindWolf8> I thought it was executed on the user's profile, not per key....
<spiv> No, it's per key
<BlindWolf8> that solves that problem, thanks!
<BlindWolf8> I have another slight issue though
<spiv> So some people use it as a relatively cheap way to have per-user repos hosted by a single user account.
<BlindWolf8> some clients get a temp file error that deals with pagent...but I'm using 0.61 with no isseus, even though the issue is supposed to be with 0.61
<spiv> I don't know much about pageant.
<BlindWolf8> relavent bug report: https://bugs.launchpad.net/bzr/+bug/820805
<ubot5> Ubuntu bug 820805 in Bazaar "access denied on Pageant .pag file" [Undecided,Confirmed]
<poolie> o/ spiv
<spiv> Hey poolie
<mgz> morning all.
<jelmer> hi mgz
<mgz> what's the way of finding out what versions of packages PQM has installed?
<jelmer> mgz: checking with a losa, probably
<mgz> okay, what's the way of changing the PQM code so it displays the versions it has installed?
<jelmer> mgz: you'd have to modify the script that is used to verify bzr submissions, I'm not sure if that's publicly available somewhere
<lifeless> mgz: change Makefile
<lifeless> mgz: in the bzr tree
<lifeless> mgz: PQM is -extremely- simple. Thats why everyone gets so confused by it.
<mgz> that only works if it's running a test I think lifeless
<lifeless> mgz: yes... that was the context of your question right ?
<lifeless> '23:31 < mgz> okay, what's the way of changing the PQM code so it displays the versions it has installed?
<lifeless> '
<mgz> but lp:pqm doesn't look too hard to poke, though actually deploying a change is probably impossible
<lifeless> pretty easy - get the losa to pull in the branch
<lifeless> and yes, lp:pqm should be fairly straight forward, though I'm horribly confused about what you're trying to do.
<mgz> okay, I will poke this.
<mgz> lifeless: I want to look at pqm.bazaar-vcs.org and know what version of testtools is being used
<lifeless> mgz: I don't think that question makes sense unless a test is runnig.
<mgz> meh, maybe not.
<mgz> there's not a sensible way of getting ther versions of python packages unless they're being used
<mgz> debian packages would kind of work, but I imagine that would also be a harder sell.
<lifeless> there is that, and that the place to check is in a chroot, of which there can be multiple versions at once (especially when bzr is transitioning)
<lifeless> having the web UI go off and probe arbitrary chroots which may or may not be active or even usable at the time ... seems odd
<lifeless> vs having Makefile report it for you.
<mgz> adding more output to the Makefile doesn't actually solve my problem though
<lifeless> what is your problem ?
<mgz> you'd still have to push a branch to see any relevent information
<mgz> ^as stated above
<lifeless> mgz: I don't follow :)
<mgz> I, right now, want to know something, and right now, the page just says "0 scripts" and the time
<lifeless> ah.
<lifeless> so in general, to know this, I ask a losa
<mgz> there's no change I can do in lp:bzr to remedy that, and it seems the same goes for lp:pqm
<lifeless> mgz: you could send a patch through that will print out the versions and return 1
<mgz> so my ping saving idea is no good.
<lifeless> mgz: making the test suite fail and thus not landing anything.
<lifeless> mgz: you could even just have that sitting around ready to go at a moments notice
<mgz> that only helps me, which is much the same as just asking an admin.
<lifeless> I must be really tied
<mgz> but it's okay, sometimes there's not an easy way of adding code to save work,
<lifeless> *tired*
<lifeless> because I thought you said you wanted to know
<mgz> I do, and when the answer was "ask someone" I wondered if I could avoid that by fixing the web display.
<mgz> The answer to the second question is "no"
<lifeless> its more yes-but-its-not-as-simple-as-all-that :(
<mgz> So, I will go back to the initial issue and forget the generalisation.
<lifeless> :)
<mgz> ah, vila is still suffering
<mgz> all I really have left today is the impressive cough
<mgz> dammit, last change somehow hasn't fixed the random failure on babune natty
<mgz> what were the chances of even hitting it again right after...
<mgz> heh, bialix and I having the same idea in these bugs at the same time
<mgz> I'm sure Gordan or someone fixed an issue related to unquoting paths from config
<mgz> but I now can't find it
<Amis> Hello o/
<Amis> I'm sure it's somewhere in the documentation but I can't find how exactly create a new branch in a shared repository. Any help?
<mgz> Amis: just `bzr init` as normal.
<Amis> bzr init "remote shared rep location" project?
<Amis> oh wait
<mgz> eg, `bzr init-repo repo; bzr init repo/branch`
<mgz> you can also branch into the shared repo and it will do the right thing
<Amis> yeah, right, thanks
#bzr 2011-11-08
<BlindWolf8> Hello all. I am not experiencing this bug, but some clients are and I can't pinpoint it: https://bugs.launchpad.net/bzr/+bug/820805
<ubot5> Ubuntu bug 820805 in Bazaar "access denied on Pageant .pag file" [Undecided,Confirmed]
<AuroraBorealis> if thats a bug in pageant
<AuroraBorealis> gl haha. its been like 6 years and only one new release since then?
<BlindWolf8> it can't be pagent, because I don't get the bug and I'm using 0.61
<BlindWolf8> other clients are using 0.61 and they get the bug
<AuroraBorealis> where is their pageant.exe file
<BlindWolf8> I tried it in a virtual machine and cannot reproduce the bug
<AuroraBorealis> cause i use pageant too
<AuroraBorealis> and i don't get said bug
<BlindWolf8> I told them to use the installer, which I use too
<AuroraBorealis> what is the .pag file anyway
<BlindWolf8> I have no idea
<AuroraBorealis> google is no help cause its keep going for page file
<AuroraBorealis> and pageant itself
<BlindWolf8> you can do -page in google to exclude page from search results
<vila> hi all !
<Merwin> hi
<mgz> morning all.
<vila> mgz: _o/
<mgz> feeling a bit better vila?
<vila> mgz: yup, not fully resumed but good enough to be here :)
<vila> mgz: how about you ?
<mgz> I'm mostly alive
<vila> good, let's join efforts to provide at least one decent bzr dev ;)
 * fullermd gets a giant steam press warmed up.
<vila> hehe
<vila> bunch of updates here (including reboots !) and weird stuff (gwibber consuming 12GB, wtf ???)
<vila> that was 12GB of VM (4GB resident) for that matter... I suspect some weird interaction caused by an update while gwibber was still running so I may never be able to reproduce :-/
<fullermd> Well, it could be worse.  Could have been firefox; it wouldn't have bothered limiting itself to so little memory.
 * vila feels weird: 8 vans, full of CRS (http://fr.wikipedia.org/wiki/Compagnie_r%C3%A9publicaine_de_s%C3%A9curit%C3%A9) below my windows...
<vila> s/below/under/ ?
<vila> the thing is, there is this library which is being renovated one block from there and our president will visit it today...
<vila> but 8 vans ??? What sort of democracy is that ? :-/
<fullermd> I know, right?  It has to be an odd number to avoid deadlocks!
<vila> haaa, makes sense, one for each of my desktop  core !
<vila> . o O (But how on earth do they know I have 4 cores (8 threads) ??)
 * vila watches for the black helicopters...
<fullermd> Oh, I told some guy.
<fullermd> He said he needed to know it to transfer the $15,000,000 (15 MILLION DOLLARS) out of the Ivory Coast into my account.
<fullermd> Now that I think back, it was a LITTLE weird...
<vila> but 15 is an even number...
<fullermd> It's certainly a rather odd even number.
<mgz> any idea why your natty chroot seems to be more of a race magnet than the other ones?
<mgz> or is it just happy chance?
<vila> happy chance !!
<vila> race bugs... the more you reproduce them, the better
<mgz> we having standup this morning?
<mgz> should perhaps have been an hour ago...
<jelmer> I'm on mumble now..
<vila> maxb: ppas updated: \o/ Thanks !
<jelmer> vila: https://code.launchpad.net/~jelmer/bzr-builddeb/has-version-multiple-tarballs/+merge/81545
<jelmer> vila: testing
<maxb> vila: No problem :-).
<maxb> Now, I suppose I should go care for the Mercurial PPAs :-/
<maxb> There is some superb irony in me ending up doing both of those
<vila> :)
<jelmer> vila: http://pastebin.ubuntu.com/731886/
<mgz> the vila bell is so cute.
<lifeless> maxb: how about cygwin mirrors of both repos's ?
<vila> jelmer, mgz: https://code.launchpad.net/~vila/udd/use-local-bzr/+merge/81555
<mgz> I'm off for an appointment, will be back a little later
<jelmer> vila: hmm, udd doesn't call bzrlib.initialize() ? :P
<vila> ha crap :)
<jelmer> vila: argh, hit a bzrlib bug
<jelmer> vila: https://code.launchpad.net/~jelmer/bzr/workingtree-pull-null/+merge/81572
<jelmer> vila: python-distro-info
<jelmer> vila: debianlp:distro-info
<jelmer> vila: lp:debian/distr-info
<jelmer> vila: lp:debian/distro-info
<mgz> am around again.
<vila> not sure I will for too long ;)
<vila> fever seems to be striking again
 * mgz hands vila a pillow
<Riddell> what's the URL to add blog entries to http://blog.bazaar.canonical.com again?
 * jelmer lunches, back in a bit
<Riddell> got it, my closing Bazaar blog http://blog.bazaar.canonical.com/?p=383
<vila> Riddell: damn, I couldn't find it myself either, where is it ?
<vila> Riddell: nice blog post, you really did a ton of stuff during this rotation...
<Riddell> vila: "log in" under meta menu in right hand side
<vila> ETHEREISNOMETAMENU
<vila> ha, here it is 8-)
<vila> weird, I went to an another url which triggered an OpenID login and from there the menu appeared, yeah for discoverability
<mgz> Riddell: nice post, I just edited it a little for formatting and some spellings
<mgz> and some random extra linkification
<mgz> Riddell: I'm a little sad it's not in french...
<Riddell> thanks mgz
<Riddell> maybe I should do my UDS summary blog in French :)
<mgz> yeay!
<vila> Riddell, mgz: hehe
<vila> Riddell: where are you at this minute ? Still in our TZ or already enjoying tropics ?
<Riddell> in the land of Liberte, Equalite et noix de cocos
<jelmer> mgz: I'm back on mumble, fwiw
<Riddell> c'est la france mais avec en plus des vaches http://www.flickr.com/photos/jriddell/
<mgz> wait, with more cows?
<vila> z'ont des vaches en Guadeloupe ???
 * mgz distrusts his vocab
<fullermd> Harumph.  Dunno why people go off and invent all these other languages when we already have English...
<vila> Riddell: did you mean: s/avec en plus des vaches/sans les vaches/ ?
<vila> perfect French otherwise, congrats ;)
<vila> jelmer: did you file the bug about the revision not present ?
<Riddell> ils sont des vaches partout
<vila> sont ou ont ? Very different joke ...
<vila> :)
<vila> jelmer: you had an overview (overhear ?) of my Darth Vader voice ;)
<jelmer> vila: not yet, still trying to get this multi-tarball thing going..
<jelmer> vila: but thanks for the reminder :)
<jelmer> vila: yeah, I was about to say. How much whiskey have you had today?
<vila> me ???
<vila> I swear ! Not a single drop !
<fullermd> Only multiple drops?
<vila> If I were to cure my Ubuflu, I'll use ti punch anyway :)
<jelmer> vila: what about some warm milk?
<vila> errr, I mean honey in a grog for inhaler  !
<jelmer> apparently there are wild cows roaming the french streets...
<vila> I had 8 vans in the street this morning but that's rather unusual
<vila> (full of cows I mean)
<vila> hmm, that was rather obscure for foreigners may be... http://en.wikipedia.org/wiki/Mort_Aux_Vaches should clarify that ;)
<fullermd> Man, you're just milking that story for all it's worth...
<vila> hmm, not sure wp really clarifies... Dutch radio station... using french slang about german cops...
<vila> Riddell: back to your photos, nice, matches my memory of Martinique... nice souvenirs :)
<jelmer> vila: that sounds like something that the VPRO would do
<vila> :)
<vila> mgz: https://code.launchpad.net/~gz/bzr/trivial_fork_error_block/+merge/81479 reviewed
<vila> mgz: finishing the discussion *here* will probably be more effective
<mgz> ...sorry vila, I'm causing needless work for you
<vila> ???
<mgz> looking at it again the problem lies in the parent side, not the child side of the pipe
<vila> did you break something I'm aware about yet ? ;)
<vila> s//not/
<mgz> okay, so your review says basically what I've come back round to.
<vila> great !
<mgz> actually fixing the problem would probably mean changes in both subunit and testtools, and isn't actually worth while
 * vila nods
<mgz> as an aside, the EINTR/short write handling is just because... otherwise I'd feel bad using os.write completely incorrectly
<vila> mgz: what I would be more interested in, in this area, is the ability to capture the subunit streams
<vila> huh ?
<vila> You mean EINTR can occur randomly ?
<vila> or that ignoring it will just cause a short write ?
<vila> s/just// that's already expressing *my* opinion ;(
<vila> argh ;)
<mgz> depending on when a signal arrives, you can get either
<vila> right, but what can cause this signal ?
<mgz> but the code wasn't on evidence of a problem, just that I don't like leaving holes
<vila> ok
<vila> specifically, my concern was more about having a helper or not
<vila> to keep *this* code short
<mgz> yeah, that's a question. the problem in general is you're exchanging more reliable c library code for less reliable python
<mgz> posted new mp which weakens the test instead.
<lamalex> hey, i have a pipes question
<lamalex> should add-pipe -i ask me about uncomitted changes interactively?
<maxb> jelmer: Hi, are you aware of severe compatibility issues between bzr 2.4.2 and bzr-git 0.6.4 ?
<maxb> As in 'bzr branch git:.....' crashes with an AttributeError
<jelmer> maxb: that's fixed in trunk
<jelmer> maxb: ah, rats.. didn't realize that 0.6.4 is in sid
<maxb> Right, do you plan a debian upload shortly?
<jelmer> maxb: thanks for the reminder
<jelmer> maxb: yeah, I will
<mgz> okay, just the funny url ones left to review of jelmer's mps
<LeoNerd> Hmmm... bzr has made me want  p4 shelve
<LeoNerd> Annoyingly awkward to produce in practice
<fullermd> You don't need 'p4 shelve'.  You just need bzr-p4   8-}
<LeoNerd> Hehe oooooh
<LeoNerd> WANT
<soren> What's "p4"?
<fullermd> The one between p3 and p5  ;)
<fullermd> Perforce.
<soren> Oh, that thing.
<jelmer> thanks for the reviews mgz!
<wgz> you were getting quite a backlog :)
<jelmer> g'day poolie
<poolie> hi all
<poolie> jelmer, gdd was interesting
<poolie> i think today i'm going to have a look at making a txfixtures package and a buildd and then chase some mps
<jelmer> poolie: gdd?
<jelmer> poolie: we tested the newer bzr on a builder today, lamont is rolling it out at the moment
<poolie> google developer day
<poolie> oh, did you
<poolie> that's good
<jelmer> poolie: ah, cool. any interesting discoveries?
#bzr 2011-11-09
<poolie> jelmer, a few
<poolie> gae is apparently more useful and successful than my out of date impression
<poolie> being one of their highest-traffic properties, which is saying kind of a lot
<lamont> moof
<poolie> hi lamont
<poolie> tell me is the mailname thing a pressing problem, or are you ok to set that on all boxes
<poolie> if it is a big thing we can try to work something out
<lamont> poolie: not pressing
<lamont> it makes for a little analysis before we go all hog-wild on $EVERYWHERE, but the buildds don't care so much about that
<lamont> I wish the builders api let me get the build currently running on the builder
<lamont> though maybe it does, dunno
<poolie> the api on launchpad.net or the api on the buildd?
<poolie> you could certainly file a bug for that
<lamont> lp.net
<lamont> yeah, I need to file multiple bugs
<lamont> all of which are feature requests, in this clump
<poolie> if they will help do smoother rollouts i'm all in favour of them
<poolie> and may even try to fix them
<peitschie> hi everyone :)
<peitschie> I was wondering if jelmer (or someone with related knowledge) would be able to provide assistance an issue encountered with https://bugs.launchpad.net/bzr/+bug/485601
<ubot5> Ubuntu bug 485601 in Bazaar Subversion Plugin "missing chk node(s) for id_to_entry maps" [Critical,Fix released]
<poolie> hi
<peitschie> long story short... I just hit this problem with bzr svn 1.1.0 ... which is supposed to have it fixed :(
<peitschie> what is the appropriate way to re-open / raise this issue again?... is a dup best, or should I just add comments etc.?
<poolie> peitschie, just reopen it for now
<poolie> sorry i don't know a lot about it and i have to deal with other things this afternoon
<poolie> but i think jelmer will look at it soon
<peitschie> poolie: looks like I dont have permissions to re-open.  I'll post a comment and cross my fingers
<poolie> oh dammit
<vila> hi all !
<vila> poolie: ping
<poolie> hi vila
<poolie> hope you're feeling better
<vila> as jelmer jokingly mentioned, I still sound like Vader ;)
<Merwin> hi
<jelmer> 'morning all
<mgz> eugh, morning all
<jelmer> hi mgz
<jelmer> poolie: hi
<vila> jelmer, mgz : hey guys !
<jelmer> hi vila :)
<jelmer> vila: how are you today?
<vila> jelmer: hehe, still a bit Vader'ish ;)
<vila> jelmer: let me know when you want to test stuff again about multiple tarballs imports
<jelmer> vila: *nod*
<vila> jelmer: also, I'll happily renew the always-on-mumble experiment as soon as my voice is back ;)
<vila> mgz: ^ goes for you too of course
<vila> mgz: by the way, it would be nice if you could summarize your ideas about BadFilenameEncoding and all that jazz
<vila> mgz: as a brain dump to start the discussion
<mgz> sure
<vila> mgz: or rather, *enlarge* the discussion
<mgz> getting covered in bugs here...
<quicksilver> reality TV these days :-/
<mterry> Is Branch.revision_history deprecated in 2.5?
<jelmer> mterry: yes
<jelmer> mterry: if you're looking at the bzr-git FTBFS, I've got a pending upload for that
<mterry> jelmer, ok
<peitschie> mornin everyone :)
<poolie> hi peitschie
<jelmer> hi poolie, peitschie
<poolie> hi jelmer
<peitschie> hi jelmer :)
<wgz> evening all.
<poolie> hi wgz
<jelmer> hey wgz
#bzr 2011-11-10
<mgz> morning!
<vila> mgz: my man ! :)
 * fullermd used to be your man   :(
<vila> I can't find the bug about the recent spurious failures on babune, do you ?
<vila> fullermd: hehe, I can multi-man for some contexts ;)
 * fullermd c&p's into his quotes file.
<vila> hehe, see if I care ;)
<vila> fullermd: by the way, did you try to run the full test suite lately ?
<vila> fullermd: I remember you had issues and mgz landed a patch on trunk that we hope should address them
<fullermd> Nah.  I'm just an optimist and assume it'll work.
<vila> mgz: also, I just noticed you use 'test' and 'test-failure' as bug tags where I was assuming 'selftest' myself, we should probably discuss and agree on which one(s) we use
<vila> mgz: oh, and 'babune' is also relevant
<fullermd> Seems the last time I tried a full run (which was however many $AGES ago) I always had the deadlocks run up.
<mgz> you edited oneyou want bug 874153 vila?
<ubot5> Launchpad bug 874153 in Bazaar "Spurious test failure" [High,Confirmed] https://launchpad.net/bugs/874153
<mgz> ...
<mgz> one you just edited, and I think that's the other current one
<vila> YES !
<mgz> I try and remember to use selftest for... issues with selftest itself, and generally don't tag test failures in any particular way
<vila> ha, right, poolie seems to be using test-failure
<vila> yeah, keeping 'selftest' for selftest itself seems like a better fit
<vila> I think I'll switch to 'test-failure' for regressions triggered on babune
<vila> bbiab
<mgz> vila: how far back are we backporting fixes currently?
<mgz> this bug report is against 2.1.4, the change is against 2.3 and we're on 2.5
<mgz> I'll propose against 2.3 for now I guess
<vila> mgz: for bug #874153 ? spurious enough to target trunk only I'd say
<ubot5> Launchpad bug 874153 in Bazaar "Spurious test failure" [High,Confirmed] https://launchpad.net/bugs/874153
<vila> mgz: oh no, 2.1.4, dunno which bug you're referring then
<hrw> hi
<mgz> vila: https://code.launchpad.net/~gz/bzr/2.3_unprintable_retrywithnewpacks/+merge/81827
<jelmer> hi hrw
<mgz> hey hrw, getting on okay with the buildds now?
<hrw> mgz: works great
<vila> briandealwis: hi
<hrw> mgz: thanks a lot for this change
<briandealwis> hi vila
<mgz> jelmer and poolie were slaving away on getting it deployed all week we were at UDS :)
<mgz> (and jelmer had been trying for... I don't want to know how long before that)
<hrw> but the question for today is: how to export set of revisions as separate patches. I need to merge some changes from one branch to other but they have no common ancestor so prefer to have patches (like I would do with git and git format-patch)
<mgz> if you have both branches, you can cherry-pick the revisions, rather than going via patchfiles
<hrw> I cannot export some of changes as they are one huge commit
<mgz> anyway, bzr diff with the revision range? depends how you want to edit the patch.
<mgz> if your normal git thing is to get interactively select hunks, I'm not sure what would suit you best.
<hrw> moment - phone call
<briandealwis> vila, I haven't had time to do any further work on hooks-related part. The exception-shielding code comes from some nearly inexplicable interactions I've witnessed from exceptions in hooks. I've nearly reported 3 bugs on bzr-svn or bzr-git that were due to hooks instead.  But I see your points about hooks being able to influence the execution too. Seems we want a HookPoint.run for both with and without exceptions
<briandealwis> (sorry for the wall of text)
<vila> briandealwis: great, I was worrying you got confused by the reviews across both proposals
<briandealwis> not at all
<jelmer> briandealwis: do you recall what those hooks were? bzr-git and bzr-svn only hook into the "info" and "version-info" commands.
<vila> briandealwis: as said, if you've got enough use cases to triangulate, run_without_exceptions makes sense for purely innocuous hooks
<jelmer> ah, bzr-git hooks into Branch.hooks['post_commit'] too
<vila> but as soon as we start playing tricks with return values or stopping hook execution when some condition is reached, run() itself becomes less attracting
<briandealwis> jelmer: it was due to one of my own plugins :)  I have a 'verbose_hooks' plugin for debugging that dumps info on the hook args for various hooks.  There was an error in one of the branch hooks with bzr-git as it doesn't support generating a revno
<briandealwis> So I'd do a dpush, which would throw an exception
<briandealwis> I was uncertain as to the state of the branch or the push
<jelmer> ah, ok
<briandealwis> So from a user's perspective, providing the exception was far more confusing an experience
<briandealwis> Or rather, showing the exception without context, was confusing
<vila> briandealwis: that being said, I think my review was more about splitting the proposal to separate the parts we all agree upon from the parts for which more discussion may be needed
<briandealwis> I moved out the exception-shielding-run into HookPoint at poolie's request :)
<vila> it generally makes it a more satisfying experience for both the submitter (stuff lands) and the reviewer (easier to review)
<vila> briandealwis: yup, I realized that *after* my review
<vila> briandealwis: cross reviews are ... confusing :)
<vila> or rather reviews across resubmitted proposals
<vila> briandealwis: you know you can just push on the same branch ?
<briandealwis> I wondered about adding BZR_PDB support, so the exceptions could be seen and debugged, but it looked harder than I thought
<briandealwis> re: pushing: I did, but on a previous proposal, I thought I was told to resubmit
<briandealwis> â¦but that was a while ago
<vila> (the distinction between re-submitting or just pushing is rather arbitrary)
<vila> and even reviewers may say resubmit for push adding to the confusion ;)
<briandealwis> ah that would make sense
<vila> it's a judgment call but generally re-submitting is when you want to really re-start the review from scratch because the first proposal is becoming too... complex/diverging from initial intent/whatever
<briandealwis> gotcha
<briandealwis> oops, I mean: got it
 * vila blinks, the subtle difference between 'gotcha' and 'got it' here escapes me...
<briandealwis> gotcha seems to have more of a connotation of a surprise.  I think.  In my head at least.
<vila> didn't 'gotcha' mean: 'I got what you said' ?
<vila> oh
<vila> thks
<vila> jelmer, mgz: freezing 2.5b3, please don't land, I'll do as fast as possible and tell you when I'm done
<vila> Riddell: ping
<diwic> Hi! I'm writing a launchpad recipe and when I'm testing it I have to enter my key passphrase 10 times, although read access to these branches are public...?
<vila> diwic: you may be interested in an ssh-agent ?
<vila> diwic: as soon as you tell lp about your ssh key, ssh will be preferred to http for performance reasons
<diwic> vila, hmm, how do I set up an ssh-agent? I tried just running "ssh-agent bzr dailydeb recipe" but it didn't help
<hrw> mgz: for f in `seq 1 12`;do bzr diff -c$f >$f.diff;done
<vila> diwic: depends on your os/distro, which are you using ?
<diwic> Ubuntu 11.10
<hrw> mgz: that what I needed ;)
 * vila blinks, wth are the key settings gone, can't find them anymore in system settings
<vila> diwic: On ubuntu the ssh-agent should already be running... 'ssh-add -l' should tell you which keys are known
<vila> diwic: 'ssh-add <path-to-key>' will add a new one
<diwic> vila, aha, thanks, that was helpful!
<diwic> My recipe still fails though :-(
<diwic> bzr: ERROR: No such tag: upstream-3.0.0
 * diwic files bug 888539
<ubot5> Launchpad bug 888539 in bzr-builder (Ubuntu) "Recipe fails with "bzr: ERROR: No such tag: upstream-3.0.0"" [Undecided,New] https://launchpad.net/bugs/888539
<jelmer> hi diwic
<diwic> jelmer, hi there!
<jelmer> diwic: is this on a local build, or using Launchpad?
<jelmer> (It shouldn't happen using Launchpad)
<diwic> jelmer, this is local, testing it before trying it on Launchpad
<diwic> jelmer, with 0.7.1-0ubuntu1 of bzr-builder package
<hrw> diwic: --force-native-mode or sth like that is needed then
<hrw> diwic: --allow-fallback-to-native
<jelmer> diwic: newer versions of bzr-builder should give you a clearer error message
<hrw> diwic: it will ignore tags and force native package
 * diwic tries "bzr dailydeb --allow-fallback-to-native recipe"
<diwic> hrw, thanks for keeping me awake at the airport btw :-)
<jelmer> I'll release 0.7.2, there are a couple of other fixes that would be nice to get out too
<diwic> hrw & jelmer, it worked, thanks!
<hrw> diwic: no problemo
<hrw> diwic: I had this problem (bzr) before
<hrw> diwic: on return path I missed someone to keep me alive - had to rebook flight from FRA to TXL as I missed it (they moved gate and I did not noticed)
<diwic> hrw, oh :-( but it got sorted out I hope
<Wellark> jelmer: hi! :)
<jelmer> Wellark: hi :)
<hrw> diwic: yes
<hrw> diwic: and they did not charged me
<Riddell> vila: pon
<Riddell> g
<vila> Riddell: I tried to follow your instructions to update po/bzr.pot
<vila> and I encountered weird stuff
<Riddell> what did you do?
<vila> I finally used 'BZR_PLUGIN_PATH=-site make po/bzr.pot' instead of 'make -f po/bzr.pot'
<vila> and froze 2.5b3 with that
<vila> I wanted to make sure excluding the plugins was the Right Thing to do
<Riddell> yes it is
<vila> otherwise the ones included depend on the RM :-/
<vila> ha good
<vila> I've updated the instructions then and I'll send a mp asap
<vila> Riddell: the associated diff is an interesting way to look at what has been added since the previous release...
<vila> Riddell: good stuff for RMs ;)
<vila> jelmer, mgs: 2.5b3 frozen, 2.5b4 opening on pqm, thanks for your patience ;)
<vila> s/mgs/mgz/
<jelmer> vila: thanks!
<mgz> stick the strings file diff up somewhere vila? :)
<vila> mgz: 'bzr pull lp:bzr' , it's part of the release commit
<mgz> an extractable part though? :)
 * mgz tries
<vila> the release commits are quite short most of the time
<vila> hehe, I just add a wtf moment: I misread 'test_non_ascii.TestNonAscii.' as '^[ascii]' and thought pqm was back in the good old days where we ran the test suite twice ;)
<mgz> bah
<mgz> a bunch of line number change junk
 * mgz grumbles at gettext and the formats it uses
<vila> hmm, that reminds me that ediff (in emacs) allows regexps to *ignore* some changes...
<mgz> hm, command help paragraphs don't seem to be shared, eg bzrlib/builtins.py:1007 and bzrlib/builtins.py:1147
<rvba> Hi there, do you guys happen to know if it's possible to have a mirrored branch inside /~me/+junk/ on lp?  Or do I have to create a project and create the mirrored branch in there?
<rvba> I've been sent here from lp-dev so please don't send me back there ;)
<fullermd> We really should switch up metals for some variety.
<fullermd> Our next beta should go palladium, say.
<jelmer> palladium is one of the launchpad buildds
<fullermd> OK, ruthenium then.
<mgz> fullermd is bored of gold by now?
<mgz> just have too much, don't know what to do with it?
<fullermd> Nono, I don't have *enough*!  And all those betas keep going off with what I have!
<vila> mgz: yup, I noticed the help paragraphs too... did you dig that ?
<mgz> nope, but I did notice one was at the end of the help block and one in the middle
<mgz> so could be a quirk of how that's split
<mgz> or perhaps help blocks aren't deduped at all.
<vila> Maybe a final \n quirk
<mgz> really, it's a sign that our help needs shortening I thikn
<jelmer> vila: 2.5b3 uploaded to sid/precise
<jelmer> sorry, experimental+precise
<vila> jelmer: Thanks !
<mgz> vila: looks like export_pot doesn't actually do deduping.
<vila> mgz: export-port is ours right ?
<mgz> yup, bzrlib.export_pot
<vila> ok, worth a bug then
<vila> 2.5 is the first series for translations, it's expected that we encounter a few
<vila> bugs
<mgz> I better read up on the po format first... :)
<vila> hmm, and PEP8 issues there too ;)
<vila> jelmer: I kinda lost track of where you are for multiple tarballs, but
<vila> jelmer: IIUC you commented a line related to branch freshness and this is causing other import failures
<vila> jelmer: is there two different bugs ?
<vila> hgaaa
<vila> jelmer: I meant: commenting that line (which one ?) will *address* other import failures that we encounter *now*
<mgz> as I recall, he only commented a line on his box, for testing, which was a path the importer doesn't go down
<mgz> the freshness issues should be all the same old freshness issues
<vila> mgz: yup
<vila> http://package-import.ubuntu.com/status/3b90b26b3585bde1d5cb6d903f83dc45.html
<vila> looks new to me
<vila> imbw but it seems that running bzr-2.5 on jubany has caused these new failures
<vila> which is surprising in itself
<vila> but checking the freshness on the importer seems useless anyway so we probably want a way to disable it if only for the importer
<mgz> vila: I wouldn't be suprised if fixing the multiple tarballs error exposed a few more packaged with freshness issues
<jelmer> vila: it works at the moment
<jelmer> vila: but I'm fixing a bug in the multi  tarball support to handle revisin parents correctly
<vila> mgz: the importer is responsible to make the branches fresh enough is what I'm trying to say ;)
<mgz> this is pretty fun too: http://package-import.ubuntu.com/status/73d7709fb86e524d019e4c119d698c58.html
<vila> jelmer: ok, so I'm still waiting for your green light
<vila> mgz: that's one of the bugs where I suspect the importer misunderstands the packager
<jelmer> vila: yep
<mgz> yeah.
<mgz> vila: do you favour merging up older bzr releases when each change lands?
<vila> mgz: yup, that means the guy doing the landing also handle the conflicts when merging up
<vila> mgz: and they should be easier to resolve by him than by anybody else
<mgz> heh, anyone can read release notes and probably realphabetise better than me :P
<vila> oh, release notes, yeah, be careful when crossing... 2.2 -> 2.3 where they were split from NEWS to one file per release
<vila> but release notes is not my concern here ;)
<vila> wgz: confused by the too many spurious test failures, I ended up filing a bug you already filed, in anger, I marked *yours* as a dupe of mine ;)
<smoser> hey all. how can i track a git repository in bzr ?
<smoser> i know i can set  up launchpad to do it for me
<jelmer> hi smoser
<smoser> but how can i do it on my own?
<jelmer> smoser: if you have bzr-git installed, just use bzr branch as you would with a bzr branch
<smoser> perfect.
<smoser> easiest question ever
<smoser> thank yoiu
<george_e> I can't seem to get Bazaar to pull from an HTTP server.
<george_e> Using Chromium, I can verify the remote server is up and running and the .bzr folder is accessible.
<george_e> ...but I keep getting errors: "bzr: ERROR: Not a branch: 'http://192.168.1.1:8083/'"
<george_e> What am I doing wrong?
<jelmer> hi george_e
<george_e> Hi.
<jelmer> george_e: is .bzr/branch-format accessible?
 * george_e slaps forehead
<george_e> It's spitting out a 403 :)
<george_e> That would explain it alright.
<george_e> (That's what I get for using IIS :P)
<george_e> jelmer: Thank you thank you thank you - that solved the problem.
<jelmer> george_e: np :)
<poolie> hi all
<GRiD> hi poolie
<Noldorin> hi jelmer
<Noldorin> poolie,
<poolie> hi
<jelmer> hi poolie, GRiD, Noldorin
<Noldorin> hey
<GRiD> hey jelmer
<Noldorin> how's it going?
<GRiD> no hurry, but if someone can take another look at https://code.launchpad.net/~weyrick/bzr/720853-max-recursion-depth/+merge/81297 ...
<poolie> oh thanks for th ereminder
<poolie> done
<GRiD> thanks :)
<Noldorin> jelmer, are we any closer to the new bzr-git release/fix, may i ask? :-)
<GRiD> poolie, btw, i suppose i should also add something to release-notes?
<poolie> yes
<GRiD> k
#bzr 2011-11-11
<jelmer> Noldorin: there's a new bzr-git release (0.6.5) from a couple of days ago
<wgz> no bed quite yet, better do travel now.
<poolie> wgz, it doesn't have to be right now
<wgz> will save round trips in the morning :)
<poolie> by 'today' i meant my today, friday
<wgz> it's done/
<wgz> and my sis is still on the phone, so I'd not have got the extra sleep anyway :)
<Noldorin> jelmer, oh does that fix the issue i was having with my branch though?
<jelmer> Noldorin: no, that issue is still open
<Noldorin> jelmer, ah, oh well...
<Noldorin> targeting it soon?
<Noldorin> i guess it's good news the project is still moving...thought this was a pretty crucial issue though
<jelmer> Noldorin: your repository is the only I've seen it with so far
<jelmer> Noldorin: it's on my list of things to work on, but I'm swamped by other stuff at the moment
<Noldorin> jelmer, heh okay sure
<Noldorin> jelmer, very surprising, since i isolated quite a simple reproduction case :-)
<Noldorin> jelmer, but clearly you haven't forgotten...thanks
<Noldorin> brb
<poolie> GRiD, ok that still sounds pretty good then
<GRiD> ok cool. the bzr-search change should be pretty easy too, i think. i can look at that after if i get a minute.
<GRiD> well, easy in that i would just skip the key it's trying to add if it's too big, although i don't know if that's the right thing to do
<poolie> i guess the question is why is the key getting so big
<poolie> if it's just encountered a really long whitespace-delimited "word"
<poolie> then skipping it would be reasonable
<poolie> i don't know if that is actually the cause
<GRiD> yeah i didn't have a chance to investigate that. but if you try to reproduce the original bug (by indexing ubiquity) with my patch, it now excepts on a key that is about a 4k (iirc) string of hex characters
<GRiD> fwiw, if the long keys are skipped (which one of my early patches did silently), the indexing of ubiquity completes and seems to be usable.
<poolie> GRiD, ok, so i think the main thing here is that the decision to skip is a policy of bzr-search, not bzr core
<poolie> search may not care about indexing long strings but for other things that might lose data
<GRiD> yep, agreed. i only meant it in that if bzr-search caught the exception and simply skipped for now (perhaps with warning), it may be sufficient. if it's not, someone who knows more about bzr-search should take a look.
<poolie> i think that'd be good
<poolie> thanks for fixing it
<poolie> lifeless, ^
<lifeless> yah, I've been following along
<lifeless> all sounds good to me
<GRiD> ok i'll take a look at making bzr-search skip then.
<mgz> morning!
<mgz> hm, it's good to know someone else is interested in maintaining paramiko, but looking at the changes 'bitprophet' has on github doesn't fill me with confidence
<mgz> the only significant changes seem to be the rename (to 'ssh'... which seems unwise) and changing all the copyright headers(!)
<mgz> and has done two releases to pypi without updating NEWS or otherwise indicating what's different as far as I can see
<jam> mgz: well, having an official release channel is what we are after. We've written a few patches that have just gone ignored for long stretches of time.
<jam> I agree that the 'ssh' thing seems a bit wonky. There can be many ssh libs around, having a unique name is nicer. Though maybe just a namespace "from paramiko import ssh"
<jam> or 'import paramiko_ssh as ssh"
<mgz> anyone know if github lets you issue pull requests for other people's branches?
<mgz> ...not that they'll let me sign in, no openid support and demand js enabled.
<jam> mgz: if you had an account, you could always 'fork' the other person's branch and propose it directly, so I would think they would allow you to propose someone elses' branch
<mgz> jam: on your running tests against implementations in different languages thing,
<mgz> (I don't know why but was thinking about that before going to sleep last night)
<mgz> what people generally do is structure the cases as data as far as possible, then just write the bits they need for the runners in python/js/etc
<mgz> eg htmllib5
<jam> mgz: sure, but it means implementing a test-suite runner in each language
<mgz> or it's nearly what bt.test_conflicts.TestParametrizedResolveConflicts is
<jam> which may not be much better than implementing a test-suite in that language
<mgz> yeah, and when you get to the point where it's nearly a mini functional language, the tests aren't very easy to read
<jam> so far, it seems the only way if we want to ensure the *same* tests get run in each language
<jam> mgz: we just need to port the python interpreter to vala, js, java, etc, and we'll be golden
<jam> php will be fun :)
<mgz> but there's probably a middle ground where the test cases are still easy enough to write, but the runners don't need to be overly complicated
<jam> mgz: I think you meant "forwarding our existing patches" not "forwarding out existing patches".
<mgz> ...I did
<mgz> the keys are like, right next to each other.
<mgz> okay, let's do the github dance
<mgz> ha, and I don't actually have git installed here, have just been using bzr-git
<jelmer> mgz: bzr-git should work for pushing too..
<jelmer> :)
<mgz> I need to do a couple of merges and thought I'd try the vanilla option first :)
<mgz> I need to go out briefly, will be back shortly
<mgz> back.
<daveb_> how do I undo a merge? I want to merge from the same branch, I just wan't to do it later
<mgz> `bzr revert`
<mgz> if you have changes in your tree you want to keep, it's a bit harder
<mgz> but you can tell bzr to forget the merge then undo the merged changes manually
<daveb_> I thought revert only changed the working directory
<mgz> it also forgets merges if you don't give specific paths, see `bzr help revert` for more.
<fullermd> The fact of a pending merge is an attribute of the working tree.
<daveb_> i commited the merge
<fullermd> And other stuff since then?
<mgz> if you haven't done other stuff, can use `bzr uncommit` then my earlier advice, otherwise you're better off... doing something clever fullermd will tell you about
<fullermd> Oh great.  No pressure, right?
<mgz> you're the super sub :)
<mgz> can sit out most of the game but expected to sometimes come on and produce miracles.
<daveb_> ok, uncommit followed by revert worked :)
 * fullermd takes the credit.
<mgz> see, this match we won anyway, so you just get to rest. :D
<fullermd> Nono, too late!  You already made me cross the sideline!
<daveb_> i guess you also have to rm -rvf any remote branches you have been pushing too...
<fullermd> Or push --overwrite 'em.
<mgz> only if you pushed that last change with the merge you didn't want
<mgz> for very public locations, it's most polite to work on from mistakes, rather than trying to pretend they never happened
<daveb_> hmm
<fullermd> Oh no, the shame is bad enough he had to change his name.
<croepha> lol
<jimis> jelmer: no need to pass a source branch revno to bzr log, it should print it so we can use it with other commands, like diff
<jimis> bzr diff -rrevno:115532:tree1
<jimis> for example
<jimis> bzr log should just display an extra line for each merge operation: "source branch revno: 115532"
<jimis> in case it is expensive it should happen only with bzr log -n0
<jelmer> jimis: that revno is specific to the source branch
<jelmer> jimis: so you have to pass in the source branch somehow
<jelmer> jimis: the revno displayed by log is already usable in e.g. diff
<jelmer> bzr diff -r13423.32.1
 * jelmer -> weekend
<slangasek> jelmer: if and when you have some time, I could use some help with (modifying) bzr-rewrite
<ccxCZ> I have bound branch, I did local commit and then bzr up, now the revision of the local branch was set back, how would I find the commit and push it?
<fullermd> The local commit is now a pending merge.
<ccxCZ> it was aggregated with uncommited changes
<ccxCZ> I would prefer to have them as two separate commits
<ccxCZ> I seem to be able to get the revid via bzr heads --all
<ccxCZ> backing up working tree, updating to revid and restoring did the job
#bzr 2011-11-12
<Merwin> hi
<jelmer> slangasek: sure
<slangasek> jelmer: I'll try the easy one first... I have two branches, bzr+ssh://bzr.debian.org/bzr/users/vorlon/freetds/trunk/ and bzr+ssh://bzr.debian.org/bzr/users/vorlon/freetds/upstream/branches/BRANCH0_63, and I want to rewrite the history so that the tip of the latter branch is the ancestor of the first revision on the former (or functional equivalent).  bzr-rewrite is failing me; I've tried to create an initial packaging revision on the latter branc
<slangasek> ... import-dsc, but even using the option to pass an id map in (stolen from cjwatson), I can't seem to convince bzr-rewrite to rewrite anything
<m1sc> hi. is there something more advanced than bzr_ssh_path_limiter and bzr_access?
<jelmer> slangasek: bzr-rewrite doesn't deal with file id differences at all
<jelmer> slangasek: which is probably the main reason for your problems with it
<jelmer> slangasek: what sort of id map option are you using?
<jelmer> m1sc: hi
<jelmer> m1sc: not that I'm aware of - more advanced in what  way?
<m1sc> jelmer: like bzr_access without the known limitations..
<jelmer> m1sc: which known limitations (sorry, I don't have any experience with bzr_access myself) ?
<m1sc> jelmer: http://wiki.bazaar.canonical.com/BzrAccess (scroll down)
<jelmer> ah
<jelmer> m1sc: I'nm not aware of any alternatives for bzr+ssh that don't have those limitations
<m1sc> jelmer: ok. thx
<slangasek> jelmer: ah, file ids would explain it then I guess :/  I was trying to use cjwatson's scratch_import bits
<slangasek> (for the idmapping)
#bzr 2011-11-13
<jo-erlend> is it possible to undo a revert?
<jelmer> jo-erlend: sortof - revert will create backup files for all the files it reverts
<jo-erlend> oh, ok. That's good to know.
<poolie> hi all
<jelmer_> 'morning poolie
<poolie> hi there
<poolie> i might have a go at memory usage during checkout :)
<poolie> see how high the fruit actually is
<poolie> jelmer, my branch to actually delete buildd from the tree failed ec2 for some mysterious reason
<poolie> so i'll try to work that out too
<jelmer> poolie: cool
<jelmer> poolie: oh? any test in particular that failed?
<poolie> oh it just didn't find the buildd library from the package
<poolie> i'm sure it was installed
<jelmer> poolie: is it a debian package?
<poolie> yes
<jelmer> poolie: did you update the ec2 image?
<poolie> no, but i ran it with my patch to the ec2 tool that makes it do an update first
<jelmer> neat, I didn't realize it could do that now :-)
<poolie> vote up https://code.launchpad.net/~mbp/launchpad/ec2-update/+merge/81946 :)
<poolie> as i say on the mp it seems unnecessary to wait for a new ami to be built etc
<jelmer> yeah, that's really useful
<jelmer> updating the AMI image was a bit of a traumatic experience
<poolie> so, seriously, say so if you think it's a good idea :)
<poolie> stevenk was concerned i guess that it might be more fragile
<jelmer> poolie: the bzr-beta-ppa is obsolete and no longer updated as far as I know
<jelmer> poolie: and the branch doesn't actually seem to remove henninge from the list of image owners
<jelmer> other than that, it seems reasonable to me
<poolie> i should remove the beta ppa
 * jelmer comments on the MP
<poolie> i should probably actually change the image-building so that that the ppas are still present
<poolie> it raced with steven removing henninge
<jelmer> ah, ok
<poolie> jelmer, i wonder if we should revert grid's patch, re bug 889872
<ubot5> Launchpad bug 889872 in Bazaar "not a valid key error" [Critical,Confirmed] https://launchpad.net/bugs/889872
<jelmer> poolie: me too - perhaps we should, we can always land it again once that issue is fixed
<poolie> GRiD, don't suppose you're here?
<jelmer> poolie: heh, nice to see a recipe for launchpad-buildd :)
<poolie> mm dogfood
<maxb> jelmer: Why do you say that? (about beta ppa)
<maxb> oh, you mean in that specific context, yup, agreed
<jelmer> maxb: Yeah, I'm talking about ppa:bzr-beta-ppa/ppa
<poolie> yep, got it
<maxb> Actually, does Launchpad development actually require ppa:bzr/ppa any more?
<poolie> we could delete the team, but istr we thought we'd keep the ppas there as an archive
<maxb> Not that it'll harm anything
<poolie> it needs _a_ bzr obviously
<poolie> i think running from ppa:bzr is likely to be close to what's deployed and also likely to be more consistent across distroseries than just using the os version
<maxb> But only good enough to get the source in the first place, I assume, since there's also a bzr in buildout
<poolie> rocketfuel-setup adds the bzr ppa so i'm being consistent with that
<GRiD> poolie, yes sure revert it for now
<maxb> Still, probably better to leave the bzr ppa in there so people can benefit from latest-stable bzr speed fixes, etc.
<poolie> maxb, in the specific case of ec2test it needs bzr to fetch the lp tree before it can run buildout :)
<poolie> though for that i guess any old version would do
<GRiD> jelmer, maybe you can help me reproduce 889872 tomorrow (mon)?
<GRiD> or even better, help me craft a test case to reproduce :)
<jelmer> GRiD: I'm not very familiar  with that bit of the code so I'm not sure if I can be of much help. I have the issue in a pdb session though, if that helps.
<jelmer> GRiD: it might be that the issues can be reproduced by forcibly repacking a bzr repository
<GRiD> ok np. i won't have a chance to take a serious look until tomorrow, so i'll try that first
<peitschie> mornin all :)
<poolie> hi there
#bzr 2012-11-05
<JPeterson> "bzr branch lp:jp-test ." returns " Target directory "." already exists."
<JPeterson> how do i fix it?
<fullermd> branch has a --use-existing-dir.  But are you sure you want to drop the branch right in '.'?  (as opposed to ./jp-test/)
<JPeterson> thx
<felipec> it looks like I can do ControlDir.open('lp;foo'), and operate in in the branch as if it was local... but the operations are too slow
<felipec> is there a facility to have an intermediary local branch?
<fullermd> Pretty sure not really.  The facility looks like "bzr branch lp:foo local ; ControlDir.open('local')"   8-}
<felipec> fullermd: yeah, I'm doing something like that, but what happens when I want to push to lp:foo?
<felipec> I guess I need to pull and push to make sure they are in sync
<felipec> I thought perhaps this concept of 'bound' branches would help
<fullermd> Oh, you can "push lp:foo" or "push :parent" or (after the first time) just plain "push", depending on when/if you expect somebody to fiddle your branch behind your back.
<fullermd> That would also be a possibility, as long as you're OK with things happening upstream the moment you do them (and handling the case of upstream moving behind your back).
<felipec> hmm, I'm not sure
<felipec> maybe I should do a clone for the initial import, and after that push directly to the server
<JPeterson> "https://code.launchpad.net/~john-peterson3/calibre/calibre/+merge/132832" returned "Timeout error Sorry, something just went wrong in Launchpad. Weâve recorded what happened, and weâll fix it as soon as possible. Apologies for the inconvenience. Trying again in a couple of minutes might work. (Error ID: OOPS-342f8cc9c38bf1ad53e6f28f3f2c2db4)"
<felipec> I'm reading about bound branches... supposedly when a commit is made on the local branch, it should be pushed to the parent branch
<felipec> no?
<fullermd> Correct.
<felipec> fullermd: but the API doesn't do that...
<fullermd> Well, I don't know at what level the magic happens.  Are you sure you actually made a bound branch?
<felipec> fullermd: branch.bind(remote_branch)
<bob2> don't do bound branches
<felipec> looks like in addition to builder.commit, I need to import_last_revision_info_and_tags
<AfC> bob2: well, bound branches are part of the magic fairy dust that makes `bzr switch` work, at which point you have a the ability to reuse a Working Tree across different Branches
<bob2> sadness
<bob2> I underspecified, binding to shared repos is my concern
<lifeless> AfC: huh? switch works fine w/out bound branches
<AfC> lifeless: really? That's new
<AfC> lifeless: when I learnt it, you had to have a checkout to be able to switch
<JPeterson> holy cow how do i remove this https://code.launchpad.net/~john-peterson3/calibre/calibre/+merge/132832/comments/285737 message? it's a duplicate message.
<JPeterson> do i have to fraking ask an admin to remove my own messages?
<lifeless> AfC: lightweight checkouts work fine
<JPeterson> admin moron? can you delete my message?
<JPeterson> it's a  duplicate. it's worthless. it must be deleted.
<AfC> lifeless: um, ok. I guess I would have said that's still a checkout. Happy to be corrected, cheers.
<AfC> lifeless: [still a bother to set up]
<lifeless> AfC: it is a checkout, but its not a bound branch
<lifeless> AfC: all the bound branch complexity can't happen in a lightweight checkout
<AfC> lifeless: fair enough
<bob2> a) #launchpad
<bob2> b) not being a dick is helpful when asking for something
<mathrick_> how can I add extra "see also" for a command?
<vila> mathrick_: look for _see_also examples in bzrlib/builtins.py
<mgz> morning!
<fullermd> Again?  I just dealt with one of those yesterday...
<mathrick_> vila: ah, thanks. I was looking for that in bzrlib.commands.Command, but it isn't documented it seems
<vila> mathrick_: quite possible, there is a leading '_' after all ;)
<mathrick_> hmm, right. Why does it have that, though?
<mathrick_> it doesn't seem like something "internal" to me
<vila> mathrick_: hysterical raisins, I can't see why it's not public indeed (but I may miss some detail...)
<mathrick_> btw, it seems like a missed opportunity that bzr help plugins/foo doesn't list the commands provided
<vila> mathrick_: patches welcome ;) That sounds like a good idea. I don't remember what's the default behavior is but I think a plugin can already do that...
<vila> at least 'bzr help qbzr' does (usual kudos to our qbzr friends ;)
<mathrick_> vila: I believe it's simply hardcoded into the docstring
<mathrick_> all the plugins I've seen do that
<vila> indeed it is
<vila> fullermd: urgh, bug #1075213 gives me a headache :-/
<ubot5> Error: Launchpad bug 1075213 could not be found
<vila> see ?
<vila> bug #1072513
<ubot5> Launchpad bug 1072513 in Bazaar "log can show too few revs" [High,New] https://launchpad.net/bugs/1072513
<vila> fullermd: but basically I think it's related to -v inspecting all the *file* revs while !-v looks at the ancestry graph
<vila> fullermd: by "file revs" I mean the existing file texts that are referenced in the revision inventories
<mathrick_> uhh, is that expected behaviour?
<mathrick_> C:\Users\Trendware\Dev\bzr-submit>bzr info ./this-doesnt-exist
<mathrick_> Standalone tree (format: 2a)
<mathrick_> Location:
<mathrick_>   branch root: .
<mathrick_> ie. no error being returned
<vila> mathrick_: yes. 'bzr info' walks upward from the location you give so it ends up in C:\Users\Trendware\Dev\bzr-submit which is a real branch
<mathrick_> that's pretty counterintuitive to me
<mathrick_> though it might be because I want to check for a branch that (possibly) lives in a subdir, so I want it to error out on non-existent location
<mathrick_> if I trigger pdb on a bzr error (with BZR_PDB=1), how can I inspect the exception that caused the debugger to step in?
<vila> meh, no general answer for that, it depends on where the debugger puts you in, you may try so start with 'pp locals()' maybe
 * vila off for errands
<mathrick_> perhaps exc_info() will help
<hasselmm> any reason bzr doesn't install the grep plugin by default?
<ReekenX> How to what will be changed from repository without running `bzr up`?
<ReekenX> I can't find on Google anything related to this
<mathrick_> ReekenX: you're missing a word in your question, it makes it unclear
<mathrick_> try repeating it
<ReekenX> mathrick_: Before updating a code with `bzr up` I want see changes coming (what will be changed in my source code).
<mathrick_> hmm, what is the API to use when I want to ensure I'm in a branch, and not a repo?
<mathrick_> ReekenX: try bzr missing :bound
<ReekenX> mathrick_: Thanks a lot! And sorry for poor english skills (trying to improve).
<mathrick_> that's alright, it just looked like you missed a word
<mathrick_> ReekenX: btw, note that with lightweight checkouts, it won't work. Lightweight checkouts are pretty hard to inspect in general, because they have almost no state on their own
<mathrick_> hrmpf
<mathrick_> how do I distinguish between NotBranchError meaning "location doesn't exist" and "location is a repository"?
<mathrick_> I want to error out only if I get a repo, but not when I get a branch or a non-existent location
<vila> mathrick_: bzrlib.branch.Branch.open() ?
<mathrick_> vila: but won't it also give me NotBranchError on non-existent paths?
<vila> from memory, I can't say
<vila> mathrick_: writing a test for it will allow you to explore at will
<mathrick_> poking reveals it will
<mathrick_> oh well, not that important
<mathrick_> I will get it right later
<mathrick_> OK, what is the canonical way to set the submit location?
<mathrick_> from the command line, that is, and/or programmatically
<mathrick_> aha, bzr config submit_branch="../upstream"
<fullermd> vila: Well, if it weren't headache-inducing, what would be the fun in filing the bug?   ;p
<vila> mathrick_: yup, 'bzr config' is the manual way (bzr config --remove may help too)
<vila> fullermd: hehe
<vila> fullermd: I didn't dig enough to fully understand (I mainly tried the script with make_dir=false and looked at the branches with bzr qlog A B C)
<vila> fullermd: the only weird thing I noticed that was you were merging older versions of the branch itself
<vila> fullermd: nothing illegal there but the result may be confusing for the user
<fullermd> Oh, that's not enough.  You don't really have a headache until you start commenting out the [1] lines and watching new revs start appearing like magic.
<fullermd> Well, the Real Branch where I first ran across it was a little twisty in how it came together; that was the simplest way I could come up with to reproduce it.
<vila> fullermd: I have no doubts the real one was even harder to grasp...
<vila> fullermd: any of the [1] ? In a particular order ?
<fullermd> Nope.  For every one you comment out, one more of the "right" revs shows up in the log output.  So any 3 of them, and all 4 "right" revs show up.
<fullermd> Or uncomment the exit in the [2] block; that causes 2 of them to show up.  So skipping [2] via the exit, and commenting out any 1 of the [1]'s, and everything works right too   :)
<fullermd> No correspondence between which one you comment out and which "right" rev shows up; they always uncover themselves in the same order.  Neat, huh?
<vila> fullermd: hmpf
<fullermd> The Particular Magic in the real case that I copied into the test case was how one branch off trunk added a dir with a couple files and was merged, and then another branch that started off trunk from before that landed merged trunk with those changes, made other changes in the dir, then was itself landed on trunk.
<fullermd> But I had to add in those --unchanged rev in the test case (in the real case there were of course real commits to other stuff in the tree before/after the revs touching the dir in those landings) to make it start showing up.
<fullermd> So I didn't actually discover that quirk by removing them and watching stuff show up; when the test worked right while the real didn't, I started adding them and watched stuff _disappear_   8-}
<fullermd> Perhaps you could hear me whimpering and curled up in the corner when that happened...
<fullermd> vila: Incidentally; I just tested; the extra merge in [2] isn't itself apparently part of the necessary special sauce.  Replacing that block with 2 more --unchanged revs on C has the same effect.  So there's one more step of simpliciation.
<fullermd> (it would be simplification, but that's more letters, so obviously not as simple...)
<fullermd> I guess I should note that on the bug, so future generations can share in the WTF.
<vila> fullermd: yup (sry otp) (and yes, less letters is simpler)
<fullermd> Say hi to whoever it is for me  ;>
<fullermd> vila: There's the updated script and some notes on the bug.  Y'know, just in case that headache went away   8-}
<vila> fullermd: cool, I'll update mine
<fullermd> Slightly more normal looking history without the extra merge.
<fullermd> http://picpaste.com/pics/qlog.1352134680.png
<fullermd> Though I did add a few extra notes about tweaks you can do to the "Merge A:1" without affecting the outcome, just to muddy the waters up a bit...
<fullermd> Anyway.  Headache widely shared; my work here is done!
#bzr 2012-11-06
 * SamB_MacG5 thinks the fact that bzr-svn and bzr-builddeb conspire to be compatible with svn-buildpackage should be advertized better ...
<jelmer> SamB_MacG5: you're hitting issues with it?
<SamB_MacG5> jelmer: issue was that I had no clue that it was supposed to work in the first place
<SamB_MacG5> ... except for a suspiciously named branch of bzr-svn ...
 * SamB_MacG5 posts http://naesten.blogspot.com/2012/11/on-bzr-svn-and-svn-buildpackage.html about it
<persia> Good day.  I've been trying to pull a large source via bzr 2.5.1 for about 20 hours, with various timeouts.  I've just tried pulling what ought be an identical source tree from loggerhead tarball export in about 3 minutes.  Is there any debug data I could produce that would generate a useful bug for this?
<persia> (or would this not be a bug because of the extra volume of history also being downloaded?)
<mgrandi> could try pasting the bzr log
<mgrandi> .bzr.log
<persia> Thanks for the pointer: it appears that I received ConnectionReset messages which would indicate a local issue.
<mgrandi> what transport were you using?
<mgrandi> or accessing the source from, sftp? bzr+ssh? ftp?
<persia> bzr+ssh
<persia> Command line was `bzr branch lp:launchpad`
<mgrandi> did you login to launchpad?
<mgrandi> you get throttled speed if you arn't logged in
<persia> How does one log in?
<mgrandi> bzr lp-login i think
<persia> Would having launchpad_username set in .bazaar/bazaar.conf be sufficient?  LP has my SSH key.
<mgrandi> i think that means you are logged in
<persia> Or does it need to be done each session?
<mgrandi> just once i think
<lifeless> mgrandi: you don't get throttled
<persia> In that case, I'm logged in.
<lifeless> mgrandi: you just g=don't get ssh
<persia> I thought login just changed transport from http to bzr+ssh
<lifeless> it does
<mgrandi> ive heard the speeds are slower if you are not logged in
<lifeless> http has no smart server attached to ut
<persia> Probably because of traffic shaping and http buffers along the way
<lifeless> so its slower, but its not throttled
<lifeless> its because you're checking out over a VFS
<mgrandi> ah
<mgz> morning!
<mira|AO> I just filed LP#1075548 and am here for back-questions
<mira|AO> in case someone has them
 * jelmer waves to mira|AO, Noldorin, mgz
<mgz> hey jelmer!
<Noldorin> hi jelmer
<jelmer> mira|AO: I've reassigned the bug to bzr-svn, but I'm not sure if there is anybody actively looking at those bugs
<mgz> also, expansion of %2F is dodgy
<mira|AO> ok
<mgz> maybe just an svn server configuration issue?
<mira|AO> mgz, the %C3 also gets expanded (and then repr'd as \xc3)
<mira|AO> I don't think soâ¦ the file is in a sub-sub-subâ¦directory of something I moved, and its name exists (with %) in both bzr and svn before
<mira|AO> and Iâm not the only one seeing such errors
<mgz> right, expanding the non-ascii is find (and bzr seems to do it correctly)
<mgz> *fine
<mira|AO> no, it's not fine
<mira|AO> the file literally has these percent signs in it
<mgz> ...oh, wow
<mira|AO> -rw-r--r-- 1 tglase Administrators 1502 Dec  9  2011 upstream/src/plugins/wiki/www/locale/fr/pgsrc/Aide%2FPluginCr%C3%A9erUnePage
<mira|AO> yeah.
<mgz> okay, that should get handled properly.
<mgz> it's perverse but hey.
<mira|AO> (it's french)
 * mira|AO hides
<mgz> french doesn't use percent escapes!
<mira|AO> right
<mgz> though I'd like to hear them pronounce that...
<mira|AO> you don'tâ¦
<mira|AO> I suffer when we do IRL meetings each time
<jelmer> I guess an issue could be that bzr-svn is unescaping filenames one time too many..
<mira|AO> probably
<mira|AO> can I attach an interactive python or ipython to it and 'live-debug'?
<mira|AO> IIRC there was something
<jelmer> mira|AO: you can set BZR_PDB=1
<mira|AO> ah, that was it
<mgz> also possibly to blame is url/file guessing code
<jelmer> mgz: that shouldn't be relevant here, that only happens when opening transports AFAIK
<mira|AO> it might only be triggered when there's non-ascii chars with percents in it
<mira|AO> so that the one-decode-too-much is cushioned by a one-encode-too-much somewhere
<mira|AO> which doesn't hit the \xc3
<mgz> mismatched decode and encode would do it too probably
<mira|laptop> (Pdb) print self._override_file_ids[u'.not-evolvis/wiki/fr/Cr%C3%A9erUnePage']
<mira|laptop> 10242@9d84d37e-dcb1-4aad-b103-6f3d92f53bf6:trunk%2Fsrc%2Fplugins%2Fwiki%2Fwww%2Flocale%2Ffr%2Fpgsrc%2FCr%25C3%25A9erUnePage
<mira|laptop> this is interesting
<mira|laptop> because the key is _not_ the real filesystem path
<mira|laptop> tglase@tglase-nb:~/Evolvis/tarent-5.1 $ l .not-evolvis/wiki/www/locale/fr/pgsrc/Aide%2FPluginCr%C3%A9erUnePage
<mira|laptop> that one is the renamed-to name
<mira|laptop> pdb is... not too easy to use
<mira|laptop> ah wait
<mira|laptop> according to debug output, it seems to move the file along all directories
<mira|laptop> first up, then down in the new subtree
<mira|laptop> (Pdb) print editor
<mira|laptop> <_ra.Editor object at 0x2213b88>
<mira|laptop> where's the source for that?
<mira|laptop> can't find it in usr/share/...
<jelmer> mira|laptop: it comes from the subvertpy sourcecode, written in C
<mira|laptop> ah ok
<mira|laptop> ok, in dir_editor_send_changes() in commit.py it's still correct...
<mira|laptop> so it may be a _ra.DirEditor object, which I assume is also in C
<mira|laptop> urgh
<mira|laptop> sorry, this is beyond what I can do during worktime
<mira|laptop> anyway, in (for me) line 309 of commit.py ('changed = True'), the values of url_join_unescaped_path(base_url,base_tree.id2path(child_ie.file_id).encode("utf-8")) and full_new_child_path are correct (the '# copy if they existed at different location' elif branch)
<vila> jelmer: o/
<jelmer> vila: \o
<fullermd> vila, jelmer: So sorry to see you've each lost an arm...
<vila> lucky us it's not the same !
<fullermd> Yeah, we can graft your stumps together and still get something with an arm on each side.
<fullermd> vila: So, did the updated script/desc simplify anything in that bug, or just make it worse?
<vila> fullermd: haven't found the time to look at it :-/ (yet)
<fullermd> Oh, sure, a likely excuse.  I know you're just making up other things to do, to get out of having to go insane watching log shift around and laugh at you.
<vila> fullermd: truth is, diving into log is... scary, so I procrastinate ;)
<fullermd> You gotta get some minions.  Then you don't have to procrastinate, you just delegate.
<vila> nah, I think I prefer to procrastinate ;)
<fullermd> Is it a reasonable guess on my part that "log DIR" looks a lot like "log -v FILE" inside, that explaining the confluence of the two in showing the bug?
<vila> but so far, I just toyed with your script, next step is to turn it into a test to get access to all the needed internals/tools to better diagnose
<vila> inside ?
<vila> you mean in the log output ?
<fullermd> In the internals of how it chooses stuff.
<fullermd> Since "log DIR" shows the bug with/without -v, while "log FILE" only does it with -v (though the behavior without -v on FILE seems a little off too; that's another matter)
<vila> well, not sure from memory, but log -v is really different from the rest as it looks at the existing text revs
<vila> you may be triggering several bugs too
 * fullermd flexes his bug-triggering muscles.
<lifeless> fullermd: you mean 'starts typing' ? ;)
<fullermd> Hey, I can't deny my inborn gifts!  The gods want me to break software; who am I to demur?
<lifeless> indeed
<BjornT_> 
<mgrandi> bzr does not really give good errors when ssh stuff goes wrong >.>
<mgrandi> dunno if this is bzrs fault or paramiko
<fullermd> Well, most *nix places, paramiko won't be involved anyway.  It's more "spawning ssh", which really limits what you can say about the results.
<mgrandi> well was trying to dpush somewhere
#bzr 2012-11-07
<mgrandi> bzr is just hanging, git actually gave output from what ssh said (permission denied: publickey)
<mgrandi> although i think its something else cause now that the key is working bzr is still hanging haha
<thumper> ping bzr folks
<thumper> why did SmartServerStreamMedium suddenly need a timeout?
<thumper> especially when the default params for the derived classes are to pass through None?
<thumper> now it complains horribly if you don't specify one
<thumper> like my old code did
<fullermd> Maybe it was naughty?
<thumper> there is no indication in the methods what it should contain
<jam> thumper: I did the timeout stuff, I would happily merge a patch that set the default to None.
<jam> IIRC, at the time I did it, I wanted to make sure I audited all the callers
<jam> and there wasn't anywhere else in the code that was using it
<jam> I didn't realize it was being poked at externally.
<thumper> jam: :-) public api and all that
<hongyun> Hi, I set the ssh through http_proxy by using corkscrew. And add Host *.launchpad.net
<hongyun> ProxyCommand /usr/local/bin/corkscrew www-proxy.us.oracle.com 80 %h %p
<hongyun> User carolliu to ~/.ssh/config file
<hongyun> But I still can not push code to launchpad
<hongyun> Can anyone help me to see the problem?
<hongyun> Is there anyone meet this error?
<hongyun> bzr: ERROR: Connection error: curl connection error (SSL certificate problem: self signed certificate in certificate chain)
<hongyun> How to deal with it?
<jam> hongyun: you can try running 'bzr XXX -Derror' to get a traceback, but I don't quite understand why curl is involved in the above chain of events.
<jam> If you aren't logged into launchpad and are using 'lp:' urls, then we may be trying to connect to http://...launchpad.net to try and resolve the lp:
<jam> so you could try using 'bzr+ssh://' directly.
<hongyun> I try bzr+ssh://  ,but get an error
<hongyun> bzr: ERROR: Don't know how to handle SSH connections. Please set BZR_SSH environment variable.
<hongyun> I have already installed corkscrew
<jam> hongyun: if you are getting that, then you don't have an 'ssh' executable in your path
<hongyun> add Host *.launchpad.net  ProxyCommand /usr/local/bin/corkscrew www-proxy.us.oracle.com 80 %h %p User carolliu to ~/.ssh/config file
<jam> which I think is necessary to get it working with corkscrew.
<jam> Do you have 'openssh' installed
<jam> can you run just plain 'ssh bazaar.launchpad.net' ?
<hongyun> Displayed :  No shells on this server. Connection to bazaar.launchpad.net closed.
<hongyun> jam, do u know what's the problem?
<jam> hongyun: well that means ssh is working at least, you don't have a login shell on bazaar.launchpad.net
<jam> but you are able to connect to it, and your login with ssh keys is working.
<jam> hongyun: so try just doing "export BZR_SSH=openssh" and then see if you can do "bzr XXX bzr+ssh://bazaar.launchpad.net/...."
<hongyun> only openssh can work?
<jam> hongyun: bzr understands a few ssh providers, mostly we just need to know what the right parameters to pass to ssh are.
<hongyun> Displayed: bzr: ERROR: Unrecognised value for BZR_SSH environment variable: ssh
<jam> You can also do "BZR_SSH=sshcorp"
<jam> hongyun: there are a few specific ones (openssh, and sshcorp), otherwise you need to pass the full path to the 'ssh' file, like: "BZR_SSH=/usr/bin/ssh"
<hongyun> ok  I try it again
<hongyun> jam, nothing diaplayed after I use push command till now
<jam> hongyun: sounds like it is working, but I couldn't tell you for sure.
<jam> You can run 'ps' and see what processes are running (ps -ef is what I usually use)
<hongyun> other method can  prove bzr work correctly?
<jam> hongyun: if you tell me where you are pushing things, I can check if the data is there.
<hongyun> //bazaar.launchpad.net/~carolliu/carol-bzr-test/
<hongyun> When I run bzr push bzr+ssh command , it always halt
<jam> hongyun: there is a problem with the URL, as you need a project and a branch name, so something like bzr+ssh://bazaar.launchpad.net/~carolliu/+junk/carol-bzr-test
<fullermd> You could also just 'bzr ping' the URL, and make sure you're at least getting end-to-end communications out of it.  The plugin's cheap to grab on older versions.
<hongyun> Displayed error :bzr: ERROR: Unrecognised value for BZR_SSH environment variable: /usr/bin/ssh
<hongyun> I am sure ssh on my machine can work
<mgz> morning!
<jam> hongyun: can you give your bzr version? "bzr --version"
<jam> Supporting path-based ssh was a newer one.  Also 'ssh' information (ssh -v I believe)
<hongyun> Bazaar (bzr) 2.3.3
<hongyun> I install it on solaris
<mgz> that has BZR_SSH settable to a specific path, but not the solaris ssh fix maybe?
<hongyun> So I must install openssh?
<jam> mgz: I don't see "solaris" mentioned in release notes past about 1.18, though it may not be mentioned in that form. Do you know what the patch is?
<mgz> trying to find it in my mail archive but failing currently
<hongyun> I can checkout code from launchpad.net . But can not push code
<mgz> question 105156 has some info
<mgz> and links bug 544786
<ubot5> Launchpad bug 544786 in Bazaar "handle sunssh " [Low,Confirmed] https://launchpad.net/bugs/544786
<mgz> which isn't fixed... so it seems either using sunssh as openssh or installing real openssh is what people have done in the past
<jam> hongyun: according to https://answers.launchpad.net/bzr/+question/105156 the issue is that Solaris has different output for "ssh -v" but if you set "BZR_SSH=openssh" it will still work.
<jam> We just fail to auto-detect the ssh vendor because of changes in Solaris.
<hongyun> ok  I try
<mgz> going by bug 374700 it would not be hard to contribute a branch fixing it
<jam> mgz: we only need the vendor type to pass the right parameters, and if sunssh is a fork of openssh, it is likely to accept the same params.
<ubot5> Launchpad bug 374700 in Bazaar "Add support for GNU lsh to ssh.py" [Medium,Fix released] https://launchpad.net/bugs/374700
<mgz> jam: indeed.
<hongyun> woo, It works . Thanks jam and mgz
<jam> hongyun: can you add the output of "ssh -V" (or ssh -v) to bug #544786?
<ubot5> Launchpad bug 544786 in Bazaar "handle sunssh " [Low,Confirmed] https://launchpad.net/bugs/544786
<jam> It is hard for us to fix things like that on platforms we don't have access to.
<hongyun> OK , no problem
<Lo-lan-do> Hi all
<Lo-lan-do> I'm working on adopting the loggerhead package, but I'm encountering problems.
<hongyun> Only this displayed :
<hongyun> ~$ ssh -V
<hongyun> Sun_SSH_2.0, SSH protocols 1.5/2.0, OpenSSL 0x100000af
<hongyun> Does it help?
<Lo-lan-do> Loggerhead uses the YUI library, but the embedded copy is very old (3.0.0pre2 or something), and it should be ported to current YUI 3.5.
<Lo-lan-do> Would anyone care to help?
<mgz> Lo-lan-do: there may be some interest or more info in #launchpad on that front, though probably US timezones
<Lo-lan-do> Apparently launchpad still uses the old one too.
<Lo-lan-do> But I'll try there.
<Lo-lan-do> Thanks :-)
<mgz> launchpad have recently done various updating of yui libraries
<mgz> and the main launchpad code was moved to 3.5 by rick_h
<mira|AO> when I do a 'bzr dpush' into git, can the git side be updated later, when there are new commits and merges on the bzr side?
<mira|AO> (assuming it doesn't *also* fail, like git cloning from bzr and bzr pushing into svn doesâ¦)
<Lo-lan-do> You can bzr dpush again, yes
<Lo-lan-do> I regularly do that :-)
<mira|AO> ok
<mira|AO> maybe this is the way out of my current problem then, unless someone steps up and fixes bzr-svn â»
 * mira|AO crosses fingers (itâs been âupdating git mapâ for >2 hours already)
<Lo-lan-do> loggerhead_1.19~bzr477-1_amd64.changes ACCEPTED into unstable
<Lo-lan-do> (Without the YUI3 hackery, I suck at Javascript)
<Lo-lan-do> mira|AO: You wouldn't have JS geeks at your place, would you?
<mira|AO> nope, sorry
<mira|AO> we're also all trying to scrape along
<mira|AO> but if you /msg me some details, I can ask around on the dev list
<mira|AO> bzr: ERROR: The file id "None" is not present in the tree <bzrlib.inventory.CHKInventory object at 0xd7d4550>.
<mira|AO> â¹ so dpush also doesn't work
<mira|AO> ok, last tryâ¦ upgrading all svn related stuff (yuk 1.7)
<mira|AO> ok, didn't work either with latest suckvÃ¼rstchen/subvertpy
<mira|AO> latest as in debian sid
<jelmer> svn 1.7 changes the working copy API in a backwards incompatible (but ABI compatible) way
<mira|AO> yeah
<mira|AO> I'm mostly concerned about getting a bzr bound checkout pushed into either svn or gitâ¦
<mira|AO> bbl, lunchbreak
<jelmer> mira|AO: the exception you were seeing (The file id "None" ...) has to do with the mappings in bzr-svn, unrelated to the svn version
<mira|AO> the 'file id is None' is actually in bzr-git
<mira|AO> (both ways)
<mathrick> hola
<mathrick> I don't suppose bzr-lp supports multiple logins, does it?
<mgz> it does, but with different bzr homes
<mgz> so, you can have multiple configs and set BZR_HOME to change between them
<maxb> Or you can just 'bzr lp-login foo' back and forth
<mathrick> oh right, it uses the ssh key
 * mirtwo tries: (gdb) b PyErr_NewSubversionException
<mirtwo> maybe I can get a useful bt
<mirtwo> oh well. I get a bt...
<mirtwo>  http://sprunge.us/SOiJ
<jlf> hi #bzr, is there a way i can find out what commit last affected a specified line in a specified file?
<jelmer> jlf: hi
<jelmer> jlf: 'bzr annotate FILE' should tell you
<jlf> jelmer: ah, perfect.  thanks very much.
<mathrick> pffft, "annotate" is PC-speak
<mathrick> I always call it bzr blame
<mirtwo> blame is git speak
<mirtwo> oh no, svn speak
<mirtwo> anyway, worse
<mirtwo> can't decide which
<mirtwo> hrm. putting debugging printfs into editor.c in subvertpy didn't help...
<mirtwo> so I now got this backtrace, but... still no further
<mirtwo> not easy to figure anything out like that
<mathrick> mirtwo: I don't care if it's svn speak, it's accurate
<mira|AO> I prefer to not blame people, it's the wrong state of mind in a team
<jelmer> Lo-lan-do: thanks for taking over loggerhead!
<Lo-lan-do> jelmer: Bleh :-)
<Lo-lan-do> Is anyone active upstream, by the way?
<Lo-lan-do> (So I could push my quilt patch their way)
<jelmer> Lo-lan-do: lp:launchpad, you mean?
<mira|AO> lo-lan-do: could be worseâ¦ look at what mess I got into, just for the forgeâ¦
<jelmer> Lo-lan-do: you can propose it as a patch on Launchpad
<mira|AO> hint: the mess uses wfSuppressWarnings() a lot
<Lo-lan-do> mira|AO: Hahaha :-)
#bzr 2012-11-08
<mgz> morning!
<mira|AO> moien
<lolek> hello all
<mgrandi> hello
<lolek> i'm looking for some documentation about, how to supply username aand login for bzr-svn ?
<mgrandi> to access a svn server?
<lolek> yes
<mgrandi> im not an expert on bzr-svn, im not sure if you can do that
<mgrandi> but i may be wrong
<lolek> well, the problem is that from the error stack trace it seems that bzr is using my system login, and system password
<lolek> so there must be some way to use another one
<mgrandi> hmm.
<mgrandi> http://stackoverflow.com/questions/3166189/how-to-save-subversion-password-with-bzr-svn
<mgrandi> maybe authentication.conf?
<lolek> ok
<lolek> next question, where authentication.conf should be placed cause i don't have that file in: ~/.bazaar
<mgrandi> pretty sure in ~/.bazaar
<mgrandi> http://doc.bazaar.canonical.com/developers/authentication-ring.html#file-format
<lolek> ok and how can i force bzr to use that file, cause it's ... not using it :/
<mgrandi> well it should, are you sure the host is the same in the conf and the host you are connecting to?
<lolek> yes
<mgrandi> are yo using the latest version of bzr-svn?
<lolek> Version: 1.2.1-1
<lolek> ok, that's weird
<lolek> with qbzr it's asking me for a password, but still using the wrong login :/
<mgrandi> hmm, i feel like its something silly but im not the expert
<mgrandi> jelmer, are you here :o
<mira|AO> it's easier to just use ssh keys
<lolek> yes i agree, but i don't have that option
<lolek> i can only use svn providing login and password
<lolek> nothing more
<mira|AO> the username's normally in the URL
<mira|AO> for svn
<mgrandi> bzr branch <scheme>://<user>:<password>@host:port/path
<lolek> ok, that's working
<lolek> but i'd like to stre it's in authentication.conf
<lolek> it should be working
<mgrandi> yeah, not sure why its not working with that file
<LarstiQ> lolek: if you login with plain 'svn', svn should cache that and bzr-svn will pick up on it, iirc
<lolek> LarstiQ: hmm ok, i've read about that, but the problem is that i don't use plain svn login, i do login only from inside eclipse with svn plugin
<LarstiQ> lolek: you could try logging in once, as a workaround?
<LarstiQ> using something like `svn info` to not do actual work
<LarstiQ> or much of it anyway
<lolek> hmm
<lolek> LarstiQ: ok, i've tried
<lolek> and it seems that it gets login from cache
<lolek> but it have some problem with password
<lolek> LarstiQ: look here: http://pastebin.com/e2pJb3qR
<lolek> password contains only ascii characters
<LarstiQ> lolek: heuh
<lolek> :D
<lolek> i knew you'd love this :D
<LarstiQ> lolek: next thing I'd do is maybe check bzr/bzr-svn versions and/or see if there any similar bugs on launchpad
 * LarstiQ prepares for his Galois Theory course
<mgrandi> its not necessarily because you have invalid characters, its just a python 8 bit string vs a unicode string
<mira|AO> oh yes, python, the only modern language with a default 7-bit safe string type
<mira|AO> and py3k doesn't improve on it
<mgrandi> python3 strings are unicode
<mgrandi> by default
<mira|AO> that doesn't mean you can print them :D
<mgrandi> thats not python's fault
<mira|AO> that's a matter of opinion
<mgrandi> i cant print weird strings on windows cause the console is CP1257 or whatever
<mgrandi> and you can't convert it
<mgrandi> how would you print the character if the character encoding its outputting doens't have said character?
<mira|AO> by defaulting to a reasonable encoding
<mira|AO> (even on windows, since 1991 the console can do Unicode)
<mgrandi> windows doesn't have a 'reasonable' encoding haha
<mgrandi> can it? ive had this problem on other languages
<mgrandi> what encoding type is that
<mira|AO> yeah, just use the API with a W on the end
<mira|AO> UTF-2LE
<mira|AO> erm no
<mira|AO> UCS-2LE
<mgrandi> i mean the windows..encoding
<mira|AO> so, just the BMP, normally
<mgrandi> or what codepage is it
<mira|AO> you've got two APIS with, in the case of the console, three encodings
<mgrandi> thats what the console uses
<mira|AO> one is the API with the A at the end, which uses the "ANSI" encoding (often cp1252)
<mira|AO> then there's the OEM encoding (often cp437 or cp850)
<mira|AO> then there's the API with the W at the end, which uses UCS-2LE
<mira|AO> codepages map between A and W
<lolek> ok guys guys guys
<lolek> there are no character outside the standard ascii
<lolek> in my password
<lolek> so this is weird why it's complaining about.. unicode
<mgrandi> because the object itself is not a unicode object
<mgrandi> aka a bug or something else is going wrong
<mira|AO>    I set up the cmd window to use Lucida Console font (and you should do it too, otherwise any attempt
<mira|AO>    to see Unicode characters in it is bound to fail!). I realized that it is possible to print wide
<mira|AO>    strings directly to the console using functions from conio.h (_cputts, _tcprintf, etc.). Very nice!
<mira|AO> like that, it can work
<mgrandi> ive tried that but it still doesn't work
<mgrandi> and python should see the default code page and adjust to it
<mgrandi> what code page do you change it to?
<mgrandi> never mind, apparently it doesn't matter? (windows encoding sounds like a cluster****)
<mira|AO> WriteConsoleW also would work
<mgrandi> that does seem to work
<mgrandi> but i dont think that its still python's problem, since you fix it when you change fonts on cmd.exe, nothing on python changes
<mira|AO> AUF DROGEN ODER WAS?
<mira|AO> oops
<mira|AO> sorry, just found someâ¦ disgusting code
<mira|AO> and forgot I had /query on
<mgrandi> like, in "terminal" font, the same python session, gives me
<mgrandi> 'garbled characters
<w7z> lolek: the get_svn_simple callsite in bzr-svn is misusing the bzr ui, by passing a str not a unicode type
<w7z> but the point is you don't want it prompting for a password right? I suspect you have your creds wrong so it's falling back to asking you again.
<w7z> lolek: `bzr version` will tell you where to put authentication.conf and check .bzr.log after connecting to see if it works
<w7z> I'd avoid putting the username and password in the url
<lolek> hmm
<lolek> w7z: well i see in the log that it's using the proper login... but i don't see anywhere in bzr.log that it's reading authentication.conf
<w7z> ...does it say it connects and does stuff? if so, problem solved, right?
<lolek> it's : Obtaining username and password for SVN connection (see only login) and then the error: http://pastebin.com/e2pJb3qR
<w7z> okay, so it's not getting the values from the conf file then.
<lolek> uhm
<lolek> but the question is... why ?
<lolek> of course if i put login/password into url it's working ok
<w7z> paste your conf with the password xxxed out?
<lolek> k
<lolek> http://pastebin.com/MxwVkTDi
<w7z> looks okay, maybe bzr-svn just doesn't check
<w7z> file a bug against bzr-svn with your traceback and I'll put up a branch that fixes it
 * mira|AO eyes âbranch that fixesâ
<w7z> jelmer or vila might know more about svn/auth specifics
<lolek> ok, where do you want me to fill a bug ?
<w7z> bugs.launchpad.net/bzr-svn
<lolek> w7z: https://bugs.launchpad.net/bzr-svn/+bug/452121
<ubot5> Ubuntu bug 452121 in Bazaar Subversion Plugin "Putting svn password in authentication.conf doesn't work" [Undecided,Fix released]
<lolek> hmm
<lolek> https://bugs.launchpad.net/ubuntu/+source/bzr-svn/+bug/532292 <- similar
<ubot5> Ubuntu bug 532292 in Bazaar Subversion Plugin "Doesn't get user/password details from authentication.conf" [Medium,Fix released]
<lolek> lol
<lolek> maybe i should wait for new bzr-svn version ?
<w7z> no, different bug
<w7z> but, you should be able to put the details in the config file and have it work
<w7z> the prompt should not happen at all if it can get the values from your config
<w7z> do you only get prompted for the password, or did you type something else in first?
<vila> w7z: sorry, my memory is fuzzy on that topic. The most common answer I remember is: connect with svn first as it will cache the credentials and bzr-svn can then rely on that
<vila> i.e. auth.conf is not used
<lolek> w7z: erm... i don't have any prompt
<lolek> w7z: i just do: bzr update and i get this error
<lolek> no prompt for password
 * jelmer waves
<vila> I'm not sure 'svn' is a valid scheme though (jelmer ?)
<vila> (for auth.conf that is)
<jelmer> I don't think I've ever seen (or tested) authentication over svn://
<jelmer> I don't see why it shouldn't work, but I don't think I've ever tested it.
<jelmer> lolek: ^
<lolek> lol :)
<lolek> that would explain the problem :)
<jelmer> lolek: It shouldn't really be different from http/https though, and those *do* work
<jelmer> I aguely recall there were some issues with the authentication interface being inconsistent about whether it expected unicode or byte strings, perhaps that's related.
<jelmer> *vaguely
<jelmer> what versions of bzr/bzr-svn are these?
<lolek> bzr: Version: 2.5.0-2ubuntu2
<lolek> bzr-svn: Version: 1.2.1-1
<w7z> lolek: okay, can you try a few debug things for me?
<lolek> w7z: i'll do my best
<w7z> #1: with your authentication.conf in place, run `bzr -Dauth branch svn://YOURDETAILS` and look in .bzr.log for a "Using authentication section" line
<lolek> ok,
<lolek> the is not such: Using authentication section in the bzr.log
<w7z> okay, so that's straight up not being matched
<w7z> so, either there's a bug in how bzr-svn uses AuthenticationConfig, or you have the conf file in the wrong place, or the details don't match up
<w7z> try adding a section that's just [something] with a username and password set underneath, then branch any (non svn) url with that -Dauth flag and see if that message then appears
<w7z> without scheme/host/port/path it should match anything
<lolek> ok, give me a second
<w7z> also, you still need to file the bzr-svn bug with your traceback? I don't see it.
<lolek> ok, that's working
<lolek> when i placed: [something] with only user/pass it was working
<lolek> ok, i'll fill it up :)
<w7z> and you got the line in .bzr.log?
<w7z> did you try branching your svn thing, or another random branch?
<lolek> yes there is line: using authentication section :  'something'
<w7z> I wonder if just the scheme matching is broken or something
<lolek> i tried to branch svn thing
<w7z> okay, so, try adding back in the host, then the port, then finally the scheme
<lolek> ok
<w7z> see which one makes it break again
<lolek> give me a minute
<lolek> it's ... port directive
<w7z> fun...
<lolek> yeah
<w7z> so, with the scheme and the host it works, but plus port then doesn't?
<lolek> when i added port=... it goes with the error  (pass is not unicode..)
<lolek> correct
<w7z> great, I can imagine the bug now
<w7z> "3690" != 3690 I bet
<lolek> hmm
<lolek> ok, give me second
<w7z> so, for you right now, just omitting the port is fine
<w7z> but can I request two bug reports from you
<w7z> one for the password traceback against bzr-svn
<w7z> and one against bzr for the autentication.conf section not matching when you supply a port
<lolek> but the password traceback is only visible when the port directive is given
<lolek> there is no problem if there is no port directive :)
<lolek> aaa ok
<lolek> i understand, ok
<lolek> https://bugs.launchpad.net/bzr-svn/+bug/1076386
<lolek> here
<ubot5> Ubuntu bug 1076386 in Bazaar Subversion Plugin "bzr-svn password is not a unicode string when given port directive" [Undecided,New]
<lolek> https://bugs.launchpad.net/bzr-svn/+bug/1076388
<ubot5> Ubuntu bug 1076388 in Bazaar Subversion Plugin "bzr-svn authentication.conf is not readed when port directive is given" [Undecided,New]
<w7z> thanks lolek!
<lolek> you welcome :)
<lolek> ok, i'm going... bye :)
<lolek> thx for helping me out :)
<jetsaredim> is it possible to create a branch based on the tree of a certain release of a given package?
<jetsaredim> like - i want to try to fix something in a quantal package but there is already a raring version of the same
<jetsaredim> so i'm assuming if i just branch the project it will give me the raring version
<mgz> you can branch lp:ubuntu/SERIES/PROJECT instead of lp:ubuntu/PROJECT
<jetsaredim> i seem to be getting an error with bzr
<jetsaredim> http://paste.ubuntu.com/1342817/
<mgz> jetsaredim: you don't have ssh configured correctly or haven't given launchpad the right ssh key
<mgz> use `ssh -vv YOURLPUSERNAME@bazaar.launchpad.net` to debug, it's not a bzr related problem
<jetsaredim> mgz: this would be the key I uploaded to launchpad vs my gpg key locally?
<mgz> jetsaredim: this is your ssh key, from ~/.ssh, which is a different thing from your gpg key. see https://help.launchpad.net pages for walkthrough
<jetsaredim> ahh - much better
<jetsaredim> so - once i download the release-based tree for a given package i can then branch it locally for my own changes?
<w7z> jetsaredim: see <http://developer.ubuntu.com/packaging/html/patches-to-packages.html> for details
<w7z> be a little careful with terms 'tree' and 'branch', they mean specific things for bzr, <http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/core_concepts.html>
<w7z> also you need to go through the SRU process for quantal, so might want to check in #ubuntu whether the change you're planning is suitable for that, see <http://developer.ubuntu.com/packaging/html/security-and-stable-release-updates.html>
<jetsaredim> w7z: its a pretty simple change to the build config
<jetsaredim> and its already in raring
<w7z> that doesn't sound security or serious data loss related
<jetsaredim> the package is broken for certain functionality due to a config option not being set
<w7z> jetsaredim: try asking in #ubuntu-devel
<delinquentme> is there some reason that I need to pass a --no-strict .. to push to a parent when I've got locally uncommitted changes?
<mathrick> hmm, I have a colocated project created on windows, which I just zipped and unpacked on linux
<mathrick> and I can't get it to work, since it can't find the repo/branches with differing absolute paths
<mathrick> http://pastebin.com/JwMDwvpK
<mathrick> how do I fix it?
#bzr 2012-11-09
<vila> mathrick: file a bug and find jelmer ;) There is probably a text file you can edit somewhere which contains the windos path.
<jelmer> mathrick: is this with the core bzr support for colocated branches, or with bzr-colo ?
<mathrick> jelmer: I dunno, 2.5.1, created via bzr-explorer with "colocated workspace" option
<jelmer> mathrick: ah, that's the bzr-colo plugin
<jelmer> mathrick: please file a bug, but against the bzr-colo project on Launchpad
<mathrick> is that really a bug in bzr-colo?
<vila> jelmer: well dodged ;)
<vila> mathrick: more or less
<jelmer> vila: :-)
<mathrick> OK, how should I describe it? Since I have no clue how that is a problem with bzr-colo and not bzr reconfigure for instance
<vila> mathrick: zip is not a transport supported by bzr ;) So you run into some absolute paths that may be better handled as relative (but obviously are  not (yet ?))
<vila> mathrick: what you explained here is good enough: zipped on windos, unpacked on linux
<vila> mathrick: it may be interesting to see if the reverse breaks in the same way (zipped on linux, unzipped on windoz)
<vila> dows
<vila> damn tyops
<mathrick> vila: I understand that, what I don't understand is how bzr-colo breaks things. Bzr reconfigure should be able to change that path
<vila> mathrick: well, the point is that bzr-colo doesn't really break things, it assumes the working trees/branches/repos would stay on the same files system (roughly)
<jelmer> mathrick: bzr-colo stores an absolute path to the colocated branch, rather than a relative one; bzr reconfigure tries to open the old branch when it reconfigures I think
<mathrick> that is a problem with reconfigure then, no?
<vila> mathrick: I suspect that there should be some way to bzr-colo push instead of zip/unzip that should work
<mathrick> yes, there is
<mathrick> I just didn't remember I made it collocated when I zipped
<jelmer> mathrick: bzr-colo should be storing a relative path
<vila> mathrick: bzr reconfigure assumes it starts with a "correct" context, it may be worth filing a different bug for that
<jelmer> mathrick: you might be able to use --force to get reconfigure to ignore the old code
<mathrick> ah, I didn't notice --force wasa thing
<vila> jelmer: good point (dunno if this will work but it should ;)
<mathrick> nope, --force only seems to influence potentially losing local changes
<vila> but in this specific case, if the branch is required, it's hard to ignore it
<vila> mathrick: you tried or you just read the --help ?
<mathrick> tried
<vila> thanks
<vila> mathrick: did you try to grep for that path under .bzr ?
<mathrick> no, but I expected to be able to change it by hand
<mathrick> I was asking for the proper way
<vila> mathrick: for this case, I doubt there is one (or that would be bzr-colo push)
<fullermd> Pfft, proper.  What fun is that?
<vila> mathrick: but really, as jelmer said, bzr-colo should use a relative path (that may not be enough but should help anyway)
<mathrick> vila: bzr-colo push is "how do I transport it properly?". But I didn't, and now my question is "how do I fix it?". Bzr reconfigure *should* be able to fix that, and I will file a bug too
<vila> mathrick: worth a try, but if there is a single place where the branch path is defined and it's broken, bzr reconfigure can't guess the right one
<mathrick> why not? bzr info tells me what the checkout thinks the source branch is. That is what bzr reconfigure is supposed to change; if it tries to open it before changing, it's kinda useless for fixing things
<vila> mathrick: it can avoid opening it (it's broken after all) but what will it use instead of that broken path ?
<mathrick> the one I give it in --bind-to?
<vila> mathrick: oh, well done !
<vila> for this specific case indeed, not sure if the code will make it easy to implement but file-a-bug++
<mathrick> done, bug #1076809 and bug #1076810
<ubot5> Launchpad bug 1076809 in bzr-colo "Copying collocated branches Windows and Linux broken by absolute paths" [Undecided,New] https://launchpad.net/bugs/1076809
<ubot5> Launchpad bug 1076810 in Bazaar "bzr reconfigure can't fix dangling paths" [Undecided,New] https://launchpad.net/bugs/1076810
<vila> mathrick: thanks
<mathrick> sure
<vila> fullermd: linked a branch with reproducing failing tests for bug #1072513, one step closer to diagnosis ;-p
<ubot5> Launchpad bug 1072513 in Bazaar "log can show too few revs" [High,New] https://launchpad.net/bugs/1072513
<vila> fullermd: you may want to look at the intermediate commits to see how I get there from your script (including revno 6515 where 'bzr test-script ./bzrlib/tests/blackbox/log_bug_1072513.sh  --null-output' was passing)
<vila> fullermd: the missing feature still being to be able to keep the built env to toy around manually with the results :-/
<vila> but at least the syntax should be copy/pastable enough for you to tweak
<mgrandi> is there a preferred way to backup a repository to a file, or is just zipping the directory pretty much
<vila> mgrandi: <cough> ask mathrick ;)
 * mgrandi asks mathrick
<vila> mgrandi: if you really want a *backup* 'bzr push' should be the fastest
<mgrandi> im just sending my code to someone, including the repo for archival purposes
<vila> mgrandi: sorry, that a was a joke, mathrick just ran into an issue while zipping on windows and unzipping on linux (special setup where an absolute path has been recorded)
<mgrandi> interesting o.o
<vila> mgrandi: same os on the receiving side ?
<mgrandi> stack overflow says this; http://stackoverflow.com/questions/1976857/bzr-create-tgz-file-containing-full-repository
<mgrandi> might not be
<vila> bzr send is safest
<mgrandi> what does bzr send actually do? generate patch files?
<mgrandi> so this just creates a series of patch files or something?
<vila> mgrandi: almost, they are called merge directives and contains both the revisions and a human-readable patch
<vila> mgrandi: it's not lossless as patches can, you get the real revisions
<mgrandi> interesting, thanks
<vila> mgrandi: the idea is that send accept a public url readable by both sides and create the delta between your branch and the public branch
<vila> mgrandi: so it can be *far* smaller than zipping the whole repo (like the stackoverflow recipe suggests)
<mgrandi> yeah, this isn't a problem here but i was just curious
<vila> mgrandi: the recipe basically uses an empty branch as a starting point
<mgrandi> so are there problems with zipping a bzr branch directory and then using it on a different os?
<vila> mgrandi: not a bzr branch, a bzr-colo environment (plugin)
<mgrandi> isn't that integrated into bzr now?
<vila> there is wip about native colocated branches yes, that's different
<mgrandi> but normal branches should be fine? besides the whole symlinks thing
<mgrandi> that i still need to work on...
<vila> yes
<vila> but it's been a looong time since I did that myself, most of the machines I'm working on have ssh and bzr so it's easier to kust push ;)
<vila> *just
<fullermd> Obviously, the solution is that somebody needs to donate vila a machine without ssh or bzr on it, to force him to work on it   :p
<vila> fullermd: the last case was a windows vm where I managed to install ssh as a service anyway ;)
<fullermd> I've probably got some OS/2 install media somewhere...
<vila> fullermd: and if they don't have ssh but bzr, well, it's easy enough to pull instead of pushing ;-)
<fullermd> vila: So, wait, you already fixed it, then re-broke it?  I mean, if the test was passing, that means everything's good, right?   :p
<vila> hehe, that's where the test scripts shine: they can express failure more easily ;)
<fullermd> 'druther they expressed success   ;p
<vila> tsk, tsk, they allow success to be *demonstrated*, that's TDD for you ;)
<fullermd> I dunno, TDD sounds like something I'd discuss with my doctor in a hushed voice.
<mgrandi> depends on who you ask. they really beat it into us at my school
<mgrandi> =P
<fullermd> Well, yes, I remember that from high school too, but...
<mgrandi> unit test ALL THE THINGS
<vila> Alzheimer, Pratchett and I.. what was it I wanted to say...
<mgrandi> so vila, i just tried that recipe out, and it seems useless cause you can't merge the file back into an empty repo =/
<vila> ha yes, tests are good substitute for failing memory
<jelmer> mgrandi: you can pull it into an empty repo though
 * jelmer wonders if vila is in the US
<fullermd> I do wish I had regression tests for stuff at work.  Sadly, I've never heard a good story for writing something useful considering the depth of stuff that breaks.
<vila> jelmer: hehe, no ;)
<jelmer> ... or just up late :-)
<mgrandi> then the documentation for send is slightly out of date
<vila> jelmer: yeah :-} Bad vila, go to sleep
<mgrandi>  `bzr send` creates a compact data set that, when applied using bzr merge, has the same effect as merging from the source branch.
<fullermd> No, but using it to replicate whole histories is out of the scope of the docs.
<mgrandi> well it should still be mentioned that pull can be used as well
<fullermd> And it does; merging the source branch into a branch with no history will also fail  ;p
<mgrandi> 'using bzr merge or pull, has the same effect etc
<vila> mgrandi: that's supposed to work, there may be a bug for *empty* branches (worth filing too, I thought we nailed down all the empty-branch-are-special ones...)
<mgrandi> well it specifically gave a bug url when i tried to do it
<vila> which one ?
<mgrandi> bzr: ERROR: Merging into empty branches not currently supported, https://bugs.launchpad.net/bzr/+bug/308562
<ubot5> Ubuntu bug 82555 in Bazaar "duplicate for #308562 Merging to an empty branch doesn't work" [High,Confirmed]
<mgrandi> dang 5 years, old bug
<vila> helllo, someone remember the shortest workaround for that ?
<vila> 'bzr init . ; bzr pull <merge-directive>' ?
<mgrandi> well yeah thats what i did
<vila> good, my job here is done ;)
<mgrandi> is that merge into empty repo a particuarly hard bug?
<fullermd> I've never been quite clear as to what it's even supposed to _mean_.
<mgrandi> probably along the lines like, its trying to merge two histories but one doesn't exist so it breaks?
<fullermd> Yeah, the whole point of merge is "take these two separate things and bring them together", so how's it even meaningful to talk about when there's only one thing?
<vila> I think the issue is about root-ids (branches of the same project shares a unique id for their root)
<mgrandi> well, it still seems to me that bzr should be smart about that, and if one history just doesn't exist, then just take the other one
<vila> the first branch of a project gets a new root-id which is then duplicated
<vila> mgrandi: devil is in the details
<mgrandi> i imagine
<vila> the fact that it's a corner case rarely encountered didn't help raise the bug importance
<vila> most of the issues are probably already solved, time is lacking for that one
<fullermd> Well, taking the other one is "pull"  ;p
<fullermd> If I wanted "merge" to sometimes silently do a "pull" instead, I'd use git...
<mgrandi> haha.
<mgrandi> maybe the error message should be updated to say 'try pull instead?"
<gmarkall> i'm having trouble rebasing a branch. I'd like to rebase the last five revisions onto another branch, but i can't seem to work out how to tell bzr that's what i want to do - i only seem to be able to rebase "all but the last 5" with -r last:5. Is there a way to do this please?
<bob2> you mean you're using bzr-rewrite?
<gmarkall> (if I don't specify a revision then bzr wants to rebase 54 revisions, which includes a lot of duplicate changes)
<gmarkall> bob2: i think i am
<gmarkall> bzr help rebase says "From: plugin "rewrite""
<lifeless> gmarkall: you might try -r -5:..
<gmarkall> lifeless: that gives me "Bzr has encountered an internal error..." - shall I submit a bug report?
<lifeless> sure
<fullermd> Without the colon, probably...
<lifeless> oh heh, yes.
<lifeless> EOUTOFPRACTICE
<lifeless> gmarkall: -r -5..
<gmarkall> ah, that didn't crash bzr! :-)
<gmarkall> I managaed to get the crash down to a small example: https://bugs.launchpad.net/bzr/+bug/1076894
<ubot5> Ubuntu bug 1076894 in Bazaar "Invalid arguments to rebase cause internal error" [Undecided,New]
<gmarkall> I managed to choose the correct revisions with the syntax suggested by lifeless/fullermd - however, when i run with --dry-run, the commit ids that it shows are printed out-of-order - is that to be expected?
<gmarkall> when i actually did the rebase, the commits were applied in the correct order
<mgz> morning!
<tbf__> can i tell bzr to just commit the changes of a conflict free merge?
<tbf__> constantly forgetting that commit and then messing up stuff
<tbf__> (well, also lack the creativity to invent merge commit messages)
<tbf__> ok. why would "bzr diff ../parent" show changes that a plain "diff -ru ../parent" doesn't see?
<tbf> apparently i still fundamentally fail in understanding things
<mgz> tbf: could be lots of reasons for the diff not being the same, fundamentally those two commands look at different stuff
<mgz> so, for instance, if the working tree of ../parent is not up to date, plain recursive diff will not see the later revisions
<tbf> mgz, ../parent is up-to-date
<tbf> mgz, at least the output of "bzr status" and "bzr diff" in ../parent is empty
<tbf> mgz, seems i seriously fail to understand even the basics of  bzr: http://nopaste.me/paste/111230873509cce1382789
<tbf> mgz, how can it be, that rev 334 contains changes from 316.1.64, while rev 333 is entirely empty?
<tbf> 316.1.64 is the last commit in that merge
<tbf> i'd only expect to see that change in 334 if i'd reverted 316.1.64 by accident while commiting 333
<mgz> ...that paste site is borked, gives 406 + error fallout based on UA string
<mgz> tbf: from that log, I'm not sure what's suprising you
<tbf> mgz, the output of "bzr diff -c 334 debian/control" entirely surprises me
<mgz> the diff for -r331..332 is empty, but the log above stops at 332 so that might be right, and 316.1.64 was merged in 333
<mgz> tbf: that command isn't in the paste
<tbf> mgz, line 51
<tbf> mgz, rev 333 already should have that change, but bzr shows it was applied again in 334
<mgz> I suspect you have some funny history
<mgz> you remerged the same branch in 334?
<tbf> mgz: forgot to commit a merge, shelved the mess. merged from parent again, unshelved.
<tbf> expecting that only the really new changes would get applied
<tbf> now bzr even crashes when accessing that branch
<tbf> great.
<mgz> okay, so the history and log/diff output is probably correct
<tbf> apparently "bzr switch -r 333" was a stupid idea
<tbf> mgz, how that?
<mgz> r333 includes the merge, and the history of the other branch, but none of the actual changes
<mgz> which you shelved, then committed in 334
<mgz> so, log tells you 333 merged stuff, but diff only sees the changes when you actually committed them in 334
<mgz> the best thing to get out of trouble here is just make a new branch from 332 and do the merge right this time
<tbf> mgz: "r333 includes the merge, and the history of the other branch, but none of the actual changes" - this makes absolutely no sense to me.
<tbf> maybe too much in git mind set. what stone i don't see?
<mgz> you merged the history from the other branch
<mgz> but left the actual text changes uncommitted
<mgz> it's the same as doing that in git.
<tbf> well. in git i usually rebase
<tbf> and stay away from merges
<tbf> too much vooodo
<tbf> voodoo and magic
<mgz> you like having a nice linear world view :)
<tbf> mgz, yup :-)
<mgz> anyway, the point of version control is you have the old stuff still
<mgz> so you can just start from where you were originally and do it right, rather than trying to fix up the current state
<tbf> mgz, sure. still at the point of merging a feature i don't care about the dirty details anymore
<tbf> all that merging zig-zack and so on
<mgz> look, it's easy, do this:
<tbf> as long as i work on the features i highly appreciate having different branches and switching between them comparing them, letting them divert, pick changes and so on...
<tbf> ...but once it is done. it is done.
<mgz> cd .. && bzr branch -r332 old new && bzr merge -r 332.. -d new ../old
<mgz> you then have a new branch, with the just the text changes you made in the last few revs ready to commit, and no hisotry to confuse you
<mgz> you could bring in the original feature branch as a merge to make the history correct, but you probably don't care about that
<mathrick> so how do install libraries needed by plugins in a standalone windows install?
<mathrick> I thought it was $plugindir/lib/, but that doesn't seem to work
<mgz> mathrick: what I did was use not use the windows standalone installers but the python ones and install all the plugins and bits I wanted via the normal setup.py method
<mgz> there was a thing added for the standalone ones to look in another location for libs though
<tbf> mgz, checking what this does...
<mathrick> mgz: I tried that before, but it's a huge PITA really and never works quite as well as the standalone installer
<mgz> mathrick: try
<mgz> $ BZR_PDB=1 bzr assert-fail
<mgz> (Pdb) sys.path
<mgz> which will tell you where the installed bzr looks for stuff
<mathrick> ah, good idea
<mathrick> ah, so site-packages has been added
<lolek> hello all
<lolek> a question, i've installed bzr-eclipse, and i'm looking for option: compare with latest from repository ... that is available when using svn but with bzr repo ?
<lolek> hmm ok, forget the question, found it, but the is only: compare with latest from branch, what if i want to specify revision ?
<jelmer> lolek: I don't think bzr-exclipse is anywhere near usable, is it?
<lolek> well ... it is
<lolek> :)
<lolek> and oh one thing
<lolek> regarding this: https://bugs.launchpad.net/bzr-svn/+bug/1076388, i've used svn:// when gave url :)
<ubot5> Ubuntu bug 1076388 in Bazaar Subversion Plugin "authentication.conf section does not match when port is given" [Undecided,New]
<jelmer> lolek: not sure I follow?
<lolek> oh.. sorry my fault... mind shortcut
<lolek> forget ;d
<mirtwo> TBF!
<mirtwo> boah ist die welt klein
<jelmer> lolek: sorry, me too :-)
<lolek> mirabilos|work: could you please speak in english ?
<mirabilos|work> yes
<mirabilos|work> âthe world is smallâ
<lolek> thank You ;)
<mirabilos|work> tbf was one of the first people I met on IRC, bÌ²eÌ²fÌ²oÌ²rÌ²eÌ² I even spoke something resembling English
<tbf> hey mirabilos|work
<lolek> uhm
<tbf> mirabilos|work, how long ago is this? 12 years?
<mirabilos|work> something like that, yes
<mirabilos|work> probably around 1999/2000
<lolek> a question, can i use this way of workflow for bzr and svn as centralized repo ? : http://doc.bazaar.canonical.com/bzr.2.5/en/tutorials/centralized_workflow.html
<lolek> i'm trying to figure out how bzr will deal with branches in folders on svn repo
<lolek> of course if You have some suggestions or better aproach, i can consider that also
<karni> Hello folks. I have a problem committing u1-servers. bzr really wants to sign with my mkarnicki@gmail.com key, while I want to sign with michal.karnicki@canonical.com
<mgz> karni: see #launchpad
<jelmer> karni: it should be using your whoami details to find the gpg key
<karni> It's picking mkarnicki by default. How do I change that? I've tried overriding gpg_signing_key
<karni> whoami says michal.karnicki@canonical.com, but it's not using that one
<karni> mgz: I think they'll send me back to #bzr :(
<mgz> probably :)
<karni> To make matters more "fun", I can sign with @canonical.com a different project with no fuss.
<karni> I don't see any specific configuration to that project in my locations.conf
<karni> nor authentication.conf
<mgz> karni, okay, looking at the code
<karni> mgz: Thank you!
<mgz> gpg_signing_key should be either "default" or suitable for passing to gpg -u
<karni> FWIW I tried passing my canonical e-mail as well as key signature (that's what you call it?) to gpg_signing_key
<mgz> if default, it looks at 'email'
<karni> right. I can try that again.
<karni> should I put it in ~/.bazaar/authentication.conf ?
<mgz> karni: nope, just bazaar.conf I think
<mgz> apart from by having a different `bzr whoami --branch` I don't see how different projects could get you different signing
<karni> mgz: I think it had something to do with me signing it within lxc..
<karni> mgz: I did add it to authentication.conf, though
<karni> mgz: I tried from my host machine, and it commited properly
<karni> yeah, it's still trying to sign with mkarnicki@gmail.com within lxc
<karni> mgz: I don't know how that works, but just so you guys know â
<mgz> but `bzr whoami` in lxc isn't that, and `gpg --clearsign -u ...@canonical.com` works?
<mgz> possibly lxc hides some of your keys, or confuses the agent in some way?
<mgz> karni: I can't find any key on your name on a gpg key server
<karni> mgz: in lxc, bzr whoami is also: MichaÅ Karnicki <michal.karnicki@canonical.com>
<karni> So correct.
<karni> mgz: http://keyserver.ubuntu.com:11371/pks/lookup?op=vindex&search=0xF1044FC25FD638E7
<karni> mgz: I bet it's confusing the agent in some way
<mgz> ah, you have an 'i' on the end I'd not registered
<karni> :)
<fullermd> You should vowel to be more careful with your spelling...
<mgz> karni: when you ran just the gpg command inside lxc, did it also want to sign with the wrong key?
<karni> I can check
<mgz> fullermd: @ expands to eat all adjacent characters
<mgz> *munch* *munch*
<fullermd> Only to the right; you can see what's where the mouth is.
<karni> mgz: gpg --sign desktop.png signs with mkarnicki, but -u michal.karnicki works to override and sign with the second key
<lolek> ok, one more time with my question, i'd like to use this approach: http://doc.bazaar.canonical.com/beta/en/user-guide/svn_plugin.html#using-a-central-repository-mirror but want to use svn as central repository, my question is what problems should i consider ?
<lolek> the problem is that i want to use that like this: http://doc.bazaar.canonical.com/bzr.2.5/en/tutorials/centralized_workflow.html, the second question is how bazar will work with branch in subdirectory on svn repo ?
<jelmer> lolek: hi
<jelmer> lolek: what do you mean with branch in subdirectory exactly?
<jelmer> bzr-svn handles it fine if there is e.g. a branch named /trunk in the repository, and recognizes copies
<mgz> karni: last thing to see is run `bzr config` in the branch, see if gpg_signing_key is set anywhere up the chain
<karni> mgz: bzr: ERROR: unknown command "config"
<jelmer> karni: your running a very old version of bzr
<karni> Bazaar (bzr) 2.1.4 in lxc (LUCID), 2.5.1 on host OS
<karni> This is because it's u1-servers branch, lucid was advised (although I hear it works on more current version)
<iwata0303> Hi.
<iwata0303> Does anyone know when bzr2.6b3 will come ?
<jelmer> vila, mgz: ^
<lolek> jelmer: may i pm You ?
<jelmer> lolek: sure
<mgz> karni: that might also be an issue with gpg signing then. you can, on lucid, us the bzr ppa to restore sanity to the world.
<karni> mgz: ah. I might try that. I'll stick with committing from host for now :) Thank you!
<mgz> karni: ppa:bzr/ppa
<mgz> iwata0303: ideally soon
<iwata0303> mgz: Thank you!
<karni> mgz: Thank you, sir!
<mgz> I'll send something to the list when I'm about to launch on working out how to do a release
<mgz> hm.... the next couple of weekends are full, might need to find a weekday night
<embersoaker> I merged and commited a branch in to trunk and then reverted it. Went back and changed my code in my branch and then when trying to merge again it won't let me. Is there a way to get trunk to forget that this branch was merged/conmitted before? or a way to force a commit?
<mgz> you merge trunk back into your branch, revert the tree but not the merge marker (`bzr revert .` && bzr commit), then merge the branch back into trunk
<mgz> basically, the feature branch needs to acknowledge the tree changes were not accepted on trunk, and have a new rev with the changes still present as well as trunk history so trunk knows to reapply them
<mgz> embersoaker: ^that make sense to you?
<embersoaker> yes
<embersoaker> thank you
<vila> mgz: I'll be in england next week, if connected the latency should be low ;)
<mgz> oh ho ho, london?
<mgz> all week?
<vila> mgz: yup and yup
<mgz> jelmer: ^
<jelmer> vila: where in England?
<vila> london
 * jelmer will be in London from Wed-Fri
 * SamB_MacG5 grumbles about how ad-hoc bzr's commands are ...
<vila> jelmer, mgz : I'll leave Friday afternoon, will need to check my schedule but... would be nice to have either lunch or dinner or something no ?
<jelmer> vila: yeah, that'd be great
<fullermd> If I start swimming now, maybe I can meet you there...
<vila> fullermd: be my guest ;)
 * SamB_MacG5 is especially thinking that "bzr missing" should support most of the options of "bzr log", like -p ...
<fullermd> https://lists.ubuntu.com/archives/bazaar/2008q2/041074.html   :p
<delinquentme_> ls
<delinquentme_> derp!
<delinquentme_> I have config files ... I'd like a new user to be able to have access to a version of them ... but not mine ...
<delinquentme_> SO .. can I include files within a bzr repo which aren't VC'ed ?
<fullermd> Well, you can PUT a file there and ignore it.  Obviously bzr won't know anything about it, so you'd have to put it there (if it's important) any time you make a WT.
<delinquentme_> WT?
<delinquentme_> fullermd, ?
<lifeless> working tree
<fullermd> Oh, shucks.  If I'd known lifeless was here, I'd have just hit 6 or 8 keys at random, and he'd interpret a correct answer out of it...
#bzr 2012-11-11
<KombuchaKip> [Bug 1077521] [NEW] Bzr not ready for digital media asset management: https://bugs.launchpad.net/bugs/1077521
<ubot5> Ubuntu bug 1077521 in Bazaar "Bzr not ready for digital media asset management" [Undecided,Opinion]
<jelmer> KombuchaKip: I'm not sure I follow - you filed a bug and then marked it opinion yourself?
<KombuchaKip> jelmer: Yes. I would have marked it as a feature request, but I didn't see an option for that. Suggestions welcome.
<jelmer> KombuchaKip: A bug filed Opinion won't show up in the open bugs list so filing it is pretty pointless.
<jelmer> KombuchaKip: there is a Wishlist importance
<KombuchaKip> Alright, I'll set that then.
<KombuchaKip> jelmer: I didn't know that.
<KombuchaKip> jelmer: I see New, Incomplete, Opinion, Invalid, Won't Fix, Confirmed, Triaged, In Progress, Fix Committed, and Fix Released, but no Wishlist.
<KombuchaKip> jelmer: Er, it looks like that's under the Importance field which I don't have access to.
<jelmer> KombuchaKip: best to leave it unset in that case
<KombuchaKip> jelmer: I can't set it anyways.
<jelmer> KombuchaKip: the bug status I mean
<KombuchaKip> jelmer: Oh, too late. Feel free to change it to whatever you like. I set it back to New.
<jelmer> KombuchaKip: Yeah, that's what I meant with leaving it unset :-)
<KombuchaKip> jelmer: Ok, no problem. Sorry about that.
<jelmer> KombuchaKip: I'm not doing bug triaging on bzr, hopefully somebody else will get around to it.
<KombuchaKip> jelmer: Well, it's a pretty big task and will probably require a lot of discussion because it's not really a "bug" per se, but more a design consideration.
<pabs3> does bzr have the equivalent of git fetch?
<fullermd> The answer is probably either "bzr pull" or "meaningless operation", depending on details.
<pabs3> "meaningless operation", since "bzr pull" modifies the local branch
<pabs3> thanks
<fullermd> Well, so does git fetch, just...  and, you're gone.
#bzr 2013-11-04
<dhanyaraj> I am contributing to ubuntu using bzr. Can anyone tell me how to push a file using bzr ?
<dhanyaraj> I am contributing to ubuntu using bzr. Can anyone tell me how to push a file using bzr ?
<LeoNerd> You don't push "a file"; you push the entire branch
<LeoNerd> bzr push $REMOTE-URL
<marcoceppi> So, I need help with workflow using bazaar
<LeoNerd> Ask, don't ask to ask
<marcoceppi> I just don't get how to manage multiple branches with bazaar
<marcoceppi> From a git world, I find myself branching stuff in to /tmp, merging, pushing, then blowing away
<marcoceppi> I don't feel like that's how to properly maintain multiple branches on local disk with bazaar
<LeoNerd> In bzr, a given working directory only contains one branch... for handling multiple branches I usually put a .BRANCHNAME on the directory name
<LeoNerd> bzr co scheme://path/to/someone's/branch Project-Name.BRANCH
<LeoNerd> http://bazaar.leonerd.org.uk/perl/  <== a few .BRANCH names in here
<marcoceppi> interesting, thanks LeoNerd
<xnox> $ bar bd -S --split
<xnox> The program 'bar' is currently not installed. You can install it by typing:
<xnox> sudo apt-get install bar
<xnox> ..
<xnox> coding at Beer O'Clock =)
#bzr 2013-11-05
<vila> xnox: :-D
<vila> xnox: ln -s /usr/bin/bzr ~/bin/bar
<dobey> hi all. how can i verify that a working tree in bzrlib is a lightweight checkout of a branch?
<mgz> `bzr info`?
<mgz> or you mean in python?
<dobey> mgz: with bzrlib in python, yes
<mgz> workingtree objects have a branch attribute you can inspect to see which it is
<mgz> and the lightweight checkout chek goes something like:
<mgz> `tree.user_url != tree.branch.user_url`
<mgz> dobey: hope that helps
<dobey> mgz: branch being a bzrlib.branch.Branch?
<mgz> right, but you get one created for you whenever you construct a tree
<mgz> you probably want to start:
<mgz> `d = controldir.ControlDir.open(location); tree = d.open_workingtree();`
<mgz> and catch some exceptons from open_workingtree
<dobey> right. already have one because tarmac creates a Branch from the launchpadlib branch, without yet opening the working tree
<mgz> then you have some fun, because you can't go from less specific to more specific in general
<mgz> you'd want to reopen the location of the branch as a new object
<dobey> yeah, it does.
<dobey> i just wanted to make sure the type was what i thought it was
<dobey> if user_url is the right thing to check for that, it should do though. thanks
#bzr 2013-11-06
<dobey> mgz: so apparently, checking user_url doesn't work so well for telling if a tree is a lightweight checkout or not. :(
#bzr 2013-11-10
<LeoNerd> Hrm. I don't think my "bzr bisect" is working properly.
<LeoNerd> I'm at -r195, and if I  bzr bisect reset; bzr bisect start; bzr bisect yes   it claims that revision 97 is OK... not sure where it gets that number
<LeoNerd> Then any amount of  bzr bisect move ... doesn't actually do anything
#bzr 2014-11-03
<hazmat> is there a way to show the revision id of a working copy
<hazmat> i remember it was some hidden option
<hazmat> nevermind --show-ids on log does the trick
#bzr 2014-11-04
<MasterPiece> How to use bzr to get lp:curtinator of $URL ?
<jelmer> MasterPiece: "bzr get lp:curtinator"
<MasterPiece> jelmer, Thanks man :)
#bzr 2014-11-07
<Fat-Zer> hi, how can I download only missing part of the branch with bzr?
<Fat-Zer> to be more specific e.g. I've already done "bzr branch lp:kicad"
<Fat-Zer> Now I want to checkout (in git terminology) the lp:kicad/stable branch.
<Fat-Zer> And I can't find the way to get it without downloading all the stuff that I already have...
<Fat-Zer> so... is it possible at all? or I'm just mistaking some bzr basic concepts?
<LeoNerd> Branches are independent
<LeoNerd> Whereas in git, all the possible branches are stored in the same place
<Fat-Zer> oh that's sad... ;(
<Fat-Zer> LeoNerd: thanks
<Peng> use a shared repository?
<Fat-Zer> Peng, what's that?
<Peng> Fat-Zer: bzr help init-repo.
<Peng> Fat-Zer: It creates a repository in a directory which all branches underneath that directory will use to store their data in.
<Fat-Zer> Peng: and hoq to add branch to it after the init?
<Fat-Zer> *how
<Peng> bzr help reconfigure
<Peng> New branches created in child directories will automatically use it.
<Peng> reconfigure can be used to convert existing branches
<Fat-Zer> Peng:  thanks but I haven't found how to use reconfigure so I done it like this:
<Fat-Zer> bzr init-repo kicad-repo
<Fat-Zer> cd kicad-repo/
<Fat-Zer> bzr branch ../kicad-branch/ kicad
<Fat-Zer> rm -r kicad/
<Fat-Zer> bzr branch lp:kicad
<Fat-Zer> bzr branch lp:kicad/stable
<Fat-Zer> a bit hacky... that that worked...
<Fat-Zer> *but that
#bzr 2015-11-05
<lefteris> Hello guys, I would like to ask if bazzar has the ability to merge a branch with multiple commits into maste with one commit
<lefteris> ?
<spiv> lefteris1: yes
<lefteris1> spiv: thanks a lot
#bzr 2017-11-09
<jam> jelmer: did you really intend to tag 2000 bugs with 'check-breezy' ? my inbox just exploded. :)
<LeoNerd> I was considering that question myself :)
<fullermd> Obviously a simple load test, revealing shortcomings in your visual cortex   :p
