#bzr 2007-11-26
<mathrick> ok
<mathrick> done
<ubotu> New bug: #165086 in bzr "bzr ls doesn't accept -V" [Undecided,New] https://launchpad.net/bugs/165086
<lifeless> thanks
<lifeless> poolie_: down to 4 failures
<lifeless> poolie_: 2 with this CRC thing
<lifeless> poolie_: 2 with the one you are patching
<poolie_> cool
<lifeless> poolie_: 6 tests to go
<lifeless> can run just upgrade repository_imp tests to see them
<lifeless> poolie_: I'm finishing now for the day
<poolie_> k
<poolie_> have a good night
<lifeless> you too
<poolie_> i am reasonably confident i will fix this today
<lifeless> cool
<ubotu> New bug: #165106 in bzr "check that get_data_stream distinguishes annotated and unannotated knits" [High,Incomplete] https://launchpad.net/bugs/165106
<vila> morning all
<poolie_> hello vincent
<vila> poolie_: hi :)
<vila> working on bug #165061 I get a traceback when branching a pack repository into a fresh branch (i.e. no repo sharing) mentionning bzr: ERROR: Revision {robertc@robertcollins.net-20050919044328-0205c679f3051340} not present in "<bzrlib.knit.KnitGraphIndex object at 0x990b78c>".
<ubotu> Launchpad bug 165061 in bzr "bzr branch http:// with a pack repository takes too long" [High,Triaged] https://launchpad.net/bugs/165061
<vila> does that ring a bell ?
<poolie_> vila, that might be bug 164637 that i was just working on
<ubotu> Launchpad bug 164637 in bzr "hpss data_stream from pack repository has deltas out of order, fails with KnitCorrupt exception" [Critical,Fix committed] https://launchpad.net/bugs/164637
<vila> ok then, seems a bit surprising that robert did not encounter it, but it's not blocking for me (investigating the bug I mean), I'll watch for your patch anyway
<lifeless> vila: that particular repo is unreconciled and buggy
<lifeless> vila: so don't worry about that error at the end
<vila> lifeless: ok
<lifeless> vila: it wasn't relevant to the bg so I didn't mention it:)
<vila> ;-)
<vila> lifeless: what is your latency against that branch ?
<vila> lifeless: well, not *yours* as such, your computer's (before fullermd made any remark ;)
<pitti> hi bzr rockers
<pitti> bzr-svn just stopped working for me and now complains about a "scheme are not unique" IntegrityError in sqlite; is that really due to bzr-svn, or did something change in bzr itself?
<pitti> I filed it as bug 165136 for now
<ubotu> Launchpad bug 165136 in bzr-svn "svn+ssh:// push: IntegrityError: columns max_revnum, min_revnum, path, scheme are not unique" [Undecided,New] https://launchpad.net/bugs/165136
<jelmer> hi pitti
<jelmer> pitti: what version of bzr-svn are you using?
<pitti> hey jelmer!
<pitti> 0.4.4-1
 * pitti is on current hardy
<jelmer> pitti: you may be able to fix it by blowing away the relevant unique index
 * pitti tries to make a clueful face about what that means
<jelmer> sorry for for being vague :-)
<jelmer> if you open the bzr-svn cache for the repository in question, you should be able to remove the index that is causing problems
<pitti> a workaround would be very much appreciated indeed :)
<jelmer> the simplest thing to do would be to remove ~/.bazaar/svn-cache/ and try again
<pitti> ah, in ~/.bzr/svn-cache
<pitti> awesome
<jelmer> assuming you've used different versions of bzr-svn on the same machine before?
<pitti> yes, I did
<pitti> at least 0.4.1 on gutsy, but probably older ones, too
<pitti> yay, that helped
<pitti> jelmer: you saved my day, thanks; I'll mention the workaround in the bug report, for others who might have the same problem
<jelmer> pitti: cool
<jelmer> pitti: btw, now that you're here..
<jelmer> I much appreciate the editmoin package
 * pitti loves it, too
<jelmer> but it's only included in Ubuntu, not in Debian yet - are you a DD?
<pitti> yes, I am
<pitti> jelmer: indeed, I'll file an ITP now, and upload it in a bit
<jelmer> pitti: Thanks, that would be very nice :-)
<pitti> jelmer: ITP sent
<pitti> thanks for the poke; it was on my list for a long time, but I forgot about it
<lifeless> vila: home to uk
<lifeless> vila: so lots, but we only do four reads, so it shouldn't be a significant factor
<vila> you do 62 requests, 4 of which are readv for the pack (one failing so that makes 5)
<vila> # requests: 62
<vila> Bytes read: 68437333
<vila> Bytes written: 0
<vila> Average latency: 1588ms
<vila> that's for fr to uk with a ping of ~20ms, so the http server do quite some work before replying...
<vila> that's from transportstats plugin, but the 68M figure may be skewed by the retry
<ubotu> New bug: #165136 in bzr-svn "svn+ssh:// push: IntegrityError: columns max_revnum, min_revnum, path, scheme are not unique" [Undecided,New] https://launchpad.net/bugs/165136
<Kinnison> Morning bazaaristas
<vila> scratch that, the retry doesn't appear in the stats, so the 68M is correct and coherent with du -sk pack-branch-speed
<vila> 63336	pack-branch-speed
<vila> lifeless: reading your report again something strange appears, read my additional comment on the bug report
<vila> lifeless: if you can mail me your .bzr.log it could help too
<vila> lifeless: and tell me if you use pycurl or ulrlib
<vila> :)
<lifeless> vila: uhm, I dunno. whatever.
<lifeless> vila: pycurl is installed
<vila> ok, so it's used
<lifeless> vila: so, I know a root cause of the problem
<lifeless> vila: look in pack.py at make_readv_reader or whatever it's called.
<vila> yes, and ?
<vila> lifeless: ouch the retry request 55M
<lifeless> right
<jelmer> lifeless: is there any hack to allow backslashes to be added to inventories but not considering them path separators?
<lifeless> jelmer: I hope not.
<jelmer> I'm trying to decide how to solve bug 163858
<ubotu> Launchpad bug 163858 in bzr-svn "bzr-svn cannot check out lintian repository" [Undecided,Confirmed] https://launchpad.net/bugs/163858
<jelmer> lintian contains filenames with a backslash in them
<jelmer> so far, the only solution I can think of is ignoring such files
<lifeless> as well as non utf8 chars
<lifeless> my opinion on this is that if you want stupid characters as test data, its appropriate to construct these at runtime, not version the fuckers
<vila> argh, and then, the transport remembering that a previous multiple range request failed stays on single range mode and issues one 57M request
<lifeless> vila: and there we go, problem found
<vila> lifeless: here is the problem
<jelmer> lifeless: sure, but the problem is you can actual control what users can version whereas I can merely deal with what has already happened :-)
<lifeless> jelmer: I would escape it
<mwhudson> jelmer: this affects ~vcs-imports fairly frequently too, of course
<lifeless> jelmer: hex or otherwise encode everything that's not valid
<jelmer> lifeless: that means I have to deescape as well
<lifeless> then a pair of plugins for tree operations can make them be as broken on disk as the user may desire
<jelmer> lifeless: and potentially interpret filenames that were never escaped things at all
<vila> lifeless: yup, problem found, the 4 readvs ends up transferring  5,8M, 25M, 55M and 57M
<jelmer> mwhudson: what does lp do? Escape?
<lifeless> jelmer: there is a hard choice here. Either we allow any pathname, or we don't :). Converters naturally want the widest range of characters - no artificial limits.
<mwhudson> jelmer: fail
<jelmer> mwhudson: fail as in fail to import the branch? Or simply fail for that one file and skip it?
<mwhudson> jelmer: fail to import the branch
<lifeless> jelmer: to date, our approach has been to require paths to be valid utf8 and not directory separators on any platform.
<lifeless> jelmer: IIRC lintian's tree has more than just \'s that are a problem, which is why I'm not getting excited about it - because we need to handle the fact that we can't encode the other paths either
<jelmer> lifeless: Sure, but there will be other repositories with just one file with a backslash or non-utf8 character in their name
<jelmer> at the very least I'll make bzr-svn throw a comprehensible exception, but I'd like to fix it if possible
<lifeless> jelmer: I think encoding is a decent answer. You can list all the encoded files in a rev in a rev property; so that you don't decode user files that happen to be encoded
<lifeless> paths with \ and non-utf8 chars are really unportable anyway
<jelmer> lifeless: that's a nice idea
<jelmer> would require a mapping upgrade though :-/
 * jelmer sees another use for custom file properties, storing the original name of files that are encoded
<lifeless> well
<jelmer> or maybe custom file properties are like a hammer to me..
<lifeless> yup
<lifeless> they are
<jelmer> I guess I've spent too much time working with svn where everything is stored in properties
<lifeless> encoded_paths: {file_id:(path, orig_path)...} is all you need
<lifeless> properties are evil
<jelmer> properties are good
<jelmer> we could store them in extended attributes!
 * jelmer gets all excited
<lifeless> at the core of the system, a dict like mechanism is a useful implementation strategy, but its a terrible API
<jelmer> :-P
<jelmer> I agree they're a storage mechanism, not fit as an API
<mwhudson> $ getfattr -n user.bzr-svn.original_name foo.txt
<mwhudson> <<<< THIS
<mwhudson> ...
<mwhudson> :)
<lifeless> jelmer: and svn's heinous mistake here is to expose them as an API.
<lifeless> mwhudson: I'm a hurta youa
<jelmer> lifeless: I think the main problem with svn is that exposes the property API as the primary UI and API for managing externals or ignores
<lifeless> gnight
<jelmer> exposing the property API in general isn't a problem
<jelmer> night lifeless
<ubotu> New bug: #165151 in bzr "Silently ignores add of file "\\"" [Undecided,New] https://launchpad.net/bugs/165151
<mwhudson> jelmer: btw, my second attempt at pushing to pydoctor worked fine
<mwhudson> (not sure if i mentioned this last night)
<jelmer> mwhudson: ah, cool
<jelmer> so it appears the ulimit was the problem?
<mwhudson> jelmer: i have no idea
<mwhudson> can lock_read() fail?
<abentley> mwhudson: It can fail for working trees if they're already locked.  I don't think it can fail for branches or repos.
<abentley> modulo system-type errors like MemoryError...
<mwhudson> abentley: just looking at Merge3Merger.__init__ which will leave the working tree locked for writing if a lock_read fails
<abentley> That would be a bug.  It was written before WorkingTree.lock_read was expected to fail.
<abentley> gotta run.
<mwhudson> ok
 * mwhudson stabs python's __ mangling
<mwhudson> abentley: yay, i managed to get diff-as-merged to work using TransformPreview for a launchpad merge!
<mwhudson> (took 4s vs 215s :)
<mwhudson> i had to comment out lots of stuff to do with conflict handling, mind
 * mwhudson goes back to look at that
<jelmer> abentley: bundlebuggy's version is currently at 1.0 - are you sure it shouldn't be 0.x ?
<jelmer> (just checking, otherwise I have to mess around with versions in Debian later on)
<gioele> hi
<gioele> is it me or bzr (0.92) does not respect my umask?
<gioele> I have a umask 077, it seems to me that bzr always applies umask 022
 * Nafallo spreads the love off bzr on the office :-)
<bialix> abentley: hi
<ubotu> New bug: #165215 in bzr "pull overwrite does not always find revisions after bind" [Undecided,New] https://launchpad.net/bugs/165215
<n[ate]vw> hey all. I've been giving bzr a test drive vs. mercurial and have a couple questions
<n[ate]vw> I'm primarily hoping to use one to enable home directory sync between a desktop and a laptop, and I'm wondering how soon bug #107967 will make it to a release?
<ubotu> Launchpad bug 107967 in bzr "Using bzr mv --after on a directory (as opposed to a filename) fails" [Medium,In progress] https://launchpad.net/bugs/107967
<luks> n[ate]vw, version control systems are not a good way to do that
<luks> they are good at ... controlling versions of files, not syncing workspaces
 * dato recommends unison instead.
<n[ate]vw> yeah, I don't really need the version history (although I can imagine scenarios where it'd be nice), and some of this stuff will be binary files (although I'll probably manage photos/music externally)
<n[ate]vw> any suggestions for a painless sync system? don't want to pay for .Mac (rumored slow, still not enough space to be worth it) and am not sure how much of a pain it is to set up a Home Sync without OS X Server
<n[ate]vw> to complicate matters, I really don't want my complete home directory synced. I'd like to keep separate desktops, and don't have room on the laptop for all my photos, etc
<n[ate]vw> I'll check out Unison again, thanks, I'd forgotten about that.
<n[ate]vw> I'm still a bit lured by the siren call of http://www.onlamp.com/pub/a/onlamp/2005/01/06/svn_homedir.html, especially with the advantages of DVCS
<n[ate]vw> on another note, is there anybody on who uses both bzr and Xcode? I'm wondering if there's a good way to take advantage of Xcode's SCM integration, although only CVS/svn have out-of-box support
<lifeless> n[ate]vw: I'm not aware of a bzr/Xcode user, but we'd sure love someone to write the plugin for XCode :)
<ubotu> New bug: #165255 in bzr-eclipse "NullPointerException in share project dialog" [Undecided,New] https://launchpad.net/bugs/165255
<lifeless> vila: so, you hav figured out the problem; what next - whats the easiest way to download only what we need ?
<vila> lifeless: fix still  not written (RL), but I've looked at the code and I may avoid rewriting response.py and just rewrite _readv
<lifeless> seems to me _readv can act as a generator quite easily
<vila> yes
<lifeless> let me know if you need anything for this
<vila> I'm to tired to do that this evening, but I think tomorrow will be ok
<lifeless> because Martin wants to make packs default real soon (days)
<lifeless> and IMO this would be a black eye for bzr :(
<vila> the actual implementation is correct but yes, http should behave :)
<vila> first this bug, then getting rid of file in memory
<vila> will it be ok to keep 65K in memory and switch to a temp file above that ?
<vila> 65K being a class constant
<lifeless> uhm
<lifeless> why the temp file? (you'll fragment disk and IO patterns)
<lifeless> I'd really not want anything touching disk until we're downloading about 80% of main memory
<lifeless> better still would be to just provide the data as you get it in reasonable amounts (note that if the caller used get_file_bytes we're asking for it in memory anyway)
<radix> that'd force everything out of my cache though
<lifeless> radix: how much mem do yo uhave?
<radix> 2GB
<vila> lifeless: yeah, thanks for refreshing these bits, I lost context, I'll go to sleep with that in mind then ;)
<lifeless> so, 1.6GB of version control history is needed for my statement; and if we did get a 1.6GB single pack and streamed it to disk, then read it back - what do you think will happen to your cache then ?
<lifeless> radix: the OS has a swap file for exactly this reason; if our access pattern to 1.6GB of memory is the same as it would be to a 1.6GB temp file (it will be) then there's no basic difference, except our code is simpler.
<radix> lifeless: ok :)
<lifeless> really though, buffering of any sort is the problem, and its that that we need to fix
<lifeless> because waiting for 1.6Gb to download before we start processing is silly, and waits a whole lot of concurrency
<AnMaster> hey I need to help someone on windows to learn bzr, is there any good gui? the tortoise one seems rather incomplete?
 * AnMaster uses FreeBSD/Linux himself
<jelmer> AnMaster: qbzr is quite good from what I've heard
<AnMaster> jelmer, any link?
<jelmer> AnMaster: http://bazaar-vcs.org/QBzr I think
<AnMaster> qt? hm qt is for windows?
<lifeless> qt is the kde toolkit
<AnMaster> I know that
<dato> is multi-platform
<AnMaster> didn't know the window version was free though
<dato> lifeless: "the toolkit that kde uses", to be precise ;)
<AnMaster> thought it was closed
<dato> not since v4
<lifeless> dato: pedants of the world unite
 * AnMaster is a KDE user himself
<ubotu> New bug: #165259 in bzr-eclipse "Does not recognize branches sometimes" [Undecided,New] https://launchpad.net/bugs/165259
<n[ate]vw> luks: did a class-dump of /Developer/Library/Xcode/Plug-ins/XcodeSubversionPlugin.xcplugin/Contents/MacOS/XcodeSubversionPlugin, but might wait until http://lists.apple.com/archives/xcode-users/2007/Jan/msg00072.html comes true to invest much into it. plus I'm still testing Mercurial as well ;-)
<luks> AnMaster, qbzr is not really a "bzr gui"
<AnMaster> oh?
<AnMaster> luks, I'm used to command line, the user I'm trying to introduce to bzr is not
<AnMaster> so now what?
<luks> then qbzr is not what you want :)
<lifeless> olive perhaps
<AnMaster> luks, what do I want then?
<lifeless> (the bzr-gtk gui shell)
<luks> I don't think there is anything complete
<AnMaster> hm :(
<luks> I was tempted to build a GUI application around qbzr a couple of times, but bzrlib doesn't really make it easy to make something usable :(
<lifeless> luks: huh? We've put quite some effort into making it wrappable; please do file bugs anywhere you find it hard to use the library directly.
<luks> lifeless, it's blocking by design and it touches a lot of global objects
<luks> which rules out either async event-based approach or threading
<luks> and running a separate process is bit too much
<lifeless> luks: we have one global, the ui_factory
<luks> lifeless, configs, registries, locks, ...
<lifeless> blocking by design is true, I ported bzr to twisted a couple of years ago but I got overrulled.
<lifeless> configs are not global, they are instances
<lifeless> registries are meant to be static once loaded
<luks> I had a lot of troubles when I tried to load log from a thread
<lifeless> locks are instances, where global state is used in a lock its to implement correct mutexing within a single process between instances and we'd love patches to make them thread correct if they are not today.
<lifeless> certainly LockDir locks do not need global state
<lifeless> luks: please please please file bugs; we need feedback on this.
<lifeless> there's no point having a strict library separation if it's not usable.
<luks> well, it is usable
<lifeless> for guis I mean
<lifeless> thats a major use case for the library
<lifeless> web apps is another, and they are often threaded
<AnMaster> is there any way with bzr to force native line endings
<AnMaster> like the svn property
<luks> nope
<AnMaster> luks, any plans to add it?
<lifeless> yes
<lifeless> someone should write it as a plugin so we can evaluate it properly
<lifeless> then we'll probably fold it into a core
<AnMaster> it is rather important for this project, compiler on either side will barf if native line endings are not used
<AnMaster> :(
<luks> I don't think it will be possible to do from a plugin
<AnMaster> so I guess I got to use svn for now then
<luks> at least not easily (without reimplementing most of WorkingTree functionality)
<AnMaster> sigh
<dato> AnMaster: if you're the *nix guy, can't you just use an editor able to edit \r\n files?
<lifeless> luks: its totally possible to do from a plugin
<luks> lifeless, it would require a lot of code to trick dirstate
<lifeless> AnMaster: ouch, thats really interesting. Could you perhaps edit the wiki page about this to note this scenario ?
<AnMaster> dato, yes I can edit such files the problem is the compiler used for the project always want native line endings, it will error out if CRLF is used on linux and plain LF is used on windows
<lifeless> luks: you don't need to trick dirstate
<AnMaster> not ub to me
<AnMaster> up*
<dato> AnMaster: ouch, baad compiler
<luks> lifeless, well, then converting the files every time it has to compare them, but that would be much slower
<luks> (compare == check if they are modified)
<AnMaster> I can't give details about the compiler, it is internal to the company *growl*
<AnMaster> and I can't fix that part
<AnMaster> :/
<lifeless> luks: dirstate should always reflect reality
<AnMaster> dato, I fully agree
<luks> lifeless, that's the tricky party
<luks> you have two realities
<luks> repository and working three, both different
<AnMaster> lifeless, and what wiki page?
<lifeless> http://bazaar-vcs.org/LineEndings
<lifeless> I don't think your particularly hard case is documented there today.
<AnMaster> "The way mercurial recently implemented this seems like a good idea." <-- ah, *goes to look, at least that is better than svn, though I prefer bzr*
<lifeless> luks: anyhow, basically it comes down to this: Someone needs to write the code, plugin or branch of bzr.dev, I don't care. We need code that does the job without changing the storage model; as a starting point to evaluate. From there we can look at how to version the setting and how it should work.
<luks> AnMaster, the mercurial way is really bad
<luks> e.g. it very often marks unchanged files as changed
<AnMaster> luks, hm I see
<AnMaster> svn's way seems to work well
<luks> svn works well because it enforces line endings in a particular way
<AnMaster> ok
<luks> both mercurial and git pretend they support LE conversions, but both suck at it for this reason
<lifeless> and bzr has a pretty high bar in our qa and design process
<AnMaster> hm ok
<lifeless> we're not happy with cruddy solutions :)
<AnMaster> and git I can't stand, way too many different commands
<AnMaster> I always get lost trying to do simple stuff
<lifeless> AnMaster: I would say - use svn
<AnMaster> lifeless, svk maybe then, kind of need distributed
<lifeless> AnMaster: bzr-svn is really cool; you can use that on the linux side :). And when we get line ending support for you migrate to bzr.
<luks> bzr-svn :)
<luks> heh
<AnMaster> hm
<AnMaster> also a lot of windows editors have a habit of storing mixed line endings
<AnMaster> so lines you edit or whatever gets CRLF and the rest if left as is
<malept> hrm...is bzr-svn supposed to eat a lot of memory?
<luks> yes, it's a known bug either in svn or the python bindings
<malept> ah, that's right.
<malept> I had forgotten.
<luks> https://bugs.launchpad.net/bzr-svn/+bug/54253
<ubotu> Launchpad bug 54253 in bzr-svn "Excessive memory usage in bzr-svn" [Undecided,Confirmed]
<AnMaster> malept, uups forget it then
<AnMaster> repo is like 5 GB iirc
<AnMaster> no wait, the source repo is 700 MB, the data repo is 5 GB
<AnMaster> still
<malept> there's a workaround in the bug.
<malept> I'm actually seeing 800MB+ memory usage in a 150MB svn repo.
<malept> I'm going to see if it persists with the workaround.
<lifeless> found it!
<lifeless> breakfast, then I fix hpss for packs
<malept> hrm...I don't see much difference with the workaround.
<kiko> hey jelmer
<jelmer> hi kiko
<kiko> jelmer, I want to help you out with your question -- what packages do you need to maintain which you don't currently? there may be a misunderstanding.
<jelmer> kiko: I'm upstream and Debian maintainer for bzr-svn
<jelmer> but in ubuntu the package is synced from Debian
<kiko> jelmer, okay. and what is it that you want to do that you can't?
<jelmer> so I can't actually change priority on bugs reported against the Ubuntu bzr-svn package
<jelmer> I'm not sure whether this is how it's supposed to work either
<kiko> jelmer, gotcha.
<kiko> jelmer, this is an interesting second case of a problem I've seen before.
<kiko> jelmer, let me talk to brian murray. hang on.
<jelmer> kiko: ok
<lifeless> its correct
<lifeless>  you need to be in ubuntu-qa to change priority
<lifeless> or in motu/core-dev
<lifeless> join motu :)
<jelmer> already on the list :-)
<jelmer> Debian Bazaar Maintainers is listed as maintainer though
<jelmer> and I am in that team
<jelmer> except that launchpad doesn't recognize it as a team
<jelmer> that's what my support Q was about
<lifeless> jelmer: on the list != being a motu; you'd probably breeze through the acceptance process
<lifeless> I think its correct as it is, because if you think about it it's not appropriate for someone outside the distro to say how important something is within the distro
<lifeless> thats a function of the distro's qa and work practices.
<jelmer> lifeless: I understand the theory behind it
<lifeless> ubuntu does not have maintainers
<jelmer> I take that back
<jelmer> the maintainer field has no meaning?
<lifeless> the package maintainer field?
<jelmer> yeah, as listed on the launchpad bug page
<lifeless> url me up
<jelmer> https://bugs.edge.launchpad.net/ubuntu/+source/bzr-svn/+bug/79333
<ubotu> Launchpad bug 79333 in bzr-svn "Use commit notifier in SvnWorkingTree.commit()" [Wishlist,Confirmed]
<jelmer> has a box in the bottom that says "bzr-svn" source package, and who the maintainer is, etc
<jelmer> that's the bit that suggested to me that being in "Debian Bazaar Maintainer" would allow me to change the bug
<jelmer> but I guess it's just the field imported from Debian?
<lifeless> yah
<lifeless> in Ubuntu, any motu can upload any package in universe; there is no concept of NMU
<lifeless> and any core-dev can upload any package in main or universe
<lifeless> that said, people do specialise, and uploading e.g. a kernel when you have no idea about the kernels would be frowned upon, but the maintainer lock is well and truely gone.
<lifeless> its one of the major social differences between ubuntu and debian package management
<lifeless> teams are social grouping for people working on the same thing; we'd need to either a) only allow devs (core-dev + motu) into such teams, or b) ignore such teams for the purpose of access control, to do acl's sanely
<lifeless> we've chosen b) because that allows interested folk that are only prospective developers (aka going through NM) to participate more
<lifeless> from ubuntu's perspective you are currently a prospective developer, you haven't passed the assessment to get upload rights & all that comes with that.
<jelmer> ah, k - thanks
<lifeless> jelmer: and you totally should to that now!. kthxbye -> #ubuntu-motu
<lifeless> kiko: ^
<kiko> yean yean
<jelmer> lifeless: I did know the bit about not having maintainers, it was the fact that it actually listed a maintainer (with clickable address) that confused me
<lifeless> kiko: just making sure you'd seen it :)
<kiko> yeah well
<kiko-zzz> time to enjoy the evening
<lifeless> night kiko-zzz
<lifeless> ok
<lifeless> NOW packs can run as default in terms of the test suite.
<lifeless> thumper: you vant a kall?
<thumper> lifeless: sure, gimmie a minute, skype?
<lifeless> k
<poolie> lifeless, jam: two minutes
<lifeless> poolie: are you going to ring-out?
<lifeless> poolie: or is it on the canonical conf server?
<lifeless> also, note that jam is not on IRC:)
<poolie> on the conference centre today, i'll send mail about it
<abentle1> Good evening, folks.
<abentle1> poolie: ping
<lifeless> hi abentle1
<lifeless> abentle1: poolie is on the phone with me
<abentle1> Hi there.
<abentle1> Okay.
<abentle1> I was just going to ask about the diff refactoring.
<lifeless> e
<lifeless> he's promised to look at it.
<abentle1> Okay.
<abentle1> I don't think it's urgent for 1.0, I'd just like to know.
<lifeless> I'd love to have it in
<lifeless> because then we can write crazy stuff like an adapter to read/use gits path attributes and diff control stuff
<jam-laptop> lifeless: your update and data size patches look good to me
<jam-laptop> +1 on both
<abentle1> lifeless: Yep, sounds crazy :-)
<jam-laptop> abentle1: on this patch: http://bundlebuggy.aaronbentley.com/request/%3C1196112144.32300.184.camel@lifeless-64%3E
<jam-laptop> I see a whole lot of commit messages
<jam-laptop> Is BB just showing the full set of messages
<jam-laptop> even though the request was  a cherrypick?
<abentle1> Yes, it shows all the revisions in the bundle.
<jam-laptop> Certainly not critical, but it looked like I should have been reviewing a whole lot more from those messages
<abentle1> I guess I still have a bit of work left on that code.
<jam-laptop> ok
<abentle1> No one used to cherrypick, so it didn't matter.  This is what I get for encouraging cherrypicking :-)
<lifeless> jam-laptop: thanks
<lifeless> abentle1: users huh.
<abentle1> Yep.  If you just write crappy enough software, no one will bother telling you how to make it better.
<lifeless> poolie: ping
<poolie> pong
<lifeless> I've filed bugs
<lifeless> I think one or two are still going through the mail handler
<lifeless> https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=packs
<lifeless> I tagged them packs; will let you judge if they are 1.0 relevant/important
<lifeless> I think they are all critical, if we are changing the default.
<ubotu> New bug: #165290 in bzr "packs do not check for missing compression parents" [Undecided,Triaged] https://launchpad.net/bugs/165290
<ubotu> New bug: #165291 in bzr "branching from hpss does not preserve format" [Undecided,Triaged] https://launchpad.net/bugs/165291
<abentle1> How can these be undecided, triaged?
<lifeless> I filed them as triaged, because that stops the janitor fucking with them
<lifeless> and I'm about to get poolie to eyeball them
<abentle1> Ah.
<lifeless> routing around damage
<fullermd> Hm.  Who was the person with bits floating around in their head for inventory reworkings?
<lifeless> me/poolie/jam/abentley
<abentle1> lol
<fullermd> Poor vila, so left out...
<fullermd> Is there a spec or something somewhere to which capability requests can be added?
<abentle1> I think poolie was taking point on inventory, all of us are thinking about it.
<abentle1> There's a spec in the development docs, I think.
<ubotu> New bug: #165293 in bzr "collisions not handled correctly" [Undecided,Triaged] https://launchpad.net/bugs/165293
<ubotu> New bug: #165294 in bzr "packs interactions with common plugins not assessed" [Undecided,Triaged] https://launchpad.net/bugs/165294
<fullermd> Hmm.  Well, nothing jumping out at me.  I'll just put it to the list.
<lifeless> abentle1: want to fix bug 164639 ?
<ubotu> Launchpad bug 164639 in bzr "rich-root format should use packs" [Medium,Confirmed] https://launchpad.net/bugs/164639
<abentle1> lifeless: already have
<lifeless> cool
<abentle1> Just went in this morning and I forgot to update the tracker.
<abentle1> I'm starting to think that post-merge reminders would be good.
#bzr 2007-11-27
<lifeless> could be; otoh getting mails from the commits list is enough for me
<ubotu> New bug: #165304 in bzr "smart server data streams not used across repository	representations" [Undecided,New] https://launchpad.net/bugs/165304
<ubotu> New bug: #165306 in bzr "merge commits are extremely slow" [Undecided,New] https://launchpad.net/bugs/165306
<ubotu> New bug: #165307 in bzr "graph.heads() does O(N^2) access to the graph" [Undecided,New] https://launchpad.net/bugs/165307
<lifeless> fullermd: what was the bug you filed yesterday about unreferenced texs ?
<lifeless> jam-laptop: if you're still hacking, lookin into that check bug would be most excellent iMO
<ubotu> New bug: #165309 in bzr "pack index has no topological locality of reference" [Undecided,New] https://launchpad.net/bugs/165309
<fullermd> The check one?  I can look up the number in my -bugs mailbox...
<lifeless> fullermd: heh
<lifeless> poolie: more bugs landed https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=packs
<fullermd> 165071
<lifeless> jam-laptop: ^
<ubotu> New bug: #165313 in bzr-pqm "working tree clean check comes after branch check" [Undecided,New] https://launchpad.net/bugs/165313
<ubotu> New bug: #165315 in bzr "Cannot version a 3M path tree" [Undecided,New] https://launchpad.net/bugs/165315
<beuno> ouch
<beuno> don't you kind folks do tests on the mozilla tree?    Is it that much smaller then the debian source opened up?
<Odd_Bloke> beuno: It evidently is. ;)
<lifeless> beuno: its 50K paths
<lifeless> so 60 times smaller
<Odd_Bloke> Aw, I checked out the mozilla tree for nothing. :p
<Odd_Bloke> 52218, 'find . | wc -l' tells me.
<beuno> lifeless, it's an interesting use cas ethen
<lifeless> poolie: https://bugs.edge.launchpad.net/bzr/+bug/159118
<ubotu> Launchpad bug 159118 in bzr "can create a pack repository over bzr+ssh, but then not open it" [Low,Confirmed]
<lifeless> poolie: just noting it
<Nephyrin> Question: How do i remove/override a default ignore for a repository? IE if I don't want *.o files to be ignored, is there a way?
<lifeless> Nephyrin: there are no default ignores.
<lifeless> Nephyrin: ~/.bazaar/ignore contains your personal ignores, which you can change
<beuno> Nephyrin, maybe explicitley adding it?   bzr add foo/bar.a?
<beuno> lifeless, he might mean if it's been ignored as a general rule, but wants to make an exception
<Nephyrin> Ah, it was in the ~/.bazaar/ignore
<Nephyrin> Thanks ^.^
 * Nephyrin doesn't consider a tree clean if it has those nasty .o files.
<j1mc> hi all.  i'm getting an error when trying to push something to launchpad via bzr.  (http://pastebin.ca/798862) can anyone help?
<poolie> j1mc, hi
<lifeless> jam-laptop: I would say your branch is bound to the http url
<lifeless> meh
<poolie> j1mc, try 'bzr info'
<j1mc> hi poolie
<poolie> or just 'bzr unbind'
<lifeless> j1mc: did you get the branch by doing 'bzr checkout' if so, try 'bzr unbind', then your push should work
<poolie> lifeless, were you trying to call?
<lifeless> poolie: yah
<lifeless> should I try again
<j1mc> poolie: ok, i did that.  no errors or anything
<j1mc> lifeless: yes, i did do a bzr checkout
<j1mc> i'll give that a try
<j1mc> lifeless: here's what i get now: http://pastebin.ca/798882
<lifeless> ah, it is a checkout, you really need a full branch I think
<lifeless> j1mc: have you seen our tutorial ?
<j1mc> lifeless: no, i haven't.
<beuno> it's a lightweight checkout. lifeless does unbid work with lightweights too?
<abentle1> beuno: unbind doesn't work with lightweight checkouts.
<abentle1> However, you can do "reconfigure --tree" to turn a lightweight checkout into a normal tree.
<beuno> j1mc, ^   :D
<j1mc> beuno: i am just trying to do a normal branch now, and will just copy my changes (two files) over those two files in the branch once it's done.
<beuno> j1mc, great then
<dash> hi. i'm crazy and I want to use bzr for versioning stuff other than files in the filesystem. How much pain am I in for?
<Odd_Bloke> dash: Define "stuff other than files".
<dash> in terms of writing code to pull data out of whatever structure i've got it in, and putting it into a bzr branch.
<dash> Odd_Bloke: something /sorta/ like the way smalltalk stores its code
<Odd_Bloke> Why not write code to pull data out of whatever structure you've got it in and put it into files and then put those into a branch?
<dash> in an opaque database-ish file
<dash> Odd_Bloke: hmm
<abentle1> I really don't like your chances of resolving text conflicts in your data.
<dash> hmm, why's that?
<dash> all the data is going to be source code of some variety
<Odd_Bloke> dash: I'm not really sure I understand your use case here.  Do you just want to store history, or do you want to take advantage of the merging capabilities of bzr?
<dash> well, let me rephrase
<dash> I'd like to manage a wad of source code with bzr, both for history and merging purposes. This source code isn't stored in individual files in a filesystem hierarchy. It's actually in one big file on the disk, but internally there is some concept of hierarchy and so forth.
<dash> The hackish way to expose this would be to write a FUSE driver to interface to this, and use bzr on that
<dash> but havng to mount things is tedious and i'd rather just use bzrlib directly.
<dash> make sense?
<Odd_Bloke> Yeah, I'm just trying to think of a way to do it. :p
<Odd_Bloke> You might be best writing a post to the ML, as it'll get more eyes looking at it...
<dash> well, mostly i'm thinking about how smalltalk and lisp have pretty rad development environments but you can't use 'normal' VCSes with them
<dash> and i'm wondering how hard it'd be to adapt bzr to deal with that
<dash> (for a new language/dev environment)
<lifeless> dash: so the layering here is:
<lifeless> repository
<lifeless> branch
<lifeless> tree
<lifeless> if you can map your current code into a conceptual tree, you can replace WorkingTree with e.g. SqueakImageTree
<lifeless> that combined with language bindings of course, should work reasonably well
<abentley> Well, aside from actually performing merging and such.
<abentley> Since TreeTransform hits the filesystem pretty explicitly.
<lifeless> right, need to replace that; and the ui layer too of course
<lifeless> ciao
<dash> lifeless: awesome
<dash> lifeless: i am expecting to embed python anyway, so that should work
<dash> and yeah, I should be able to punt on merging for a while so long as i've got history
<j1mc> hi all - me again.  i'm getting closer, but i still can't upload changes to launchpad via bzr, even though i have commit access: http://pastebin.ca/798954
<ubotu> New bug: #93609 in bzr "Better error messages for bzr lp://" [Medium,Confirmed] https://launchpad.net/bugs/93609
<j1mc> beuno: any advice?  ^^
<Verterok> j1mc: do a 'bzr commit -m "<your commit message>"'  first, then a push
<j1mc> thanks, Verterok
<Verterok> y're wellcome
<j1mc> "Pushed up to revision 3624."  w00t  :)
<j1mc> thanks
<ubotu> New bug: #172249 in bzr "bzr check help out of date / confusing output" [Low,Confirmed] https://launchpad.net/bugs/172249
 * siretart feels stupid. can someone have a look at http://pbot.rmdir.de/6b5ea9950aeacc1ce3c11455362c6b72 and tell me what's wrong with fetching a branch from launchpad via https?
<AfC> siretart: try dropping SSL and just using http?
 * AfC doesn't use launchpad much, though
<siretart> AfC: launchpad doesn't support plain http, only https
<Odd_Bloke> siretart: https://bugs.edge.launchpad.net/bzr/+bug/82086
<ubotu> Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Confirmed]
<AfC> siretart: well Launchpad advertises http://bazaar.launchpad.net/~bzr/bzr-push-and-update/trunk for the Bazaar push-and-update plugin that I was experimenting with a few days ago. That looks like HTTP to me.
<AfC> (needless to say, I have recommended to them that they get with the program and get a bzr:// server going)
<siretart> Odd_Bloke: thanks!
<vila> morning
<vila> Is there a prize associated with the best performance_gained / size(code_modified) ratio ?
<vila> lifeless: bug #165601 fixed, more fear than harm, with a fun twist ;)
<ubotu> Launchpad bug 165601 in inkscape "win32: non-ascii filenames still don't work" [Critical,Fix released] https://launchpad.net/bugs/165601
<vila> lifeless: bug #165061 fixed, more fear than harm, with a fun twist ;)
<ubotu> Launchpad bug 165061 in bzr "bzr branch http:// with a pack repository takes too long" [High,Fix committed] https://launchpad.net/bugs/165061
<vila> the hell with the typos !
<vila> siretart: what OS/distro are you using ?
<vila> siretart: if debian or ubuntu check wether or not the ca-certificates package is installed (there seems to be some inconsistencies in dependencies around pycurl/libcurl/ca-certificates)
<lifeless> vila: ironic to have a typo given the root cause
<vila> lifeless: yeah, story of my bzr life ;-)
<vila> hhtps, 165601, _max_readv_combined, brz, the list goes on...may be scripting languages and their run-time checks nature are not for me finally, will look at ada/c++ again...
<lifeless> vila: bb:approve
<lifeless> vila: JFDI
<vila> lifeless: :) no way, sub minute cycles are too good :)
<vila> lifeless: your 'bb:approve' above means I should pqm-submit now ?
<siretart> vila: gutsy, and ca-certificates was not installed. installing it doesn't help either
<lifeless> vila: hell yes
<lifeless> vila: this probably makes knit pulling faster too
<vila> lifeless: ok, I'll merge
<vila> rats, forgot NEWS update again
<vila> siretart: wow, what version(s) of libcurl and pycurl are installed ? (Note that you can force urllib use if these problems get to boring)
<siretart> vila: note that pulling from https://code.launchpad.net/~debian-opensync/opensync/upstream works, but not from https://code.edge.launchpad.net/~debian-opensync/opensync/upstream
<siretart> ii  python-pycurl       7.16.4-1        Python bindings to libcurl
<siretart> ii  libcurl3-gnutls               7.16.4-2ubuntu1               Multi-protocol file transfer library (GnuTLS)
<vila> siretart: ha, I think the problem is that code.launchpad.net and code.edge.launchpad.net do not use the same certificate authority (Go Daddy for the later)
<vila> siretart: so the obvious workaround is to avoid code.edge
<siretart> not sure if this is really a problem or a feature :)
<vila> siretart: I don't enough about ca-certificates packaging to answer that :-) Short of updating /etc/ssl/ca-certificates.crt  yourself or creating your own...
<siretart> vila: what If I don't have root on the machine like in a student lab?
<vila> avoid code.edge, only launchpad beta-testers should ever see it or bug launchpad admins :)
<vila> AFAIK people are working on the ca-certificates problem so I hope they'll address that but I don't have more info on the subject, I just saw that new CA days ago, so I don't know when it appears nor if it will stay that way
<vila> from the bzr point of view, as of today, either you use pycurl and relies on it to find the right certificates (or use CURL_CA_BUNDLE env var) or you use urllib and certificates are not verified at all
<lifeless> siretart: you can overrite the ca certificates file with an env variable I believe
<lifeless> siretart: see vila's last line in fact
<siretart> lifeless: seems like a good candidate for being documented in the bzr manual for 1.0
<siretart> I think I can fiddle that out for me, but I now have a more easy workaround for myself
<lifeless> siretart: could be; you know where to record that :)
<siretart> lifeless: on my list. right after updating the opensync packages :)
<theSoftMan> Hello.. Does somebody have a comparative experience in using Bazaar and Subversion ?
<mwhudson> i suspect most of the people in here have used svn at one time or another
<AfC> theSoftMan: what are you looking for?
<theSoftMan_> I ask me what is the right choice for me ? actually i'm using CVS... and i'm looking for other one...
<theSoftMan_> I like subversion for it's branch versionning system, atomic commit, binaries files improvements, ...
<Zindar> hehe... it has no branches... it just thinks it does :)
<theSoftMan_> but bazaar looks very "sympatic" too but the GUI for Windows system are not so user friendly as subversion ones ( IMHO )
<Zindar> (sorry.. I'd like to answer... but got a phone call...)
<theSoftMan_> How bzr treat binary files ?
<vila> jam-laptop: ping
<jam-laptop> vila: pong
<vila> time to synchronize :)
<vila> I just replied to an email before seeing the next
<vila> the simple fix for 165061 has been merged
<jam-laptop> i saw that, which is good
<jam-laptop> did you include a NEWS entry?
<vila> yes, before merging
<vila> lifeless gave the bb:aprove here and and launchpad so I merged a few hours ago
<vila> s/and and/and on/
<jam-laptop> sure, and I certainly gave you bb:approve
<jam-laptop> your patch is definitely correct and an improvement
<vila> so, you propose to still coalesce until we get a reasonable number of ranges
<jam-laptop> I just think we can go a bit further
<vila> I'm concerned about downloading too much data compared with issuing several get requests
<jam-laptop> I think issuing multiple requests is *better*, but harder for us to do right now
<jam-laptop> And as I mentioned, we may want to limit any given collapsed range
<jam-laptop> depending on how we fix the incremental parser
<vila> ha, ok, so you think the risk to encounter too much ranges is still high and want to guard against that until we implement several gets ?
<jam-laptop> right
<jam-laptop> I think in *my* repositories
<jam-laptop> you are going to get a lot of fragmentation
<jam-laptop> bzr.dev and roberts repository
<jam-laptop> are probably rather clean
<jam-laptop> mine have a lot of uncommits
<jam-laptop> and revisions from other projects
<jam-laptop> While my public would be a bit cleaner
<jam-laptop> (since pushing from local to remote would clean it up a bit)
<jam-laptop> I still have a lot of branches in 1 repository
<jam-laptop> and not all of them will have been merged
<vila> hmmm, I wish we could test against that simply...
<jam-laptop> vila: I can put it up for you if you want
<jam-laptop> I can probably push it up to a canonical server
<jam-laptop> so you don't abuse my bandwidth
<vila> or you can push it up here, so *you* abuse mine :-)
<vila> then I should find a good candidate from your heads()
<jam-laptop> I can give you a few branches along with it
<ubotu> New bug: #172360 in bzr "bzr 0.92 unable to branch from knit repo to pack repo" [Undecided,New] https://launchpad.net/bugs/172360
<n[ate]vw> is there a way to add a file "sÃ¼bÏÎ¿Î»Î´ÎµÏ/ÆilÅ" to a bzr repository? my LANG=en_US.UTF-8, and bzr says encoding: 'UTF-8', fsenc: 'utf-8', but no love
<n[ate]vw> (hmm, my IRC client doesn't seem to be showing any conversation....)
<n[ate]vw> I'm trying to add a unicodey folder/file to bzr, and getting no love. when it spits back the error it does say encoding/fsenc/lang all UTF-8, though.
<dato> added "sÃ¼bÏÎ¿Î»Î´ÎµÏ/ÆilÅ"
<n[ate]vw> hey, so my earlier messages must have gone through
<n[ate]vw> it says:
<n[ate]vw> added "sÃ¼bÏÎ¿Î»Î´ÎµÏ", then bzr: ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'file_id'
<n[ate]vw> (that's if I bzr add the folder)
<n[ate]vw> when I try to add the file itself I get the same "added <folder>", then: bzr: ERROR: The file id "None" is not present in the tree <Inventory object at 11d5f10, contents={ ....massive dump..... }
<fullermd> Works for me, too, with 0.92 and .dev.
<jam-laptop> n[ate]vw:  can you post the traceback to a pastebin?
<jam-laptop> !paste
<ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<n[ate]vw> yeah, I can
<rthalley> works for me with bzr.dev
<dato> works for me to, but when I `bzr revert`, it reverts, but then spits an error
<dato> involving loggin, I think; sorry, I lost it
<n[ate]vw> http://paste.ubuntu-nl.org/46007/ for the folder
<fullermd> Mmm.  Darwin.
<jam-laptop> hmm....
<jam-laptop> that looks like parent_ie is being None
<jam-laptop> which is a bit odd
<jam-laptop> n[ate]vw: what happens if you use just plain "bzr add" ?
<jam-laptop> to recursively add everything.
<n[ate]vw> similar error to adding the folder
<n[ate]vw> http://paste.ubuntu-nl.org/46010/ for the file directly
<n[ate]vw> hold on, the plain 'bzr add' ives back a KeyError exception instead
<n[ate]vw> http://paste.ubuntu-nl.org/46012/ for the recursive add
<n[ate]vw> (paste.ubuntu-nl is hosing some of the unicode -> ??? in those dumps)
<n[ate]vw> anyone else able to reproduce, or workaround? (sorry, might have missed first responses)
<n[ate]vw> (my client started cooperating @ "I'm trying to add a unicodey folder/file to bzr")
<jam-laptop> wait a sec, your on Mac, right?
<jam-laptop> n[ate]vw: I wonder if there is a path normalization problem
<n[ate]vw> yeah, OS X 10.5.1
<jam-laptop> as in, when you create a file with Ã¥
<jam-laptop> you might type it is as u'\xe5'
<jam-laptop> but the FS changes it to
<jam-laptop> 'u'a\u030a'
<jam-laptop> certainly I'm seeing u'su\u0308'
<jam-laptop> which would be u with dots
<jam-laptop> (u) (with dots)
<jam-laptop> rather than
<jam-laptop> (u with dots)
<jam-laptop> (u'\xfc')
<n[ate]vw> doesn't bzr convert to a normalized form internally?
<jam-laptop> we used to
<jam-laptop> but it added a lot of overhead
<jam-laptop> and broke when platforms didn't normalize themselve
<jam-laptop> selves
<jam-laptop> It turns out that Windows likes to do mixed normalization
<jam-laptop> Sometimes using wide parethesis
<jam-laptop> but usually using narrow
<jam-laptop> etc
<jam-laptop> there are also some heavy performance issues if you have to normalize every file in a 50k entry tree
<n[ate]vw> but if bzr doesn't do any normalization internally, wouldn't it just keep whatever the shell passed it?
<n[ate]vw> or fs, in the case of adding the tree recursively,
<n[ate]vw> -,
<jam-laptop> except the shell could have passed in one
<jam-laptop> versus the fs
<jam-laptop> but yeah, I would think recursive adding would have worked
<jam-laptop> let me try that here
<jam-laptop> I can reproduce it here
<jam-laptop> I'll try to track it down
<n[ate]vw> great, thanks
<n[ate]vw> fwiw, mercurial seems to have handled the same folder fine. no complaints on add, and I was able to clone the repo succesfully.
<jam-laptop> n[ate]vw: you might want to try checking it out on another platform
<jam-laptop> at least Windows will puke pretty badly
<jam-laptop> last time I tried that
<jam-laptop> well, not puke
<n[ate]vw> hg, or bzr?
<jam-laptop> but it puts the UTF8 strings into OEM encoding
<jam-laptop> so all the names are bad
<jam-laptop> hg
<jam-laptop> hg doesn't pay attention to Unicode
<jam-laptop> so it just versions 8-bit strings
<jam-laptop> which depends on your encoding
<n[ate]vw> ah, indeed
<jam-laptop> so while Windows fs is MBCS
<jam-laptop> you will get different paths on Russian windows
<jam-laptop> versus US windows, etc.
<fullermd> So it causes double-pane on Windows?
 * fullermd sneaks back under a rock.
<dato> I've asked in several channels, so I guess one more can't hurt.
<dato> I'm looking for a tool to manage my configuration files, particularly distributing them over a set of remote machines. I would like to be able to specify which files to transfer, if non-default versions of them are to be transferred, and ideally, that the tool is able to detect remote changes and merge them back, or not.
<n[ate]vw> by "merge them back", do you mean a diff or just picking one copy of the file? unison is able to do two-way sync, but I'm pretty sure it doesn't do text merges
<n[ate]vw> jam-laptop: should I file a bug on the OS X unicode issues, or will you once you've looked into it
<jam-laptop> submit one, and I'll comment on it
<n[ate]vw> I'm assuming nobody is interested in seeing the several-KB dump when I add the file directly?
<n[ate]vw> I suppose I could just link to the pastebin, if those don't get cleaned out too quickly
<n[ate]vw> I did find this https://lists.ubuntu.com/archives/bazaar/2007q2/024773.html, which clarifies the problem a bit but seems to be posted before the normalization routines were removed
<sabdfl> hey folks
<sabdfl> do we have dapper packages for bzr 0.92 yet?
<dato> doesn't seem so
<ubotu> New bug: #172383 in bzr "Cannot add normalized Unicode file to repo" [Undecided,New] https://launchpad.net/bugs/172383
<n[ate]vw> jam-laptop: filed https://bugs.launchpad.net/bzr/+bug/172383
<ubotu> Launchpad bug 172383 in bzr "Cannot add NFD normalized Unicode file to repo" [Undecided,New]
<n[ate]vw> whoops, bot beat me
<n[ate]vw> so currently, bzr stores filenames in whatever form they are received, but is aware they are Unicode when writing to disk (the distinction from hg)?
<n[ate]vw> I guess I'm still wondering how bzr stores/compares the filenames in memory, and whether normalizing only when checking equivalence would be a good compromise
<n[ate]vw> (or maybe "checking equivalence" doesn't happen like that, I don't really know anything re: the internal architecture)
<jam-laptop> n[ate]vw: no, I just responded to bug 172383
<ubotu> Launchpad bug 172383 in bzr "Cannot add NFD normalized Unicode file to repo" [Undecided,New] https://launchpad.net/bugs/172383
<jam-laptop> Some of the normalization calls are still present
<n[ate]vw> not seeing how this relates to bug #165071
<ubotu> Launchpad bug 165071 in bzr "check reports spurious unreferenced texts" [Undecided,New] https://launchpad.net/bugs/165071
<jam-laptop> n[ate]vw: just a bad copy and paste on my part
<jam-laptop> I meant bug 102935.
<ubotu> Launchpad bug 102935 in bzr ""combined" unicode characters are renamed on Mac" [Wishlist,Confirmed] https://launchpad.net/bugs/102935
<jam-laptop> vila: what is the status of your fix for bug 164567
<ubotu> Launchpad bug 164567 in bzr "FTP push does not work without specifying password" [Medium,Fix committed] https://launchpad.net/bugs/164567
<jam-laptop> nm, it was merged in 3025
<jam-laptop> But your name wasn't mentioned in the commit message
<jam-laptop> so i had trouble finding it
<n[ate]vw> jam-laptop: no prob. from that ticket, do I understand if I were add a directory named sÃ¼b on an NFC fs, and then clone it to an NFD fs, bzr would eventually: 1) notice the file missing internally, 2) normalize the name and find it in the new form, and 3) do the right thingâ¢?
<jam-laptop> n[ate]vw: from 102935?
<jam-laptop> no, unfortunately not anymore
<jam-laptop> it used to
<jam-laptop> but because of problems of users having filenames in mixed normalization on other platforms...
<jam-laptop> (and for whatever reason not being able to change their filenames)
<lifeless> hi
<jam-laptop> morning lifeless
<jam-laptop> any chance you had time to backport any bzr releases to dapper?
<n[ate]vw> when dealing with a "missing" file would it be possible to normalize both sides of the comparison - disk names vs. internal name - or would that case be a recurring performance drag?
<lifeless> jam-laptop: if we we're scrambling to make packs default, sure.
<jam-laptop> lifeless: sabdfl was just in earlier asking for them, and I know we haven't been getting regular backports to dapper
<jam-laptop> I understand you are busy with other things
<jam-laptop> Maybe someone else should be doing the .deb building?
<lifeless> he wanted them for the datacentre
<lifeless> elmo has rolled it out already
<jam-laptop> k
<lifeless> there is a patch I need to apply
<lifeless> so whats up with NFD ?
<ubotu> New bug: #172392 in bzr "interrupting a client waiting for a lock over bzr+ssh leaves process on server" [Undecided,New] https://launchpad.net/bugs/172392
<jam-laptop> Mac stores everything as NFD, our current code is normalizing them when creating an Inventory Entry
<jam-laptop> but then the "smart_add" code doesn't realize that
<jam-laptop> and looks up the NFD
<jam-laptop> So Inventories are still NFC only
<jam-laptop> but the smart_add() code is using NFD
<lifeless> grah
<lifeless> andyou're saying 'dont fix smart_add, stop normalising' ?
<jam-laptop> We *could* go through this again and try to make smart_add use NFD
<jam-laptop> lifeless: correct
<jam-laptop> we have a bug open for it
<jam-laptop> because other wise on mac
<jam-laptop> bzr add Ã¼
<jam-laptop> bzr status
<jam-laptop> will show Ã¼ as missing
<jam-laptop> and an unknown file Ã¼ as being present
<jam-laptop> If we fix smart_add
<jam-laptop> we have to fix status, etc.
<lifeless>  well you're the guru
<lifeless> but I don't see anything thats changed the validity of your prior argument *to* canonicalise.
<lifeless> brb
<jam-laptop> lifeless: the effort required to get it working with dirstate trees
<jam-laptop> and the performance hit of normalizing
<jam-laptop> n[ate]vw: that might be possible
<jam-laptop> n[ate]vw: then what happens when someone stores both forms on disk...
<jam-laptop> there is also a possibility to work this into case-insensitive issues as well
<jam-laptop> lifeless: oh, and on Windows, it likes to create non-normalized names under certain situations
<jam-laptop> lifeless: Japanese Windows was creating filenames with Wide-form parenthesis IIRC
<n[ate]vw> heh, I suppose there's some OS that would allow both Ã¼'s on the same branch
<jam-laptop> Which meant that we couldn't version them, since they cannot be accessed under their other names
<jam-laptop> n[ate]vw: another possibility was to store the canonicalized name, as well as the form on disk
<jam-laptop> so that when scanning through directories
<jam-laptop> we could see which path lines up with which other one
<jam-laptop> it certainly would be nice to only do this sort of thing on "misses" rather than for every file
<n[ate]vw> so each clone could have the working copy in the OS-preferred format, but internally it would be stored canonically?
<n[ate]vw> doing something just on misses might be nice for performance, but I'd be worried it would just be wacking one mole to come up again in some other function. I don't know bzr well enough to say, though
<jam-laptop> the old code did it only for misses
<jam-laptop> but always normalized in one direction
<jam-laptop> os => normalized form == internal form
<jam-laptop> otherwise when you get a miss
<jam-laptop> you have to normalize everything (at least in that directory)
<jam-laptop> since you don't know *which* one it should have been pointing at
<jam-laptop> (since, after all, it missed)
<fullermd> Well, you could skip all the known files at least.
<jam-laptop> true
<jam-laptop> I suppose you could keep track of what things hit, and what missed
<jam-laptop> and then at the end compare them
<jam-laptop> however,
<jam-laptop> the current api (I believe) expects to get everything in sorted order
<jam-laptop> so you have to defer returning anything
<jam-laptop> until you have processed the whole directory
<jam-laptop> not terribly onerous
<jam-laptop> but probably would have an impact
<n[ate]vw> wow, that's a tough problem. it'd be nice to get it right by using a canonical form internally, but then it gets benchmarked against a system that ignores some of those issues....
<n[ate]vw> do users expect bzr to keep the original working form on all same-platform clones?
<n[ate]vw> especially with regards to mixed-normalization?
<jam-laptop> n[ate]vw: well the concern is that the program generated mixed normalization (MS Office)
<jam-laptop> is going to do weird things once you change the normalization.
<n[ate]vw> so in the jp locale, MS Office doesn't even want to open a file if it doesn't use fullwidth parentheses?
<n[ate]vw> jam-laptop: you'd almost need to keep track of three forms: original form as added, canonical form, form on disk
<lifeless> jam-laptop: have you looked at the new check refcount error ?
<jam-laptop> lifeless: it looks like it is still present
<lifeless> k, I'll fix it then
<jam-laptop> !paste
<ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<jam-laptop> lifeless: the simple fix should just be: http://paste.ubuntu-nl.org/46034/
<jam-laptop> A more complex one would intersect "planned_revisions" with w.versions()
<lifeless> abentley: ping
<Lo-lan-do> Hallo
<Lo-lan-do> I'm stracing a bzr process, just for fun, and I see it repeatedly uses (and unlinks) /tmp/tempfile.tmp
<Lo-lan-do> That sounds like a potential security problem, but I'm not sure where it comes from.
<Lo-lan-do> (I'm pulling changes from a local bzr-only branch into another branch bound to an SVN repo)
<jam-laptop> Lo-lan-do: are you sure it isn't running the test suite?
<Lo-lan-do> During a "bzr pull"?
<jam-laptop> and is it always explicitly "/tmp/tempfile.tmp"
<jam-laptop> or is it using a randomized name
<lifeless> Lo-lan-do: I suspect its a bug in bzr-svn
<lifeless> jelmer: ^ can you confirm?
<lifeless> Lo-lan-do: bzr itself doesn't do that.
<Lo-lan-do> There are random names plus /tmp/tempfile.tmp
<jelmer> it only uses tempfiles for svn dump files
<lifeless> jelmer: does it use a hard coded name though?
<jelmer> no
<jelmer> tempfile.mkdtemp(prefix='bzr-svn-dump-')
<Lo-lan-do> Maybe svn-python then.
 * Lo-lan-do grabs the source package
<jam-laptop> yeah, I don't see that existing anywhere in the bzr-svn source
<jelmer> svn-python doesn't really provide any functionality, it just wraps libsvn
<jelmer> and I would be surprised if svn used that file
<lifeless> Lo-lan-do: thanks for noticing this
<Lo-lan-do> http://paste.debian.net/43600
<lifeless> Lo-lan-do: we'd obviously like to fix it; i you can figure out what is doing it that would be fantastic
<jam-laptop> any chance you could find what is being written to the file?
<lifeless> Lo-lan-do: at least within python you can override open and file
<Lo-lan-do> Any wlue what line 3 looks like?
<jam-laptop> maybe have a process that spins waiting for it to appear and dumps the content
<jam-laptop> I guess the write() calls
<jam-laptop> say it is dumping SVN  data into it
<lifeless> line 2 suggests SVN
<jelmer> Lo-lan-do: can you try with -s 4000 or something?
<Lo-lan-do> Yeah
<jam-laptop> Lo-lan-do: line 3 *looks* like it might be the data you are copying
<jam-laptop> it looks like english with a typo
<jam-laptop> 'latd' => 'late'
<jam-laptop> other 2, or (atr op) any late inhomogeneous...
<Lo-lan-do> http://paste.debian.net/43603
<Lo-lan-do> ./subversion/libsvn_client/ra.c:  truepath = svn_path_join(truepath, "tempfile", pool);
<Lo-lan-do> Sounds fishy
<lifeless> yay svn
<lifeless> quick, make an exploit
<Lo-lan-do> Maybe I'll just quietly report the problem first :-)
<Lo-lan-do> Hm.  Actually, that file is opened with O_EXCL, which fails if a symlink exists.
<Lo-lan-do> ...and it even retries with another name if it can't use that precise file.
<Lo-lan-do> False alert, then, I guess.
<lifeless> Lo-lan-do: still *looks* suspect, and shouldn't be hard to fix
<lifeless> what happens if you create that file in advance
<lifeless> as root, without permission to unlink
<lifeless> (for your user)
<Lo-lan-do> From what I read from the code, it tries /tmp/tempfile.2tmp
<Lo-lan-do> If that still fails, /tmp/tempfile.3tmp and so on
<lifeless> abentley: ping
<lifeless> jam-laptop: ping
<lifeless> jam-laptop: poolie did not review my fix for 165306; perhaps you could before you finish today ?
<jam-laptop> lifeless: sure
<lifeless> jam-laptop: thanks.
<lifeless> jam-laptop: thanks, replied.
<lifeless> bbiab food
<poolie> jam, lifeless: ping
<poolie> one minute
<igc> morning
<jam-laptop> morning igc
<poolie> hi igc
<lifeless> jam-laptop: conf call
<poolie> coming to the meeting?
<igc> yes
<abentley> lifeless: pong
<jam-laptop> yep
<lifeless> abentley: hi, jst on a call, but will get back to you soon, its about LCA and merge
<jam-laptop> lifeless: you don't have to pop the commit, it is fairly trivial, though it has a lot of baggage for such a simple change.
<jam-laptop> lifeless: are you sure you want to use __heads? __ parameters can't be used by subclasses
<lifeless> jam-laptop: yes, I do
<lifeless> jam-laptop: I wanted to use heads() -> _heads(), but you thought that was too public.
<lifeless> jam-laptop: we're under a lot of time pressure and I just want to get this out of the way.
<jam-laptop> k
<jam-laptop> you could just name it
<jam-laptop> _graph_heads()
<lifeless> if you're not feeling the pressure, fix more bugs:)
<jam-laptop> but anyway
<lifeless> abentley: hi, so. Did you see my mail about resolving >1 LCA's by merging amonst them rather than recursing for a deeper LCA ?
<abentley> You mean the way git does?
<lifeless> jam-laptop: I've commented on the missing compression parent bug
<lifeless> abentley: appears to; yes.
<jam-laptop> thanks
<lifeless> jam-laptop: the basic thing is to avoid individual index lookups; so batch and dispatch.
<abentley> I don't see why we'd want to do that.
<abentley> You can get multiple sets of conflicts, one per merge.
<lifeless> abentley: if it can correctly merge without conflicts, even an addition 10% of the time, I'd love it.
<lifeless> abentley: I was reminded of this when I spend 40 minutes this morning resolving conflicts because I had a dual-LCA situation
<abentley> I'd rather focus on making knit merge rock than follow git's weirdness.
<lifeless> abentley: well; I guess I'm asking if its *weird*, or if they've come up with a solid answer.
<lifeless> abentley: I agree re: making knit merge rock; its a shame that it will suck in 1.0.
<lifeless> (because packs are unannotated)
<jam-laptop> what if we go back to per-file LCA's?
<jam-laptop> (well, go to, as we haven't ever done it before)
<lifeless> jam-laptop: abentley has previous indicated he's against that because it doesn't solve the root problem of >1 LCA's, only defers it.
<jam-laptop> The usually have a less complicated graph
<lifeless> jam-laptop: my opinion is that deferral is fine if its an improvement :).
<abentley> lifeless: Even with un-annotated knits, I bet we can to knit merge quickly.
<abentley> As long as we don't annotate lines we don't need to annotate.
<jam-laptop> lifeless: your comment on bug 165290 seems like you only detect corruption after the fact, rather than preventing it from the beginning.
<ubotu> Launchpad bug 165290 in bzr "packs do not check for missing compression parents" [Critical,In progress] https://launchpad.net/bugs/165290
<lifeless> abentley: if a line is common that doesn't mean it has the same introducing revision;
<abentley> I actually think using the per-file graph might make sense now.
<lifeless> jam-laptop: atomic insertions remember
<jam-laptop> write_group.abort?
<abentley> lifeless: If a line is common, we don't try to trace its origin in the first place.
<lifeless> jam-laptop: just raise an error, there is a sample there - look for missing_texts
<lifeless> abentley: oh, ok
<abentley> First step in a knit merge is finding the differences in the un-annotated texts.
<abentley> So if they came from different sources, but they're the same now, we leave them alone.
<abentley> I'm by no means trying to stop other people from implementing merge algorithms.
<abentley> But I think knit is the most promising, especialy wrt cherry-picking.
<abentley> And using the per-file graph is probably a good fallback strategy when we *are* doing three-way, since semantic mergers will be three-way mergers.
<lifeless> yay!
<lifeless> jam-laptop: are you redoing your http readv change patch ?
<jam-laptop> I submitted an update
<jam-laptop> I'm not sure what you are looking for
<lifeless> to bb or the bug ?
<jam-laptop> to bb
<lifeless> the bug is now marked closed wth vila's patch in
<lifeless> http://bundlebuggy.aaronbentley.com/request/%3C474C1123.1050903@arbash-meinel.com%3E ?
<jam-laptop> lifeless: yes
#bzr 2007-11-28
<lifeless> jam-laptop: ok, reviewed.
<lifeless> basically I think what you have done is the wrong approach, though the code is reasonable.
<lifeless> jam-laptop: and I've suggested an alternative approach
<jam-laptop> lifeless: I think that might end up returning data out of order
<jam-laptop> coalesce will re-order to get better packing
<lifeless> jam-laptop: so some options.
<lifeless> we could coaelsece knowing that we'll submit 200 at a time
<jam-laptop> I suppose you could just not collapse them?
<lifeless> so we have a window of 200 and we pack linearly out-of order up to 200, then a new window etc
<lifeless> another option is to do what I suggest but use that to accumulate the result rather than to return it
<lifeless> that is, coalesce optimally, then do all the reads, then start yielding in-order.
<lifeless> (also not that we have an out-of-order-is-ok option for readv)
<lifeless> s/not/note/
<abentley> Can't we just join the gaps between ranges until we have a suitable number of ranges?
<jam-laptop> abentley: lifeless is saying that it ends up downloading too much
<lifeless> abentley: that results in reading vast amounts of data
<jam-laptop> that was my approach
<lifeless> its exactly the bug that I filed
<lifeless> now it turned out that the case I filed was trivially solved, but when it gets more complex we will still trigger bad behaviour
<lifeless> the cost of a new round trip, for nearly anyone on the planet is < 2 seconds
<abentley> Right.
<lifeless> a 512kbps line - thats 1Mbit, or 128K
<jam-laptop> I *do* think that multiple GETs is the right approach
<jam-laptop> this was mostly expedient
<jam-laptop> (Default fudge is 128 bytes, by the way)
<lifeless> so any expansion over 128K is a net loss in this scenario.
<abentley> Well, I'm going over to the dark side to see if I can't get the case-insensitivity problems fixed.
<lifeless> faster links expand the amount we can tolerate, but also tend to reduce latency, shrinking it.
<lifeless> abentley: may the force be with you
<abentley> tx.  laters.
<jam-laptop> abentley: good luck, later
<Peng> Hmm, anything happen since Thursday?
<lifeless> code
<Peng> Wow, pulling bzr.dev has been going for almost 5 minutes now.
<fullermd> Well, it took me a minute and a half, and I pulled yesterday, so...
<Peng> What did you do, update to Python 3k?
<Peng> Rewrite it in Perl? :D
<Peng> Just finished. 7 minutes.
<Peng> It only downloaded r3011-3038.
<lifeless> you're probably experiencing the http readv coalescing bug
<lifeless> that we fixed:)
<Peng> Were 'bzr cat' and bzr+ssh fixed for packs?
<lifeless> yes
<Peng> Yay.
<Peng> 'Course, I'd have to use bzr.dev..
<lifeless> though mixed packs and knits over bzr*:// may do bad things
<Peng> lifeless: Mixed?
<lifeless> its being investigated right now
<Peng> Like having a pack repo locally and pushing to a knit repo?
<lifeless> bzr pull bzr+ssh://someknitrepo local-pack
<lifeless> pushing will be fine
<Peng> Okay, good.
<lifeless> pull may insert incorrectly formatted data.
<lifeless> look at bugs tagged packs in launchpad
<Peng> Um. How bad is that?
<Peng> Is that like rm-the-repo bad or reconcile-while-whine-some-more bad?
<lifeless> Peng: *if* it doesn't handle it correctly, you'll get raw knit hunks that are annotated in a pack repo; or vice verca.
<lifeless> if the error checking is there (I think it is), it will just error.
<lifeless> Peng: and this *only* affects pull.
<Peng> Oh.
<Peng> Does it affect clone?
<lifeless> cloning is pulling
<Peng> Or merge?
<Peng> Okay.
<lifeless> merging does a pull
<lifeless> basically, if you have a pack repo today, don't pull/merge/whatever from a knit repository over bzr+ssh using bzr.dev until https://bugs.edge.launchpad.net/bzr/+bug/165304 has some comments on it
<ubotu> Launchpad bug 165304 in bzr "smart server data streams not used across repository	representations" [Undecided,New]
<Peng> will*
<Peng> lifeless: Like I said, is it rm-the-repo bad or reconcile-will-whine-some-more bad?
<lifeless> rm the repo
<fullermd> IWBNI(tm) the SS data were totally divorced from the repo formats.  That way the client wouldn't even have to be able to read or know anything about the server format (or vice versa), as long as it could store the requisite data.
<fullermd> I'd also like a pony.
<lifeless> fullermd: it is
<lifeless> fullermd: the question is if the client code DTRT
<fullermd> I'm pretty sure it isn't, as broadly as I mean it.
<Peng> Hmm.
<Peng> This affects 0.92 too, right?
<lifeless> Peng: 0.92 is safe because bzr+ssh and packs will just die
<Peng> Haha. That's right.
<Peng> I think I'll stick with using sftp just to be safe.
<fullermd> My bzr 1.0 client Should(tm) be perfectly able to read over bzr*:// a branch9/pack5 branch, as long as my local data format can store all the same info as the remote.
<Peng> Even though I won't pull much.
<Peng> Well, I don't expect to pull over bzr+ssh at all, but just to be safe...
<lifeless> fullermd: yes, for the current smart server verbs, thats exactly what can be done
<lifeless> fullermd: we haven't made all operations smart server verbs, so it won't actually /work/ but that's being picky :)
<Peng> Hey, wait a minute. Isn't this a data loss bug? Or are they okay in bzr.dev?
<lifeless> Peng: bzr.dev is fine
<lifeless> Peng: sorry, I don't get what you mean quite;
<fullermd> Well, in much the same way that we're totally faster than git; it's just incompletely implemented   ;p
<Peng> The homepage claims you've never had a data loss bug or something.
<lifeless> Peng: in a release
<Peng> Heh.
<fullermd> Riding dev head on anything is wild and wooly.
<Peng> How many data loss bugs have snuck into bzr.dev? :X
<lifeless> right now, there is this *potential* one. And its not necessarily a bug: we're checking.
<fullermd> (says the guy running bzr head under his window manager head+ on his OS head...)
<lifeless> its 'There might be a problem, please dont do X until we have checked'
<lifeless> not 'There is a problem, dont do X'
<Peng> Both mean "don't do X".
<lifeless> right.
<lifeless> and in a few hours we'll know if this is an actual bug or not
<lifeless> I suspect its not, it will just error. But safety first.
<lifeless> hi jelmer
<Peng> Man, my cat sat down on my lap literally 30 seconds before I was planning to get up.
<fullermd> That's pretty bad.  Most cats have much better timing than that; 30 seconds is long enough that you might think it a coincidence.
<Peng> Heh.
<Peng> I've been away for a few days too.
<Peng> Anyway, bye.
<lifeless> ciao
<Peng> To help decide which VCS to use, are you guys dog or cat people? :)
 * Peng wanders over to #mercurial to ask, and then leaves.
<fullermd> Probably merits a FAQ entry...
<lifeless> cat person
<lifeless> is what I am
<poolie> looking at bug 164443
<ubotu> Launchpad bug 164443 in bzr "can't branch bzr.dev from codehost over bzr+ssh" [Critical,Confirmed] https://launchpad.net/bugs/164443
<lifeless> poolie: I'm waiting for pqm to quiesce to reconcile it for you
<poolie> the bzr.dev branch
<poolie> you can kill my 'post-review cleanups' branch if that would be easier
<lifeless> hmm,  I might do that.
<lifeless> reconcile started
<poolie> ok
<poolie> do i need to resubmit that, or will you reenqueue it when it's done?
<lifeless> you will need to resubmit
<lifeless> it's in the replay set already
<jelmer> the FAQ mentions tailor, svn2bzr and bzr-svn for migrating from svn (in that order)
<jelmer> I think tailor shouldn't be listed first because it's going to give the worst results of the three
<lifeless> agreed
<lifeless> surely bzr-svn is the best
<fullermd> That's so that by the time the user gets to bzr-svn, they really appreciate it   ;)
<poolie> what is a replay set?
<lifeless> poolie: the hash from the gpg signature is noted
<lifeless> poolie: if we get the same again it is rejected
<lifeless> stops replay attacks
<lifeless> Peng: bzr+ssh is safe
<lifeless> Peng: it will just error
<abentley> Phew!  Made it back with my soul intact.  Turns out the last version of bzr I had on Windows was 0.8
<lifeless> rofl
<lifeless> poolie: we're safe to change the default
<abentley> bialix isn't kidding when he says it's messy.  I fixed four test cases for transform while I was there.
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/165304
<ubotu> Launchpad bug 165304 in bzr "smart server data streams not used across repository	representations" [Undecided,New]
<lifeless> abentley: cool
<abentley> lifeless: I know that WorkingTree4 has a much stricter locking policy, but I wonder if we should have the same policy for is_executable on *nix and win32.
<lifeless> abentley: I'm not sure what you mean
<lifeless> could you phrase it as a change
<abentley> *nix doesn't need a lock and win32 needs a lock.
<lifeless> I said in a review to bialix that I thought requiring a lock on unix was fine
<abentley> We could wrap is_executable in a lock decorator, or we could make it require a lock even on *nix.
<lifeless> he had some massive cruft in his 'make things be known failures' patch
<abentley> Okay, maybe that's a saner way forward.  Otherwise, we'll just introduce new lock failures without noticing.
<lifeless> I think most things should require a lock; because it will help track adhoc api abuse
<lifeless> that can cause errors and performance bugs
<abentley> I miss the days when locks were almost implicit.
<lifeless> it was easy
<lifeless> but it performed terribly
<ubotu> New bug: #172483 in bzr "progress bars on http push behave badly" [Undecided,New] https://launchpad.net/bugs/172483
<Peng> lifeless: Great.
<abentley> lifeless: One thing I noted on win32 is that our config directory is still *\Bazaar\2.0\
<abentley> I don't know if we *can* fix it, but it seems like it would be good.
<lifeless> well, we'll reach 2.0 eventually :)
<dewd> btw, I'm updating to trunk latest to give pack a new try with bzr+ssh push. :P hopefully it's going to work. hehe. exciting.
<lifeless> dewd: okies
<lifeless> dewd: it should packs->packs
<dewd> i thought it was the default format already. looks like dirstate-tags is the one still
<dewd> something wrong? I created a new packs repo on the remote server, and when branching it on the local machine with bzr+ssh, the local format says "dirstate-tags".
<abentley> dewd: No, that's a bug.
<lifeless> I'm just looking it up in fact
<lifeless> bug 164628
<ubotu> Launchpad bug 164628 in bzr "branching from hpss doesn't preserve repository format" [High,Confirmed] https://launchpad.net/bugs/164628
<abentley> You can work around it by creating a branch in pack fomat, then pulling into it.  Or by not using the smart server for the branch command.
<dewd> ok. thx.
<spiv> Hello everyone.
<spiv> I'm back from honeymooning.
<lifeless> poolie: check passed; pushed to a packs branch, then pushed that to a new one gave the same size pack, now running check in the resulting branch
<spiv> lifeless: good afternoon
<lifeless> yo spiv
<poolie> hello spiv
<lifeless> you working or slumming?
<spiv> poolie: hello.
<spiv> lifeless: working a half day, starting now.
<poolie> i should really go and see "Keating!"
<spiv> poolie: I nearly saw that, but the night I had tickets for got cancelled due to a performer having a cold :(
<poolie> lifeless, is pqm running? the web ui is stuck on the output from my killed job
<poolie> it's still running
<poolie> he's not very kind to spivs though :)
<lifeless> poolie: yes, pqm is running, dunno why the UI shows that
<lifeless> poolie: oh, I know
<spiv> Heh.
<poolie> lifeless, you're right, using a reconciled branch in the same way works fine
<lifeless> poolie: its got jobs,s o the status file looks like the end of the run I canned
<poolie> ?
<poolie> spiv, quick call?
<spiv> poolie: jml just got in first
<spiv> poolie: I'll ping you when we're done?
<poolie> just call me
<poolie> lifeless, you were right it just needed reconcile
<spiv> poolie: will do
<Peng> Wow, almost 1 MB pack from just the last 6 days.
<Peng> (... of changes to bzr.dev)
<dewd> wow. packs rocks
<abentley> lifeless: if you've got a branch where packs are the default, I'd be interested in running bzrtools against it.
<lifeless> abentley: I posted a patch to the list
<lifeless> just change the format name to pack-0.92 and it will work
<lifeless> dewd: glad you like them
<poolie> spiv, the streaming hpss changes don't seem to be mentioned in NEWS; can you please add something appropriate?
<spiv> poolie: ack
<thumper> hi spiv
<abentley> spiv: welcome back.
<thumper> spiv: welcome back
<thumper> abentley: snap
<abentley> heh.
<dewd> lifeless: packs seems much more network friendly for me now in my sample tests. congrats. :-)
<lifeless> dewd: we have quite a few future enhancements planned
<lifeless> that will help even more
<spiv> abentley, thumper: thanks!
<dewd> it's a winner in my book. nice decision to go for it sooner. much more pleasant
<poolie> great
<lifeless> poolie: ok, it passed, migrating to escuderi
<Peng> ISTM that if one is going to use packs, one should use bzr.dev.
<lifeless> Peng: seems fair to me.
<lifeless> in 0.92 they were explicitly tagged experimental
<Peng> True.
<Peng> I didn't expect that "experimental" would mean "half-broken", though.
<Peng> Honestly, I thought that they were marked experimental because they weren't fully optimized and because you're planning to change the format a couple times in the future. I didn't know that there was more work to be done for them to work fully.
<Peng> Hmm. "bzr diff -c X.Y" seems to be a lot slower than "bzr diff -c Z".
<Peng> Woah, you made bzr.dev packs already?
<lifeless> Peng: we'll issue more versions of packs as we change it.
<Peng> Mm-hmm.
<Peng> That's whast I meant.
<Peng> what*
<lifeless> ok.
<lifeless> Peng: diff -c x..y will have to extract two full inventories vs 1, so if thats slow (many files) then yes.
<Peng> lifeless: Not two dots, just one. The crazy revnos from branching and merging.
<lifeless> oh, hmm..
<Peng> It's not like I did real scientific testing. But when reading through the log of new things in bzr.dev and diffing some, it felt slower.
<jamesh> Peng: do the two revisions change similar numbers of files?
<Peng> jamesh: Didn't pay attention.
<jamesh> i.e. could it be that the time taken is proportional to the size of the change rather than whether it is on mainline
<Peng> Since I'm using packs, would you recommend using bzr.dev? I mean, I'm afraid of data loss and stuff, so I don't even always use the release candidates.
<jamesh> the other check would be to see whether "bzr diff -c revid:whatever" differs in speed to the dotted lookup
<lifeless> abentley: please resubmit your patch
<abentley> Okay.
<lifeless> pqm is missing some lock correctness stuff itself
<poolie_> Peng, if you're concerned about data loss i'd generally recommend using releases
<lifeless> right now bzr.dev looks solid to me
<lifeless> Peng: we called it experimental cause it was; it was supported in 0.92, so if you had encountered corruption or something we'd have happily spent time fixing your data
<lifeless> Peng: and we needed more feedback on it; I wouldn't call it half-broken. It was literally 4 days work to fix all the glitches we encountered making packs be able to be default
<Peng> jamesh: Argh, not sure.
<lifeless> packs took way more than 8 days to make :)
<lifeless> poolie_: you too, please resubmit.
<lifeless> I'll monitor the first one to go through
<poolie_> again?! :)
<lifeless> yup
<Peng> jamesh: Um, yes. Using the revid changes 3009.2.29 from taking 8.5 seconds to 0.5.
<lifeless> tree.lock_write() FTW
<poolie_> done
<jamesh> Peng: I guess you've found the reason then
<jamesh> the dotted revnos are the sort of thing that could probably be cached in the branch though
<jamesh> so it is something that could be fixed
<Peng> lifeless: <kinda quiet voice>Well if it only took 4 days, you could've delayed the release.</>
<Peng> (</> is valid SGML, right?)
<lifeless> heh
<lifeless> ' needs & though
<jamesh> Peng: depends on your sgml definition
<jamesh> or whatever they call it
<Peng> :D
<lifeless> well, the release hasn't happened yet has it? And at 0.92 time that was a month ago, there was UDS and allhands, and time based releases
<i386> lifeless: ping
<lifeless> we didn't know at 0.92's timeframe how long the piece of string was, or what issues would arise
<lifeless> i386: yo
<lifeless> i386: you in SF?
<i386> yo
<i386> Yeah I am
<Peng> lifeless: Well, maybe not half-broken, but 'bzr cat' and pushing over bzr+ssh didn't work, and there seems to have been a *lot* of work in bzr.dev to fix things.
<jamesh> the SGML declaration is what I was thinking of
<Peng> Will bzr.dev being packs make pulling a lot faster?
<lifeless> Peng: try it ;), using bzr.dev because 0.92 has the http range combining bug
<Peng> I was just about to try it, then I discovered I have two extra copies of bzr.dev from November 2, at r2954. I wonder why?
<Peng> Both are dirstate-tags.
<Peng> One is dirstate.
 * Peng shrugs.
<Peng> Using packs over bzr+ssh, is there any reason to upgrade the server to bzr.dev?
<Peng> Or is 0.92 okay?
<lifeless> you'll need bzr.dev, there were a few broken methods
<Peng> Ooh.
<Peng> That sounds unappealing.
<Peng> Especially since I'll never remember to keep it up-to-date.
<lifeless> just the one update
<lifeless>  then at our next release you can switch back to releases
<Peng> Should I run check and reconcile now? Or will it still report millions of non-error errors and take gigs of RAM?
<lifeless> check and reconcile in bzr.dev are a-ok
<Peng> Last time I tried a couple weeks ago it used 1.6 GB of RAM.
<lifeless> they will check but not reconcile packs.
<lifeless> they will check and reconcile knits
<Peng> Blaah.
<Peng> Never mind, then.
<lifeless> pack reconcile is on my laptop and my top priority tomorrow
<Peng> :)
<lifeless> it got sidelined with this 'get packs ready for default'
<Peng> Wow.
<Peng> Err. Not wow at that.
<Peng> With 0.92 and http://bazaar-vcs.org/bzr/bzr.dev/ being dirstate, pulling from 3010-3038 took some 7 minutes. With bzr.dev and the remote being packs, 3010-3040 took 1m15s. Nice.
<Peng> Wait. The 1m15s test was also without a working tree.
<Peng> But that couldn't take more than about 5 seconds.
<lifeless> hmm, 1 minute is still slow
<lifeless> I bet you its in graph traversal
<lifeless> what speed adsl do you have?
<lifeless> 1M is 16 seconds on 512
<Peng> 1.5 down.
<lifeless> so, 6 seconds + figuring out what to pull
<lifeless> 4 round trips there minimum, should be able to do this in say 12 seconds total
<lifeless> e.g we still suck
<Peng> Yikes.
 * jml takes his inner pedant out for a coffee
<Peng> lifeless: Are you going to abandon the knit version of your repository branch now?
<lifeless> Peng: I'll probably make it a packs version, so I can hack on the next experimental format
<Peng> repository will be the new format, repository.knits will be the current format. Okies.
<lifeless> Peng: well, I'll rename it too, for clarity :)
<Peng> Right.
<lifeless> ok, pqm is happy now
<lifeless> so I'm off
<Peng> Pushing packs over sftp, is bzr.dev any faster than 0.92?
<Peng> (Creating a new branch.)
<Peng> Wait, never mind. I am using bzr.dev.
<Peng> (I was asking because if it was faster, I might want to kill a push I'm running and start over with bzr.dev. But since I am using bzr.dev, doesn't matter. Still might be interesting to know though.)
<lifeless> should be the same
<lifeless> if its a shared repo it should be really fast
<lifeless> if its not really fast and is a shared repo, please file a bug, tagged packs.
<jml> why does addCleanup enforce uniqueness of cleanup callables?
<poolie_> jml, no good reason
<jml> ok
<poolie_> if you're motivated to do it, send a separate patch removing that check
<jml> poolie_: the motivation is low.
<ubotu> New bug: #172499 in bzr "Bazaar knit corruption "Not a gzipped file" " [Undecided,New] https://launchpad.net/bugs/172499
<jamesh> ^^ sounds like the web server helpfully adding Content-Encoding or Transfer-Encoding headers
<Peng> lifeless: I dunno. It took 25 minutes to push into an empty shared repo, but it was a large branch (bzr.dev), so that might not be bad.
<lifeless> Peng: oh, new content has to upload; It's 50MB
<lifeless> Peng: whats your upload rate
<Peng> lifeless: I'm not sure. I thought it was 256k.
<lifeless> so, thats 32 seconds/MB
<lifeless> or 2MB/minutes - so 25 minutes
<Peng> Okay.
<lifeless> Peng: sounds like we got wire rate total time
<Peng> And that's with sftp's overhead.
<lifeless> not to shabby
<lifeless> when we halve the size of storage it will get faster again
<Peng> Halve? How?
<lifeless> new storage level diff algorithms
<Peng> New delta algorithm?
<lifeless> yah
<lifeless> viao
<lifeless> ciao
<Peng> Which one?
<poolie_> lifeless, can you please chmod the .knits branch?
<ubotu> New bug: #172506 in bzr "allow users to force an empty commit message" [Low,Confirmed] https://launchpad.net/bugs/172506
<lifeless> wb
<lifeless> poolie_: sure; will do shortly
<lifeless> poolie_: done
<poolie_> dude go home!
<lifeless> I am :)
<lifeless> just got dinner
<spiv> lifeless: the memory consumption of reconcile is much better now; thanks!
 * spiv stops work for the day
<Peng> Definitely.
<Peng> Wait, I only ran check.
<Peng> 0.92's new "bzr help formats" is nice. :)
<Odd_Bloke> Have I missed an email regarding a new release schedule (as bugs are now being targeted for alpha releases I've never heard of :p)?
<Peng> Huh, Ctrl+Cing pushing from packs to dirstate tracebacked.
<lifeless> Peng: file a bug please
<mwhudson> when did 'bzr viz' become so much more awesome?
<mwhudson> six months ago if i fired it up on launchpad it produced a window about 5000 pixels wide
<Peng> Uh-oh. Using a copy of bzr not installed in the system means the plugins aren't available.
<Olberd> Is there some way to find out what revision I had before a bzr pull
<Olberd> A log or something
<Peng> No.
<Odd_Bloke> What can cause 'bzr shelve' to fail to remove changes from the working tree?
<ubotu> New bug: #172567 in bzr "Per-file log is *very* slow with packs" [Undecided,New] https://launchpad.net/bugs/172567
<Peng> lifeless: Seems my upload speed is 512k (1/3 of the downstream? huh). That would mean bzr over sftp is half the wire speed.
<Odd_Bloke> Peng: I assume you're using ADSL, in which the A stands for asymmetric (that is to say, they use more lines for down than up as most people use more down than up).
<Peng> Odd_Bloke: I know that. I thought it was lower than 1/3, though.
<vila> jam-laptop: ping
<jam> vila: <dodge>
<vila> lol
<jam> what's up?
<vila> looking at doing multiple get for readv, will be simpler if we don't have to respect the provided order for the offets
<jam> vila: you can look at the sftp readv code
<jam> it does out-of-order fetching
<jam> but only buffers what it cannot return
<jam> all we really need is to change how we parse the values
<vila> hooo
<jam> I've done all that work
<jam> I just haven't had time to rewrite the http response parser
<vila> I think we can avoid that rewriting for now, but I have to look at sftp first
<jam> well, I think all the actual parsing is fine
<jam> it is just written to parse a complete response
<jam> rather than parsing as you go
<vila> hmmm, that will buffer quite a lot of data... well price to pay to respect the order while minimizing network use, I suppose you did the analysis at the time
<vila> Do you think it's still valid with packs handling megs of data ?
<jam> vila: in my testing the amount of out-of-order data was all very small
<vila> so reading as you go bufferd only small amounts of data, ok, let's say that ;-)
<jam> vila: also if adjust_for_latency = True
<jam> we can return things out of order
<jam> But I think that may be taken care of in the base readv() implementation
<jam> (it sorts them so the individual implementations don't know it is out of order)
<jam> vila: And I believe most pack operations use that
<vila> soooo, I don't have to worry
<vila> phone
<radix> Is there a way to get "bzr shelve" to be "tighter" in what it considers a single hunk?
<radix> And by "tighter hunks", I mean what "bzr diff --diff-options=-U0" might give.
<elmo> GGGGGGGGGGGGGGGGGGAR
<elmo> bzr add precious; bzr rm precious
<elmo> oh look, 'precious' is no more
 * elmo stabs himself repeatedly
<fullermd> Looooost!  Precious is lost!
 * fullermd hugs his rm --keep alias.
<luks> it doesn't actually remove anything that isn't in the branch history
<elmo> luks: except in the example I just posted
<elmo> I just did this IRL and lost like 70 files as a result
<luks> what version of bzr?
<luks> mine says "bzr: ERROR: Can't safely remove modified or unknown files:"
<elmo> luks: 0.92
<elmo> ah, it's a bit more involved
<elmo> bzr init; bzr add precious; bzr ignore precious; bzr rm precious
<luks> ouch
<luks> that sounds like a pretty nasty bug
<luks> it probably doesn't check the modified status for ignored files
<warren> Will bzr upstream ever reconsider the decision to not track all permission bits in bzr?
<warren> (not just execute)
<warren> bzr is *really* close to being suitable to track system config files, for example.
<elmo> warren: AFAIK, it's not that they don't want to do that, they just haven't decided quite how to
<warren> elmo, oh
<warren> elmo, yeah, I guess a solid plan would be necessary.
<warren> there are other permission bits than the chmod XXXX
<warren> there are also filesystem acl's and xattrs now
<elmo> warren: lifeless mailed me just the other day, asking for details of how we use bzr for managing /etc and how we'd like permission management to work
<jam> elmo: with the 'bzr ignore' involved I do see the file being deleted
<elmo> jam: yeah, I filed it as https://bugs.launchpad.net/bzr/+bug/172598
<ubotu> Launchpad bug 172598 in bzr "bzr rm <file> loses data under some circumstances" [Undecided,New]
<jam> otherwise I see the "cannot safely remove modified files"
<warren> elmo, ok, looking forward to a future of true permissions management =)
<fullermd> I'd think the most likely near-term solution would be plugins using a per-file properties system (as might come about for line-ending and such support)
<ubotu> New bug: #172598 in bzr "bzr rm <file> loses data under some circumstances" [Undecided,New] https://launchpad.net/bugs/172598
<ddaa> What is the shellyscript way to find that a bzr tree has uncommitted changes?
<LeoNerd> Something around bzr di   maybe?
<ddaa> looks like it would work...
<Peng> bzr st?
<Peng> bzr modified
<Peng> ?
<ddaa> I was looked at bzr st, but it does not have non-zero exit status if uncommitted changes are found
 * Peng shrugs.
<ddaa> bzr di has
<Peng> (modified would only show files that had changed, not other things like added files, of course.)
<Peng> Something with python -c "import bzrlib..." ! :D
<ddaa> "if ! bzr diff > /dev/null" it is
<jam> ddaa: bzr status -q ?
<jam> no, it isn't that quite
<ddaa> jam: has zero exit status in all cases
<jam> quiet
<jam> diff seems to be the way to go
<jam> I thought we had something different
<ddaa> yup
<ddaa> a bit wasteful, but not biggy
<ddaa> jam: maybe we can have "bzr diff --no-diffs"? :)
<fullermd> Maybe something with version-info --check-clean?  Think that triggers on unknowns, though...
<ddaa> if I upgrade to packs, will "commit after a big crazy merge" stop being slow?
<ddaa> It used to be fast, but he regressed quite badly in recent releases.
<mwhudson> hmmmmmm
<mwhudson> does pull with packs have a progress bar yet?
<ddaa> s/he/it/
<ddaa> mwhudson: ask linus, you do not need progress bars when you're fast ;)
<ddaa> about "commit after big merge", it's a real issue for me
<Peng> ddaa: Committing merges with packs can be/is slow. There's been recent work to make it much faster, but it didn't solve what made it slower than with knits in the first place.
<Peng> ddaa: You could try it.
<ddaa> Peng: not really
<ddaa> upgrading the launchpad repo to packs requires something like 20GB RAM
<ddaa> waiting for that to be fixed
<mwhudson> ddaa: eh, no
<mwhudson> ddaa: i pulled launchpad/devel into a packs repo and it was perfectly smooth
<ddaa> am I confuzzled?
<mwhudson> it's reconcile that takes/took megagigabytes of ram
<ddaa> wasn't there this discussion about "bzr upgrade" eating crazy memory for the launchpad repo?
<ddaa> ah right
<ddaa> but upgrade won't work if it's not reconciled, right?
 * mwhudson is confused too now
 * ddaa holsters his confuzzlerizer
<Peng> Some repos need to be reconciled, some don't.
<ddaa> mh
<ddaa> maybe some launchpad repos have this problem and others don't
<ddaa> so maybe it's worth for me to let bzr check run on mine
<keir> is there any way to do something like bzr push --uncomitted? this is not a good description; what i want to do is push uncommitted changes in my working tree to the branch i'm bound to
<keir> use case: i suddenly have to leave while working on my laptop. i'm 80% done a feature, but it doesn't even compile at the moment. i want to push my working tree to the branch i'm bound to, without actually committing.
<keir> this happens to me a fair amount
<keir> what i do now, is have many commits of 'junk state'
<keir> but i'm trying to move to a more sanitized mainline
<mwhudson> well, there's merge --uncommitted . other-location isn't there?
<mwhudson> ah, merge --uncommitted -d other-location .
<keir> oh cool
<keir> but this won't work with a bound branch; so i'd have to unbind first?
<mwhudson> though i don't know if that'll update a working tree over sftp or whatever
<mwhudson> hm not sure, i don't use bound branches
<mwhudson> keir: but hang on a moment
<mwhudson> keir: there's another answer here: don't commit to mainline
<keir> i didn't either until recently; they are pretty handy for my laptop/desktop combo!
<keir> mwhudson, yes, i understand that option; i still don't like it because e.g. bisect becomes much less useful
<fullermd> A third option would be to uncommit away the dirty rev if it bothers you that much.
<keir> but then it'd be uncomitted on my desktop when i get back, but still committed on my laptop
<fullermd> Well, you have to 'update' on the laptop anyway, so what's the difference?
<keir> unless i made a script commit, unbind, uncommit, ssh into desktop, uncommit
<keir> i suppose what i'm looking for is bzr synctree
<fullermd> No, you just update.
<keir> if i 'update' on my laptop after uncommitting on the desktop, does that uncommit the changes on the laptop?
<fullermd> Pretty sure I've done it more'n once.
<fullermd> update's pretty much like pull after all; move the head to the new rev, merge any outstanding WT changes.
<fullermd> Just because the new head isn't a descendant of the old one doesn't change anything material there.
<Odd_Bloke> keir: You might have to 'pull --overwrite', but I don't use bound branches much so I don't know.
<keir> interesting
<keir> i recently turned one of the machine learning researchers here at U of Toronto onto bzr; he generally likes it
<keir> but had some problems: http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/33525
<jam> ddaa, Peng: The commit after merge has been fixed for both knits and packs
<jam> The problem was searching the global revision graph
<jam> versus the per-file ones
<jam> when finding common ancestor, etc.
<keir> i didn't have a good answer to his issue, so i asked if he could post to the list, but no one has responded.
<jam> Both are *valid*, just the global graph has more nodes to search
<Peng> jam: Oh, cool.
<jam> There is more work to be done (to make searching the graph faster)
<ddaa> jam: thanks, I'll wait for my lpdev update, then :)
<jam> ddaa: yeah, I don't recommend you converting your personal one to packs until the upstream is packs.
<jam> Oh, and the reconcile memory consumption has also been fixed
<jam> I'm not sure what it would be for LP now
<ddaa> cool
<mwhudson> is b.control_files._lock.peek()['user'] really the easiest way to find out who has locked a branch?
<jam> but for bzr.dev it dropped quite a bit
<ddaa> that means we'll probably switch devpad to packs shortly after the next bzr release.
<ddaa> I appreciate how keeping memory use in control is difficult in Python
<keir> uncommit after a commit from a bound branch is not putting the changes back into the working copy
<ddaa> it's much easier when you can use custom allocators.
<ddaa> that's probably the only thing I think really sucks with Python
<jam> ddaa: well, having an algorithm that reads all inventories and buffers them in memory
<jam> is just a poor algorithm
<jam> It stored a slightly more efficient form
<jam> but still had a record for every file in every version
<ddaa> Sure, but you'd have found out earlier if you had bounded cache mechanism with a custom allocator, so you could have tested it with different memory limits.
<ddaa> It's a recurring problem in bzr.
<ddaa> "If we do not cache, it's slow, if we cache it eats tons of memory."
<Peng> LRUCache?
<fullermd> Well, Ubuntu used to send out those free CD's.  Can't we send out free DIMM's to bzr users?   ;)
<ddaa> (I realize this is a blanket statement and that they are many bad reasons for things to be slow or eat tons of memory, I am just trying to make a point about memory management in general)
<Peng> fullermd: Sign me up!
<ddaa> if we do that, people will complain that those DIMMs do not have free VHDL.
<ddaa> So we balanced the PR implications, and decided not to ;)
<fullermd> "Lightsabres aren't open source!"
<ubotu> New bug: #172612 in bzr "new commit is overly verbose" [Undecided,New] https://launchpad.net/bugs/172612
<Peng> Wow, bzr 0.12 is only 1 year old. You've been busy.
<lifeless> vila: packs make an effort to request in-order for .pacll
<lifeless> vila: and same for indices - but with indices they set the flag saying out-of-order-ok
<lifeless> elmo: and are you going to mail me back :)
<lifeless> ddaa: yes packs commit merge is faster
<lifeless> ddaa: reconcile is fast now, in .dev
<Peng> You were just adding dotted revnos and bzr+http.
<Peng> (I wonder if bzr+http worked then. Grumble grumble.)
<lifeless> hi jam, how is the missing-compression-parent patch coming ?
<lifeless> ddaa: actually, we knew it was bad on memory in 0.92
<lifeless> ddaa: I don't think the actual developer realised how bad bad memory issues become in the sort of scaling environments we encounter
<lifeless> tap tap tap is this thing on?
<keir> lifeless, i think your tapping knocked ddaa's connection out
<lifeless> :)
<gander> Hi. Does anyone here know anything about these bzr irc logs? <http://bzr.arbash-meinel.com/irc_log/bzr/2007/>
<james_w> gander: that would be jam
<gander> Why would he do that? It's a spammers delight
<james_w> why?
<jelmer> gander: why's that? hostmask accidently matches email address?
<gander> Because anyone can trawl for email addresses of it. Cant they?
<james_w> yes, but the percentage of working email addresses you would get would be tiny.
<fullermd> It'd be pretty poor trawling, I'd think.  The density of addresses is miniscule.
<lifeless> most users email and hostmask don't match the reverse lookup of the machine they IRC from.
<lifeless> that said, santising them should not be hard. jam: ^
<fullermd> Hey, the more nonexistent hosts spammers try, the less time they'll spend rapping on my servers   :p
<gander> Looks like I need to mask mine then
<lifeless> you'll likely find other channels you are in are also logged
<Peng> If you participate in FOSS development, your email address is screwed anyway. Bug trackers, VCS author information, mailing lists ...
<gander> Pah! :(
<lifeless> Peng: yes, but gander may be just using bzr :)
<Peng> True.
<Peng> s/True/Right/
<lifeless> luks: ping
<luks> pong
<lifeless> hi
<lifeless> nice performance regression
<lifeless> well, not nice, but nice catch noticing it
<luks> the file log?
<lifeless> yes
<lifeless> I've replied with an analysis of the callgrind
<lifeless> we can probably trivially drop it to 7 minutes by removing the duplicate call to get_revision_graph
<luks> 7 seconds, I hope :)
<lifeless> the other two will take a little more work; if you're interested in hacking on this code ...
<luks> well, I have generally very mixed feeling about packs, so I'm probably not motivated enough :)
<luks> maybe it's just me, but it feels a lot slower on many local operations, which is what I'm primarily interested in
<lifeless> luks: file bugs, lots of bugs.
<luks> it's all caused by parsing the big indexes
<lifeless> luks: I know for absolute fact that its faster and many local operations; but we're likely not looking at the same data set, nor the same operations.
<lifeless> s/and/on/
<luks> yep, simple things like diff or st are faster
<luks> historical diff and st, I mean
<luks> but for example just genering a bundle for 'send' is slower
<lifeless> luks: this is why is was experimental in 0.92; and I was expecting a little more time to find performance regressions (where 'all history' become more expensive, but 'partial history' became possible.) and fix then
<lifeless> s/then/them/
<lifeless> bug 165309 will help with the index performance
<ubotu> Launchpad bug 165309 in bzr "pack index has no topological locality of reference" [Medium,Confirmed] https://launchpad.net/bugs/165309
<lifeless> but changing all-history API usage to partial-history API usage is the key thing needed to improve performance
<lifeless> knits are incapable of partial-history operations
<lifeless> but they were tuned to do all-history very fast
<lifeless> it turned out that this was not a good enough solution
<luks> knits with better indexes would be, IMO
<luks> the current text index for packs probably needs some kind of subindex to make it fast
<lifeless> luks: the current text index for packs is /way/ faster than knit indices at extracting say 1% of keys
<lifeless> anyhow, bug 165309 will deliver a subindex of sorts
<ubotu> Launchpad bug 165309 in bzr "pack index has no topological locality of reference" [Medium,Confirmed] https://launchpad.net/bugs/165309
<Peng> I think uncommit is slower with packs.
<luks> lifeless, which is why diff -c X and st -c X are fast
<lifeless> luks: anyhow, here's what I'd *love*. File a bug anytime a pack operation is slower than a knit operation.
<luks> ok
<lifeless> they will nearly all involve commands accessing too much history
<fullermd> That's interesting.  I wouldn't expect uncommit to need to do any repository actions at all.
<lifeless> Peng: please file a bug.
<lifeless> I'll mail the list right now.
<fullermd> I guess to find the parent, maybe.
<lifeless> luks: can I quote you in my mail? I'd like to give people context about what I'm asking
<luks> sure :)
<Peng> Shrug. Uncommit takes a couple seconds with packs, and I don't remember it being non-instant before.
<Peng> I'll confirm it in a few minutes.
<Peng> But now to brush my teeth!
<buxy> Hi, I'd like to convert an existing CVS repository to bzr
<buxy> I tried using tailor but it fails: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=439124
<ubotu> Debian bug 439124 in tailor "tailor: Fails to convert debian-admin CVS repository to bzr" [Important,Open]
<Peng> lifeless: Hey, what's hte status of pack reconcile?
<Peng> the*
 * Peng goes back to tooth-brushing.
<fullermd> buxy: Have you tried using the cvsps-import plugin?  IME it's a lot more reliable than tailor, as well as _much_ faster.
<buxy> fullermd: no, do you have a pointer?
<ksmith99> Hi folks, I have a share-repository I have been checking  out of but the dns name got changed... what do I do to use the new name? thxs
<buxy> of found at http://bazaar-vcs.org/CVSPSImport
<buxy> I'll look into it, thanks
<marianom> ksmith99: I know you can use --remember with "pull" to make it change the default location
<marianom> do you guys know when bzr-gtk 0.92.x will be in the repository http://bazaar-vcs.org/releases/debs ?
<ksmith99> marianom: thanks, looks like a good start
<marianom> ksmith99: this is not as clean (and maybe it's a bad advice) but you can change the parent branch address accessing .bzr/branch/parent
<lifeless> Peng: I'm hacking on it as we speak
<lifeless> marianom: we're not currently building bzr-gtk; next monday I should get time to do repository stuff
<marianom> thanks lifeless
<ksmith99> marianom: thanks, I might try that if remember doesn't work
<Peng> Is there a command to make a repository default to having working trees or not?
<fullermd> The bzr install hacks your system to add those capabilities to the 'rm' and 'touch' commands   ;)
 * Peng wanders off.
<lucasv1> hi
<lifeless> hi
<lifeless> Peng: you can rm .bzr/repository/no-working-trees; I don't think we have a UI for it yet
<lucasv1> I have moved a bzr repository to a different server, now it give me the following error: http://pastebin.org/9773
<lifeless> Peng: there is a python API to change it
<lifeless> luks: use a modern bzr
<lifeless> meh
<lifeless> lucasv1: use a modern bzr
<lifeless> 0.11 is very old
<lifeless> we're at 0.92 today
<buxy> Similar question, I have a git repository I'd like to convert to bzr, I found bzr-git but there's no doc on how to use it
<lifeless> bzr-git is incomplete
<lifeless> jam: was most recently working on it
<lucasv1> lifeless: it's debian stable  I think
<lucasv1> that's what my hoster gives me
<lifeless> lucasv1: you've been using a more recent bzr
<lucasv1> possible, I have an ubuntu workstation
<lifeless> lucasv1: the one you have switched to cannot handle kind changes properly
<lucasv1> ah ok
<lifeless> so, you need to get them to upgrade; newer bzr's are in debian backports
<luks> lifeless, damn, now you got me interested in packs again :)
<lifeless> luks: my email ?
<luks> I'm looking on the code right now, but is there some limit when a pack is considered "final" and won't be repacked?
<fullermd> aleph-null?   ;)
<luks> yes + the irc discussion
<luks> _max_pack_count seems kind of random
<lifeless> luks: no; we could consider that though. Some things to consider - each item is moved log10(total commits) times.
<lifeless> luks: its arbitrary yes, but not random :)
<luks> well, for 100000 revisions you get only 1 pack, for 99 revision you get 18 packs
<luks> not very good distribution, IMO
<lifeless> at 100000 revisions, the things committed in the first commit will have been copied 5 times.
<lifeless> luks: and you'll need to do 900000 commits to get them copied again
<luks> well, let's say I have 999 revisions, so I have 27 packs
<lifeless> right
<luks> now I do a commit and all of them get repacked
<lifeless> at that point you're paying quite a high latency price
<luks> which means I have to reupload the whole repository
<lifeless> so we correct that by dropping it to 1
<lifeless> luks: with the smart server, once streaming push is implemented, you won't upload the repository again; instead the server itself will do the repack.
<luks> I think lucene-like repacking would work better
<luks> well, but dumb servers are a big advantage of bzr :)
<lifeless> do you have a link for that ?
<luks> umm, no I don't think so
<lifeless> if you can find one I'd be delighted to read up on it.
<luks> bit the point is that you have ~ logaritmic distribution of index sizes
<luks> and you combine smaller indexes into bigger ones
<lifeless> luks: so far this is exactly what we do
<luks> but almost never touch the "top" indexes
<luks> well, 27 -> 1 is not exactly that :)
<lifeless> luks: thats precisely that. You're sampling only the times that we do touch the top indices.
<luks> lucene would take for example the lower 5 ones and pack those
<lifeless> luks: again, thats exactly what we do.
<luks> nope
<lifeless> say you have 899 revisions, with 26 packs
<luks> it always maintains a certain number of indexes
<luks> it will never drop to 1
<luks> unless you manually merge them
<lifeless> well, we could do that easily; just change the distribution logic
<lifeless> you could do that with a plugin in fact :). The code that takes a distribution already chooses to only move around the smallest amount of revisions possible
<lifeless> there are two problems that it has though, that seem to me to need serious consideration
<lifeless> one is scaling
<lifeless> if you have a really big repository its reasonable to pay more latency
<lifeless> so a constant number of indices is really bad for small repositories (too much latency), or really bad for big repositories (too much repacking)
<luks> the number is not constant, it depends on the whole index size in lucene
<lifeless> ok
<lifeless> the other thing is that if you are going to touch two indices its cheapest to just combine them together rather than in some other form
<lifeless> this isn't quite represented correctly in the autopack.
<lifeless> its something I realised after doing the initial code and before coming back to it.
 * lifeless files a bug
<jelmer> lifeless: is there some way to tell the code how often to repack?
<jelmer> lifeless: I'm thinking of mass-imports that could potentially be speeded up if the number of repacks could be reduced
<lifeless> jelmer: well, you'll trade index latency off against repacking.
<lifeless> jelmer: if mass imports will be improved, improve the autopack logic.
<lifeless> jelmer: (but I do understand the desire to control this through code; I'm entirely open to a disable_autopack() api call.
<lifeless> luks: so I've filed a bug about that. if we're going to read N packs, only ever bother writing 1 new pack.
<lifeless> I don't know if lucene does this.
<lifeless> but basically its silly to aim for a constant number. Because - to keep it constant, you have to shuffle data *between* your indices[packs]
<lifeless> and as each pack is write-once.
<lifeless> this means reading N packs and writing M packs, where N=M+1 once you hit your constant number
<luks> well, the point is that you shuffle only the small ones or in small incremental steps
<lifeless> (each new commit adds one pack, then you put it into your constant-sized collection)
<lifeless> luks: but thats what we do? We only shuffle the smallest ones
<lifeless> luks: I feel like we're talking past each other here.
<luks> yes, but you drop the number of packs radically
<luks> that's the only thing I don't like -- I don't want to reupload most of my repository if I really don't have to
<lifeless> its at power of 10 intervals
<ubotu> New bug: #172644 in bzr "autopacking should just combine all packs it touches" [Undecided,New] https://launchpad.net/bugs/172644
<lifeless> to reupload most of your repo occurs extremely rarely.
<lifeless> and mathematically I can't see that happens any more often than lucene would do it
<lifeless> for instance, bzr is at 15K commits now after 3ish years.
<luks> in the terms on total used bandwidth probably not
<lifeless> our next full-upload is going to be at 100K commits
<luks> but in the case of lucene, it would be done in small steps
<luks> here it's a "all or nothing" situation
<lifeless> luks: then you have described lucence to be badly; because logarthimic expansion of size will behave identically
<lifeless> at some point lucence will decide to touch a top index
<lifeless> and make a bigger
<luks> yes, and it would be more often than in case of bzr
<lifeless> that bigger one will have 10 times what the previous top had in it (what whatever logN they are using)
<luks> but the distribution of pack sizes would be different
<luks> so you will be never in situation you have to reupload/redownload the *whole* repository
<lifeless> I think you are wrong about the impact and frequency; rather than debating - point me at code/docs.
<Peng> With bzr.dev working on a fresh copy of bzr.dev, "bzr uncommit --dry-run" uses 0.41 user seconds in dirstate, 0.86 in dirstate-tags, and 3.84 in packs.
<lifeless> Peng: please file a bug as per my email
<luks> can't find anything except API docs, which doesn't explaing it at all
<Peng> I haven't seen your email, but I will.
<lifeless> Peng: thanks!
<lifeless> Peng: my email contains a request for a callgrind file
<lifeless> Peng: just of the packs version
<Peng> Just of the packs version? Okay.
<lifeless> yah
<Peng> Will the time spent waiting for me to hit enter to exit it hurt callgrind?
<lifeless> rarely need a knit version, its usually obvious where packs are slow
<lifeless> Peng: not at all
<lifeless> Peng: but you can probably enter in advance
<lifeless> luks: so for clarity; I'm open to improving autopacks user experience.
<lifeless> luks: It will need serious sum of operations and frequency of size impact analysis.
<Peng> I'll file a bug in a second.
<lifeless> luks: I did this for the current code, and I'm very happy to help with the analysis of a proposed replacement algorithm.
<jam> Peng: you can also use "bzr uncommit --force" to avoid the prompt.
<lifeless> luks: for instance, here's a replacement algorithm: pack the smallest packs we want to get rid of into a new pack bigger than any current pack.
<luks> hmm
<lifeless> luks: this would guarantee that we always leave at least the current top in place; and only do this when the sum of the smaller packs is bigger than the current top, so autopack would be about choosing a 'top' to use
<Peng> jam: Oh, good. That even works with --dry-run.
<lifeless> (so if we are leaving (say) the 10K packs alone, we might choose a 'top' to spin around of a 1K pack. Then all the < 1K packs become a new ~10K pack.
<lifeless> this of course has other problems. We currently have the situation that most data most operations want is in the smallest packs.
<lifeless> because we strictly shuffle small->next size up.
<jam> lifeless: don't forget that pull just creates 1 new pack of all streamed data, right?
<lifeless> and that lets us optimise the order in which we attempt to retrieve index entries as well as providing high locality of data
<lifeless> jam: right
<jam> do we have 'push' doing the same thing?
<lifeless> jam: it still tends to preserve this property.
<luks> oh, even pull over http?
<lifeless> luks: yes, pull over http -> one new pack.
<lifeless> jam: yes push does the same thing
<luks> so it autopacks everything into a single pack on the client side?
<lifeless> luks: single *new* pack.
<jam> luks: basically it just figures out what it will need, starts streaming the data to the pack, and then finishes once it got everything.
<Peng> What's the pack bzr+ssh thing that corrupts the repo?
<jam> (into a new pack)
<lifeless> luks: then after the transaction it checks to see if it needs to autopack the whole repo.
<lifeless> Peng: there isn't one.
<lifeless> Peng: it was a concern that was all.
<Peng> lifeless: Okay, right. Just an error.
<luks> er, I actually didn't realize you can "pick" only some revisions from pack even over http
<lifeless> luks: so here are the parameters: We want adjacent texts to combine into the same pack as we combine packs, so that they can be efficiently delta compressed. We want to provide a natural cap on latency. We always have to replace an entire pack - we can't delete from a pack, nor add to one. We never want a user to have to worry about the internals.
<lifeless> luks: over http we: perform bisection in 64K chunks on the .*ix indices. Then we plan a readv for each pack, and readv the data we want precisely out of the pack file.
<lifeless> luks: we do one readv per pack for the revisions we need. Then one readv per pack for the inventories we need. Another for the text deltas. And finally one for digital signatures.
<lifeless> luks: each readv is done in ascending order to make range combining as efficient as possible.
<luks> yep, that's makes my concerns about redownloading completely invalid
<lifeless> we're very strong about downloading; your concerns about re*uploading* are valid.
<luks> I thought people will have to download whole packs if I repack something on the server
<lifeless> but a reupload does not screw readers over :)
<lifeless> luks: ah! any suggestion about where you got that impression?
<luks> from the fact that packs are write-once and then only for reading
<luks> so I though bzr will treat it as one big blob
<lifeless> luks: ah; you didn't join the 'better at partial operations' thing to that
<lifeless> luks: patches for doco appreciated :)
<luks> lifeless, I did, but only for indexes, not for packs theirselfs :)
<lifeless> brb
<ubotu> New bug: #172649 in bzr "uncommit is slow with packs" [Undecided,New] https://launchpad.net/bugs/172649
<Peng> :D
<lifeless> thanks pen
<lifeless> *Peng*
<Peng> Once someone called me Feng a bunch of times.
<Peng> I should change my nick.
<lifeless> heh
<lifeless> to Shui?
<Peng> Heh.
<Peng> That might work.
<Peng> Aww, already taken.
<lifeless> jam: ping
<Peng> Actually, registered 2 years 33 weeks ago and last seen 2 years 33 weeks ago. The opers might delete it if I ask.
<jam> lifeless: pong
<lifeless> jam: how is the missing-compression-parent patch coming
<jam> ok, I'm still at a bit of a loss for how to force corruption into the repository
<jam> that, and I got side-tracked reporting a performance impact for "bzr status" after a merge
<lifeless> there's a BrokenRepository test base class somewhere
<jam> get_ancestry(revision_id) is a lot slower now
<lifeless> what I do with such things is note them and move on
<lifeless> yah, thats a typical size_history vs partial_history tradeoff
<jam> well, you had asked for a callgrind, and I have trouble not looking at it myself
<lifeless> jam: :)
<lifeless> I was just saying what I do :)
<jam> all the time is spent in _lookup_keys_bylocation
<lifeless> yup
<lifeless> the next index layer will remove bisection
<lifeless> so I'm not that interested in tuning this
<lifeless> s/.*/am not interested in/tuning this
<jam> is there any way to upload a file as part of the bug submission?
<lifeless> if you use the web ui
<jam> yeah, but I wanted to "just send an email"
<jam> so I don't have to click 10 times to set the status and the tags
<jam> but then I don't get a bug number for a long time
<jam> to upload the callgrind too
<lifeless> https://bugs.launchpad.net/malone/+bug/30225
<ubotu> Launchpad bug 30225 in malone "Attach files via email" [High,Confirmed]
<jam> to
<ubotu> New bug: #172657 in bzr "bzr status after merge slower with packs" [Undecided,Triaged] https://launchpad.net/bugs/172657
<lifeless> jam: ping; can I ask for an insta-review?
<lifeless> jam: my trivial progress bar fix - I'd like to flush that
<jam> I'll give it a shot
<lifeless> its 3 lines or so :)
<jam> I don't see it in BB or in my emali
<jam> email
<jam> lifeless: you can paste-bin if you want
<lifeless> grah
<lifeless> http://rafb.net/p/ArhA5197.html
<jam> lifeless: you are changing that function into a generator
<jam> which with python2.4
<jam> will fail
<jam> try/finally doesn't work with a yield there
<jam> bb:reject
<jam> sorry
<lifeless> oh foo
<jam> python2.5 only
<lifeless> fuckity
<jam> Since people have troubles even getting 2.4, I don't think we want to depend on 2.5 just yet :)
<jam> I know we discussed it a long time ago, but it really seems like at least RHEL is taking *forever* to get past 2.3
<Peng> 2.6 is close to alpha, right? What about it?
<lifeless> try: except ?
<lifeless> I don't even have 2.4 to test on now
<jam> lifeless: try/except works (I believe), but I'm not sure what you would catch.
<lifeless> Exception: and raise
<jam> and then a plain "pb.finished()" as well?
<jam> (outside the exception)
<jam> we can go for it
<lifeless> try:except Exception: finished();raise() else: finished()
<jam> lifeless: I don't really like it, but BB:approve anyway
<jam> not much else we can do, unless we want to allocate the pb in a non-generator
<lifeless>         try:
<lifeless>             for result in self._do_copy_nodes_graph(nodes, index_map, writer,
<lifeless>                 write_index, output_lines, pb):
<lifeless>                 yield result
<lifeless>         except Exception:
<lifeless>             pb.finished()
<lifeless>             raise
<lifeless>         else:
<lifeless>             pb.finished()
<lifeless> aka what try:finally: stands for.
<lifeless> bastards.
<lifeless> ^ ok with that ?
<jam> lifeless: except it isn't guaranteed to finish
<jam> because someone in 2.4 may not consume the whole generator
<lifeless> right
<jam> 2.5 actually guarantees it will finish
<lifeless> thats ok with me
<lifeless> we control all the consumers
<jam> anyway, BB:approve, though the "correct" fix is to move pb = ui.ui_factory.nested_progress_bar() up a level
<lifeless> it gets fugly fast if we do that
<lifeless> there are multiple callers of this
<lifeless> and that sort of cruft is what we want pb's to avoid
<jam> lifeless: go ahead
<jam> lifeless: maybe with a comment so people understand the bit of cruftiness
<lifeless> done
<warren> bzr diff has -r, but is there an equivalent for a tag instead of revision number?
<fullermd> -rtag:FOO
<fullermd> (see 'bzr help revisionspec' for the full list of possibilities)
<lifeless> bbs
<warren> fullermd, thx =)
<poolie> hello
<lifeless> poolie: please save me from elevator music
<poolie> jam, lifeless, igc, spiv : ping
<jam-laptop> conference time, right poolie ?
<poolie> yep
<poolie> i'm in
<lifeless> jam-laptop: to setup a repo where a fetch will find a missing text parent, here is an easy way
<lifeless> jam-laptop: repo a: do two commits, A and B that add and alter a file foo, with id foo-id
<lifeless> repo b: do one commit, A, that does not add the file foo
<lifeless> then fetching into b from a will only copy the deltas for B, and the text parent for foo-id will be absent.
<lifeless> long term this test has some flaws, but it will ensure that the sanity checking we need today is in place; and defers the other work until we have code that will need it, which is a good thing.
<jam-laptop> lifeless: why wouldn't fetching into 'repo b' copy both A and B
<jam-laptop> and thus fetch the basis
<lifeless> jam-laptop: because B already has an 'A'
<jam-laptop> or are you giving them the same revision id
<jam-laptop> ok
<lifeless> alternatively
<lifeless> commit A and B
<lifeless> then
<lifeless> repo_b.add_inventory(repo_a.get_inventory(A))
<lifeless> repo_b.add_revision(repo_a.get_revision(A))
<lifeless> repo_b.fetch(repo_a, 'B')
<lifeless> *boom*
<jam-laptop> adding the inv and revision without adding the texts....
<jam-laptop> ok
<jam-laptop> thankns
<lifeless> np :)
<lifeless> poolie: yes pqm is sending mails AFAIK
<poolie> lifeless, yes, it just seemed to be delayed somewhere
<lifeless> abentley: diff is snappy now; thanks
<lifeless> abentley: in particular no-op diff is 1/2 sec
<lifeless> poolie: I want time before going on leave to fix bzr-email to be fast
<lifeless> poolie: its by far the slowest part of commit
<lifeless> abentley: ping; are you on packs yet? :)
<jam-laptop> well, I've proven that Knit1 repositories *don't* fail under those conditions
<jam-laptop> because they always copy all missing revisions in the ancestry
<jam-laptop> we probably knew that already
<lifeless> good;
<lifeless> knit->pack will today do the same thing; a test that it stays like that would be good
<lifeless> pack->pack will explode
<lifeless> well
<lifeless> fail to explode
<jam-laptop> right
<jam-laptop> :)
<lifeless> where's the ka-boom.
<lifeless> there's meant to be an earth shattering KA-BOOM
<poolie> lifeless, well, performance of plugins is less important than performance of the core
<lifeless> poolie: depends on the plugin though; if you were evaluating a VCS, would you setup email on commits ?
<poolie> probably not in my initial evaluation
<poolie> (tbh)
<lifeless> poolie: I think the core has to support high performing plugins; this is likely a case where core changes are needed
<poolie> it's important, just imo not as important as the stability and performance of the core tool
<lifeless> 10:48 < lifeless> poolie: I think the core has to support high performing plugins; this is likely a case where core changes are needed
<lifeless> because deployments will eventually expand out to need the whole ecosystem for a given project to be fast
<lifeless> anyhow, after friday
#bzr 2007-11-29
<poolie> right
<jml> hello
<jml> I've got a straightforward documentation patch that still needs another positive review.
<jelmer> lifeless: I'm looking for a SubunitTestRunner - is there something like htat yet?
<lifeless> jelmer: all my changes are pushed; what is it you want to do ?
<lifeless> jelmer: run a suite in a subprocess?
<jelmer> yes - samba4's testsuite is subunit based
<jelmer> but the main process is written in perl, not python
<jelmer> including the subunit parser
<poolie> jml, url?
<lifeless> jelmer: contribute it back dude
<jml> poolie: http://bundlebuggy.aaronbentley.com/request/%3Cd06a5cd30711261654k61edd4c4n66c7d5894d1c485c@mail.gmail.com%3E
<jelmer> lifeless: I will at some point, once we get rid of some of our extensions
<poolie> btw you should think about naming a child, should you have one, U.R.Lange :)
<lifeless> jelmer: in subunit itself, you can use ExecTestCase to run external tests, and IsolatedTestCase/IsolatedTestSuite to run existings tests past a fork() barrier
<jelmer> lifeless: I doubt you want support for setting up a Samba server inside subunit ;-)
<lifeless> jelmer: well, thats really part of your tests: )
<lifeless> jelmer: but the hook to make that easier; that I could go for
<jml> poolie: heh heh
<jml> poolie: I guess that's better than Minnie Lange
<jml> poolie: thanks
<poolie> jml, can you merge it or do you need an adult to help?
<jml> poolie: I need a grown up to do it.
<jml> poolie: will I get an email once it's merged?
<poolie> no, but you can poll that page
<lifeless> jml: subscribe to bazaar-commits
<jml> lifeless: yeesh.
<lifeless> spiv: you can commit kthxbye
<spiv> lifeless: ta :)
<spiv> 'bzr: ERROR: bzrlib.errors.ShortReadvError: readv() read unknown bytes rather than unknown bytes at unknown for "http://bazaar-vcs.org/bzr/bzr.dev/.bzr/repository/packs/a3069b4df97462558e8666ff0cc72386.pack": Server aborted the request'
<spiv> That's a lot of unknowns.
<lifeless> -rw-r--r-- 1 robertc warthogs 58844730 Nov 28 03:44 a3069b4df97462558e8666ff0cc72386.pack
<lifeless> .bzr.log have any hints? I pulled ok earlier today
 * spiv looks
<lifeless> we have 58844730, 52560, 13592, 5453, 4930, 2259, 2052 packs
<spiv> http readv of a3069b4df97462558e8666ff0cc72386.pack  offsets => 649 collapsed 149
<spiv> got pycurl error: 18, transfer closed with 162685 bytes remaining to read, (18, 'transfer closed with 162685 bytes remaining to read'), url: http://bazaar-vcs.
<lifeless> in bytes
<spiv> org/bzr/bzr.dev/.bzr/repository/packs/a3069b4df97462558e8666ff0cc72386.pack
<lifeless> spiv: interesting
<lifeless> link error perhaps?
<spiv> Lots of other successful readvs before that, but none with more than 16 parts after collapsing.
<spiv> This is updating my bzr.dev from before I was on leave.
<spiv> (but using a current bzr.dev to the pull, and the local repo is now in packs-0.92 format)
<lifeless> is it in knit or pack form?
<lifeless> strange
<spiv> i.e. pulling into 2977 pqm@pqm.ubuntu.com-20071109154145-1yq4oi390uk3z90o
<lifeless> are you using bzr.dev to do this? or your old bzr.dev ?
<spiv> Current bzr.dev, as of last night.
<lifeless> ok, that has the http fix
<spiv> (3041 pqm@pqm.ubuntu.com-20071128045852-9ii8fj85vxz1om46)
<lifeless> is it repeatable?
<spiv> Let's find out.
<spiv> Oh, one other interesting fact:
<spiv> real    38m32.140s
<spiv> user    0m3.196s
<spiv> sys     0m0.380s
<lifeless> erm
<lifeless> ex-wtf-me
<spiv> Which seems... odd :)
<spiv> Possibly supports the "link error" hypothesis I guess.
 * spiv tries again.
<lifeless> time bzr pull
<lifeless> Using saved location: http://bazaar-vcs.org/bzr/bzr.dev/
<lifeless> Now on revision 3047.
<lifeless> real    0m36.865s
<lifeless> user    0m6.844s
<lifeless> sys     0m0.344s
<lifeless> still slow
<lifeless> but I think mostly fixable via indexing work
<lifeless> also we could do
<lifeless> read-invs
<lifeless> then read revs + texts + sigs in one readv to the pack
<lifeless> dropping latency by 2 RTT per pack
<spiv> lifeless: still weirdly slow
<spiv> lifeless: long delay at "http readv of a3069b4df97462558e8666ff0cc72386.pack  offsets => 381 collapsed 4" in the .bzr.log
<spiv> lifeless: now another long delay now that it's reached "http readv of a3069b4df97462558e8666ff0cc72386.pack  offsets => 649 collapsed 149"
<spiv> lifeless: no network traffic atm according to tcpdump
<lifeless> spiv: disable your squid.
<jelmer> jml: how does trial retrieve tests from a path?
<lifeless> spiv: or otherwise bypass; then try again.
<jelmer> jml: hi, btw :-)
<jml> jelmer: hi
<jml> jelmer: black magic.
<jelmer> jml: appears to be something custom, and I can't easily figure it out from the source, but I guess I'm missing something...
<spiv> lifeless: ok.
<jml> jelmer: you are particularly interested in 'trial foo/bar/baz' rather than 'trial foo.bar.baz', right?
<jml> (foo bar baz BZR)
<jelmer> jml: yep, in running stuff that's not in my PYTHONPATH
<spiv> lifeless: btw, some traffic has occurred finally
<jml> jelmer: the code is in twisted.trial.runner.filenameToModule
<jelmer> jml: This is for the Samba testsuite - I really don't want people to have to install twisted just to run the testsuite but I like how easy it is to use trial
<jelmer> jml: thanks!
<spiv> lifeless: for added laughs, Ctrl-C doesn't interrupt it.
<spiv> (nor does Ctrl-\)
<spiv> lifeless: gdb seems to think it's in pycurl.so (but there's a lot of ?? in the backtrace).
 * spiv SIGTERMs it
<fullermd> I think 'pycurl is uninterruptable' is on the known list...
 * spiv nods
<spiv> lifeless: it just completed in 3m 7s real when I bypass squid.
 * spiv files a bug
<lifeless> spiv: interesting.
<spiv> lifeless: filed bug 172701
<ubotu> Launchpad bug 172701 in bzr "Large readv requests can fail if there is a squid proxy" [Undecided,New] https://launchpad.net/bugs/172701
<spiv> Perhaps I should have just said "readv requests" rather than "Large readv requests" in that summary.
<lifeless> spiv: a http request decode of what is sent to squid, and squid to upstream for the .pack read that fails would help
<spiv> lifeless: do you know an easy way to get that off the top of your head?  (e.g. the right tcpdump magic?)
<spiv> I can look it up if you don't.
<fullermd> Wireshark's decoder/trace is handy.
<poolie> -R 'http.request' i think?
<lifeless> tshark ftw
<fullermd> Coming up with 'wireshark' of course mentally requires a detour through "etherea...  wait, what did they change their name to?".  Stupid program renaming.
<lifeless> yes
<lifeless> because wireshark is so much more clear and inuitive
<ubotu> New bug: #172701 in bzr "Large readv requests can fail if there is a squid proxy" [Undecided,New] https://launchpad.net/bugs/172701
<grovers> quick question: what's the best bzr setup for two people working on a project in a LAN? I can't seem to get permissions that work for the both of us
<poolie> grovers, sftp tends to have problems with permissions
<poolie> so i'd suggest using bzr+ssh, which should preserve them
<grovers> is there any way to use bzr+ssh with a non-standard SSH port?
<poolie> sure, i think you can put it in the url, or in your .ssh/config (on unix)
<grovers> so it would be acceptable for us to push/pull to each other?
<abentley> lifeless: Bundle Buggy's on packs, but I'm in the middle of reconciling my bzr repo.
<lifeless> abentley: cool
<lifeless> wool
<lifeless> :!./bzr --no-plugins selftest reconcile.*ack  -1
<lifeless> testing: /home/robertc/source/baz/reconcile/bzr
<lifeless>    /home/robertc/source/baz/reconcile/bzrlib (0.93.0.dev.0 python2.5.1.final.0)
<lifeless> [141/141 in 11s, 3 skipped] repository_implementations.test_check_reconcile.TestFileParentReconciliation.test_reconcile_behaviour(RepositoryFormatKnitPack3,UnreferencedFileParentsFromNoOpMergeScenario)
<lifeless> native packs reconcile FTW
<lifeless> let me check all pack tests, then I'm firing this off and done for the day.
<lifeless> later all
<Peng> Omg! I got git to compile!
<Peng> Wait, I don't want to learn git.
<lifeless> I was going to say
<lifeless> Peng: there is a native pack reconcile patch I just sent to the list; if you
<lifeless> are interested.
<lifeless> Peng: (take a backup of .bzr first, of course :)).
<Peng> I am interested, but I'm too tired to try it now.
<Peng> Also, running bzr.dev is pushing it enough. But a patch?
<lifeless> :)
<lifeless> just giving the customer what they want :)
<Peng> The customer wants a nap. :P
<Peng> Anyway, thanks.
 * lifeless gives Peng a nap
 * Peng snoozes.
 * spiv -> late lunch
<Peng> Woah.
<Peng> I keep ~/local in a bzr branch, and the pack for installing git is 68 MB!
<Peng> A lot of bin/git-* files are the same 4.2 MB file. Might be hardlinked together, but bzr doesn't know that.
<abentley> Heh, converting my branches from format 5 to 6 saved about 14M of storage.
<abentley> knits: 145M, Pack+branch5 98M, Pack+branch6 84M.
<Peng> Branch6?
<Peng> Branch5 to branch6, that would be dirstate's branch format to dirstate-tags's?
<Peng> Heehee, I've got git installed. Cloning git.git had crazy fun output, and only took 2 minutes.
 * Peng goes to bed.
<abentley> Peng: correct.
<poolie> ok, i'm looking at bug 165304
<ubotu> Launchpad bug 165304 in bzr "can't pull knits to packs over hpss" [Critical,In progress] https://launchpad.net/bugs/165304
<poolie> spiv, still here?
<poolie> spiv, if you think it's correct could you merge john's fix for check? it looks plausible to me
<spiv> poolie: I'm here.
<spiv> poolie: I think it may have been obsoleted by an API change that got merged a bit later (which effectively made the same fix); I sent that reply will trying to catch up on the >1000 bazaar@ messages waiting for me :)
<spiv> poolie: I'll double check that's what happened, and if not I'll merge John's fix.
<poolie> hm
<poolie> i'm not sure if reading, or even trying to skim all the messages is a good idea
<spiv> Well, I mostly just marked entire threads as "read" based on subject line alone.
<spiv> I wanted to make sure I didn't miss anything about e.g. 1.0 planning.
<spiv> I had to resist my curiousity several times :)
<spiv> poolie: yes, an equivalent fix was made by a separate change.
<poolie> oh ok, so it's not still happening?
<spiv> As of yesterday, by the looks.
<poolie> cool
<spiv> In r3040; that particular change was in 3036.1.2.
<abentley> lifeless: My tests show that on some merges, the text extraction time for the simple case (no text merge) is the bottleneck.  I'll be interested in putting in iter_files_bytes, once we have a good implementation.
<poolie> i'm seeing some odd failures - new tests from alexander for making the tree hidden call build_tree() incorrectly
<poolie> passing just a string, not a list
<poolie> i don't understand how this passed before
<i386> lifeless: ping
<lifeless> i386: yo
<lifeless> abentley: if you'd like to write up a decent iter_files_bytes, I'd be happy to give pointers
<i386> hey :)
<i386> Ive been prototyping some APIs for rhodes recently
<i386> and I dont like the feel of JavaScript for my usecase
<lifeless> abentley: basically we need to plan the texts and retrieve them across N weaves, so need more code extraction for reuse from knits; generalising the underlying stuff to be arbitrary delta code instead, and make it talk (file_id, revision_id) pairs
<lifeless> i386: yah
<i386> so ive decided the world needs another DSL
<lifeless> have you implemented lisp yet ?
<i386> :P
<i386> I bought a book on ANTLR
<i386> from the pragmatic dudes
<lifeless> ok...
<lifeless> so you're going to write an entire DSL, or layer it on javascript using jantler, if such a beast exists.
<i386> No on top of python
<i386> since it already has a target
<i386> and I already have some code :)
<i386> anyway
<i386> Ill buy you many beers if you can poke holes in my implementation / give me advice
<lifeless> :)
<lifeless> mail me a link to code
<i386> Only when I have a language though
<lifeless> what is rhodes?
<i386> http://i386.kruel.org/blog/?p=257
<i386> ^^ rhodes
<lifeless> i386: hmm, my first reaction is doom
<lifeless> rhodes++
<lifeless> new language--
<Necrogami> hmm
<i386> Yeah
<i386> I want something simple and really controllable
<Necrogami> Bazaar is Python?
<lifeless> Necrogami: oh yes; i386 and I are talking off-topic.
<i386> Necrogami: yes
<Necrogami> Stackless or standard python?
<lifeless> standard
<Necrogami> :-\
<lifeless> python 2.4 or above
<i386> perhaps we could take this somewhere else lifeless ?
<lifeless> i386: #rhodes I guess :)
<Necrogami> im a svn user currently how does it compare? or should i spend more time reading?
<lifeless> Necrogami: stackless python is a little harder for users to get :). I'm not sure why you'd want it to require stackless python.
<Necrogami> stackless is quicker :-\
<lifeless> Necrogami: we think its superior to svn (and we're biased :)). Its got many features svn does not; and a few notables ones svn has are missing.
<lifeless> Necrogami: speed is relative; we commit on trees with 50K files in about 4 seconds on laptop hardware;
<Necrogami> Right
<Necrogami> im worrying about size of my files to commiting vs time it takes to commit
<lifeless> Necrogami: most of the places we're not extremely fast are in the process of being solved; and stackless wouldn't give as much of a win on its own as just fixing our code
<Necrogami> that's the problem  i'm currently having
<lifeless> Necrogami: how many MB are your files ?
<Necrogami> 44.82gb
<Necrogami> lol
<Necrogami> XML
<lifeless> each ?
<Necrogami> it's one main file
<lifeless> *blink*. Just to be clear; you have a single file that is ~40GB ?
<Necrogami> but it has about ... 12.5Million Files attached
<Necrogami> Yes
<Necrogami> Xml rendered map
<lifeless> and 12M subordinate files. wow.
<Necrogami> It's a map for a game i'm designing
<lifeless> so I can tell you today that we can't commit that; we hold files we're committing in memory as we commit them
<Necrogami> 12.58 million Sq Miles each sub file is a sq mile
<lifeless> Necrogami: ok this isn't making sense to me; if you have separate files then your main file is not going to be 44G
<Necrogami> no ...the Sub files are Images
<Necrogami> nothing more
<lifeless> Necrogami: so to be sure I'm reading this right
<lifeless> you have:
<Necrogami> The main file contains all of the linking data for down 1 sq ft
<lifeless> 12.58M images
<lifeless> 1 xml file that is 44GB in size
<Necrogami> yep
<lifeless> bzr can't handle that today; we currently start swapping at 3M versions paths; we will be fixing that.
<Necrogami> kk
<lifeless> each individual file gets held in memory to commit: 1 copy for the basis, 1 copy for the current version.
<lifeless> merges need 3 copies
<lifeless> so you'd need about 150GB of memory to do a commit of that file.
<Necrogami> yeah ow
<lifeless> I'm surprised any tool can manage that size file well though, xml requires a data shuffle to modify elements
<lifeless> so my immediate reaction is to suggest ways to shrink that file
<Necrogami> Yeah were in the process of breaking it down to SQL of some sort
<Necrogami> be it oracle or something
<lifeless> now, versioning a database is still going to be a problem :)
<Necrogami> oh i know
<Necrogami> but breaking down the database by regions is alot easier
<lifeless> so, we'd like to handle such size files in principle.
<i386> wow
<i386> big file
<Necrogami> oh i know
<lifeless> there are a number of engineering tasks to complete before we can.
<Necrogami> i'll definately have to stick around...
<lifeless> mainly writing streaming diff and merge
<i386> Necrogami: You might have better luck breaking each "record" of that file into a single file
<Necrogami> any current webapi's for bzr?
<i386> and having an index that lists all the "records"
<Necrogami> uh
<lifeless> i386: 24M paths will be a problem too
<Necrogami> right?
<lifeless> i386: :)
<i386> ahh :)
<Necrogami> Lifeless.... Every building and item on the map is in the XML
<lifeless> Necrogami: if you mean web viewers to see the code; yes - there is loggerhead, and bzr webserver
<Necrogami> so record count .. is about 85 Million
<i386> whoa
<lifeless> Necrogami: sure thats fine; like I said, currently 3M files makes us swap on commonly available hardware
<i386> enjoy :)
<Necrogami> Last time i ran a record counter...
<Necrogami> Yeah
<lifeless> we often hold the full tree in memory; the next inventory format should take us some way to solving that and only needing to hold modified regions in memory
<Necrogami> Nothing about this game is gonna be "common"
<Necrogami> Yeah i just lost a SVN database ...
<Necrogami> so i'm looking around for an alternative
<i386> backups are good :
<i386> :)
<Necrogami> Always .. but not necessarilly easy
<lifeless> I'm quite surprised svn managed to handle that
<lifeless> and impressed
<Necrogami> it wasn't handeling the main file
<Necrogami> just all of the images and sub files
<lifeless> oh :)
<Necrogami> Yeah :-\
<Necrogami> the first time i tried to load that main file on there
<Necrogami> it segfaulted the box
<lifeless> rofl
<Necrogami> so i quit there w/ that file
<lifeless> Dinner time
<poolie_> lifeless, i tryed changing the default and get a failure in switch tests
<poolie_> this might be after you last tested it
<poolie_> nm, enjoy your dinner
<lifeless> poolie_: ring me if you want to chat aboot it
<ubotu> New bug: #172741 in bzr "merge from knit-repo to knit branch: invalid progress bar 0/0" [Undecided,New] https://launchpad.net/bugs/172741
<mrevell> morning
<poolie_> hi mrevell
<poolie_> on the phone, will be off in a bit
<mrevell> Hi poolie_
<jdahlin> I have bzr-svn question
<jdahlin> Is it no possible to merge from an svn repo in a normal bzr branch?
<jdahlin> I branched of a vcs-import of a svn-repo, and then tried to merge from the real repository
<jdahlin> which  gives me bzr: ERROR: Repository KnitRepository(...) is not compatible with repository SvnRepository(...)
<pbor> jdahlin: I think that to be able to merge you should have branched the bzr repo with bzr-svn, branching from a vcs-import doesn't ensure that your bzr branch and the svn repo have a common ancestor
<poolie> jdahlin, i think you might need to upgrade to a rich-root repository for the bzr side
<jdahlin> pbor, ah, I take it that the vcs import tool is not creating branches which are compatible with bzr-svn.
<jdahlin> poolie, hmm, how do I do that, and are you sure that would help?
<pbor> jdahlin: yeah, that's what I've been told
 * jdahlin prays bzr-svn will survive importing his 4000 revision repository
<nebuchadnezzar> hello
<nebuchadnezzar> I want to make a svn branch with the bzr-svn plugin but I need to define a http_proxy
<nebuchadnezzar> the proxy is defined for the svn command, it works but it doesn't with bzr-svn :-/
<pbor> jdahlin: no way, you have to do that in chunks
<jdahlin> nebuchadnezzar, did you try setting the environment variable http_proxy ?
<nebuchadnezzar> yes
<nebuchadnezzar> it is set
<jdahlin> pbor, I'm 60% done, so almost there
<pbor> jdahlin: then you have plenty of ram :)
<jdahlin> pbor, ram usage by that process is also 60%, interestingly :-)
<nebuchadnezzar> jdahlin: netstat show me that python send a SYN to the remote web server instead of the proxy
<jdahlin> nebuchadnezzar, iirc urllib is supposed to pickup http_proxy
<jdahlin> I'm not sure what bzr uses for http though
<james_w> bzr uses pycurl by default, but this is probably going through the libsvn, so I'm not sure why it would differ to the svn client.
<james_w> nebuchadnezzar: have you tried bzr branch svn+http://...?
<nebuchadnezzar> james_w: it works
<nebuchadnezzar> with svn+https:// the connection is done via the proxy
<VSpike> hi folks.. probably a simple question but working on a train with limited battery and no internet except cellphone...
<VSpike> i want to move versioned files from foo to foo/baz
<VSpike> I tried bzr move foo foo/baz
<VSpike> and it gave me a exception trace
<VSpike> which i will email when i can as it asks
<VSpike> so i did mkdir foo/baz
<VSpike> mv foo/* foo/baz
<VSpike> bzr mv foo foo/baz --after
<VSpike> but it said foo/baz was not versioned (Id moved .bzr too)
<Kinnison> Was this within a tree?
<Kinnison> E.g.
<Kinnison> mkdir foo foo/baz
<Kinnison> bzr add foo
<Kinnison> bzr mv foo foo/baz/
<Kinnison> or moving a tree in its entirety?
<VSpike> so i moved files back and tried bzr init foo/baz && bzr mv foo foo/baz
<VSpike> i want to move tree entirely
<VSpike> if i just move it all including .bzr it thinks files have been deleted
<VSpike> will i have to move it sideways then down?
<Kinnison> Erm
<Kinnison> So you have dir foo
<Kinnison> and dir foo is a bzr branch?
<Kinnison> you can just rename the dir
<VSpike> yep
<VSpike> .bzr doesnt contain any absolute paths?
<Zindar> no
<Kinnison> nope, it's all relative to where the .bzr is
<VSpike> hm ok i figured i would have to tell it somehow
<poolie> mrevell, can you please make sure to read ian's user guide draft, if you haven't already
<poolie> it's on the list
<VSpike> let me try that again
<Zindar> hi all :)
<mrevell> poolie: Thanks for the reminder. I'm working through it now.
<Kinnison> VSpike: http://rafb.net/p/PcjCBE85.html
<VSpike> sorry..dunno if you saw my last msg
<VSpike> when i move it bzr status list lots of files as unknown
<VSpike> if u did i missed ur resp
<Kinnison> VSpike: I offered http://rafb.net/p/PcjCBE85.html
<Kinnison> that was the last bit I said
<AfC> jdahlin_: how's your import going?
<jdahlin_> AfC, oh
<jdahlin_> it broke :-)
<jdahlin_> SubversionException: ("REPORT request failed on '/svn/!svn/vcc/default'", 175002)
<AfC> Gee, I wouldn't have used a smiley for that!
<jdahlin_> ah, it was at 90% or so
<jdahlin_> how could I not smile?
<jdahlin_> let me attempt to do it in steps as pbor suggested
<jdahlin_> so the first run is simple, just say, -r 500
<jdahlin_> and after that should just be a merge -r 1000
<jdahlin_> right pbor?
<pbor> yeah... I may have a script I used for gedit
<pbor> r=$1
<pbor> while [ $r -ne $2 ]; do
<pbor>         bzr pull -r$r svn+ssh://pborelli@svn.gnome.org/svn/gedit/trunk
<pbor>         r=$(( $r + 100 ))
<pbor> done
<AfC> jdahlin_: (can I suggest doing it in steps of 5 or so, to get the technique right first?)
<jdahlin_> AfC, too late, but I'll do the 5 revisions in the first merge
<jdahlin_> assuming I can branch of the first 500 revisions
<AfC> heh
<jdahlin_> thanks pbor
<jdahlin_> pbor, I tried bzr-svn 6 months ago or so, I had some issues merging back and forth
<jdahlin_> pbor, do you know if it's working better these days?
<pbor> jdahlin_: I tried it a bit and it worked
<AfC> jdahlin_: I gather that it is - although the person who was hacking on it most (jelmer) is now faced with writing bzr-git
<pbor> (to be honest I am doing so little dev that I went back to plain svn)
<pbor> jdahlin_: make sure to also get the rebase plugin
<jdahlin_> cool, bzr-git!
<jdahlin_> does that mean that I don't have to use git any longer?
<AfC> Hopefully it will someday.
<AfC> Roundtripping between dissimilar systems is always going to risk being lossy; I'll be happy with one way import if I can get it.
<jdahlin_> pbor, what is the rebase plugin for?
<pbor> jdahlin_: suppose you branch from svn at rev 100 and then hack away and commit locally...
<pbor> then some commits happen in svn, e.g. the current head revision is 102
<pbor> you can rebase your local changes as they were done branching from 102
<jdahlin_> I thought I would be able to get these changes by doing another bzr merge?
<pbor> and then you can safely push to svn to commit
<AfC> Why wouldn't you just merge?
<pbor> I guess this allwows to keep th history more linear
<pbor> not sure what the practical implications are
<ubotu> New bug: #172791 in bzr "bzr merge A B and bzr merge B A produce different sets of conflicts" [Undecided,New] https://launchpad.net/bugs/172791
<Janzert> To upgrade from 0.90 is it safe to just run setup.py install or should I remove the 0.90 bzrlib directory first or?
<jdahlin__> hmm, and no bzr-svn ubuntu packages for bzr-svn 0.4.4
<ubotu> New bug: #172794 in bzr-eclipse "add support for quick diff" [Undecided,New] https://launchpad.net/bugs/172794
<jdahlin__> oh, there is one in hardy. nice.
<abentley> lifeless: I am starting to work on mpdiff-based packs.  I'll be making iter_files_bytes the underlying content-retrieval mechanism.
<AfC> Janzert: should be safe
<Janzert> AfC: ok, thanks.
<mneisen> Hi, I just wanted to branch the mainline branch of bzr and got the error message: "bzr: ERROR: Connection error: curl connection error (problem with the SSL CA cert (path? access rights?))". What shall I do?
<mwhudson> uh
<mwhudson> mneisen: what command line did you use?
<mneisen> mwhudson: The right one :-D ... Anayway, case close, I garbled up the URL ... https instead of http. No wonder bzr could not make any sense of it!
<mwhudson> mneisen: well, that's not the correct url then is it :)
<mwhudson> mneisen: glad to hear it's working in any case
<mneisen> mwhudson: thank you anyway?
<mneisen> mwhudson: The question mark was unintended.
<mwhudson> mneisen: :)
<dato> heh, here I was wondering why updating bzr.dev was taking so long
<jam> dato: pulling from packs into knits?
<dato> yes
<jam> if you have an older bzr that is *really* slow
<jam> with bzr.dev it is a bit faster
<jam> but it isn't transparently fast
<dato> the best I could do would be `bzr upgrade` in my bzr.dev copy, right?
<jam> dato: well if you only have 1 branch of bzr.dev (no personal ones) I would probably nuke it and start from scratch
<jam> because you should "bzr reconcile" before you "bzr upgrade"
<dato> ok, thanks; I'll branch from scratch
<jam> Though bzr reconcile should be better than it used to be
<jam> The last time I reconciled, it took about 1hr
<jam> so I'm guessing a fresh pull will be faster for you
 * dato does `rsync -avP --exclude .bzr.backup bazaar-vcs.org::bazaar-ng/bzr/bzr.dev bzr.dev`
<dato> jelmer: hi, are you around for a bzr-svn problem? I'm finally trying to push a bzr branch to svn, but I get this error:
<dato> % b svn-push https://forja.rediris.es/csl2-minirok/trunk/
<dato> bzr: ERROR: Not a branch: "https://forja.rediris.es/csl2-minirok/trunk/".
<jam> dato: just as an aside, did you try "bzr svn-push svn+https://" ?
<dato> nope, should I?
<dato> ah
<dato> right
<dato> nope, same error
<jam> dato: are you sure you have the right URL, going there in a browser
<jam> gives me a 404
<jam> "Page not Found"
<jelmer> abentley: hi
<jam> dato: it certainly seems difficult for a 404 to be a branch
<jam> especially an svn one
<jelmer> s/abentley/dato/
<dato> hm
<jam> dato: https://forja.rediris.es/svn/csl2-minirok/
<jam> you need the "svn/" in the url
<dato> oops, thanks
<jam> dato: however, there is no 'trunk' either
<jam> though maybe you are creating it?
<dato> yes
<dato> sorry for having you debug this
<jam> I don't know if you can create branches with svn-push
<jam> jelmer: ^^ ?
<dato> yes, afaik
<dato> not with "push" alone
<jelmer> yes, you can - but only with svn-push
<dato> jelmer: svn-push -r 1 should just push one revision, right?
<jelmer> yep
<jelmer> uhm
<jelmer> if -r is supported for svn-push
<dato> it's in the help
<dato> let's see if they've actually enabled the pre-revprop-change
<dato> bzr: ERROR: Permission denied: ".": MKACTIVITY of '/svn/csl2-minirok/!svn/act/eedb297f-6600-4219-a18b-b62d24fcce9b': authorization failed (https://forja.rediris.es)
<dato> jelmer: is that error sort of known?
<jelmer> dato: you weren't expecting a permission denied error?
<dato> well
<dato> I guess it makes sense, since it didn't ask for a passwrd
<jelmer> bug 120768
<ubotu> Launchpad bug 120768 in subversion "Should prompt for passwords" [Undecided,New] https://launchpad.net/bugs/120768
<jam> vila: ping
<vila> jam: pong
<jam> vila: I think you took Robert's code too literally
<jam> I just sent an email
<jam> but: ranges = coalesced[group * max_ranges:group+1 * max_ranges]
<jam> looks like it has a host of problems with it
<jam> I think the real value you want is:
<jam> ranges = coalesced[group:group+max_ranges]
<vila> rhaaa, I knew something simpler was possible ;)
<jam> I don't know how what you had was working
<jam> Unless you only had 1 range
<jam> or maybe 2
<vila> ..and correct too :)
<vila> it worked in the smoke test because no readv required more than 200 ranges
<vila> thanks anyway, fixed, nobody could use that buggy version so far except me, I rarely commit before testing but I'm highly interruptible these days, so...
<vila> jam: did you read the rest of my patch, any comments ?
<jam> vila: did you read my email
<jam> ?
<vila> I tried re-factoring sftp_readv up front, but there was too many unclear small diferrences between sftp and http
<jam> yeah, the off-by one is a killer
<jam> http ranges are inclusive
<jam> I don't remember sftp
<jam> but it is either start+length
<vila> jam: about sftp patch ? Yes replied ;-) off-by-one ? did you send several emails ?
<jam> or start => end non-inclusive
<jam> vila: I sent 2 email
<jam> emails
<vila> ok
<jam> one to your list email
<jam> and one to your patch email
<jam> (from bazaar-commits)
<jam> vila: for the 65536... openssh supports larger ranges
<jam> but the sftp spec
<jam> says they "must support at least 32k"
<jam> I believe it says they must support a total request of at least 34k
<jam> including overhead
<vila> paramiko seems to use 32768 anyway in my currently installed version, nvm
<vila> but I looked at the async implementation with a thread... ;-)
<jam> well paramiko uses threads, IIRC
<jam> but bzr itself doesn't
<dato> jelmer: so how should I do it, do a dummy commit with the svn client so that the credentials get stored and bzr can use them?
<jelmer> dato: yes, that's the only way I'm aware of
<vila> ha, your second email is there
<jelmer> dato: until I manage to fix upstream svn...
<vila> main problem for the http parser: if we turn it into an iterator to return data as soon as they arrive, there will be no guarantee anymore that the socket is left "clean", i.e. no finally statement for the iterator
<vila> I can clean that when the last offset is handled but do I have the guarantee that bzr will always consume all offsets ?
<vila> jam: Since http processing is still synchronous I don't understand your point, more requests means more latency means more clock time.
<jam> vila: well, I'm thinking more polling the socket for more data
<jam> I won't make a strict guarantee that we iterate all of the data, just because if we get an exception we won't pull the rest
<jam> but the fact that we requested it means we want it
<jam> so I don't think we will issue a request and only read 1/2
<jam> in 2.5 you could use a try/finally
<jam> the poor man's version is a try/except/else
<jam> (for 2.4)
<jam> but you aren't guaranteed to have the finally happen if we stop iterating
<jam> vila: for you other statement...
<jam> right now bzr pull http:// *feels* slow
<jam> because we spend a long time buffering a huge request
<jam> a) Not consuming memory may help VM pressure, but that isn't really a primary effect
<jam> b) It will *feel* faster because we can at least spin our little progress bars as we go
<jam> c) you will be able to ^C even with pycurl
<jam> because it isn't buffering 20MB before returning control
<vila> c) hehe, you leave me no surprise to announce ;-)
<vila> a) and b) should be addressed by rewriting the http response parsing
<jam> vila: well the other fix for (c) is to give the pycurl code a python write function
<jam> so that as it gets data, it calls back into python
<jam> which can check for ^C
<vila> jam: I know
<jam> but I'm not sure how well pycurl handles having the callback raise an exception
<jam> I think we could even just have a simple progress callback
<vila> jam: realized it lately, but didn't look at how do it
<jam> and have it still do the buffering internal to pycurl
<vila> regarding exption/iterators, you say that if an exception occurs in the user code, the execption can be seen in the iterator func and a simple except Exception is enough to catch it ?
<jam> vila: no
<jam> just if it happens in the readv code
<jam> in python2.5
<jam> try/finally works
<jam> because when a generator is garbage collected
<jam> it gets an exception
<dato> jelmer: ok, it worked. I'm so happy to have bzr-svn. :-)
<jam> but that construct is *illegal* in python2.4 :*(
<jam> :'(
<jam> hmm. what is the tear smiley?
<jam> I guess Colloquy doesn't have it
<vila> bah, garbage collection is far too late for me, I should clean the http socket before reusing it for another request while in the same time not trying to read too much if it's clean ;-/
<jelmer> dato: cool :-)
<vila> well, thanks for the explanation, the easy way does not work then
<jam> vila: I'm not talking GC as in python interpreter shutdown
<jam> I mean as soon as it is no longer referenced
<jam> aka, the calling code has had an exception
<jam> vila: I wouldn't try too hard
<jam> I think we will always consume everything
<jam> except when we have an unrecoverable error
<jam> I suppose you could set a flag
<jam> which tells the HTTPTransport whether it is clean
<jam> and set it to false at the beginning of readv()
<jam> and only set it True if you get to the end.
<vila> jam: hmm, not trying too hard and get blamed when the next hhtp request fails :-)
<jam> vila: I'm always happy to blame you
<vila> jam: yeah sure, but just  an expect clause is easier and cleaner
<vila> jam: that's a good start ;-)
<jam> "expect" or "except"
<vila> except of course
<vila> most of my typos occurs because the brain->fingers socket is UDP
<jam> have you ever been checked for Dyslexia ?
<jam> :)
<vila> have you ever been trying to change you keyboard mapping between azert and qwerty hundreds times by day ? ;-)
<jam> vila: I have gone from dvorak to x,dokt
<jam> oh, I mean qwerty :)
<vila> I now use only qwery keyboards but the harm is done ;)
<jam> ,dppw G hslqk vls, ,jak tsf mdal
<jam> Gq.d ld.do jah rosnpdm; ,gkj vdtmar;
<jelmer> jam: Why'd you decide to go back?
<jam> (I don't know what you mean, I've never had problems with keymaps)
<jam> jelmer: I still use dvorak primarily
<jam> but it is hard to touch type with one hand
 * jelmer has attempted to switch to dvorak a couple of times
<jam> with a baby in the other
<jelmer> but I just get so annoyed after a couple of days that I switch back
<jam> when you have a qwerty keyboard in dvorak mode
<jam> jelmer: it took me 1 month to get back to real speed
<jam> I had a slow month one time when my wife was away
<jelmer> jam: There's single-handed dvorak as well :-)
<jam> jelmer: sure, but try getting that on the keyboard :)
<jam> And it is also a left form
<jam> and a right-form
<jam> and the baby goes both ways too
<jam> so I would need keys with dynamic labels
<jelmer> :-) More keymaps to learn...
<jam> which would be really cool
<jam> some other oddities
<jam> the "A" and "M" keys don't move
<jam> so it is really easy to switch to the wrong keyboard after typing one
<jam> But Typing Tutor showed my WPM rate to be huge on those keys
<jam> I would be like 10-20 WPM for most keys
<jam> and then Spacebar was about 90
<jam> and A & M were still in the 70 range
<jam> the graph looked pretty funny
<jam> jelmer: I'm pretty happy with dvorak now. And I know Martin uses it, too.
<jam> Vim was the hardest to switch between
<jam> because so many commands just become muscle memory
<jam> rather than "O" or "a"
<jelmer> yeah, I've heard from quite a few people that it's really good
<dato> jelmer: I think it'd be best if the changelog of bzr-rebase and bzr-svn would explicitly have a DD adding the DM-foo header, so it's clear it wasn't sneaked or anything. I'll put my name if you don't mind?
<jam> When I switched and started getting *good*
<jam> it felt like I was typing slower
<jam> because my fingers weren't moving as much
<jelmer> dato: sure, thanks!
<jam> Which I felt was a good sign that it is actually less stressful
 * jelmer just needs to gather the discipline at some point to actually make the switch and not quit halfway through again :-)
<jam> jelmer: well, I would switch back occasionally when I had a long email to write
<jelmer> did you relabel your keyboard or anything?
<jam> I did not relabel
<jam> but I'm a strong touch typist (now)
<jam> In high-school I always looked at my hands, but eventually I just grew out of it
<jam> not sure exactly when it happened
<jam> but it wasn't a conscious effort
<jam> anyway, not having the keyboards labeled actually worked well for me
<jam> I do have a keyboard with the labels moved around now
<jam> but I couldn't move the "F" and "J" keys
<jam> because they have the little dots that you put your fingers on
<jam> and I accidentally switched the V and W
<jam> and haven't gone back to fix it.
<jam> (Which is a pretty big issue because ^W is close window, while ^V is paste text)
<jam> not something you want to mix up.
<jelmer> :-)
<ubotu> New bug: #172861 in bzr "add: accepts aliases due to case insensitivity" [Undecided,New] https://launchpad.net/bugs/172861
<ubotu> New bug: #172865 in bzr "commit: fails to detect deletion of aliased file" [Undecided,New] https://launchpad.net/bugs/172865
<ubotu> New bug: #172870 in bzr "'bzr fetch' broken" [Low,Triaged] https://launchpad.net/bugs/172870
<mwhudson> er
<mwhudson> bzr --no-plugins selftest test_build_and_install
<mwhudson> fails for me on bzr.dev
<mwhudson> oh duh
<mwhudson> ./bzr
<mwhudson> i'm always doing that
<dato> OH GOD
<dato> this is *so* fast
<dato> commiting in bzr.dev with packs
<mwhudson> abentley: should revisiontree have case_sensitive = True somewhere?
<mwhudson> how long should i expect reconciling bzr.dev (with bzr.dev) to take?
<mwhudson> (in a knits repo)
<dato> 16:27 <jam> Though bzr reconcile should be better than it used to be
<dato> 16:27 <jam> The last time I reconciled, it took about 1hr
<mwhudson> thanks
<mwhudson> the progress bar is doing funny things :)
<jam> mwhudson: it depends a lot on hardware. I don't think I've tested it after Robert's latest improvements
<jam> but just prior to that, my desktop was about 1.5hrs and my laptop was 2-3hrs
<mwhudson> going for 28 minutes here
<mwhudson> and the progress bar is almost all the way across
<mwhudson> for the second time :)
<mwhudson> oh wow, just finished
<mwhudson> so must have been ~30 minutes
<mwhudson> not bad at all
<mwhudson> fooey
<jam> ?
<mwhudson> my upgrade to packs broke
<mwhudson> bzr: ERROR: Revision {('aaron.bentley@utoronto.ca-20070517163555-3i7jamitmffdg85l',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x4cb3ed0>".
<mwhudson> /home/mwh/src/bzr/bzr.dev/bzrlib/lockable_files.py:110: UserWarning: file group LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///home/mwh/src/bzr/.bzr/repository.backup/>) was not explicitly unlocked
<jam> that isn't good
<jam> is that from a 'bzr check' ?
<jam> mwhudson: how did you get that error?
<mwhudson> "time ./bzr.dev/bzr upgrade --format=rich-root-pack"
<jam> so the upgrade itself failed
<mwhudson> yes
<jam> hmm.. rich-root-pack will have to rebuild all of your inventories
<jam> are you sure you don't want pack-0.92 ?
<mwhudson> not really no
<mwhudson> let me try that instead
<jam> It still shouldn't fall over and die
<jam> but we should start with 1 step at a time
<jam> mwhudson: if you have been using bzr-svn in that repository, you probably *have* to use it, though.
<mwhudson> indeed, if this works i can try upgrading again
<mwhudson> ok, so _that_ went rather more smoothly
<jam> well, pack-0.92 just has to do a very simple transformation
<jam> actually, I think it can just shove the inventory data over verbatim
<jam> but for the file data
<jam> it gunzip, split & strip, gzip
<jam> (it strips the annotation lines.)
<mwhudson> oh, is pushing from knits to packs still terrible?
<mwhudson> er
<mwhudson> packs to knits
<jam> mwhudson: not as terrible
<jam> It has to add the texts one by one
<jam> but it doesn't rebuild the whole history of each modified file
<mwhudson> jam: ok
<jam> I'm using it right now
<jam> (my local repos are packs, bound to a knit repo)
<mwhudson> oh, actually this is a fairly big push i'm doing
<igc> morning
<jam> morning igc
<igc> hi jam
<jam> enjoying OSDC?
<igc> excellent
<igc> all finished now
<ubotu> New bug: #172893 in bzr "test_lock_permission selftest fails" [Undecided,New] https://launchpad.net/bugs/172893
<mwhudson> yah, ./bzr.dev/bzr upgrade --format=rich-root-pack fails starting from packs-0.92
<mwhudson> i guess that's a bug or something
<jam> or you might still have inconsistent data, and the plain upgrade to packs doesn't notice
<jam> can you try running 'bzr check'?
<jam> It is probably a bit slower than 'bzr reconcile', though.
<mwhudson> in a bit
<jam> thanks
<lifeless> mmoin
<mwhudson> actually it fails in 0.3 seconds :)
<mwhudson> oh, partial upgrade
<beuno> abentley, when you got a minute, I'd like to have a quick chat with you over this whole XML thing if possible. Seems easier then through the ML
<lifeless> hi statik
<beuno> I'm pulling bzr.dev to my current local knit repo and it's *extremely* slow (I'm at revno 3021 and it's been ~25 minutes and I'm < 10% through)
<beuno> is this an expected behaviour due to the change to packs?
<lifeless> beuno: what revno are you using to pull?
<beuno> lifeless, I'm at 3021 and I just did "bzr pull"
<lifeless> beuno: there was a bug where it reannotated too much, which you could be experiencing
<beuno> would it be useful if I canceled and debuged somehow, or is it solved?
<dato> beuno: jam recommended me to pull a new fresh branch
<lifeless> beuno: looks like that is not the case
<lifeless> beuno: don't stop it
<lifeless> beuno: look in  ~/.bzr.log
<lifeless> is there http readv log output
<lifeless> if so, look for 'error...retring with one request' after a large collapsed readv count
<beuno> lifeless, yeap
<beuno> http readv of a3069b4df97462558e8666ff0cc72386.pack  offsets => 14 collapsed 4
<beuno> GET: [http://bazaar-vcs.org/bzr/bzr.dev/.bzr/repository/packs/a3069b4df97462558e8666ff0cc72386.pack]
<beuno> http readv of a3069b4df97462558e8666ff0cc72386.pack  offsets => 15 collapsed 4
<beuno> GET: [http://bazaar-vcs.org/bzr/bzr.dev/.bzr/repository/packs/a3069b4df97462558e8666ff0cc72386.pack]
<beuno> http readv of a3069b4df97462558e8666ff0cc72386.pack  offsets => 14 collapsed 5
<beuno> GET: [http://bazaar-vcs.org/bzr/bzr.dev/.bzr/repository/packs/a3069b4df97462558e8666ff0cc72386.pack]
<beuno> lots of those
<lifeless> beuno: so each of those is reading one text
<lifeless> beuno: then it gets annotated and inserted into your local repo
<beuno> lifeless, right, so it's a "known bug". Can we make use of this case in anyway, or should I follow dato's suggestion and re-branch?
<lifeless> beuno: I would reconcile and upgrade to packs, then pull. No need to rebranch
<beuno> lifeless, will do, thanks
<lifeless> jam: ping
<jam> lifeless: pong
<lifeless> how are you going on the pull bug
<jam> doing okay
<jam> getting sidetracked again because bzr+ssh is taking 6s to copy 2MB on my loopback
<lifeless> that will be the data stream api sucking on bzr:
<jam> sftp is taking 700ms
<jam> but on my server it is 244ms
<jam> for bzr+ssh
<lifeless> oh
<lifeless> push or pull
<jam> and 358ms for sftp
<jam> transport.get_bytes()
<lifeless> pull
<jam> I don't know if Mac is just really Fubar
<jam> or if we are provoking it
<lifeless> do you want me to take over the patch then ?
<jam> I'll finish it up
<lifeless> ok
<jam> just frusttrating to use bound branches
<jam> when every commit is taking > 6s
<jam> because it is loading the remote index
<lifeless> I'll are they packs?
<jam> remote is still knits
<lifeless> well then
<jam> I want to test the pack => knit stuff
<lifeless> packs -> partial indices.
<jam> since it exposed some real issues
<lifeless> kk
<jam> weird, the Pack=>Pack code isn't being tested by interrepository_implementations
<jam> I'm adding it, since the way you had me set up the test is portable across all repos
<lifeless> are you sure ?
<jam> (with the rule that you either have to copy the basis text, or you have to fail)
<jam> lifeless: InterPackRepo isn't listed in __init__.py
<lifeless> I am positive I have test failures within interrepository when I bugger up pack to pack
<lifeless> jam: which __init__ ?
<jam> hmm... you are using InterRepository._optimizers
<lifeless> right
<lifeless> dynamic registration -> tests
<jam> interrepository_implementations/__init__.py
<lifeless> so that plugins get tested too
<jam> lifeless: I don't think it is working as you expect
<jam> since it wasn't testing that code
<lifeless> __init__ only lists specific manual combinations where the dynamic stuff isn't sufficient
<jam> until I manually added it
<jam> hmm.. maybe
<jam> I'll take a closer look
<lifeless> it may have been masked by poolies nuking the default repository format attribute; unlikely but possible; run with -v
<jam> Unfortunately the ids only show you the inter object
<jam> so Knit1 => Knit3 is just InterKnit
<lifeless> right
<lifeless> so if -v shows InterPack
<lifeless> then it thinks its testing it
<lifeless> but if its not failing, something is masking it.
<jam> you're right
<jam> and it seems like Pack=>Pack is the only thing that fails
<jam> Pack => Knit is file
<jam> fine
<jam> and Knit => Pack is fine
<lifeless> probably incorrect parameterisation - some aspect of the format isn't actually one that will cause it to match
<jam> (Probably because both use the Knit=>Knit code)
<jam> lifeless: it is present, and it is failing
<jam> I just thought I should see more failures
<lifeless> jam: good; why did you think it wasn't being tested :)
<jam> Only 1 fail
<jam> I thought it was a Pack => knit
<jam> or knit => pack
<lifeless> no, they do the dumb recursive-join-of-versioned-files stuff
<lifeless> remote* uses data streams
<jam> so do we need an inter that goes through Remote ?
<jam> by the way, we use pack_repo.Packer() to do the fetch
<jam> is this going to conflict with your latest revising of that code?
<jam> I suppose I can just review your patch
<jam> and get it merged
<kiko>  1366 kiko      15   0  302m 300m 2812 R    6 14.9   0:59.62 bzr
 * kiko tells bzr to stop growing
<jam> kiko: what are you doing? and what version of bzr are you doing it with?
<jam> (reconciling launchpad code with an older version of bzr is not recommended)
<kiko> jam: just a bzr branch
<jam> from/to ?
<jam> (that said, at the moment, if you are using http we will buffer all requests before processing them.)
<lifeless> jam: there are two
<lifeless> jam: two and from
<lifeless> jam: my reconcile patch contains most of the code you need.
<jam> I'm trying to review your "trivial syntax error"
<lifeless> kiko: what version of bzr  ?
<jam> which I think is your reconcile patch
<lifeless> jam: yes; see the prior email for the cover text
<kiko> Bazaar (bzr) 0.91.0
<kiko> jam: a local branch of launchpad from a local rsynced launchpad
<kiko> no repo
<lifeless> kiko: use bzr.dev; I think you'll find its a lot more efficient on memory
<jam> lifeless: it is a little bit hard to track down what actually changed versus what is just mechanical
<jam> since you split the functions up
<jam> I can certainly check ReconcilePacker directly
<jam> but any hints for just plain Packer ?
<lifeless> oh
<lifeless> so, in plan Packer there are no changes, just shuffling
<lifeless> there is one new method in Packer, which is useful to you
<lifeless> but not actually called
<lifeless> thats the external_text_references method
<lifeless> it might be better on Pack actually; still - its the thing you need to determine what external texts you need to reconstruct all the texts in the pack
<jam> lifeless: "external_compression_parents_of_new_texts" ?
<lifeless> yes
<lifeless> e.g. for the scenario we cooked up
<jam> yeah
<lifeless> rev B file id F deltas against rev A file id F
<lifeless> that should return [(F,A)]
<kiko> lifeless, where does bzr.dev live
<lifeless> then you can do present_external_keys = list(self._pack_collection.text_index.combined_index.iter_entries([(F,A)]))
<lifeless> if len(present_external_keys) != len([(F,A)]):
<lifeless>    error here
<lifeless> kiko: http://bazaar-vcs.org/bzr/bzr.dev, or lp:bzr
<kiko> lifeless, and debs?
<lifeless> we don't currently build debs of bzr.dev
<kiko> ah, I see
<lifeless> kiko: you know you can run from source trivially -
<kiko> yeah, I know
<beuno> lifeless, I reconciled and did: "bzr upgrade --format=knitpacks-experimental", and it's still taking forever to pull with the same feedback in ~/.bzr.log.  What could I have done wrong?
<lifeless> beuno: do you have a shared repository? did you actually upgrade the repo and not just a branch?
<lifeless> bzr info will tell you
<beuno> lifeless, aaaaah, yes, shared repo
<beuno> that might be it
<beuno> doing the same with the shared repo
<lifeless> hi jrydberg
 * igc breakfast
<poolie> morning
<beuno> hello again
<beuno> upgrading to packs
<beuno> and I'm getting this: http://paste.ubuntu-nl.org/46275/
<beuno> (the shared repo has already been reconciled and upgraded)
<jam> well, it seems the reconcile is seeing nothing to do
<jam> but I don't know why it is trying to remove the un-added pack from the memory index
<jam> beuno: so (a) the error is "harmless" your data is good
<jam> (b) I'm guessing Robert's new code (which I'm reviewing now) is going to change all of this anyway
<lifeless> beuno: what version of bzr are you doing that with ?
<lifeless> beuno: oh, yes. you can't reconcile packs without my patch
<lifeless> hhi poolie
<lifeless> poolie: I've changed the deefault; patch up for review
<poolie> ok, thanks
<lifeless> poolie: I'm working on 165106 now
<dato> bug #165106
<ubotu> Launchpad bug 165106 in bzr "check that get_data_stream distinguishes annotated and unannotated knits" [High,Invalid] https://launchpad.net/bugs/165106
<lifeless> nearly done
<poolie> i didn'tread the reconcile patch now, but will soon
<beuno> lifeless, latest bzr.dev
<beuno> freshly pulled
<jam> lifeless: generally it seems good
<beuno> lifeless, it's actually a knit branch with a shared-repo with packs
<jam> There are a couple confusing things which should probably be documented
<jam> and a small bug in some error handling code
<jam> lifeless: and I would like to build on your patch, but I think I can do it without any cleanups
<lifeless> jam: feel free to +1, then merge it into yours and build on it and cleanup at the same time :)
<lifeless> jam: no point serialising your fixes to me then me deserialising and doing
<lifeless> jam: unless its easier for you
<jam> lifeless: as long as you are okay with my comments
<jam> I've already bb:tweak ed it
<lifeless> ref-keys is missing_texts
<jam> I'm planning on merging your code into my branch
<lifeless> k
<jam> it should be fine as is
<jam> for what I need
<lifeless> so your comments and questions are good
<lifeless> this is unannotated so the ordering stuff is moot
<jam> other than "locality of reference" but sure
<lifeless> yah
<lifeless> but this is meant to be rare
<lifeless> the _use_pack stuff looks correct to me; its a little redundant is what I think you are saying
<jam> lifeless: correct
<lifeless> the knitversionedfile index stuff I'll write up for you
<jam> but also I meant to point out you could check the indexes there
<lifeless> well we don't want to have to compare 10's of thousands of keys
<lifeless> better to set a flag when we notice a problem
<lifeless> and not all issues will show up in the indices
<poolie> lifeless, did you fix the switch thing implicitly to change the format?
<poolie> i think there were no other failure
<poolie> s
<lifeless> poolie: I fixed the switch thing yes
<lifeless> part of the same patch
<poolie> lifeless, spiv, igc, jam: one minute to call
<igc> sure
<vila> spiv: have you looked at my comment on bug #172701 ?
<ubotu> Launchpad bug 172701 in bzr "Large readv requests can fail if there is a squid proxy" [High,In progress] https://launchpad.net/bugs/172701
<spiv> vila: Thanks; I just saw it.
<spiv> vila: I'll try again with pycurl.VERBOSE.  Also I'll try capturing the actual HTTP requests/responses involved, both before and after the proxy.
<lifeless> vila: I knew spiv had a proxy
<lifeless> vila: I was doing divide and conquer
<vila> lifeless: oh, I hoped you had an insight...
<spiv> vila: in case it helps, my proxy is an intercepting proxy (i.e. the client thinks it is connecting to port 80 of bazaar-vcs.org, but it actually connects to squid).
<spiv> lifeless: you wanted to figure out which software of yours to blame? ;)
<vila> hehe
<vila> spiv: anyway, there is a bug here since we should have catched the short read and issued another request (the new implementation will catch it, but I want to to give a try to read-as-we-receive before submtting)
<vila> good night all, kudos for the hard work of the last days
#bzr 2007-11-30
<Peng> Anyone who knows bzrlib.commit here?
<Peng> I decided to take a stab at bug 172612 (change the first line of commit's output to say "Committing to: <dir>" instead of 'Committing revision N to "<dir>"'), but I ran into something: the location passed to NullCommitReporter and friends is optional. Is it ever actually not given? In Commit, it's either self.master_branch.base or self.branch.base. Are those ever None?
<ubotu> Launchpad bug 172612 in bzr "new commit is overly verbose" [Low,Confirmed] https://launchpad.net/bugs/172612
<Peng> I changed it to throw an assertion if it's not given and ran the testsuite (well, at least the commit part of it) and it never failed.
<Admiral_Chicago> a lightweight checkout grabs the repo withou the history correct?
<poolie> Admiral_Chicago, right
<poolie> Peng, that sounds reasonable then
<poolie> though if it's just for the message, maybe it'd be better to handle it not being passed
<Admiral_Chicago> poolie: is there a way to grab the history after I do a lightweight checkout?
<Peng> poolie: Yeah. I'm wondering what the message should say then, though. It used to just say "Committing revision N", but now it would say, what, "Committing"? Nothing?
 * Admiral_Chicago waves to jam
<poolie> Admiral_Chicago, i would think 'reconfigure --checkout' but i'm not usre
<poolie> maybe just 'committing'
<poolie> but i can't think of a good case where we wouldn't know the location
<Peng> poolie: In the current code, it's either self.master_branch.base or self.branch.base (depending on if it's a checkout or not). Is it possible for those to be None?
<Admiral_Chicago> okay thanks, I'll look at the man page, perhaps that has some info
<poolie> Peng, i suggest you just post a patch with the assertion in
<Peng> poolie: Really? Okay.
<poolie> easier to look at it in the actual text
<poolie> don't forget [merge][#172612] in the subject
<Peng> poolie: use commit --fixes too?
<poolie> yes, --fixes lp:172612
<Peng> poolie: Update NEWS, you think?
<poolie> yes, as a bug fix
<Peng> 'kay.
 * Peng is reading the mailing list thread on this.
<jam> Peng: branch.base will never be None
<jam> it is the URL to that branch
<jam> (and we have to have a location to have a branch)
<jam> *however*
<jam> I think the =None is there
<jam> to support people who might have been using that api
<jam> before the location was required
<jam> It is unlikely that there are many people doing it
<Peng> Well, Daniel Watkins only added .started() in that patch. It's been required from the moment it was added.
<jam> well, obviously for some reason he wanted the ability to pass None...
<jam> Isn't Daniel Watkins Odd_Bloke ?
<jam> (maybe that will summon him :)
 * Odd_Bloke appears from his lamp.
<jam> Odd_Bloke: any reason why you wanted location=None?
<Odd_Bloke> If the other hooks in CommitReporter use it, then it's probably because I just used one of those as a model.
<Peng> Hmm.
<Odd_Bloke> So it's probably a case of YAGNI.
<Peng> As of now, none of the other commit reporter methods take a location.
<Odd_Bloke> OK, I'll have to have a look at the code in the hopes it'll remind me. :p
<poolie> jam, i commented on the get_ancestry patch
<Peng> Hell, Smallville is on, and it's a repeat, but I missed the first 15 minutes of this episode last time. BRB.
<poolie> is there anything else you'd like tonight?
<jam> poolie: I saw that... so what is your feeling for bzr.dev versus 1.0?
<poolie> btw you didn't mark that as [merge]
<jam> I really think it should be in 1.0
<poolie> i think just put it in both
<poolie> me too
<poolie> and when we fix it to avoid that call, great
<poolie> (robert's just at the station, going to meet him)
<jam> I do understand Robert's point about wanting to provoke the devs and the community into fixing the real issues
<jam> (not going through all of history)
<Odd_Bloke> Peng: AFAICT, the 'location=None' part is an artefact from when I refactored the location notification from the 'completed' hook to the 'started' hook.  As the completed hook already existed, I had to add an extra parameter to avoid breaking the API and this got carried over, unnecessarily, to 'started'.
<Peng> Odd_Bloke: Oh.
<Peng> Hmm. Is making it non-optional worth an unannounced API break?
<Peng> Or deprecation warning?
<Peng> Or just an ugly workaround? :P
<Peng> Is it possible to deprecate an argument?
<Peng> Well, deprecate the optionalness of an arg.
<spiv> Peng: sure
<spiv> Peng: if the argument is not passed, do warnings.warn(..., DeprecationWarning).  There may be a fancy decorator somewhere too.
<Peng> I don't see a fancy decorator in symbol_versioning.
<Peng> I see an FIXME from 2006 about adding one.
<Peng> (*January* 2006)
<Odd_Bloke> Heh.
<Peng> Smallville's back. BRB.
<Peng> So, before I come back, what should I do? Deprecate it? Break API compatibility since it's minor?
<Peng> Also, if I do deprecate it, how would I do that? I mean, what message should I use? "location must be passed"? And then how do I tie that into symbol_versioning?
<jam> Peng: you *could* do something like:
<jam> if location is None:
<jam>   symbol_versioning.warn('As of bzr 0.93 you must pass a location to starting')
<jelmer> jam: Do you know whether lp already uses --fixes lp:... in some way?
<jam> jelmer: afaik it does not use it yet
<jam> poolie: ^^ ?
<jelmer> I don't see an open bug against launchpad-bazaar about it either >-)
<Peng> Yet another question about my one-line code change: In NEWS, it should go under improvements, right?
<jam> Peng: since it has a bug associated with it
<jam> I always put it under bugfix
<jam> it is a bit grey, though
<Peng> There's one thing in the improvements section that does have a bug.
<jam> so you can put it under improvements if you prefer
<Peng> Oops. commit.py imported symbol_versioning but didn't use it at all.
<ubotu> New bug: #172970 in bzr "packs regression: 'bzr pull ../other'" [Medium,Triaged] https://launchpad.net/bugs/172970
<Peng> Ooh, I just thought of something. I should deprecate it in the base class too, right? Just copy and paste the warning?
<poolie> spiv, hi
<Peng> When there's a base class that's, you know, all empty and NotImplemented, and I deprecate something, do I deprecate it in the base class and the, err, child class too?
<spiv> poolie: hello
<poolie> Peng, you should deprecate every concrete implementation
<Peng> poolie: What's that mean?
<poolie> because python doesn't inherit the decorators or now about deprecation itself
<poolie> what i mean is
<poolie> if there's a method in the base class that just says raise NotImplemented
<Peng> Actually, it says "pass", but yeah.
<poolie> then just add something to the docstring about it being deprecated
<poolie> oh, in that case people may actually call it
<poolie> and i'd say you should add @deprecated_method
<Peng> It's a deprecated argument so I call warn() myself inside it. So just add that?
<Peng> s/add/copy and paste/
<Peng> Oh! NullCommitReporter is used with --quiet.
<poolie> spiv, i meant to ask, how's bug 164626
<ubotu> Launchpad bug 164626 in bzr "branching from hpss doesn't preserve repository format" [High,Confirmed] https://launchpad.net/bugs/164626
<poolie> jam, hi?
<jam> poolie: hi
<jelmer> poolie: are there any plans for launchpad to recognize and use --fixes lp:# ?
<jelmer> poolie: hi, btw :-)
<jelmer> poolie: (for example, automatically change bug status to "fixcommitted" and point at the branch that contains the revision with the bug marked as fixed)
<poolie> jelmer, that's jml's department
<poolie> jam, hi, i was wondering about bug 165290
<ubotu> Launchpad bug 165290 in bzr "packs do not check for missing compression parents" [Critical,In progress] https://launchpad.net/bugs/165290
<poolie> did you say you had a patch for it?
<jelmer> poolie: ah, thanks - I'll ask him
<jam> poolie: I'm close to having a patch for it
<spiv> poolie: just composing the email with the merge directive.
<poolie> cool
<jam> but I wanted to merge in Robert's reconcile patch
<poolie> cool!
<poolie> yay
<jam> and to do that
<jam> I had to create a separate branch
<jam> because his submission was a cherrypick
<poolie> jelmer, or you could ask thumper
<jam> which means that I ran into bug 172970
<ubotu> Launchpad bug 172970 in bzr "packs regression: 'bzr pull ../other'" [Medium,Triaged] https://launchpad.net/bugs/172970
<poolie> (i can call spirits from the vasty deep)
<jam> which means that instead I'm focusing on the buffering patches
<jam> so that I can at least have a bzr that doesn't take 30s to complete a simple operation
<poolie> jelmer, i *think* at the moment it creates a link between the bug and the branch
<poolie> but it may not
<poolie> jelmer, thumper should still be awake so i expect he'll be back soon
<jam> poolie: from what I've seen, if you use a commit message of "bug #XXXX" it will show you a bug link in the revision view
<jelmer> poolie: thanks, I'll check back tomorrow though
<jelmer> well past 3 AM here
<jam> (code.lp.net/~user/project/branch/
<Peng> Odd_Bloke: Mind if I quote your explanation of location=None in a mailing list message?
<poolie> oh that too
<Peng> Wow. If this patch is an example of my usual productivity, I can produce about 2 lines of code an hour. :P
<Peng> And I ask about 10 questions per LOC.
<fullermd> Well, I remember years ago seeing the stat than an average programmer produces 10 good LOC a day, so I guess that means you get to go home after only 5 hours   :p
<spiv> Hmm, thunder and rain.
<spiv> poolie: sent.
 * spiv -> lunch
<Odd_Bloke> Peng: That's fine.
<Peng> Thanks.
<Peng> Question #39 of the night, where do I put a deprecation of something in NullCommitReporter in NEWS? API breaks?
 * poolie reads spiv's patch
<poolie> Peng, yes
<Peng> Oops. I uncommitted and rewrote the commit message and patch so much that it triggered a repack.
<lifeless> :)
<lifeless> jam: have a good friday
<jam> thanks
<jam> have a fun weekend
<lifeless> jam: I'm off now, and if I've done ~8 hours, I know you have too :)
<lifeless> I shall, its slug night shortly
<lifeless> and we're tryin out Twilight Imperium tomorrow
<lifeless> jam: have a good weekend too
<jam> sounds like a good time
<jam> lifeless: quick question
<jam> does get_graph().is_ancestor() answer True
<jam> if the candidate is the NULL_REVISION?
<jam> I guess I can just test it
<lifeless> I'd have to try to tell you
<ubotu> New bug: #172975 in bzr "bzr log slower with packs" [Medium,Triaged] https://launchpad.net/bugs/172975
<lifeless> I think it will say True
<jam> lifeless: it does say true, but it takes it a while to get there (since it traverses all of history)
<jam> so I'll leave the shortcut in for now
<jam> I was going to just deprecate the function entirely since only merge uses it
<lifeless> ah
<lifeless> get_heads() is usually more useful anyhow I think
<jam> lifeless: merge needs to know to know whether it can set a pending merge
<jam> or whether it was a cherrypick
<lifeless> I'm off; if you need to talk about something I can be reached on mobile
<jam> k
<poolie> spiv, so did you read my review comments?
<Necrogami> how's it going tonight?
<Necrogami> Funny Randomness do you use bzr to version control bzr?
<Odd_Bloke> Necrogami: We do indeed.
* i386 changed the topic of #bzr to: Not a automato
<Necrogami> Bzr is funded by Mark Shuttleworth?
<poolie> yes
<poolie> spiv, did you read my review? are you ok to merge it?
<Peng> Necrogami: Bazaar is "sponsored" by Mark Shuttleworth's company, Canonical.
 * Peng points in the direction of the website.
<Peng> ....
<Peng> Is it just me, or does this channel have a useless topic?
<Peng> /topic, I mean.
<Peng> Oh. That just happened.
<fullermd> Yeah, I was just noticing that...
* poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org
* poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org/
* fullermd changed the topic of #bzr to: The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.92 is out - http://bazaar-vcs.org/Download | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d
<fullermd> (last I have in my logs...)
<poolie> jam, you didn't attach a patch to your mail about get_revision_graph
<jam> hmm.. ok
<Peng> Yeah, that's the most recent topic.
<Peng> (Unless someone changed it during a netsplit.)
<jam> poolie: I seem to have an attachment, but it may be 0 length
<jam> I hit send too soon
<Peng> Aww, you threw out the first month of bzr.dev's history when converting it to bzr, didn't you? :(
<poolie> Peng, when it was stored in Baz?
<Peng> poolie: I think so.
<Peng> First log message is "import from baz patch-364"
<poolie> jam, i'm going to make a tarball soon
<poolie> i think i'll at least merge your index fix to the 1.0 branch
<poolie> if you're free, maybe you could look at http://bundlebuggy.aaronbentley.com/request/%3C1196392148.32300.468.camel@lifeless-64%3E
<spiv> poolie: ping
<Peng> jam: How did you get directory listings on bzr.arbash-meinel.com to show the .bzr directory?
<jam> Peng: IndexIgnore .????* *~ *# HEADER* README* RCS CVS *,v *,t
<jam> The default is ".*"
<jam> which ignores everything starting with a '.'
<jam> I changed it
<jam> to ignore only those that are longer than '.bzr'
<jam> A bit of a cheap hack
<jam> but it worked
<jam> It will also show .svn
<jam> or
<jam> .hid
<jam> .foo
<jam> etc
<jam> but not
<jam> .long
<poolie> spiv, hi
<spiv> poolie: you'd like me to review Robert's fix for 165304?
<poolie> thanks, yes
<Peng> jam: One has to have access to httpd.conf to do that, right?
<jam> Peng: that is where I do it
<jam> poolie, spiv: I'm reviewing it right now
<jam> but you are welcome to review it too
<spiv> jam: ok, I'll do that.  I'm interested in this code anyway :)
<spiv> (plus I've already started ;)
<jam> spiv: i finished
<Peng> jam: I don't know of a way to un-ignore something from a .htaccess. Shoot. I should get a VPS.
<jam> my apache-fu is generally look at the docs, and try something, reboot and see if it works
<jam> repeat until desired effect is reached
<poolie> Peng, according to the docs there does not seem to be a way to reset it
<jam> I've always found it to be a bit of voodoo
<poolie> if it's set at a higher level
<jam> especially when a trailing '/' matters and when it doesn't
<jam> and when you are working in URL space
<jam> versus when you are in "disk" space
<jam> etc
<Peng> Heh.
<Peng> Lighttpd anyone? :P
<Peng> poolie: Mm-hmm.
<igc> poolie: ping
<igc> poolie: I'm just pushing the latest User Guide work to my public branch right now
<igc> I'll be submitting it to pqm in minutes
<poolie> ok
<poolie> you'll need to send a merge to the 1.0 branch too...
<Peng> IBM Hash Suffix Array Delta Compression: http://alphaworks.ibm.com/tech/hsadelta?open&S_TACT=105AGX59&S_CMP=GRsite-lnxw02a&ca=dgr-lnxw02aawhsadelta
<igc> poolie: public branch is http://people.ubuntu.com/~ianc/bzr/ianc-integration
<igc> submitted to pqm now
<igc> night all
<poolie> spiv, could you try fixing the insert_data_stream review comments?
<spiv> poolie: I'll give it a stab.
<poolie> thanks
<Necrogami> i wonder if IBM use's that in ther VCS
<Peng> IBM has a VCS?
<Odd_Bloke> Peng: http://www-306.ibm.com/software/awdtools/clearcase/
<Peng> Oh, ClearCase.
<Peng> Doesn't that suck?
<poolie> spiv, thanks for the bug 164626 patch
<ubotu> Launchpad bug 164626 in bzr "branching from hpss doesn't preserve repository format" [High,Fix committed] https://launchpad.net/bugs/164626
<poolie> can you please either also merge it to bzr.1.0, or tell me a url i can merge your fixed version from?
 * Peng wanders off.
<Peng> The default RAM size for the tool based on that algorithm is 200 MB. Not exactly great for a VCS.
<poolie> ?
<Peng> poolie: IBM's delta algorithm. http://alphaworks.ibm.com/tech/hsadelta?open&S_TACT=105AGX59&S_CMP=GRsite-lnxw02a&ca=dgr-lnxw02aawhsadelta
<spiv> poolie: ok, just pushing up now so I can submit to pqm.
<Peng> poolie: Did you miss anything when you disconnected? igc linked to http://people.ubuntu.com/~ianc/bzr/ianc-integration
 * Peng wanders off.
<poolie> oh thanks for that
<Necrogami> http://people.ubuntu.com/~ianc/bzr/ianc-integration/ <--- Empty Folder
<poolie> actually no, just a branch with no working tree
<Necrogami> heh
<spiv> Necrogami: look at http://people.ubuntu.com/~ianc/bzr/ianc-integration/.bzr ;)
<spiv> Necrogami: or try "bzr info http://people.ubuntu.com/~ianc/bzr/ianc-integration/"
<Necrogami> heh
<Necrogami> don't have bzr installed
<Necrogami> :-\
<Necrogami> if i ran my repo in bzr
<Necrogami> it'd kill a system
<poolie> are you the guy with the 50GB file?
<Necrogami> yep
<Necrogami> 44gb~ but close enough
<poolie> heh
<Necrogami> We started killing that thing today
<poolie> well, i guess in ~6 years we'll have that much mem on our laptops
<Necrogami> lol
<Necrogami> but yeah we started working on converting the XML to a SQLite database for temp storage and transfer
<Necrogami> Don't let me kill the channel heh
<poolie> spiv, https://edge.launchpad.net/bzr/+milestone/1.0alpha1
<poolie> spiv, oh, right, the other problem was bug 165290
<ubotu> Launchpad bug 165290 in bzr "packs do not check for missing compression parents" [Critical,In progress] https://launchpad.net/bugs/165290
<poolie> i think john didn't get to finish it today
<poolie> after i've looked over the list, i'll see how he got along in that branch
<spiv> Ok.
<poolie> BB seems to be down...
<vila> poolie: often around this hours
<poolie> oh, really
<poolie> i wonder why
<poolie> a db cron job maybe
<Necrogami> gah :-\ i really need to figure out how i'm going to lay out my db structure
<Necrogami> x = 100705 Miles y= 125 miles ~.~
<poolie> spiv, ok, i can see john seems to have most of a test and implementation for bug 165290
<ubotu> Launchpad bug 165290 in bzr "packs do not check for missing compression parents" [Critical,In progress] https://launchpad.net/bugs/165290
<poolie> but, the thing thta should trap it is not actually reached....
<spiv> poolie: ok, I think I've dealt with all the review comments.
<spiv> poolie: I'm just rerunning tests to make sure I didn't break anything.
<poolie> yay
<poolie> i'm making some progress on bug 165290
<ubotu> Launchpad bug 165290 in bzr "packs do not check for missing compression parents" [Critical,In progress] https://launchpad.net/bugs/165290
<spiv> poolie: I've sent a reply to John's review with a diff attached.
<spiv> poolie: there was one part I didn't feel confident that I could address with Robert, but I also don't think it's show-stopper for merge.  So I think with my patch it's ok to merge.
<spiv> s/with/without/
<spiv> (Sometimes it's too easy to accidentally say the opposite of what you meant!)
 * poolie reads
<poolie> s/thunk_flay/thunk_flag
<spiv> Oops.
<spiv> My firewall system is called flay, so it's an easy typo for me to make :)
<poolie> np
<poolie> after anything in particular?
<spiv> The naming scheme is characters from Gormenghast (Mary's idea).
<poolie> that looks like a reasonable response to the comments
<poolie> could you send it in please?
<spiv> Gladly.
<vila> poolie: did you get feedback for next bzr sprint yet ? Sry to bother you but some decision on the dates mainly will help me planning.
<spiv> And my previous branch merged to bzr.dev successfully too, excellent.
<vila> spiv: if you can provide me your squid config I may be able to reproduce your problem too
<poolie> vila, no more than what's on the list
<poolie> but it'll probably finish prior to march 13
<vila> poolie: ok, I'll take that bet then and plan accordingly, thks
<poolie> do those dates work for you?
<spiv> vila: it's a fairly standard config AIUI, but I'll send you my squid.conf by email.
<vila> spiv: thanks
<poolie> i'm going to slip 165290 and make an rc now
<vila> poolie: march 3th to march 10th was planned for reworking kitchen plumbing, but we can postpone that to April.
<poolie> with andrew's change
<spiv> poolie: I only landed my fix for 164626 to bzr.dev btw; so if you haven't already could you put it in the 1.0 branch?
<poolie> yes, i'm merging trunk
<spiv> Great, just double-checking :)
<Peng> An rc? Wasn't the last release like 2 days ago?
<Peng> And aren't packs still not in great shape?
<poolie> they're in good enough shape that getting some more exposure and testing will be useful
<poolie> gah
<poolie> again, failure because assertions are not run on pqm
<poolie> i don't think the balance there is quite right
<Peng> Well, at least things aren't entirely broken now, they're just sometimes really slow. But when there's active work being done on that situation, why not wait another few days?
<poolie> the short answer is, because mark asked us to make a test release today
<Peng> Heh.
<Peng> I didn't know he was so involved with bzr.
<Peng> Well pretend your e-mail's down and wait a few days. :P
<Odd_Bloke> Peng: It's only an RC.  You ever tried running an early kernel RC? :p
<dewd> I think the RC is welcome. it has been a tough job and it's a refreshing thing to do. it lays the work for a solid Xmas gift as well. :P
<ubotu> New bug: #173002 in bzr "Branching from hpss doesn't preserve non-repository formats" [Medium,New] https://launchpad.net/bugs/173002
<Peng> Usually there are only about 2 new NEWS entries between an rc and release. That makes me feel like they're release-quality, but you just want to be safe. Here, you're not going to lose data or anything, but it's intended for testing, not end users. I don't like that being called an rc.
<Peng> When was the last time there was an entirely new repo format?
<Peng> (Well, not 100% new. Packs are still knits inside.)
<poolie> peng, there will be a small delta between the last rc and the final
<Peng> Aren't there half a dozen commands that are seriously slower?
<Odd_Bloke> Might it be worth releasing the first one as an alpha (as it's marked on LP)?
<poolie> people thought that alpha seemed too low
<Peng> Beta?
<poolie> guys, at this point i just want to do the release
<Peng> Gamma? :D
<poolie> and we can assess what to do from there
 * spiv is done for the day
<poolie> me too
<poolie> i've uploaded a tarball
<poolie> am composing a mail
* poolie changed the topic of #bzr to: Bazaar Version Control System | http://bazaar-vcs.org/ | please test http://bazaar-vcs.org/releases/src/bzr-1.0rc1.tar.gz
<Peng> Hey, what? Why is my shared repo empty and everything is in the branch?
<Peng> Argh, and do to the server's process nazi, 'bzr branch' into another branch got killed.
<ubotu> New bug: #173007 in bzr "SIGQUIT debugging breaks http networking" [Undecided,New] https://launchpad.net/bugs/173007
<ubotu> New bug: #173010 in bzr "initial branch over http: can show no ui activity for a very long time" [Undecided,New] https://launchpad.net/bugs/173010
<mwhudson> wow, bzr.dev get http://bazaar-vcs.org/bzr/bzr.dev is a "bit" faster than bzr.dev get http://bazaar-vcs.org/bzr/bzr.dev.knits
<dato> oh, I guess I'll package the rc for Debian.
<dato> siretart: ^
<dato> siretart: also, I guess it'd be appropriate for a NEWS.Debian entry warning that the default format has changed, and that created branches will be not operable with bzr < 0.92 ?
<dato> great; again we still have paramiko 1.6 in Debian.
<siretart> dato: that would indeed be appropriate.
<siretart> \o/ bzr has migrated to testing :)
<dato> ok.
<dato> I think I'll also notify the paramiko maintainer for my intenton to NMU.
<Peng> Mildly interesting: sizes of packs of 500 top-level revisions of bzr.dev (as in 1-500, 501-1000, etc.): http://paste.pocoo.org/show/13197/
<Peng> (I'm not sure about the first 40 KB one.)
<abentley> vila, poolie: I have no idea why BB would go down around 2:00 am my time.
<vila> abentley: do you want a report each time I encounter a firefox timeout so that you can check the logs ?
<vila> not a big concern for me but if that can help you..
<Peng> Yikes, UnicodeDecodeError traceback in uncommit.
<abentley> Well, at this point, BB is slow on the first request generally.
<abentley> I think it has to swap back into memory or something.
<abentley> Mine is a pretty hurtin' virtual server.
<abentley> If it actually times out rather than being slow, I guess I'd like to hear about that.
<spiv> abentley: I was seeing various database errors (database is locked, and some sort of OperationError as well IIRC) rather than timeouts.
<spiv> abentley: part of the problem is that it's so immensely useful that even short glitches are very noticeable :)
 * spiv -> zzz
<vila> abentley: indeed, I just connected it was very slow, close to some timeout somewhere, that may be that, I'll try to watch that more closely, I'm used to not use it early in the morning though ;-)
<blauwal> Hi, my name is Jens-Heiner Rechtien and I'm the SCM guy for OpenOffice.org. We are currently seriously evaluating a new SCM system for replacing our old CVS repository. We've got 7 years of CVS history, some 11 GBytes of it code related, so yes, it's huge. I'm currently trying to setup a bzr+ssh server, can someone point me to some infos about it? I've read the spec on the Wiki page.
<Peng> bzr+ssh is trivial. Just install bzr.
<Peng> Okay, not helpful, since that's not just what you meant. Sorry.
<blauwal> Peng: Well, Python segfaulted for me
<Peng> Ouch. Doing what?
<blauwal> Peng: bzr -serve segfaulted when I accessed the repository
<blauwal> Peng: But I'll figure it out if you say me that bzr -serve is supposed to ve working
<blauwal> Peng: I found that the docu is not very clear about the status
<jelmer> blauwal: I think you mean "bzr serve"?
<blauwal> Another problem I have is the import. Our CVS repsitory is not *that* clean
<blauwal> yes
<vila> blauwal: look at cvs-import and summon jam here (fullermd may be helpful too)
<jelmer> jam: alive?
<blauwal> Another problem I have is the import. Our CVS repsitory is not *that* clean, but I managed a full history import in SVN. Now I thought it might be asier to import from subversion and yes it works, but svnbzr is so slow that after week it read only 15000 of 500000 revisions
<jelmer> blauwal: jam has done big imports before, in particular of the mozilla cvs tree
<jelmer> blauwal: svn2bzr of bzr-svn ?
<blauwal> svn2bzr
<blauwal> I've yet to try out bzr-svn
<blauwal> because it requires subversion 1.5 bindings
<jelmer> blauwal: is your tree available publicly?
<blauwal> Yes
<vila> blauwal: bzr-svn is reputedly superior to svn2bzr and there you should summon jelmer (which may too shy to say that ;-)
<jelmer> I've never tried bzr-svn on anything > 100000 revisions, so I'd be happy to try it on your repository and fix any scalability issues
<jelmer> blauwal: is this 500k revisions in a single branch or across multiple branches?
<blauwal> jelmer: Multiple branches
<blauwal> We've got some 500 libe branches and 5000 dead ones.
<blauwal> The dead ones were already excluded
<blauwal> The subversion repository is about 55GBytes huge
<blauwal> s/libe/life/
<jelmer> whoa
<blauwal> I've written a page with detail, I'm looking it up, mom
<blauwal> http://wiki.services.openoffice.org/wiki/SCM_Migration
<blauwal> jelmer: svnsyncing via http is reported to be slow :)
<blauwal> jelmer: I've got an 11 GBytes bzipped dump which I yould provide if you want to try you tool on it
<jelmer> blauwal: I'll try bzr-svn on an individual branch first
<jelmer> blauwal: no need to import the whole repository
<blauwal> jelmer: great. I would suppose the .../svn/tags/OpenOffice_2_3_0 tagged version or the trunk version, they represent the current size of OpenOffice.org
<jelmer> blauwal: thanks, I'll give that a try
<blauwal> jelmer: I would be very interested how it works. You can reach me via hr @ openoffice.org
<Peng> This isn't related to Bazaar, but is there some sort of etiquette when registering a branch of someone else's project on Launchpad? As long as I file bugs too, is it okay?
<Peng> Jeepers, 1400 testbzrxxx.log files in /tmp.
<jelmer> Peng: launchpad keeps track of both author and registrant
<jelmer> from what I've seen, it's ok to register any branch
<Peng> I know how Launchpad works. I was just wondering if there was general etiquette.
<jam> was I summoned this morning?
<jelmer> jam: yep, see ^^
<jam> blauwal: I think we've spoken a bit before (actually on the phone)
<jam> the thing I was waiting on was some time to hack on cvsps-import so that it could do merge commits
<blauwal> jam: Yes. I'm doing the OOo SCM stuff
<jam> since OOo has special tags for that
<jam> (recording that a branch was merged)
<jam> CVS natively doesn't support any of that
<blauwal> jam: Yes, we are doing all sorts of nasty stuff
<jam> unfortunately, this is getting close to bzr-1.0 release, so I've been using all my cycles for that
<jam> I would be happy to give some pointers, etc if you want
<blauwal> jam: moving tags, even branches, partial tags and branches etc
<blauwal> jam: my most urgent problem is to create an import with history so we can start compare apples with apples
<jam> jelmer: would you have any time to try an SVN conversion?
<jam> It probably won't have the merges I wanted to add
<jam> to cvsps-import
<jam> but it would at least give linear histories
<blauwal> jam: All my efforts have failed up to now :-(, cvsps bombs out, and svn2bzr (on an already migrated subversion repository is way to slow=
<jam> blauwal: that is after the cleanup we discussed, right?
<blauwal> jam: yes
<jam> (your script which renames the directories, and deletes old stuff)
<blauwal> yes
<jam> blauwal: have you had any chance to try the cvsps patch from kenny
<jam> (i think it was kenny)
<blauwal> jam: I've received the patch but did not try it out. Next thing I'll do.
<blauwal> jam: kendy (Jan)
<jam> ah, right
<jelmer> jam: I'll have a look at trying bzr-svn on the repository and fixing any performance issues in bzr-svn I come across
<blauwal> jam: One other thing I noted was that doing a full local branch on a simple minded flat imported OpenOffice_2_3_0 repository (some 70000 files) is quit slow. Maybe I'm doing something wrong
<jam> blauwal: 2 things
<jam> a) You should be using a shared repository
<blauwal> jam: I did
<jam> b) you might try packs
<jam> however, if it is time spent in build_tree
<jam> blauwal: ok
<blauwal> b) packs? Ok I don't know what packs are ...
<jam> (b) bzr upgrade --pack-0.92
<Peng> That could take a while.
<jam> It is a different repository format
<Peng> Heh heh, run reconcile too!
<jam> Peng: on anything created post bzr 0.92 you don't need reconcile
<blauwal> jam: I'll try it.
<jam> it was pre 0.92 that had small issues about the file graph.s
<jam> blauwal: what bzr are you using?
<jam> (bzr --version)
<jam> 1.0rc1 is just released
<jam> which has some pretty big improvements for packs
<jam> (sometimes it is hard to remember where things were at a couple months ago, since we have been actively releasing ~ every month)
<blauwal> jam: I used 0.92. No problem upgrading to 1.0rc1
<blauwal> jam: OK, just that I do the things right. Let's say I want to reimport OOo 2.3.0 without history. I fo
<blauwal> I do
<blauwal> 1) bzr init-repos --no-trees bzr
<blauwal> 2) bzr init bzr/trunk
<jam> (i think it is 'bzr init-repo' but yes)
<jam> (and if you want to try packs from the start you can do "bzr init-repo --pack-0.92")
<blauwal> 3) bzr checkout --lightweight bzr/trunk trunk.dev
<blauwal> ah ok
<blauwal> 4) add and commit all files
<jam> but yes, that sounds correct for starting a new tree with 0 history.
<blauwal> then, to test the time to do a local branch
<blauwal> time bzr branch bzr/trunk my.test.branch
<blauwal> jam: Yes. Branching took 48min even a single history revision
<blauwal> jam: but I'll try out packs
<jam> blauwal: what did you do for "branching" ?
<jam> what was the command?
<jam> (bzr branch bzr/trunk bzr/olderbranch) ?
<blauwal> jam: no bzr branch bzr/trunk mybranch
<blauwal> I also tried out checkout and checkout --lightweight, there were no big differences (no wonder since there isn't really a history in there)
<jam> blauwal: that is branching *out* of the shared repository
<jam> which is causing it to copy all of the history
<jam> if you did
<jam> bzr branch bzr/trunk bzr/mybranch
<jam> it would have been a lot faster
<jam> packs *do* help on the branching to a new repository
<jam> as they have fewer files to touch
<blauwal> jam: Yes. I know. The equivalent of "git clone"
<jam> blauwal: we provide shared repositories as a way to avoid the copying you need with git clone
<blauwal> jam: Yes, but I was trying to simulate here a developer cloning from a central server
<jam> ko
<jam> ok
<blauwal> jam: not just creating a new branch inside the shared respository
<jam> sure
<dato> I'm writing a NEWS entry for this upload of bzr to debian; I'll give a paste line for comments, but I have one question:
<blauwal> I did this "git clone" stuff on exact the same amount of data on the same machine and it took 4min instead of 48min
<dato> in a shared repository with branches, one has to run `bzr reconcile; bzr upgrade` in the top level directory (the repository), in the branches, or in both?
<blauwal> but, I'll redo it again with packs
<jam> dato: just the top level, iirc
<dato> that's what I thought
<dato> but I read vila say otherwise in the mailing list, I think
<dato> ah, maybe not
<dato>     robert> To upgrade, please reconcile your repository (``bzr
<dato>     robert> reconcile``),
<dato> I'm pretty sure many shared repositories users will update their
<dato> branches only. I think we should be more explicit:
<dato>    reconcile your branches and/or your shared repositories
<jam> hmm... I would have thought reconciling a branch in a repo would reconcile the shared repo.
<vila> jam: it doesn't last time I did it (this week IIRC)
<dato> so, branches inside a shared repo need a reconcile+upgrade or not?
<Peng> Branches do need an upgrade.
<Peng> All it upgrades is the minor metadata, but it's still something. dirstate didn't have branch.conf.
<hsn_> who converted bzr.dev repo to packs? i cant merge
<dato> Peng: and? can't pack repositories work with branch5 format?
<Peng> dato: Well, they don't *need* it. But if you're already upgrading the repo, why not?
<jam> Peng: they don't *need* an upgrade, but I would recommend it
<jam> Branch5 works fine in a packs repository
<jam> Branch6 just is a bit more trim
<jam> (doesn't store the full mainline on disk)
<dato> ok, thanks.
<dato> comments welcome: http://dpaste.com/26320/
<jam> hsn_: use http://bazaar-vcs.org/bzr/bzr.dev.knits
<jam> hsn_: it should by sync'd from the other repo every hour
<jam> vila: is it that the 'reconcile' doesn't effect the repo, or the 'bzr upgrade' ?
<jam> I would think reconcile would always do the repo, but upgrade may not upgrade something not in the current dir
<jam> but I realize that may or may not always be the case.
<Peng> Yeah, upgrade won't upgrade branches.
<vila> jam: I don't remember ;-)
<jam> Peng: upgrade at the repository level doesn't recurse and upgrade the branches
<jam> I was wondering about the reverse
<jam> does upgrade in a branch
<jam> upgrade the repository
<jam> dato: your text sounds ok, but I'm guessing that you only need to run reconcile on the repository
<jam> and upgrading the repository will give you packs
<jam> upgrading the branches will give a slightly better branch format
<dato> jam: reconcile on the repository, yes; but isn't it also needed for branches which are outside a shared repo (since they contain a repository)?
<jam> dato: outside a shared repository, yes
<jam> I don't know that your text made that clear
<jam> and I wouldn't really want to force people to run "bzr reconcile" 200 times for each branch inside a shared repo.
<dato> oh, you're right on that
<dato> but I don't want to make the explanation too complex
<Peng> jam: Oh.
<dato> jam: hmmm. I have a knit shared repo with branch6 format branches. if I run `upgrade` in the branches, it complains:
<dato> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
<dato> is that expected?
<jam> dato: yeah, because it is upgrading the branch, but has nothing to upgrade
<dato> ok
<jam> It really shouldn't be telling you the meta-dir is the latest format
<jam> I'd be happy with a bug report on that
<dato> what should it say?
<jam> it should tell you that the bzrdir, and branch are the latest format
<jam> anything it is trying to upgrade
<jam> not just the first one
<jam> (that way it is obvious whether it is or isn't trying to upgrade the repository)
<dato> ok, I'll quote this in the report
<luks> hmm, pack repo reloads all indexes every time I lock/unlock it
<ubotu> New bug: #173061 in bzr "possibly confusing message when upgrading an already-upgraded	branch" [Undecided,New] https://launchpad.net/bugs/173061
<dato> jam: http://dpaste.com/26325/
<dato> bbiab
<jam>  but  only once in the toplevel directory for shared repositories.
<jam> (s/the case of//)
<jam> dato: otherwise I like it
<jam> luks: yes
<jam> luks: so do knits
<jam> luks: that is what locks are for
<luks> yep, but knits don't need locking
<jam> telling us that you are okay seeing a snapshot
<luks> that's what I didn't realize
<jam> luks: they drop the cache as well
<jam> or at least, they were supposed to
<jam> a lock tells us that we don't have to check for changes
<luks> I mean, knits will always have older revisions at the same place
<luks> so if I don't lock it, I can always use an older version
<jam> I'm pretty sure internal to the code we still dropped the index caches
<luks> I guess I'll need to lock the repo globally in qlog
<jam> so that we would see new items
<jam> luks: locking it globally will see some pretty big advantages even with knits
<luks> well, not really in a GUI application
<luks> because I already have revision data loaded
<luks> and those are in some state
<luks> with knits I could always get more info even it new data were added in the meantime
<luks> maybe it could check pack-names and if it's not modified, then keep the old indexes
<jelmer> dato: Could you perhaps sponsor another upload of bzr-svn, 0.4.4-2?
<jelmer> dato: -1 doesn't install the FAQ and there are some other minor changes as well
<blauwal> jam: thanks for the tip with "pack-0.92", it mades all the difference. "Outside" branching of the trivial OOo repository is down to 5min from formerly 48 minutes
<jam> blauwal: that is why we implemented them :)
<jam> the old format just doesn't scale well
<blauwal> :)
<jam> It handles a lot of things nicely
<jam> but we saw ways to do it better
<dato> jam: thanks
<dato> jelmer: ok. I guess that upload would not be compatible with 1.0~rc1, by any chance? :)
<blauwal> jam: are there any drawbacks with the new format?
<jelmer> dato: not yet, no
<jam> blauwal: all current drawbacks are being addressed and most of them should be fixed in the final 1.0 release
<jam> oh, except 'bzr annotate' being slower
<jam> bzr commit should be faster
<dato> jelmer: ok. is all the -2 stuff in place? (IOW can I upload already?)
<jam> but the old commit was annotating at commit time, rather than waiting until you do 'bzr annotate'
<jam> post 1.0 we will probably have a flag that lets projects choose which they want to do
<blauwal> jam: I take faster commits over annotate everytime :)
<jelmer> dato: yep
<jam> blauwal: well, there is annotated merging which is also effected
<jam> but that isn't the default merge algorithm anyway
<jam> (it helps when your ancestry gets really messy)
<jelmer> dato: do you need a binary package uploaded somewhere?
<siretart> jelmer: aren't you a DM these days? ;)
<dato> siretart: but he needs one last sponsored upload to set DM-Upload-Allowed :)
<jelmer> siretart: yes, but bzr-svn doesn't have XS-DM-Upload-Allowed: set yet
<blauwal> jam: we do lots of mass merges (CVS style), would they also be affected?
<siretart> which is going to happen with this upload, I believe, right?
<dato> yes
<jelmer> siretart: yep, exactly
<Peng> blauwal: The "current drawbacks" are mostly/almost all that some commands (log (at least on a file), uncommit, pull on a bundle, others) are several seconds slower, but they're not unusable, so when branching is that dramatically improved, it's definitely worth the upgrade.
<jam> blauwal: mass-merges are generally not ancestry provoking
<jam> it is when you have 4 branches that merge back and forth randomly betweent hem
<jam> between them
<jam> well, among them
<jam> Peng: and most of that is addressable
<jam> Peng: try with my buffer_all patch
<jam> it helps a lot of those commands
<jam> Peng: and it should be in 1.0rc1
<jam> I'm currently trying to plug through the root causes of them being slow
<jam> which will mean they end up faster than the knit form
<jam> (the problem is generally that they use all of ancestry when they don't need to, and packs are a bit slower at all-ancestry stuff, but much faster at partial ancestry stuff)
<Peng> jam: I know.
<Peng> jam: I didn't mean to negate that you said they're being addressed; I was just expanding on what you said.
<jam> Peng: I didn't know if you knew it would be in 1.0rc1, and I'm sure blauwal didn't know :)
<jam> (And I was expanding on your expansion :)
<blauwal> jam: ah I see. Ok our development model is rather simple. Developers branch from a milestone (trunk), work on the branch, after a while thy merge new stuff from newer milestones (trunk) into their branch. Later, the branch will be integrated back into the trunk. Problem is that these merges can affect thousands of files
<jam> blauwal: that shouldn't be a problem for any of our merge code
<Peng> jam: I didn't know they would all be in 1.0. That relieves me greatly.
<blauwal> jam: I thought so, even CVS can do it with some help (manual mergetracking)
<Peng> blauwal: A couple things were broken in 0.92 (bzr cat, bzr pushing over bzr+ssh) with packs, but they have since been fixed.
<blauwal> Peng: great
<Peng> blauwal: This was all a long way of saying that there were some rough edges with packs in 0.92, but they're being worked on or have already been fixed, so don't get discouraged. Also, it would be great if you reported any new issues you run across.
<blauwal> Peng: I'll do.
 * dato giggles at `dh_perl -pbzr`; yay cdbs.
<jam> vila: ping
<vila> jam: Peng
<vila> silly Xchat
<vila> jam:  pong
<jam> vila: just reviewing your patch
<jam> I thought I would tease you directly about writing "htpp"
<jam> you always used to write "hhtp"
<jam> (my review should be on the list)
 * vila installs Ktouch and pratice instead of hacking bzr
 * vila re-type practice
<jam> I was trying to figure out whether it was a sign of improvement
<jam> that at least your typos are evolving
<jam> anyway bb:tweak
<jam> you didn't give yourself enough credit in NEWS
<vila> about what ?
<jam> vila: you only talk about -Dhttp and ShortReadv
<jam> but you also fixed the code when issuing too many range requests
<jam> (well, to at least only issue 200 at a time maximum)
<vila> Ha yes, as I said in my email ?
<vila> regarding the typos, the progress is making them in the comments instead of the code ;)
<fullermd> blauwal: As far as the CVS conversion, there was a cvs2svn guy in here a month or two ago soliciting for somebody to write a bzr output backend for it, who said it probably wouldn't be too much work.
<fullermd> That may be an avenue to explore.
<blauwal> fullermd: yes. Actually cvs2svn does a lot of the heavy lifting - make sense out of not so consistent CVS archives
<blauwal> fullermd: actually, the last version of cvs2svn that worked for me is 1.5.1. They did something to 2.0.1 which makes it as slow as molasses, I need to talk with him anyway :)
<fullermd> Yeah.  So with a little work on a backend to write into bzr, we get to stea^Wborrow all that work  ;)
<blauwal> fullermd: yeah. I will look into it, but, unfortuantely I'm more of a perl than python expert and don't know anything about bzr to boot (though way too much about CVS) so I don't know if anything will come out of it.
<fullermd> Oh, I wasn't suggesting locking you in the basement until you came out with it done   ;)
<jam> blauwal: I think fullermd was suggesting locking *me* in a basement.
<blauwal> jam: :)
<fullermd> Just that it's alleged to be a fairly simple thing (couple days work for someone familiar), so it may get done by someone else in the coming months.
<fullermd> jam: Of course not.  That would be unhumane.
<fullermd> That's what attics are for...
<jam> fortunately, my basement has escape windows
<jam> hmm... my attic doesn't
<Peng> jam: Fall through the ceiling.
<jam> messy, and still an 8-foot fall, but I suppose better than trying to break through a wall and falling 30 ft
<Peng> You could try to kick a hole in the ceiling and drop down.
<fullermd> No, no, you gotta crawl through the duct work.  It's more dramatic that way.
<fullermd> And you get to hum the M:I theme while you're doing it.  What more could a man want?
<vila> blauwal: still being more a perl expert than a python myself, I'd say just try it, you are in for some good surprises
<fullermd> Pshaw.  Python doesn't even have $>, how good can it be?
<blauwal> vila: Yes, python has come a long way. I've only dabbled with it so far.
<jam> fullermd: don't you mean: $Pshaw. @Python $doesn't $even $have $>, @how $good @can ~/it/be
<blauwal> but even after working with perl for > 10 years, perl is still good for some surprises, too ...
<vila> TIMTOWTDI often becomes this is the way to do it, but getting rid of $@% and replacing '->{}' with '.'  is quite a relief
<fullermd> %{@not[$much]}, obviously.
<jam> vila: you mean that you can do it 10 different ways, but only 1 is good?
<vila> jam: no, I mean python promote a good way where perl leave decide which one you prefer
<blauwal> vila: I agrre TIMOWTDI is no really a strength but a weakness of perl
<blauwal> s/agrre/agree/
<jam> s/no/not/
<fullermd> Ack!  vila's spelling is already infecting you!
<jam> :)
<jam> It is all about the UDP connection from brain to hands
 * vila cries seeing fullermd spoling its own joke while trying to fix his typos...
<jam> there really should be some checksums in there
<vila> 44
<jam> not that I'd want to pay the speed of an ACK round trip for each character
<fullermd> My problem, OTOH, isn't data corruption; it's mixing multiplexed streams.  Hands multitask poorly   :|
<jam> fullermd: I beg to differ. *A* hand multitasks poorly. *hands* can do a decent job :)
<vila> blauwal: I don't think it's a weakness, it makes reading others code harder since nobody agree on how to do things, but it also gives more freedom
<fullermd> Yeah, you'd THINK that, until the first time you accidentally chew your stomach and pat your gum while walking...
<blauwal> vila: I admit I love to code perl because of this freedom, but I usually don't love what other guys make out of my carefully crafted perl code :)
<vila> blauwal: hehe
<vila> python execptions is a good example, you *can* throw and catch exceptions in perl (die, if ($@)) but since there is no agreement on how to do that, there are rarely used
<jam> $@ ????
<jam> ouch
<jam> I guess it makes your perl start to look more like math notation
<jam> since everything is in symbols
<blauwal> vila: yes. Actually I use die; if ($@) all the time, but no here seems to understand it
<vila> jam: see, you talk perl ! $@ contains the reason of your 'ouch' ;-)
<blauwal> jam: It's actually a very nice regular syntax
<jam> blauwal: true, but it takes a while to learn the difference between $_ $> $@ @foo $foo $<
<jam> and implicit operators
<jam> ~/foo/
<jam> chomp
<fullermd> I do tend to use the names rather than the symbols for all but the handful that I use most often.
<vila> use English is your friend
<jam> I could see that once you get used to them, maybe you can parse more symbols per second than
<jam> you could english words
<jam> but until then, it is completely opaque
<blauwal> jam: yes. Now one can code in perl very productive but I bet this also holds for python and maybe ruby, too
<jam> blauwal: I think python has less implicit stuff in it.
<fullermd> Well, in ruby, you don't have to be productive; running the code is so slow it doesn't matter if writing was fast  ;>
<jam> So you have to learn less of the language to understand what someone else wrote
<jam> (certainly one of the main design comments is :Explicit is better than implicit.)
<blauwal> jam: Actually the biggest obstacle in perl is to learn how to create complex data strcutures.
<jam> I found perl's argument handling to be.... iffy
<blauwal> jam: Everything else (objects etc) comes easy later
<jam> That may have gotten better
<jam> since I used it
<fullermd> Yeah.  That's the big thing that kills me in perl, since I don't use it enough anymore to remember   :|
<fullermd> Function args are a close #2.
<fullermd> Supposely, though, both are much better in perl 6, so that should be a nice switch to make in, like, 2025 or so.
<jam> python's ability to name the arguments at call time is really nice
<jam> foo(bar=X, baz=Y)
<vila> blauwal: fully agree, but once you understand than perl references are C pointers and fight perl tendency to make sense of every bogus expression, you define *far* less types than in python
<jam> often makes it very clear at the call site what you are trying to do
<jam> vila: well, and perl is happy to auto-cast your variables
<jam> '1' + '2' == 3
<vila> jam: you can name perl arguments, just a hash as an arg
<fullermd> Oh, that's not the big problem with function args; it's that they're a list, not args, so trying to pass, say, two @arrays requires some hoop-jumping (normally they'll just turn into one large @)
<blauwal> vila: yes.
<vila> jam: I'm been bitten more often by python '%d' % '12' -> '12' is not an int than by perl
<jam> vila: but then can you pass them as positions?
<blauwal> fullermd: Thats what references are for
<jam> vila: always use '%s'
<jam> vila: it works for *all* types
<jam> But I'm guessing you are doing that because you are *coming from* perl
 * fullermd is reminded of Jim Fulton's monkeys/snake quote.
<vila> jam: yup, and I realized that '%s' was the way in my problematic cases
<blauwal> My biggest complain about perl is that classes are more or less bolted on and look strange
<vila> coming from perl one the most annoying one is '' is the same as ""
<vila> funny one ;-)
<fullermd> blauwal: Well, yeah, but that's the hoop jumping.  Kinda annoying.
<vila> fullermd: always use references and you're done
<blauwal> I've written a CVS client library in perl, which is nicely object oriented and looks strange for most
<vila> @$array is your friend ;-)
<jam> vila: well, I imagine having perl inline expand is nice when you want it
<jam> "$foo" versus "%(foo)s" % vars()
<fullermd> Yes, but you have to use the \ everywhere you call the function then.
<fullermd> Luckily, I don't hold with OOP, so any weakness perl has there bothers me not at all   ;)
<vila> fullermd: no you *declare* them as references $array = []
<vila> instead of @array = ()
<fullermd> Ugh.  Trading one problem for another...
<fullermd> I'll just keep on working in PHP all day, where it works rationally.
<jam> vila: you point out something, though @$array versus $@ exception object
<vila> fullermd: TIMTOWTDI ;-)
<vila> jam: no $@ is a special variable ;-) @$ dereferences an array reference
<blauwal> fullermd: It's quite funny, but all these $,@,% come quite easily after you get used to it. Well, and you have understood the difference between evaluating them in scalar or list context
<vila> %$ dereference a hash
<jam> vila: sure, but $@ means something *very* different from @$
<Peng> vila: That line should be quoted.
<jam> and I don't think the @ symbol in "$@" has any similar meaning to the "@" in @$
<jam> sort of like if I named my variables
<Peng> FWIW, http://www.selenic.com/mercurial/wiki/index.cgi/BzrVsHg
<jam> foo, fOo, Foo
<jam> foo = 10
<jam> Foo = object()
<vila> jam: $@ (Mnemonic: Where was the syntax error "at"?)
<jam> def fOo()
<fullermd> Yah, but I don't do perl nearly enough to remember all the rules for different contexts and passing and making references in a deep array for easier code writing and yada yada.  So it's always a fight.
<jam> if fOo(foo) == Foo:
<jam>   Foo.foobar()
<jam> Would be hard to read
<fullermd> I understand the intent behind "things that _are_ different should _look_ different", but my life is easier when you just reference variables all the same.
<vila> fullermd: yup, that's the blocking point, I had problems overcoming that and I've seen many block there.
<jam> die if($@ == @$bar)
<fullermd> Whether it's a $scalar or a $numeric[$array] or an $associative['array'].
<vila> jam: true, I don't like the separate namespaces for scalars, arrays, hash and so on
<fullermd> Or $however['deep'][$one][$may]['go'].  Lot simpler.
<fullermd> And sometimes in perl you have to $do{'this'}, except for when you have to $do->{'this'}, and the latter often works even when not necessary, except...
<fullermd> There _is_ rhyme and reason behind it, but if you don't do it every day, it seeps out of your head _real_ quick and leaves you crying.
<vila> fullermd: my main trick is: $scalar $carS $handler_OF (caps for emphasis) works very well for perl, not for python
<vila> fullermd: that's why always using references simplifies you only use $do->{this} (stop the silly quote, keys don't need them except if they contain spaces or such) the same trick in  python is to do dict(car='2cv', house='small') instead of {'car': '2cv', 'house': 'small'}
<vila> but $->{} for perl when '.' for python.... far less typos ;-)
<fullermd> Oh, I always use the quotes.  It looks better to me.  Bare words are keywords, not data strings  ;)
<vila> fullermd: argh, {'car': '2cv', 'house': 'small'} killed me until poolie showed me the dict() trick
<jelmer> dato: anything else I should do for the bzr-svn upload?
<dato> jelmer: no, I'll do it later today
<jelmer> dato: cool, thanks :-)
<blauwal> I've got to go for today, but I certainly will come back to this channel and pester^H^H^H^H^H ask you for more infos regarding bazaar and Openoffice. Thanks!
<dato> jelmer: do you know if bzr1.0 has been branched off, or bzr.dev is still only open for 1.0 stuff? I thought the latter was the case, but I saw bialix talking about opening a new entry in NEWS.
<vila> blauwal: thanks for OpenOffice ;-)
<fullermd> dato: I'm pretty sure I've seen an extant 1.0 branch discussed...
<Peng> Another Launchpad behavior question: Is it worth registering a branch for like a small thing that probably won't be changed and is fine as a bundle?
<dato> vila: is the "dict trick" dict(a='b', c='d'), or something else?
<Peng> Worth mentioning is that due to my locations.conf setup, bundles include a source_branch location, so I do create a public branch location anyway.
<Peng> dato: That's it.
<jam> fullermd, dato: 1.0rc1 has been released
<jam> but it has been done so with an expectation that we will likely see 1.0rc2
<jam> Peng: depends on your definition of "worth it"
<jam> I do it all the time
<jam>  (I think having branches associated with bugs is a nice thing)
 * Peng giggles and runs off to Launchpad.
<dato> jam: yes (I already uploaded it to debian ;); my question was whether development of 1.0rc2 would take place in bzr.dev, or in a separate branch.
<jam> especially if someone ever wants to backport a fix, etc.
<jam> dato: you would have to ask poolie
<jam> I'm guessing bzr.dev
<dato> jam: that's what I thought; I was asking because bialix was talking about opening NEWS a new.
<Peng> I mostly feel like I'm imposing, jumping into a fairly inactive project with 3 or 4 bug reports and half a dozen branches.
<jam> Peng: well, that is what distributed control is all about
<jam> it lets someone take over the inactive stuff
<jam> in a friendlier way than a fork
<jam> And LP helps too, since it gives you a place to announce your stuff
<jam> near where people. might be accessing the original stuff
<jam> (without LP a branch on your on host would probably never be seen)
<jam> Peng: what projecT?
<jam> project
<Peng> And now that I can be seen, I'm really wanting to set up HTTPS. Hmph.
<Peng> jam: pytz.
<jam> Peng: well it seems like it may not be officially hosted on LP
<jam> just that stub uses LP + bzr to track upstream
<jam> hmm, take that back
<jam> as stub is the developer
<dato> haha
<jam> dato: We should start a new section at the top
<jam> even if it is going to be 1.0rc2
<jam> if you look at older NEWS records
<jam> you can see that we break down the changes by each public release
<jam> sorry I didn't think about it earlier.
<dato> bah, you're right :)
<chiefinnovator> Why is bazaar not working?  The first command on the tutortial breaks.  $ bzr whoami "John Doe <john.doe@gmail.com>"
<luks> how does it break?
<chiefinnovator> I get: bzr: ERROR: extra argument to command whoami: John Doe <john.doe@gmail.com>
<luks> um, what version of bzr?
<chiefinnovator> 0.8.2
<fullermd> Whoah.
<chiefinnovator> It sucks being on Dapper.  Everything is old
<jam> chiefinnovator: http://bazaar-vcs.org/releases/debs/dapper
<luks> wget http://bazaar-vcs.org/releases/src/bzr-0.92.tar.gz && tar -zxvf bzr-0.92.tar.gz && cd bzr-0.92 && python setup.py install :)
<chiefinnovator> I just did aptitude install bzr
<luks> oh, there are debs for dapper...
<jam> chiefinnovator: http://bazaar-vcs.org/DistroDownloads
<jam> chiefinnovator: we have a repository for dapper versions
<jam> I don't think it has the latest latest
<chiefinnovator> ah I see
<jam> but it has stuff a lot newer than 0.8
<chiefinnovator> So the default did .8 though
<chiefinnovator> You couldn't identify yourself in .8 :-)
<luks> you can edit ~/.bazaar/bazaar.conf
<jam> chiefinnovator: well if you want to use 0.8, you can go to the 0.8 tutorial
<jam> http://doc.bazaar-vcs.org/bzr-0.8/tutorial.html
<fullermd> Did email even exist back when 0.8 was current?   ;>
<chiefinnovator> I'll go ahead and get the new one
<chiefinnovator> So this is better than Mercurial right?  I was trying to decide all morning
<jam> we think so :)
<fullermd> Obviously, this is the place to come for an unbiased answer to that question...
<chiefinnovator> isn't
<jam> chiefinnovator: http://bazaar-vcs.org/BzrVsHg
<chiefinnovator> Biased is ok, just want to reinforce my decision :-)
<chiefinnovator> Yeah, I read that one
<fullermd> Of course, I've long subscribed to the belief that it doesn't matter if I'm biased, as long as I'm right   ;)
<chiefinnovator> sounds good
<jam> fullermd: a completely true statement, it is just that the former influences the perception of the latter
<chiefinnovator> well I go ahead and update then, thanks for the help
<Peng> chiefinnovator: The problem is, they're both better!
<chiefinnovator> true, coming from SVN
<fullermd> It would do us well to explain once why hg's hardlinking is not a capable alternative to shared repos, instead of having to fumble it up every time it comes up.
<Peng> Hg's hardlinking also has its benefits, mainly that you can clone to anywhere on the filesystem, not just inside the shared repo.
<fullermd> Well as long as you're using a fs that supports hardlinks.  And cloning on one fs (though I don't know if shared repos can span fsen; branches can't)
<jam> Peng: though packs will also support hardlinking without having to ever break the links
<jam> fullermd: shared repos can span fs
<jam> you just have to have a containing fs
<jam> so if you put one it /
<jam> all your branches would share across all filesystems
<jam> we do expect that .bzr/* is on the same filesystem as all working files
<jam> so that we can do atomic "os.rename()"
<fullermd> (mind you, I have a very low opinion of any fs that _doesn't_ support hardlinks.  But they are out there.)
<jam> fullermd: and there are those like HPFS+ that *do* but very poorly
<jam> (as in, performance is better without hardlinking)
<fullermd> Mm.  Packs may support hardlinking without strictly speaking having to break, but they still have all the same side effects as breaking.
<jam> fullermd: the problem with knits is that you have to probe and see if you need to break
<jam> before writing to them
<jam> (same thing for revlog)
<jam> which means it isn't safe to do over sftp
<jam> etc
<jam> but it *is* safe to use packs in a similar fashion
<jam> over sftp when the remote one is hardlinkde
<jam> hardlinked
<fullermd> Safety isn't my argument against it.  It's that it's not shared; your branches only share storage as long as you don't touch either one.
<fullermd> Soon's you start commiting in one or the other, you progressively work back toward 2*space.
<jam> fullermd: completely true
<jam> and packs have the side effect that changing 1 file 10,000 times
<jam> will get you back to 2x space
<jam> because it breaks the link for "unrelated" files
<fullermd> So saying "We don't need shared repos, hardlinks do just as well" is false, even if it's done completely safely.
<jam> (though if one file is changing 10,000 times, you probably don't have that much in common anyway)
<jam> fullermd: I agree (I certainly never made that assertion, I like shared repos) but that doesn't mean it is incompatible with also doing hardlinks
<jam> probably our bigger impedance to hardlinking packs
<fullermd> Oh, I'm arguing against the statement I've heard from hg before (and is on their reponse page against our BzrVsHg)
<jam> is that we garbage collect when you push/pull/branch
<jam> fullermd: do you have that page? I'd be interested in reading it
<fullermd> 11:17 <Peng> FWIW, http://www.selenic.com/mercurial/wiki/index.cgi/BzrVsHg
<Peng> If I had a wiki account, I might add a comparison of shared repo vs. hardlinks.
<jam> Peng: if you want to write it up in ReST format
<jam> I'll upload it for you
<Peng> I meant to the hg wiki. :P
<Peng> And it would only be one paragraph.
<kiko> wow, what a nasty page.
<james_w> wow, you guys have been busy.
<Peng> They're always busy.
<james_w> true, *especially* busy.
<jam>  james_w who is "you guys"? the chat channel?
<james_w> jam: no, everyone flooding my bzr mailbox :)
<kiko> hey I've been busy too!
<james_w> all the merge requests, bug triaging :)
<james_w> kiko: I don't doubt it, feel free to bounce me copies of all your work so that I can marvel at that as well :)
<kiko> I deal in psychological counseling and disaster management. I wouldn't bounce those to you.
<kiko> you seem like a nice person.
<james_w> ah, thanks kiko.
<kiko> however if you have a crisis, you can call me!
<jam> james_w: well that is just a targeted strike to make you unproductive by DOS'ing your email server
<lifeless> jam: hi
<jam> hi lifeless
<jam> good morning
<jam> you are actually showing up at a reasonable time
<jam> I'm so proud of you
<lifeless> well I have guests
<lifeless> been doing stuff round the house :)
<lifeless> given it's my sat, I'm not sure showing up is reasonable :)
<lifeless> anyhow, I thought I'd ask if there was anything you needed help with; I have somewhat under 2 hours that I can do 'stuff' in if needed.
<jam> lifeless: I have 3 patches up for review
<Peng> Make packs more awesome!
<jam> one is the "fetch checks basis"
<jam> patch
<jam> Which depends on your reconcile stuff
<jam> so get your reconcile merged (if it isn't yet)
<jam> and then review mine
<jam> 2 and 3 are performance patches
<jam> that get rid of some of our poor scaling
<lifeless> I was going to let your branch merge both
<jam> lifeless: sure, if you want to approve it... though I did want the comments, etc from you
<lifeless> right; I'll review now
<lifeless> abentley: whats my password again ? :)
<lifeless> I'm not on my normal machine
<lifeless> Peng: we will make them more awesome
<Peng> :D
<lifeless> abentley: nvm, got it
<lifeless> jam: reviewed one
<fullermd> Peng: You need bzr init --format=pack-moreawesomeer"
<Peng> If only improving software were as easy as adding a "--moreawesomer" argument...
<lifeless> jam: okies, reviews done
<lifeless> jam: bbiab
<lifeless> jam: ping
<jam> lifeless: pong
<lifeless> so
<lifeless> I will be going in < 1 hour
<lifeless> if you need more discussion or review we should do is asap
<lifeless> *i*
<lifeless> *it*
<jam> Nothing that cannot wait the weekend, IMO
<lifeless> ok
<lifeless> I have only mon and tuesday next week
<Peng> lifeless: Changing the delta algorithm will halve disk usage?
<lifeless> Peng: yes
<Peng> lifeless: From what to what?
<jam> k, I only have a couple more hours, and you've given me enough for that
<jam> lifeless: to xdelta from line-deltas
<jam> and changing the compression order
<jam> Peng: ^^
<lifeless> Peng: well e.g. 50 to 25M thereabouts, for bzr.dev
<jam> just changing the order brings the biggest benefit
<lifeless> jam: something you might find interesting when you get say 2 hours 'spare'.
<jam> ?
<lifeless> jam: put your inventory reweave into 'bzr pack'
<lifeless> jam: that is, subclass Packer to one that regenerates the inventory deltas to be optimal.
<jam> oh, to change the # of inventory fulltexts
<lifeless> jam: or at least analyse and decide if it's optimal/blind reinsert. That sort of thing. yes.
<jam> Peng: there is an interesting property when it comes to deltas and merges
<jam> in that the delta against left parent when merging
<jam> is the sum of the chain of commits
<jam> which means it is usually rather large
<jam> multiparent diffs help
<jam> but that means you have to unpack both sides
<beuno> oook, after two days of using packs, it seems all in all considerably faster then knits. I have ~140 branches at the office spread around the filesystem, is there some clean/automatic way of upgrading all of em to packs?
<dato> find/locate + script, probably
<jam> beuno: "for branch in `bzr branches`; do bzr upgrade $branch; done"
<jam> (if you have bzrtools for 'bzr branches')
<lifeless> beuno: find .bzr/repository/revisions.knit - dirname twice; reconcile; upgrade
<jam> which will be a lot slower than "find . -path '.bzr/branch'"
<dato> jam: (s/path/wholename/, I think, in case you'd be interested)
<jam> beuno: I would recommend lifeless's solution but dirname 3 times
<lifeless> jam: does your reweave inventory do anything strange?
<beuno> we might want to have a nice downloadable script handy once 1.0 hits the stores
<jam> lifeless: I believe it just inserts inventories into the target using the new algorithm
<lifeless> jam: or is it just get_graph_with_ghosts + topo_sort + reinsert ?
<jam> for version in knit.versions(): knit.add_lines(...)
<lifeless> hmm, I might whip this up
<jam> it has been a while, though
<lifeless> another thing that would be niftt
<lifeless> nifty
<lifeless> have bzr info -vv
<lifeless> show how much space each fileid consumes
<lifeless> - sum the record sizes for everything with that id
<lifeless> spiv: in case you haven't figured it out; index is self.stream_index compares object instances, (self.stream_index is a _StreamIndex). So its safe, its a string when its a thunk request - that is not self.stream_index.
<jam> lifeless: another way it could be rewritten... compute what should be a delta and what should be a fulltext. If the current index matches, just copy the data across. only if it misses do we need to do add_lines()
<jam> it would make it a lot faster
<lifeless> jam: yah
<lifeless> jam: same as reconcile's stuff for texts
<jam> yep
<lifeless> jam: its what I meant by 09:12 < lifeless> jam: or at least analyse and decide if it's optimal/blind reinsert. That sort of thing. yes.
<lifeless> jam: another possibility is to consider only the fulltexts
<jam> lifeless: also, I think if you favored doing a fulltext at a merge revision
<jam> since those would tend to be larger anyway
<beuno> hey Verterok
<jam> It seems we don't have any branch_implementation tests that pull(other) will raised DivergedBranches
<jam> we have 1 blackbox test that happens to exercise it
<jam> weird
<jam> (it turns out my pull_set_last_revision stuff broke it, but not branch tests failed)
<Peng> I have a plugin (bzrtools) installed with bzr 0.92 in my system. But now I'm running bzr.dev. How should I hook up the plugin into it?
<jam> Peng: I always install it in ~/.bazaar/plugins/bzrtools
<jam> directly from Aaron's branch
<jam> because he has to usually update it for each bazaar release anyway
<jam> so I can just "cd ~/.bazaar/plugins/bzrtools; bzr up"
<Peng> Ahh.
<Peng> You run non-release bzrtools too?
<Peng> Oh, duh.
<Peng> If I'm using non-release bzr, I need non-release bzrtools too. Hmm.
<jam> not always, but usually
<jam> aaron is pretty good about not really breaking stuff
<jam> actually, I've been spoiled by bzr, such that I feel like running tip of lots of projects
<jam> only to find out they aren't as careful
<Peng> Heh.
<Peng> Run Mozilla from CVS!
<jam> well, CVS by its very nature will tend to create broken stuff if you do anything but get tags :)
<jam> and even then
<jam> ...
<jam> oh, I'm wrong, the pqm has just been changed to stop on the first error... shame, I always used the pqm to give me the list of tests I needed to fix :(
<Peng> Modern computers are fun. I just did a find through my entire home directory to find all of the .bzr dirs, and run upgrade on them, and it took like 30 seconds.
<Peng> (I had manually gotten all of the repos, but not all of the branches.)
<Peng> There were 45 of them.
 * lifeless waves
<lifeless> oh Peng - are you using bzr again now ?
<Peng> Only 28 .hg dirs. :P
<lifeless> Peng: if so, cool, and welcome back to the fold :)
<Peng> lifeless: Not for that main thing. But I never stopped using it for other things.
<lifeless> Peng: oh, cool.
<Peng> (The main thing being where I could stress-test it best. Hmph.)
<lifeless> Peng: please let us know where we fail w.r.t. that main thing at the moment.
<Peng> lifeless: I have no idea.
<lifeless> :)
<Peng> But even if I wanted to go through the hassle of another conversion, then I would barely be using hg, and I don't want that.
<lifeless> Peng: well, :)
<lifeless> ok, gone for real.
<Peng> lifeless: I'd be happy to do any tests you want me to on a copy of the bzr branch from before the conversion. It's about the same, just a bit smaller.
<Peng> (Don't really feel like doing it right now, though. Also, Firefox is busy hurting the system's responsiveness.)
<Peng> (A fun way to measure what Firefox is doing is to time my usual large commit that I do frequently. When Firefox is closed, it's 16 seconds user time and a couple seconds sys and wall-clock time is normal, but when Firefox is really hogging things, wall-clock is always above 50 seconds, rarely above a minute.)
<fullermd> You can't run Mozilla from CVS.  The compile time is longer than their release cycle...
<Peng> Heh.
<Peng> You can always be out-of-date *and* unstable.
<fullermd> No, I don't have a Windows CD.
<Peng> Mozilla has an hg branch, which is just a direct copy of almost all of the CVS tree. Last I heard, it couldn't compile without CVS. Hmph.
<Peng> Off-topic, but since everyone here is smart and GPG-signs everything, what do you do about backing up your PGP key? I'd store encrypted backups, but there has to be an unencrypted version somewhere to be able to decrypt the backup of it! Do you put it on a floppy at Grandpa's? Encode it in the Bible and hide it in multiple safes in booby-trapped locations on each continent? Upload it to a hidden directory on your shared web space and hop
<Peng> e no script kiddies hack your blog?
<Peng> Ooh, multiple lines. Nice.
<fullermd> Tattoo it on the inside of your eyelid.
<Peng> What if I get a new one with a longer algorithm? :(
<kiko-afk> so somebody tie jam up
<kiko-afk> jam, do you have all this code in a DVD somewhere and you are slowly unleashing it to the world?
<fullermd> Write smaller.
<Peng> Seriously, though.
 * fullermd shrugs.
<fullermd> I'm not an especially heavy user.
<fullermd> I follow the methodology of "put all your eggs in one armor-plated basket, and watch it like a hawk"
<Peng> What's that mean?
<fullermd> It's the opposite of avoiding putting all your eggs in one basket, because spreading them securely and reliably isn't as easy as a lot of people think.
<Peng> Hmmph.
<abentley> jam: are you planning on doing xdelta packs?
<Peng> I believe Mercurial has had problems with how xdelta scales.
<Peng> What about IBM's algorithm? http://alphaworks.ibm.com/tech/hsadelta
<abentley> Well, I'd rather use the MPDiff format we already use in bundles.
<abentley> But the main thing is, I don't want to duplicate effort with jam.
<schierbeck> jelmer: ping
<jelmer> schierbeck: pong
<schierbeck> jelmer, does the bzr-gtk trunk still reside in ~bzr/bzr-gtk/trunk?
<schierbeck> even when we have a ~bzr-gtk team?
#bzr 2007-12-01
<jelmer> schierbeck: yes, though I can try to change that
<schierbeck> that would be great -- i have a one-line patch that fixes a crasher in the mainline version of the viz
<schierbeck> i'm not sure if it needs to go through the review process -- even if it doesn't, i'm not able to push
<jelmer> schierbeck: ok, it's now at ~bzr-gtk/bzr-gtk/trunk
<schierbeck> wow, that was fast
<schierbeck> do you think i should push the revision?
<schierbeck> it's just removing an import of a now nonexisting file
<jelmer> yeah, sounds good to push without review
<jelmer> so now the main branch is at ~bzr-gtk/bzr-gtk/trunk you could start pushing your own approved revs :-)
<schierbeck> nice :)
<Peng> What order are the sections ("BUG FIXES", "IMPROVEMENTS", etc.) in NEWS in?
<Odd_Bloke> Peng: I'd suggest looking at NEWS to find out. :p
<GuyIncognito> Newbie question:  I'm working on a project with the "Decentralized with shared mainline" workflow.  I want to "fork" the project into two different development efforts.  I guess this would be "making a new revision"?  But what is going to happen when people start pushing their changes back to the mainline from the two different branches?  Is there a best practises for this, or am I going about it the wrong way?
<GuyIncognito> * sorry I meant to say "This would be 'making a new branch'?"
<Odd_Bloke> GuyIncognito: What you would do is 'branch' the shared mainline into a separate branch.  You would then 'merge' changes from that branch back into the mainline.
<GuyIncognito> Old_Bloke:  OK.  What happens if several people want to work on the new branch?
<Peng> Odd_Bloke: Seems to be arbitrary.
<fullermd> GuyIncognito: You can have multiple shared branches, instead of just one.  Just set up the second similar to the first.
<Odd_Bloke> GuyIncognito: Well, any given branch can be treated as centralised.  That is to say you could branch 'mainline' to 'feature-1' and then have people use 'feature-1' using any of the listed workflows.
 * Peng adds a reference to the bzr branch to the trivial bug he's been working on. :O
<Peng> I feel kinda bad about polluting the big important list of branches with something trivial.
<Peng> But it also has taken a few commits and continued to be modified, at least a little.
<GuyIncognito> fullermd, Odd_Bloke:  Thanks!
<Odd_Bloke> GuyIncognito: No worries. :)
<JordanC> Hyello
<JordanC> Does anyone else have problems with Launchpad & olive?
<JordanC> I try to grab from there or push and I get "unexpected response"
<abentley> The location for bzr-gtk has just moved to ~bzr-gtk/bzr-gtk/trunk
<JordanC> ?
<abentley> ?
<JordanC> Were you talking to me?
<abentley> Yes.  I thought that might be relevant to you.
<JordanC> Hmm
<JordanC> Still wondering why no SVN on launchpad :P
<abentley> Still wondering why no SVN on list of "once-popular products that no one's using"
<JordanC> ...no-one's using SVN?
<abentley> No one should be.
<JordanC> (I know of at least 30 off the top of my head)
<JordanC> Well, i've had nothing but problems with bazaar -_-
<abentley> I'm sorry to hear that.
<fullermd> It probably saw svn installed on the system and got huffy.
<abentley> So what protocol are you using to retrieve bzr-gtk?
<JordanC> I'm trying to use olive at the mo
<abentley> Same source tree.
<JordanC> Can i get bzr-gtk via yum
<abentley> No idea.  The Bazaar project has debs, but I don't think any rpms.
<JordanC> Yeah, I have it
<JordanC> But there's no GUI
<JordanC> It's just tools
<JordanC> And I'm using KDE :P
<JordanC> bzr-gtk is a plugin for Bazaar that aims to provide GTK+ interfaces to most Bazaar operations.
<fullermd> Can probably do a quick grep through yum list (or is it yum search?  I can't remember) to see if it's in its standard repo.
<abentley> The Bazaar project has debs FOR BZR-GTK, but I don't think any rpms.
<JordanC> Well, no app is shown
<JordanC> lessee
<abentley> I know what bzr-gtk is.  I am one of the contributors.
<fullermd> If it's not in the 'official' yum db, I haven't heard of anywhere else offering RPMs (which doesn't mean much since I don't track that, but...)
<JordanC> Oh dude
<fullermd> If it's not there, it's probably easiest (for experimenting, anyway) to just grab a copy manually and stick it in your personal plugins dir.
<JordanC> Now I have to install nautilus
<JordanC> No way am I using bazaar
<JordanC> :X
<fullermd> You don't have to for bzr-gtk itself; some package may be listed with it.  I sure don't have nautilus around.
<abentley> Nautilus is not a hard dependency of bzr-gtk.
<JordanC> Man, good
<JordanC> Cause it's nowhere near as good as Konqi :/
<JordanC> Anyhow
<fullermd> Is that some new-fangled version of 'ls'?   ;p
<JordanC> What is just, the long and short of it -- how do I make it easier just to commit without having to fanny around? :P
<JordanC> It's getting annoying when there's GUI's that don't work and bazaar is similar to arch
<abentley> I'm not sure what you mean about guis that don't work.
<JordanC> Olive doesn't work
<fullermd> That's a bit off my turf.  I always just use the CLI; only thing I generally use -gtk for is an occasional viz.
<JordanC> Won't let me commit, won't let me pull
<JordanC> Can't connect to servers
<abentley> Well, commit works for me.
<JordanC> Using olive?
<JordanC> Okay, well if this is the case maybe I'm not getting the connection URL's correct
<fullermd> You'd probably have to be a little more specific about what you're trying to commit/pull and what servers   :p
<JordanC> What's the actual URL you need to specify
<JordanC> My project on launchpad is photoncrm
<JordanC> And the advised path is ~jordancdarwin/photoncrm/modules/
<abentley> JordanC: yes, using olive.
<Odd_Bloke> So 'bzr+ssh://jordancdarwin@bazaar.launchpad.net/~jordancdarwin/photoncrm/modules/' for pushing.
<Odd_Bloke> JordanC: ^
<fullermd> For writing it, I think it would be something like bzr+...   what Odd_Bloke said.
<JordanC> Still
<JordanC> When I use that, I get "Cannot read response from server"
<JordanC> And for pulling?
<fullermd> Mmm.  I get a bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~jordancdarwin/photoncrm/modules/" when I try branching it.
<JordanC> bzr push bzr+ssh://jordancdarwin@bazaar.launchpad.net/~jordancdarwin/photoncrm/modules
<JordanC> That's what I get given
<JordanC> Haha
<JordanC> Yeah, it just crashed
<abentley> Well, it looks like there really is no branch there.
<JordanC> " This branch has not been published yet."
<fullermd> So LP has the branch listed, but not really there.  I don't know LP well enough to know how you do that, or fix it.
<fullermd> I've never created a LP branch except by pushing it.
<JordanC> Why is it that after some errors, GTK will actually not allow me to click buttons, but use the keyboard instead? Argh, frustrating
<JordanC> Hmm
<JordanC> Unsupported protocol for url "bzr push bzr+ssh://jordancdarwin@bazaar.launchpad.net/~jordancdarwin/photoncrm/modules"
<JordanC> Everything is fine
<JordanC> Hang on
<JordanC> Why is it pasting that
<JordanC> Okay, here we are
<JordanC> Unknown error
<JordanC> end of file reading from server.
<JordanC> :)
<abentley> The bzr+ssh protocol has poor diagnostics.
<abentley> Try using sftp instead.
<JordanC> In olive?
<abentley> Sure.
<JordanC> Same error
<abentley> Just switch sft for bzr+ssh in the URL.
<JordanC> Yeah, I know how to do it ;-)
<abentley> Sorry "sftp".
<abentley> Okay, can you log into launchpad?
<JordanC> Already done
<abentley> e.g. using an sftp client?
<JordanC> Yes
<JordanC> Works fine
<abentley> And you're using the same user-id?
<JordanC> yup
<abentley> Sound like you need to talk to someone in #launchpad, then.
<bialix> jam: ping
<gdoubleu> I can't remember, bzr branch lp:/// support is in bzr proper correct?  Not bzrtools?
<fullermd> gdoubleu: Technically, I think it's in the launchpad plugin, but that's shipped with bzr.
<imbrandon> anyone got any clues on this error ( trying to use bzr-svn )
<imbrandon> http://paste.ubuntu.com/2392/
<imbrandon> *hopes some is awake at this hour*
<AfC> imbrandon: Upgrade to >= 0.92 and try again
<AfC> imbrandon: (1.0rc1 would be better)
<imbrandon> AfC: ok , is it in hardy or do i need to compile
<imbrandon> i'm running gutsy with all -backports/-updates
<AfC> imbrandon: I haven't the faintest idea what a gutsy, hardy, or whingy are, but if you look on the Bazaar website you'll find that they have an apt repo that Debian derived distributions can use.
<imbrandon> AfC: rockin ok, ( fwiw they are the ubuntu codenames )
<imbrandon> gutys being the latest stable , anyhow thanks, i'll try that
<imbrandon> gutsy*
 * AfC is heaping scorn on the idea a) of codenames, and b) that Debian and Ubuntu people seem to expect that anyone else would have the faintest fucking clue what the hell they are talking about
<imbrandon> no i dident *expect* you to know, sorry for the assumtion, bzr being another canonical project i assumed the right hand would know about the left hand, but assuming makes an ass+u+me , wont happen again
<AfC> Anyway, 0.93 ^W 1.0rc1 is just out, and you'll probably do well to give it a try as it's 3-4 months (and 3-4 releases) newer than what you were using. The Bazaar hackers continue to move at an astonishing rate and problems encountered in a version that's that old are likely long since resolved.
<imbrandon> k
<JordanC> Hey dudes
<JordanC> :)
<imbrandon> ello JordanC
<dato> siretart: so, as a person who's fought with Recommends... ;) what's your opinion on having bzr recommend: bzrtools, and suggest: bzr-gtk, bzr-svn
<dato> siretart: I think bzrtools is on the verge of not being appropriate for recommends, but only on the verge :)
<siretart> dato: I would argue this way:
<siretart> dato: would you expect a typical bzr user to also install bzrtools?
<siretart> if yes -> recommends, if no ->suggest
<siretart> (I'd vote in favor of it)
<dato> yeah, me too. I think it'd be useful for it to be available by default.
<dato> I'm also revamping the description.
<siretart> great, thanks
<dato> jam, vila: I would also like to know whether you think python-pycurl should still be pulled by default when installing bzr (in Debian, and possibly in ubuntu), or it's better to leave it out now.
<dato> siretart: do you have any idea why on earth we Suggest: libxml2-utils?
<siretart> dato: no idea. maybe lifeless knows?
<dato> maybe. the changelog is not helping.
<james_w> /usr/bin/xmllint, /usr/bin/xmlcatalog
<james_w> I'm not sure what either of those would be for.
<james_w> hi all btw.
<dato> hi james_w
<dato> oh, no jelmer
<dato> siretart: http://dpaste.com/26427/
<james_w> dato: conclicts
<james_w> "yet able to adapt to many workflows, reliable, and easily extendable." is a little uncomfortable, I would suggest dropping the "yet".
<dato> james_w, thanks, fixed (both).
<james_w> dato: it's good, thanks for doing it.
<vila> "no special software the server is needed" ? "no special software is needed on the server"
<dato> the intention was "no special software *in* the server is needed"
<vila> regarding pycurl, there are two http implementations in bzr: one based on pycurl, the other on urllib
<dato> yes
<vila> if pycrul is the default if present
<dato> yeah, I know.
<vila> the major difference is that pycurl verifies ssl certificates
<dato> the question was, whether to make installing bzr in a system also pull pycurl in
<dato> iow, what do you feel that would be a better default: pycurl available or not
<james_w> dato: I would think available.
<vila> dato: I'm a bit biased since I rewrote most of the urllib ;)
<james_w> also looking again I think vila's "no special software is needed on the server" is better.
<dato> ok, done
<vila> frankly I don't know if pycurl should be pulled or not. When people want certificate verification pycurl is mandatory (today), if they don't want certificate verification pycurl should be avoided (by forcing the use of  urllib)
<james_w> of course the best solution would be to get vila enough spare time to add certificate validation to urllib.
<dato> vila: avoided?
<vila> james_w: ;-)
<james_w> yeah, pycurl wont let you access a site with a self-signed certificate for instance, so you have to force urllib to access it.
<vila> dato: no hhtps connection can be issued if certificate verification fails (included self-signed certificates)
<vila> and also if your installation is screwed or the site use an unknown CA
<vila> since urllib makes no verification... it's usable. *And* I will provide the necessary hooks to allow urllib to cope with the situations above
<dato> so, maybe not pull pycurl, and leave a note in README.Debian on when it could be useful?
<dato> maybe downgrade it to suggests
<dato> ah, I meant to mention in the description what paramiko is useful for
<vila> you stop doing that ?
<vila> put it back and add an equivalent section for pycurl maybe ?
<dato> stop doing what? there was never any place in the debian packagin explaining what was paramiko needed for
<vila> s/if your installation is screwed/& regarding the certificates/
<vila> I heard at least two reports (or three) where the ca-certificates package were not installed even when pycurl was (or liburl, or curl, whatever ;)
<vila> s/liburl/libcurl/
<vila> err, waitaminute, james_w, *you* had a case where ca-certificates not installed no >
<vila> s/>/?/
<james_w> vila: yeah, I've tried to see why, but I'm couldn't see it.
<vila> dato: sry, misunderstood you, I thought you said you *was* doing, I think it will be a good idead to do so.
<vila> james_w: I think I sent you an email afterwards with some hints (after looking a bit myself)
<vila> Subject: ca-certificates as a bzr dependency
<vila> To: James Westby <jw+debian@jameswestby.net>
<vila> Date: Wed, 21 Nov 2007 12:01:48 +0100
<james_w> vila: yeah, thanks.
<vila> AAARGH silly posting addresses here :-(
<vila> so sorry :(
<dato> is paramiko needed to push over bzr+ssh?
<james_w> vila: no problem, there are plenty of other places to harvest it.
<james_w> and the '+' is a good anti-spam device anyway.
<vila> really ? I was wondering about that cause my spam level have never been too high and I tend to always use + addresses
<vila> dato: checking...
<vila> dato: yes it is
<dato> thanks
<dato> bbiab
<dato> (maybe it'd should be a dependency then)
<dato> bbiab
<james_w> vila: my MTA's logs show loads of rejects to debian@jameswestby.net, which I think is a great help.
<vila> amazing... I thought there were clever enough to include + as a valid component... or may be the clever ones think that people using + are naturally anti-spam ;-)
<vila> regarding urllib's certificate verification, I have a branch whith an https test server using the ssl module provided by python2.6 (after  dirty port of bzr to python2.6)
<vila> this branch is on the back burner for now because that module is currently under work in 2.6, 3k and as a package for py2.3->2.5, so it's bit hard to find the right version ;-)
<vila> 2.6, 3k and the package being at different levels last time I checked...
<james_w> vila: apparently 0% of my current spam folder (1700 messages) is to that address, > 90% of ham is to that address.
<james_w> do other countries have the real SPAM, i.e. the meat product?
<vila> Not that I know of ;-)
<james_w> ah, you're missing out.
<abentley> vila: What's it used or?  The ssh connection can be through openssh, and the protocol is our own.
<vila> abentley: try:
<vila>     from bzrlib.transport import ssh
<vila> except errors.ParamikoNotPresent:
<vila>     # no paramiko.  SmartSSHClientMedium will break.
<vila>     pass
<vila> in smart/medium.py
<vila> ?
<abentley> Perhaps it's used for something, but I would have thought not.
<vila> me too, that's why I checked, I'm as surprised as you, may well be a bug
<abentley> I guess we'll just have to harass spiv.
<vila> spiv: ^
<ubotu> New bug: #173274 in bzr "Allow pre-export hooks" [Undecided,New] https://launchpad.net/bugs/173274
<jelmer> abentley: your announcement of bzrtools 1.0 doesn't mention switch being merged into core. Did it make it into 1.0rc1?
<abentley> Actually, I did mention switch.
<abentley> Oh, drat.
<abentley> I meant "switch", not "shelf".
<abentley> Okay, I've fired off a correction.
<jelmer> ah, that explains it :-)
<Peng> Huh. Now that I'm using bzr.dev, I don't want to bother installing 1.0rc1.
<abentley> Yeah, I'm chronic that way.
<abentley> I did have to revert to 1.0rc1 temporarily, to make sure bzrtools 1.0.0 works with it.
<abentley> Which you can do with "bzr revert -r branch:http://bazaar-vcs.org/bzr/bzr.1.0/"
<Peng> What the hell is wrong with Firefox? It refuses to download GPG signatures. /me wgets the bzrtools .sig file.
<jelmer> so why's bzr.dev still claiming it's 0.93 ? shouldn't that be 1.0.1 ?
<Peng> NEWS was updated but I guess nobody got around to updating the version number.
<Peng> And now they're off for the weekend?
<Peng> Going from an installed copy of 0.92 to 1.0rc1 is a 291 KB pack. :)
<Peng> Hm, it's not possible to branch a dirstate branch into an (empty) pack repo?
<Peng> Oh, never mind.
<Peng> dirstate-with-subtree.
<Peng> Yes, "KnitRepository" is super-useful information.
<Peng> jelmer or something: Who runs doc.bazaar-vcs.org? The docs need to be updated. 1.0rc1 links to packrepo.html but it's still a 404.
<james_w> Peng: I think one of poolie, jam or lifeless should be able to update it.
<Peng> Okay.
<Peng> jam or lifeless or someone: http://doc.bazaar-vcs.org/latest/developers/ needs to be rebuilt. 1.0rc1's "help formats" links to packrepo.html, but it's still knitpack.html on the server. It would also be nice if there was a 301 redirect from knitpack.html to packrepo.html.
<Peng> Am I still connected?
<dato> jelmer: re REJECT, possibly the XS-* field has to be installed in the archive, not only in incoming, for it to work; so try again tomorrow
<james_w> Peng: no :)
<Peng> That was weird.
<Peng> I lost my connection to the Internet, but the DSL light on the modem was still on. Then while I'm reconnecting to all the IRC networks, the last one, Freenode, recovers.
<Peng> Weird.
<Nafallo> not really...
<Peng> Yes it is.
<Nafallo> why?
<Peng> How can I get disconnected without either the modem or computer being aware of it?
<Nafallo> did you get a new IP?
<Nafallo> ah
<Peng> Nafallo: Nope. But since my account was shuffled around, I've stopped getting new IPs anyway.
<Peng> (The one time it's gone down since it was shuffled, anyway.)
<Nafallo> well, your PPPoE can disco without line-sync go down, and your computer is only aware of connectivity to the modem.
<Nafallo> as far as freenode go, you never reached the TCP timeout.
<Peng> Not PPPoE anymore. "ENET ENCAP".
<Peng> My hostname changed from saying "dyn" to "dhcp" and now I get crappier IPs.
<Nafallo> nice :-)
<Peng> I got a new modem too, because apparently mine should've burned out years ago. I'm still using the old one because I don't want the (minor) downtime. I was just about to switch it out before the connection started working again.
<Peng> Anyway, back on topic. Not like anything's happening...
<dato> jelmer: ping
<sommer> hello, I checked out the ubuntu-hardy docs branch from LP... I then changed my "name" and "Display Name" in LP and I can no longer commit
<sommer> I think the local version is still using the old name
<sommer> is there a way to change that without re-downloading?
<lifeless> Peng: which branch? the one took to hg? basically I'd like to know how we compare
<lifeless> Peng: are we still so slow you would have moved?
<Peng> lifeless: Can you rebuild the docs? Or poke someone who can?
<lifeless> I'll see what I can do
<Peng> Thanks.
<james_w> sommer: you probably want to use 'bzr bind' with your new username in the URL.
<sommer> james_w: ah... I'll try that
<Peng> Let's see how long it takes to extract a 1.3 GB .tar.
<lifeless> Peng: obviously for these tests I want you to upgrade the branch to packs
<Peng> 1 minute and 3 seconds!
<sommer> james_w: genius that worked.  Thank you very much
<Peng> Hmm. I had like 8 copies of the data, and removed all of it except for 1 copy (well, there are still 2 copies of the bzr repo), and it looks like I took the copy I was experimenting with with it.
<Peng> What makes something a shared repo vs. a non-shared repo? The presence of a branch in the same dir?
<lifeless> .bzr/repository/shared-storage
<Peng> Ah.
<Peng> Bah, should've just checked.
<Peng> Now, let's see how long it takes to convert to packs.
<Peng> (even worse, pull into a new branch, building a new working tree)
<Peng> Think I have time to brush my teeth?
<Peng> Well, let's see if I can brush my teeth in time, then!
<Peng> BRB.
<Peng> Hmm. It might work well to use git for ~/local instead of bzr. Since it doesn't track renames, I don't have to try to.
<Peng> Wait, I do like being able to do renames, though.
<lifeless> rofl
<Peng> I like being able to do renames when I want to, but I don't want to have to think about them when I don't.
<lifeless> commit --automatic is what you want
<lifeless> as we delete automatically today
<lifeless> you can do:
<lifeless> bzr add; bzr commit;
<lifeless> and you'll get a new snapshot
<lifeless> no thought.
<Peng> Oh, gosh. It only took 9 minutes.
<Peng> Now, why am I swapping so badly?
<Peng> Better now. I guess bzr had just used a lot of RAM.
<Peng> lifeless: Wow. 17 seconds user time. Slightly higher sys than with hg, I think. :P
<Peng> lifeless: Now, it's gotten larger since this old copy was made, so it would be slower (no idea how much), but if bzr was this fast in August, I never would've switched to hg.
 * Peng wanders off. Star Trek.
<lifeless> Peng: cool
<lifeless> Peng: btw, histor shouldn'y slow it down noticably for commits anymore, only total count of files/size of changed files.
<Peng> lifeless: Cool!
<Peng> lifeless: Same with hg.
<Peng> Meh. The problem with me is also that the files I'm committing keep getting larger, so even if history doesn't slow it down, the diffs will.
 * Peng wanders off.
<dato> jelmer: btw, you were the second approver of my small patch to NEWS, maybe you could merge it? http://bundlebuggy.aaronbentley.com/request/<20071129185051.GA12330%40chistera.yi.org>
<abentley> lifeless: ping
#bzr 2007-12-02
<lifeless> abentley: pon
<abentley> So I started hacking on per-file base selection yesterday, and I found a locality-of-reference problem.
<lifeless> ok
<abentley> The file content is stored in the versionedfile.  The file type is stored in the inventory.
<abentley> So to do it absolutely correctly, I'd have to retrieve all the trees for the selected revisions.
<abentley> Because the selected revision may not be a file-- it may be a directory, symlink or tree reference.
<lifeless> ok
<lifeless> I see
<lifeless> now, if the kind is the same on both tips
<lifeless> does that make it easier ?
<abentley> In fact, we're already assuming it's a file on both tips.  Otherwise, we wouldn't need a base at all.
<lifeless> so if its the same on both tips
<lifeless> 3-way merge says that if the base is a different kind
<lifeless>  -> we'd treat is as empty of the same kind ?
<abentley> Not quite.  We'd still emit foo.BASE in the correct kind.  But wrt the file merge, yes.
<lifeless> now symlinks and dirs have an existing empty text for their revisions
<abentley> AFAIK, correct.
<abentley> So we can shortcut the kind check 99% of the time.
<lifeless> so; and I realise this is hacky;
<lifeless> if doing a 3-way custom base on two currently-file-texts, w.get_lines(custom_base) will give us [] when the kind has changed.
<abentley> I hate to have it shortcutted 99% of the time, though.  It makes me fear the full path won't get adequately tested.
<lifeless> are you doing custom bases for symlinks and dirs too?
<abentley> No.  Those will get handled by the standard merger, which also handles inventory issues such as renames and executability.
<abentley> I don't think those things change enough to require the same care as text files.
<lifeless> so I guess I'm saying; if we're only doing custom base on (text, text) pairs; and get_lines(custom_base) will always return a suitable set of lines, ([] when the common base has a different kind), then its not a shutcut situation
<abentley> By shortcut, I mean that we're avoiding retrieving the file kind from the relevant inventory.
<abentley> But in the case where it's [], we will have to do so.
<lifeless> I don't see that we ever need the file kind for the base if the parents are both texts; other than to write foo.BASE.
<abentley> Right.  But we will have to write foo.BASE.
<lifeless> ok
<lifeless> so lets look at that
<lifeless> we write foo.BASE when we ended up doing a merge right
<abentley> Right.
<lifeless> now, will we avoid doing 'merges' sometimes with custom file bases ?
<abentley> No, but if the BASE is not a file, we will do a two-way merge between THIS and OTHER.
<lifeless> which is where [] is useful because it's just a clean degradde.
<abentley> A clean what?
<lifeless> degrade
<lifeless> it's what 3-way degrades too
<abentley> Okay.
<lifeless> hmm, one sec local interrupt
<lifeless> back
<lifeless> wondering if we will ever get base == left or base == right with custom merge bases
<lifeless> I think we can
<lifeless> consider this
<lifeless> at the graph level we have two lca's
<lifeless> so we recurse
<lifeless> its easy then for at the file level for one side to be purely an extension of the other for a single file
<lifeless> so when we are considering that single file we'll not need to merge at all
<lifeless> I'm going to think out lout now
<lifeless> and enumerate what I think the possible cases are
<lifeless> * Base is one side (common I suspect in criss-cross merges; many files won't be actually unmerges)
<lifeless> * Base is the revision the graph level base had
<lifeless> * Base is another inventory
<lifeless> s/another inventory/from &/
<lifeless> done
<lifeless> abentley: ^
<josep17> buenas noches
<josep17> desde venezuela
<abentley> lifeless: I would expect base==left or base==right to be rare.  But I would imagine we can get it.  I'm not sure why it matters.
<abentley> We need a general solution.
<abentley> Sure, I can hack up something gross to do per-file bases, but I think you ought to consider how an upcoming repo format could give us cheap access to file kind, symlink target, and maybe execute bit.
<abentley> Right now, I'm re-implementing annotate merge, and it's going swimmingly.
<jelmer> dato: resubmitting bzr-svn fixed it
<jelmer> dato: your upload of 0.4.4-2 hadn't been processed yet, apparently
<abentley> jelmer: Have you noticed that the bzr-gtk test suite is completely borked if run as part of the bazaar test suite?
<lifeless> abentley: I'm pretty sure I hit it all the time.
<lifeless> abentley: anyhow, our current format can give use kind/target/execute quite cheaply
<lifeless> abentley: just use the same parse-a-delta-fragment logic.
<abentley> Oy.  Can't we do up a format where that works by design instead of being a tremendous hack?
<lifeless> abentley: yes, both the ones poolie and I have been fiddling/mailing about will work by design
<abentley> Awesome.
<lifeless> abentley: but they largely formalise useful properties we have been able to leverage from the current format.
<lifeless> abentley: I have been thinking that content object information should be pushed down to the per file graph anyhow; as metadata on the node
<abentley> Well, I know the new format will do comparisons much faster, but that sounds like it would slow them down.
<lifeless> abentley: I'm thinking some duplication actually
<lifeless> abentley: but also there is locality of data possibilities.
<lifeless> abentley: this would be a 2nd or 3rd iteration out.
<lifeless> abentley: one possibility is:
<abentley> Oh, by "pushing down", I thought you'd be taking it out of the inventory.
<lifeless> kind + exec + content in the 'knit'
<lifeless> inventory has parent + name + pointer to the knit version
<lifeless> 'knit' index can pull kind + exec into it.
<lifeless> abentley: the open things in my mind about whether this makes sense are what datum we actually need at the same time
<abentley> For our tree-manipulation functions, we generally use inventory and file texts simultaneously.
<abentley> When building a tree, to create a file, we need file_id, name, parent, kind, execute bit, and content basically simultaneously.
<abentley> That's not a hard requirement.  TreeTransform could work efficiently if you learned names, parents and file-ids in one pass, and everything else in a second pass.
<lifeless> abentley: so its the case of status/diff when the last-mod is different and the value is the same that would be hurt
<lifeless> abentley: -> how common is that
<lifeless> (assuming we don't want false positives for st
<lifeless> another possibility here though is to decouple the metadata graph from the content graph
<abentley> This is assuming we're not diffing against a DirstateRevisionTree?
<lifeless> right
<abentley> So we wouldn't have the md5sum in the inventory?
<lifeless> so you'd have (fileid, parentid, name, content-pointer[revid, validator]) as a graph
<lifeless> and (kind, exec, content) as a graph
<abentley> I'm not sure at all how common that is.  Merges can produce it, though.
<lifeless> you'd have a sha1, but not of the lines, of the lines & kind and exec bit
<lifeless> this would for instance, allow us to start only storing one copy of 'COPYING' etc, depending on how we want to take it.
<lifeless> this is all still wildly speculative
<abentley> I don't think kind is a big concern.  If it changes, we definitely need to get all the data.
<abentley> I dunno, though.  I think having all the data in the inventory might well be a win.
<lifeless> I'd like to be in a position to experiment
<abentley> Just because there are many operations that just want to know which files changed.
<lifeless> write some arbitrary benchmarks outside bzr that simulate access patterns and the like
<lifeless> maybe this is something we can reason about in march
<abentley> Also, some stats on real trees might help us answer these questions about what's common better.
<lifeless> abentley: indeed. So having an analyser that can report what a transformed tree would look like would be good
<abentley> I'm not sure what you have in mind.  The PreviewTree thing?
<lifeless> nah
<lifeless> just a script to take a branch
<lifeless> and break it out into the things I'm talking about, without doing disk transformations, just in-memory, and report
<abentley> Oh, to simulate a changed repo format?
<lifeless> right
<jelmer> lifeless: what breaks about it?
<jelmer> s/lifeless/abentley/
<jelmer> ah, I see
<lifeless> meh
<lifeless> sorry about disappearing; what did I not respond to
<Odd_Bloke> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
<Odd_Bloke> 05:03:21 -!- lifeless [n=robertc@ppp245-86.static.internode.on.net] has quit [Read error: 113 (No route to host)]
<Odd_Bloke> 05:15:45 -!- lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #bzr
<Odd_Bloke> Oops, got the trackbar.
<Odd_Bloke> But yeah, nothing. :p
<lifeless> thanks
<alecwh> hello, I'm considering using bazaar for a project of mine... we're using subversion right now, because subversion is offered on Google Code, and Gna! (http://gna.org). Are there any free repository hosts that our GPL program can use (using bazaar)?
<beuno> alecwh, sure, https://launchpad.net/
<beuno> it also works as a bug tracker
<beuno> (and a bunch of other stuff)
<alecwh> no way... it hosts a free bazaar repository? that's awesome.
<alecwh> how do I set it up?
<alecwh> https://code.launchpad.net/phpns/
<alecwh> This is our project
<alecwh> Register branch?
<beuno> alecwh, let me fetch you a how-to real quick
<Peng> Hmm. I just started using LP a bit. I should look into the launchpad plugin.
<beuno> alecwh, https://help.launchpad.net/FeatureHighlights/BazaarHosting might help a bit
<beuno> but you basically just push to the right address with bzr
<beuno> and the branch gets created
<beuno> the folks at #launchpad might be able to give you more details though
<beuno> it's a bit over 5am here, so I'm going to bed
<beuno> good luck  :D
<alecwh> ok, thanks a lot bueno. ;_
<alecwh> ;)
<Peng> Might be even simpler using lp: URIs.
<Peng> New Pyrex release.
<alecwh> How do I import a subversion repository into a bazaar repository?
<Peng> alecwh: You could use bzr-svn.
<alecwh> what does that do?
<Peng> alecwh: bzr-svn can even allow pushing from bzr to svn. It's pretty neat.
<Peng> alecwh: Well, for one thing, it imports svn repos into bzr repos.
<alecwh> yeah, that's what I'm looking for. =D
<alecwh> how does that look like?
<alecwh> the bash command.
<Peng> Not sure.
<Peng> "bzr branch" might do it.
<Peng> Read the docs.
<alecwh> ok, thanks Peng. =)
<lifeless> alecwh: www.bazaar-vcs.org/svn IIRC
<alecwh> This page does not exist yet. You can create a new empty page, or use one of the page templates.
<alecwh> lifeless: I got that error.
<lifeless> alecwh: there is a link on it
<lifeless> alecwh: to BzrSvn :)
<alecwh> ok, thanks lifeless. I'll read over it.
<JordanC> Hey there
<JordanC> Tried to get things working with olive, but no dice/
<alecwh> hey JordanC. =D
<Odd_Bloke> JordanC: Define 'no dice'. :p
<alecwh> Odd_Bloke: It didn't work.
<Odd_Bloke> Yeah, I got that much. :p  I was hoping for something a little for specific. :D
<Odd_Bloke> s/for/more/
<JordanC> I came in here a while back, and yeah
<Odd_Bloke> JordanC: Are you using Olive or bzr-gtk?
<JordanC> I spoke to some developers, and they said that because of the SSH factor, I can't connect to launchpad using olive
<Odd_Bloke> Ah, OK.
<Odd_Bloke> Have you looked at QBzr?
<JordanC> Hmm, lesee
<JordanC> KDE Bazaar proggy?
<Odd_Bloke> JordanC: http://bazaar-vcs.org/QBzr
<luks> no, in two ways
<Odd_Bloke> Qt, not KDE.
<luks> not a program, not kde
<JordanC> Damnit
<ronny> yo
<ronny> is there a way to get more easy to parse output from bzr ?
<ronny> (im parsing the status output for an ide, an its really tricky to get it together atm)
<Odd_Bloke> ronny: There's an xmloutput plugin, I believe.
<Odd_Bloke> ronny: https://edge.launchpad.net/bzr-xmloutput
<Odd_Bloke> ronny: Which IDE were you thinking of?
<abentley> luks: I'm looking at your patch more carefully now.
<luks> thanks :)
<abentley> I think a nicer way to extract the name would be to have a pattern that only matches if there's "name <email>", and if it fails to match, just return the original string.
<ronny> Odd_Bloke: pida
<luks> well, I think returning "email" from short_author is better than "<email>"
<luks> unless you want to match "(name )?<email>", which is exactly what the patch does
<abentley> I think that's highly unlikely.
<ronny> Odd_Bloke: right now we parse the command output, cause the subsystem for python-api based vcs tools is basically nonexistant
<luks> abentley, "<email>" is the use case from the bug report
<ronny> the bad thig is - we get wrong data sometimes, but cant figure the exact source, cause the bzr output aint nice to parse (so the parser is tricky)
<abentley> Also, I don't know if lazy_regex was meant to be used in new code.
<abentley> I thought it was just to make existing code faster.
<abentley> And I really doubt there's a performance win by using it.
<luks> but what's the point of compiling a regular expession you are not going to use
<luks> sure, it's not a big win, but there is a lot of small things like this
<abentley> There's no win, there's loss in compiling a regular expresion.  I was talking about not compiling at all.
<luks> hm? you mean parsing the string manually?
<abentley> no, just using re.match
<luks> that compiles it every time you use it
<abentley> Right.
<luks> so about 3k times for log on bzr
<ronny> actually its cached
<abentley> luks: I really doubt that performance difference is observable.
<ronny> the more often a re is used, the more sense it makes just to compile it
<ronny> but the difference is only small, cause all re's u use are cached in re._cache
<luks> abentley, I mean, bzrlib already has code to delay regex compilation, pre-compiled regex is faster than re.match, there is a patch that use it -- why make is slower? even if the difference is small
<abentley> Because it's clearer to just write re.match
<abentley> Takes fewer lines.  Doesn't require people to grok lazy_regex.
<ronny> hmm - how does lazy_regex work ?
<luks> compiles the regex when it's first used
<luks> *first time
<ronny> im more intrested how the store works
<ronny> cause i doubt it has any notable gain compared to re.match
<abentley> ronny: It allows the "lazy_compiled" patterns to be substituted for really compiled patterns-- that's what it's for.
<abentley> So you can fix import slowness without rewriting the module.
<ronny> "import slowness" ?
<abentley> regexes that compile at import time reduce cause latency problems for programs like Bazaar.
<abentley> You run bzr, it imports a whole bunch of modules, they compile a whole bunch of regexes, and then, finally, it starts doing what you asked.
<ronny> hmm - why do you guys need so many regexes ?
<abentley> The libraries we import need them.
<abentley> (well, they *have* them.  *need* is debatable)
<ronny> btw - any timeframe when bzr will be as fast as hg ?
<abentley> For example ConfigObj has regexes that produce a noticeable compile delay.
<abentley> ronny: It depends what you're talking about.  With the packs format, commit speed is pretty similar.  With the smart server, pull time is similar.
<abentley> status has been comparable for some time now.
<ronny> ah - so its mostly cause bzr has tonns of other operation modes ?
<abentley> Well, it depends what operation you want to speed up.
<ronny> all i care for is fast sync and fast commit
<abentley> I think 1.0 will give you that.
<ronny> hmm - i didnt exactly use bzr for quite some time
<ronny> does it still try hide the existence of multiple heads (for example by allways enforcing merges)
<abentley> I think we've got the pieces in place to support good performance for most commands.
<abentley> I don't know what you mean by hiding the existence of multiple heads.
<abentley> But in some cases, the commands must be updated to take advantage of them.
<ronny> last time i used it it dodnt allowme to hae multiple heads in my repo
<abentley> Repositories typically have many heads due to people uncommitting revisions.
<abentley> But we don't have multiple heads for a single branch.  Instead we allow multiple branches per repository.
<ronny> hmmk - thats a problem for me
<abentley> Why?
<ronny> enforces me to split one semantical branch into multiple branches if more than one person is working on that
<abentley> No, they can use heavyweight checkouts.
<Odd_Bloke> ronny: That's what you're doing with multiple heads anyways...
<abentley> That lets them commit locally.
<abentley> And then sync up with the main branch when they're ready.
<ronny> damn - how many modes of operation does bzr have ????
<abentley> We support a range from svn-like to fully distributed.
<ronny> hmm - having too many choices tends to be confusing
<abentley> Well, we have three: a "tree" has a branch and working copy at the same location.  A "heavyweight checkout" has a branch in one location and the working copy is at different location, but has a local copy of the branch to act as cache.  A lightweight checkout is like a heavyweight checkout with no local cache.
<alecwh> I just created a bazaar branch at launchpad (https://code.launchpad.net/~alecwh/phpns/devel), and now I want to upload my project (which is in /var/www/devel) to the repository. In the terminal, my working directory is /var/www/devel, and I gave the command:  bzr push bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel , but it doesn't seem to be working. I get the error: bzr: ERROR: Not a branch: /var/www/devel/ , can anyone help me upload
<luks> cd /var/www/devel; bzr init; bzr add; (check if it added only files you want); bzr commit
<luks> and then you can use bzr push
<luks> http://doc.bazaar-vcs.org/bzr.0.92/en/mini-tutorial/index.html#putting-files-under-version-control
<alecwh> ok, I'll try that. will 'bzr add' add every single directory and file inside /var/www/devel?
<lifeless> moin
<alecwh> moin?
<lifeless> alecwh: yes, add adds recursively, obeying your ignore rules
<alecwh> thanks lifeless. I've got one more question: when I was using svn, every 'commit' you made actually uploaded your changes to the online repository. Is this not the case with bazaar?
<lifeless> alecwh: if you have a checkout it acts like svn
<alecwh> a checkout?
<lifeless> alecwh: that is, if you do 'bzr checkout bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel local-dir-name'
<lifeless> then you can cd local-dir-name, and do
<alecwh> that will download the project, right?
<lifeless> 'bzr commit', which will commit back to bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel, just like svn
<alecwh> oh.
<beuno> alecwh, or, when you want to send all your commits, just use "bzr push"
<lifeless> alecwh: if you have a separate 'branch' though, then your commits are performed just on your machine
<alecwh> ok, that makes sense.
<alecwh> https://code.launchpad.net/~alecwh/phpns/devel
<beuno> (when using branches instead of checkouts)
<alecwh> I just finished uploading everything...
<lifeless> alecwh: and then when you want them to be in bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel, you do 'bzr push bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel' (bzr will remember the push location the first time, so you don't need to type it every time0
<alecwh> how do I make it so every time I 'commit' it will update this repository?
<lifeless> alecwh: bzr bind bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel
<alecwh> ok lifeless, that worked. =D
<alecwh> I was using 'cia.vc', which puts a bot inside your channel on freenode, and then it will post a message inside the channel whenever a commit/change is made. Is there something like this for bazaar?
<lifeless> alecwh: there is a plugin for bzr to announce to cia
<lifeless> alecwh: you can also subscribe to the branches on launchpad
<lifeless> alecwh: or install bzr-email to send emails to arbitrary email address's on commits
<alecwh> ok, cool. Do you know what the plugin was called? I'm just looking for it...
<lifeless> http://www.google.com/search?q=bzr+cia&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:official&client=firefox-a
<lifeless> 3rd and 4th hits look relevant to me
<alecwh> https://launchpad.net/bzr-cia
<alecwh> lifeless, uhm, how do I get the plugin? =P
<beuno> alecwh, with bzr, of course  :D
<alecwh> https://code.launchpad.net/~jelmer/bzr-cia/main
<alecwh> is this the one I'm looking for?
<beuno> alecwh, yeap
<alecwh> bzr branch http://bazaar.launchpad.net/~jelmer/bzr-cia/main?
<alecwh> use that command?
<beuno> alecwh, yeah, you download it with that command
<alecwh> ok, done. =D
<alecwh> I think I got it now
<beuno> now, follow the instructions in: https://launchpad.net/bzr-cia
<lifeless> success; we have a 1.0 build on dapper-amd64
<lifeless> i386 testing now
<lifeless> brb foodstuff time
<dato> jelmer: very well
<dato> jelmer: btw, I guess there is no way to convert from svn a trunk and a branch, if I somehow say which revisions from the trunk are merges from the branch, right?
<jelmer> dato: only if you can go back in history and set some magic svn properties
<dato> jelmer: can I a dump of the repository, load it locally, set the properties there, and redump? that ought to work?
<jelmer> dato: yes, but you would want to change the uuid
<dato> ok. is there a document explaining what properties I should set?
<jelmer> and pulling from the original in the future may be problematic
<jelmer> http://bazaar-vcs.org/BzrForeignBranches/Subversion/mapping
<jelmer> basically, you'd want to set the bzr:ancestry:vX-SCHEME property
<lifeless> dato: is it really worth doing? why not just do a merge after the conversion?
<dato> jelmer: it's a one-time conversion
<dato> lifeless: I seem to find a strange pleasure fiddling with the tools.
<lifeless> dato: :)
<dato> jelmer: ok, thanks for the link. I'll try to do it. also, I svn-import trunk didn't work for me yesterday, but the packaged version worked fine. I'll try again tomorrow. finally ;), changing the UUID is just a matter of editing the dumpfile by hand, or?
<jelmer> dato: the trunk branch for bzr-svn is highly experimental
<jelmer> dato: 0.4 is the branch that is packaged
<jelmer> dato: yep, editing the dumpfile should be all that's needed to change the uuid
<abentley> lifeless: What do you consider a good way to decide if something should be a separate module or not?
<abentley> I was expecting plan_merge to be bigger than it is, which is why I originally did it.
<lifeless> abentley: I don't have a good rule; sometimes I get there and combine; sometimes I start in the same module and split.
<vila> wtf ? test_revision.TestIsAncestor.test_is_ancestor is failing just under the comment:
<vila>         # NB: if you see an assertion error here, its probably access against
<vila>         # an unlocked repo. Naughty.
<abentley> I guess by analogy, I'd think if merge3 has its own module, then annotate merge can have one, too.
<vila> the problem is I'm working on http response parsing rewrite and I can't find any link >-/
<vila> Worse, the same test on bzr.dev@3059 fails too, midnight bug ?
<vila> and on top of that, I see (when doing bzr missing in my bzr.dev branch) revno: 3061, deprecate bzrlib.revision.is_ancestor
<vila> Ran 9939 tests in 437.020s
<vila> FAILED (failures=1, known_failure_count=5)
<vila> bah, time to sleep anyway, a bit frustrating though
<vila> not failing anymore in bzr.dev@3065... at least....
<lifeless> jelmer: where is bzr-gtk for 1.0 ?
<lifeless> abentley: oh it can have one if you think it should; I was asking the question.
<abentley> Sure, and I've actually decided to move them into versionedfile and merge.
<abentley> Just because there's so much related stuff in those modules.
<jelmer> lifeless: phanatic is doing release management these days, I'll ping him by email
#bzr 2008-11-24
<pygi> jelmer, duck branches :p
<pygi> good work btw
<jelmer> hi pygi :-)
<jelmer> Thanks :-)
<jelmer> pygi: Duck branches ? What does the duck refer to?
<pygi> jelmer, It can swim on water, and it can walk on ground. Users who don't use the plugin see only one branch, and  others can see the whole thing :P
<pygi> bzr duck create
<pygi> bzr duck remove
<pygi> bzr duck [branch] (switches to branch)
<pygi> bzr duck (lists branches)
<pygi> so obviously, argument to create and remove is [branch] too :)
<pygi> o, and bzr duck [branch] asks you if you want to create branch if it doesn't exist
<jelmer> pygi: :-) I like the name
<pygi> jelmer, good, so you'll take it? :p
<pygi> we need to make this bzr thingy more fun, perhaps more people will use it then :D
<pygi> I'm having a hard time convincing O'Reilly that it's worth to do a book on bzr :(
<jelmer> pygi: yeah, I think so
<jelmer> pygi: :-(
<jelmer> what bit is the problem? Are the other books on VCS not doing well?
<pygi> jelmer, actually, they only want to do book on most popular DVCS :/
<pygi> and that is Git ...
<pygi> Andy said that if I can show him that every version of bzr gets downloaded 80000 times per version, he might be able to convince his bosses...
<pygi> but I can't do that, so :P
<pygi> (some other publishers are interested tho ... but O'Reilly is O'Reilly)
<jelmer> Did you look at ubuntu popcon?
<pygi> yup ...
<pygi> 20745 downloads of bzr
<pygi> 41440 downloads of git-core
<pygi> that's 1:2 ratio
<pygi> at debian, ratio is 1:6 ...
<jelmer> a 1:2 ratio isn't that bad, if the downloads are apparently high enough for O'Reilly
<jelmer> *downloads for git
<pygi> I think they have the source tarball download number for git ...
<pygi> not sure
<pygi> but yes, they're doing git book
<jelmer> There's more publishers than O'Reilly out there though...
<pygi> yup, I know
<pygi> already got offer from one, waiting on others
<jelmer> we were pretty happy with PH when we published the Samba HOWTO
<pygi> I don't have any contacts with PH ...
<pygi> So far we've got offer from Packt Publishing, and I think we have good chances with Manning
<pygi> Pragmatic said they'll contact us in two weeks
<pygi> jelmer, if you know someone in PH ... :)
<jelmer> I can check, but I don't think I do anymore
<jelmer> my only contact (our editor) has switched jobs since the book was first published
<pygi> aha, don't worry then ;)
<james_w> nice work jelmer
<chandler1> so bzr is claiming to be unable to load the paramiko module. Is this a known issue, or how could i diagnose it? (bzr from the repo, paramiko v1.7.4)
<james_w> chandler1: does "python -c 'import paramiko'" work nicely?
<chandler1> nope
<pygi> chandler1, sudo apt-get install python-paramiko then?
<chandler1> james_w: ImportError: No module named Crypto.Util.randpool
<chandler1> not on a debian system
<pygi> aha ...
<chandler1> but my package manager says the version is 1.7.4
<pygi> well,whatever the system ..
<pygi> hm.
<pygi> chadmiller, locate randpool
<pygi> chadmiller, tell me what you get
<chandler1> pygi: was that for me?
<pygi> ups, yes chandler1 :)
<chandler1> and if so, no locate, what area would it be in so i can do a relatively fast find?
<pygi> /usr/lib/python2.4/site-packages/Crypto/Util/randpool.py
<pygi> and
<pygi> /usr/lib/python2.5/site-packages/Crypto/Util/randpool.py
<chandler1> ahh
<chandler1> its in 2.4, but not 2.5
<pygi> ok, you're missing symlinks then :)
<pygi> sudo dpkg-reconfigure python-crypto would fix that if you were on debianish system :)
<chandler1> ;]
<chandler1> i'm on gentoo
<pygi> uh xD
<pygi> you know how to do symlink manually then I guess :p
 * pygi hides
<pygi> chandler1, does it work now?
<chandler1> pygi: i know about symlinks... =p
<chandler1> my lack of knowledge centers firmly on python at the moment. =D
 * pygi notes this errors for "Lets troubleshoot" section of the book :p
<chandler1> hehe
<chandler1> apparently there is a nifty tool that may help here, python-updated
<chandler1> python-upder
<chandler1> :: sigh :: spelling ftl
<c0mpub0mb> can you use bzr to push data from a .bzr directory to an svn vise versa ?
<pygi> c0mpub0mb, bzr-svn?
<c0mpub0mb> pygi: do you use bzr-svn ?
<pygi> I used to, why?
<c0mpub0mb> pygi: how do i use it ?
<pygi> chandler1, that tools seems to be used only in gentoo?
<chandler1> pygi: yes, its specifically to help moving modules between python versions
<chandler1> pygi: if it doesn't work, i'll do it manually, or beat on the package manager until its fixed
<pygi> c0mpub0mb, http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id72
<pygi> this might explain it better then me in a sentence or two :)
<pygi> chandler1, oki, please do let me know if it works
<chandler1> it's being slow, surely its doing something productive. ;]
<pygi> :P
<chandler1> lame, didn't work
<chandler1> is this part of pycrypto or paramiko?
<pygi> pycrypto
<chandler1> brilliant, i lied, python-updater worked perfectly
<chandler1> =]
<chandler1> thanks btw, pointed  me at the right spot right off the back
<pygi> how rude, lying :P
<pygi> most welcome
<pygi> what do you think of recently introduce local branches plugin btw?
<pygi> *cough* duck branches *cough*
<pygi> s/introduce/introduced/g
<c0mpub0mb> pygi: does bzr support private repo's with user priviliges ?
<pygi> you could do something with ssh keys, sure
<c0mpub0mb> pygi: so it doesn't have the kind of user control as svn ?
<pygi> you mean authz file?
<pygi> no, it doesn't
<pygi> Adam Olsen is working on a nifty tool that would allow you to have something like that
<pygi> but you'll still require ssh keys
<chandler1> pygi: was that aimed at me? and if so, what local branches plugin?
<pygi> chandler1, yes, at you :)
<pygi> jelmer released a plugin that adds the ability to have git-like branches
<chandler1> pygi: interesting
<chandler1> i'll have to read up on it to give a competent opinion
<pygi> chandler1, oki, its on mailing list
<chandler1> ok
<pygi> c0mpub0mb, any more questions?
<pygi> hi hi fta
<awmcclain> I remember someone in here mentioning to me some tool that allowed me to batch build/upload to different ubuntu releases on launchpad. Did I imagine that?
<james_w> autoppa
<awmcclain> Oh, hooray.
<awmcclain> Thank you.
<awmcclain> bzr-svn: Depends: bzr (< 1.8~) but 1.9-1~bazaar1~gutsy1 is to be installed <----- frowny face.
<pygi> awmcclain, yea, hasn't been updated yet
<jelmer> bzr-svn should probably be removed from the ppa, at least while the package is not maintained
<pygi> jelmer, probably, yes
<chandler1> is bzr-svn no longer being maintained?
<spiv> chandler1: it's quite actively maintained, by jelmer
<chandler1> ok, was confused, prob just the packaging thats not
<chandler1> (a statement by jelmer a couple of hours ago)
<spiv> The packaging is regular irritant, yeah :(
 * jml hands spiv 0x88
 * jml takes that back and passes spiv 0x58
<jml> spiv: use that, or 0x78
<jml> ok, ok.01011000
<spiv> jml: :)
<vila> hi all
<awmcclain> Ug. I'm sorry if this is OT, but I'm trying to get autoppa to work on the console and it's dying when it asks for my passphrase in order to sign the package (since I don't have Seahorse installed). Anyone know how to pre-cache my passphrase using gpg-agent or something?
<awilkins> jelmer: I've had some trouble getting the 0.5 branch of bzr-svn to work ; first, the minor change of having to replace the substitute header file includes. After it compiled though, I am getting errors
<awilkins> http://pastebin.ubuntu.com/76319/
<awilkins> It does mystify me slightly why the plugin is doing anything at all when doing `bzr version`
<Peng_> If your bzr install exists in a branch, "bzr version" will open it up so it can display the basic details. bzr-svn is involved while it's probing to see which format the branch uses.
<awilkins> Peng_: It's not a branch
<awilkins> Neither is the plugin
<awilkins> But that would seem to be the source of the problem
<awilkins> Meh, it seems to be fetching data from a public SVN repo just fine. Trust me to pick the one command that makes it go "bang"
<awilkins> Aha, not the only command that makes it go "bang" then
<awilkins> Same error from a "branch"
<awilkins> It manages to grab the revision metadata
<pygi> jelmer, poke
<matkor> Hi ! How can I get information from bzr update which file exactly it gets "bzr: ERROR: [Errno 13] Permission denied" ?
<awilkins> Patching the source to report it in the traceback or you could use Sysinternals filemon (you seem to be on Windows)
<awilkins> matkor: Vista or XP?
<matkor> linux :)
<hmeland> If it is a local file, strace can help you.
<hmeland> E.g. "strace -e trace=file -o strace.log bzr update" and have a look towards the end of strace.log when that finishes.
<hmeland> There might be a more-to-the-point solution within bzr, though; the strace log will be quite verbose.
<VSpike> Sod's law says which ever machine I have IRC open on, it will be the wrong one
<VSpike> Must install an IRC proxy sometime
<VSpike> Anyways, using bzr shelve in cygwin w/ 1.8 I get "bzr: ERROR: Failed removing shelved changes from theworking (sic) tree!"
<VSpike> Any ideas?  Google did not help me much
<VSpike> http://pastebin.com/m234d816b
<VSpike> I wonder what bzr command it's trying to execute at that point?
<pygi> VSpike, do you have diffutils  installed?
<VSpike> pygi: I definitely have patch.exe .. let me check exactly
<pygi> VSpike, and see if it accepts "--dry-run"
<VSpike> pygi: yep, I have diffutils, patch and patchutils
<VSpike> which, bzr shelve?
<pygi> no,patch
<VSpike> pygi: yes it does
<pygi> do you have binary files?
<VSpike> pygi: "bzr shelf list" shows the patches, and "bzr shelf show 00" shows the contents OK
<VSpike> pygi: these aren't binary files, no
<pygi> VSpike, open shelf.py
<pygi> lets try something ...
<pygi> hm, or rather not
 * pygi thinks
<VSpike> I'm going to have to do it the manual way I think
<VSpike> i.e. just copy the current files to a "saved" dir somewhere and revert :)
<pygi> VSpike, nah, lets figure it out
<pygi> could you paste complete output pls?
<pygi> http://rafb.net/paste
<VSpike> Cos I also realised the changes I need to shelve span a couple of commmits - they are not just in this revision
<VSpike> But yeah could spend a couple of mins on it to investigate if you like :)
<pygi> thanks VSpike :)
<VSpike> So you want me to bzr shelve the file and paste the complete output?
<pygi> yup, obviously :)
<VSpike> http://rafb.net/p/VOwv1b50.html
<VSpike> I just created a simple test case and it works
<VSpike> So it's not universally broken
<pygi> but its broken on certain use-cases...
<VSpike> Wondering what it could be. Doing two files at one? Files not in root? The fact that ~/projects is a symlink?
<pygi> VSpike, well, did you try one file?
<pygi> try it
<pygi> (I know I'm bugging, please bear with me)
<VSpike> Ah, it appears to be the subdirectory
<VSpike> I tested a single file, still broken
<VSpike> I tried navigating to the location without using the symlink, still broken
<VSpike> Tried shelving a change in the root project folder, it works
<pygi> right, so it only allows to shelve what's in the project root...
<pygi> that's evil behaviour...
<VSpike> just testing with my simple test case
<VSpike> Oh
<VSpike> Hm
<VSpike> It works in the test case :)
<pygi> vila, what works?
<VSpike> I created a sub dir, add a file, committed, edited the file, and tried shelving the change
<VSpike> worked fine
<pygi> so hm, whats wrong here ...
<pygi> VSpike, would you be willing to try a little hack?
<VSpike> Could it be because they are sometimes unicode files?
<VSpike> They usually don't contain anything other than a start record
<VSpike> The rest is normally ascii
<VSpike> pygi: I was thinking of editing ~/.bazaar/plugins/bzrtools/patch.py to log/dump command line
<pygi> VSpike, we pretty much know what the command line is
<VSpike> pygi: what were you going to suggest?
<pygi> editing  ~/.bazaar/plugins/bzrtools/shelf.py
<pygi> and change:
<pygi>       if reverse:
<pygi>             args.append('-R')
<pygi> to:
<pygi>       if reverse:
<pygi>             args.append('-R -d=yoursubdir')
<pygi> ergh
<pygi> args.append('-R -d yoursubdir')
<VSpike> pygi: that code is not in mine
<pygi> VSpike, in def _run_patch ?
<VSpike> It's in patch.py
<pygi> ah, ok, patch.py then
<pygi> sorry
<VSpike> yoursubdir is the full path or relative one?
<pygi> relative should work
 * pygi is mostly shooting in the dark, never had this problem :p
<VSpike> Relative from project root I take it?
<VSpike> I wonder if the code should apply --binary on cygwin?
<pygi> VSpike, yup, project root
<pygi> VSpike, I'm not sure if that'd had any effect, considering test case does work ...
<pygi> but you could try patching sources to do it...
<VSpike> yeah, that fixes it :)
<pygi> VSpike, what, the binary thing, or the "-d" ?
<thrope> is there any way to get bzr shelve to show colored diffs? (bzr shelve is a complete revelation by the way - amazingly useful!)
<thrope> why is it called shelve1 though? is there a new shelve2 coming?
<VSpike> thrope: strangely, it does show coloured diffs for me
<VSpike> pygi: the binary thing
<thrope> oh - I saw the no-color option in the help but I don't get colored diffs
<pygi> VSpike, could I now convince you to file a bug, and assign me to it?
<VSpike> Sure. Where do bugs for bzrtools go?
<VSpike> pygi: the reason my test case worked is possibly because I used cygwin tools to create it
<pygi> VSpike, yup, mention all that in a bug :)
<pygi> VSpike, https://bugs.edge.launchpad.net/bzrtools
<pygi> mario-danic
<pygi> thrope, does bzr cdiff works for you?
<thrope> pygi: yep, works fine
<pygi> thrope, what bzr/bzrtools version?
<thrope> bzr 1.9, bzrtools 1.9.1
<thrope> shelve is an alias to shelve1 for me
<pygi> yea, its the old shelve ..
<thrope> how do I get the new one?
<pygi> its in the mainline perhaps?
<pygi> not sure
<pygi> thrope, sudo apt-get install colordiff?
<pygi> but I think you already have that..
<pygi> VSpike, thanks for submitting bug when you do btw ;)
<pygi> and thanks for investigating it
<awilkins> shelve2 is in bzr.dev now I think
<awilkins> I've seen at least a couple of commits for it
<VSpike> pygi: done
<VSpike> Can you check the report contains all you need?
<pygi> VSpike, yes, moment pls:)
<VSpike> #301639 in case your email is slow
<VSpike> no probs - going to go back to doing what I was doing before :)
<pygi> VSpike, have fun ;)
<pygi> VSpike, ah, you have bzr 1.8 ... perhaps that's why you still have colored shelve
<pygi> VSpike, bug report is perfect, thank you :)
<VSpike> pygi: yeah, cygwin always seems to lag a version or two
<VSpike> pygi: yw
 * pygi goes back to sleeping :p
<VSpike> Not sure why the patch command works without --binary in one direction and not the other
<VSpike> And also not sure why it passed on another windows generated file when I tested it
<pygi> VSpike, this is a pretty safe-failover I'd say, so we don't have to break our heads on it :P
<VSpike> pygi: agreed, it's the right thing to do anyway, I think
 * pygi nods
<VSpike> I hate thinking about line endings in cygwin anyway.  I just close my eyes and hope it works, mostly
<pygi> VSpike, its a pretty rare bug ...
<pygi> only two known occurances so far
<VSpike> probably worth grepping the source for other cases where sys.platform is tested against win32 and not cygwin and checking they are correct
<VSpike> Oh, while your about it, can you fix the missing space in the error message? :)
<VSpike> s/your/you're/
<pygi> sure sure
<VSpike> hehe thx
 * pygi writes that down somewhere
<VSpike> echo "TODO: fix space in error message" > /dev/null ;)
<pygi> :p
<VSpike> it's the only task manager you need
<pygi> my head still serves me, so I'm fine :p
<pygi> ok, can I  go to sleep now or is there anything else I can help you with? :)
<VSpike> Nope, sleep away :) Thanks for the help
<pygi> no,thank YOU!
<pygi> laters
<pygi> awww
<pygi> awilkins, poke
<pygi> awilkins, no, no own implementations of pull/push/whatever
<pygi> bzr can only access branches that are url-addressable
<pygi> awilkins, we can probably do a workaround for it to work on Win once its more then proof of concept
<pygi> awilkins, third, as jelmer said, plan is to move infrastructure for it in core
<pygi> awilkins, and what do you have against ducks? :p
<markh> I find they keep acting like a goose! ;)
<jelmer> pygi: hi
<jelmer> awilkins: hi
<markh> py23
<markh> oops :)
<jelmer> awilkins: still there?
<jelmer> hi markh :-)
<markh> hi jelmer :)  You've been busy :)
<jelmer> I was a bit disappointed by how little work the local-branches stuff was
<jelmer> It's less then 200 lines of code, so I regret not writing it earlier
<markh> heh - everything seems so much simpler the more experienced you get at doing it :)
<pickscrape> jelmer: can you create local-branches of remote branches, if you know what I mean?
<jelmer> pickscrape: not directly
<pickscrape> That would be useful. You could then add a command to allow you to 'pull-all' or similar.
<jelmer> pickscrape: You'll get that for free once this is all a bit more integrated in the bzr core
<jelmer> (including pulling of multiple branches)
<pickscrape> sweet :)
<jelmer> it'll require a new bzrdir format though, so that means upgrading existing bzrdirs
<awilkins> jelmer: Hi
<jelmer> awilkins: you were having trouble building 0.5 ?
<awilkins> jelmer: I had to put back stdbool.h
<awilkins> (the included one)
<awilkins> jelmer: After that it builds, but doesn't work for me
<awilkins> Did you get the trace off the pastebin
<jelmer> awilkins: We should probably fix the include path instead to use subvertpy
<awilkins> jelmer: Yes, that would work (pardon my complete C-noobness)
<awilkins> I tried to learn C when I was a teenager but the lack of cheap textbooks and no internet rather killed that before it started
<jelmer> awilkins: do you perhaps have subvertpy installed manually as well?
<awilkins> jelmer: I think I used the script but I had to copy the pyd files manually
<awilkins> I'll check and see if there is an egg-info
<jam> speaking of jelmer... how much do you know about the FTP spec? It seems our FTP "readv" support is basically just read the whole file and extract the bits we need.
<jam> It might be nice to actually use whatever partial-read support is available from FTP
<jelmer> jam: Yeah, that seems to be the main downside compared to sftp atm :-(
<jam> which is a rather large one :)
<jelmer> awilkins: the pyd files should end up in bzrlib.plugins.svn.subvertpy, not in subvertpy at the top-level
<awilkins> jelmer: Ah, so subvertpy shouldn't be a package on it's own then
<awilkins> I just tripped an assertion in 0.4 as well
 * awilkins is a pita
<CardinalFang> Hi all.  How can I find the revision where a file was removed?
<awilkins> CardinalFang: You have to run the whole log in verbose mode to do so
<awilkins> You must be the 4th person to ask in here at least
<awilkins> Someone put it in the FAQ!
<CardinalFang> :)  I am asking as the proxy for someone else in my org.
<CardinalFang> Maybe there are others here.
 * CardinalFang waves!
<CardinalFang> I don't suppose "-m FN" will work.
<awilkins> CardinalFang: I don't think so. It's fairly easy to modify the log command to list the revisions a file participates in if you know it's file-id, but alas, deletion is now one of the ways a file particicpates in a revision due to the way that invent
<awilkins> ories work
<awilkins> *not one of the ways
 * CardinalFang writes some sed to print the log.
<verterok> hi
<verterok> is there any problem in rich-root -- push -->  non-rich-root?
<LarstiQ> verterok: yes, there is
<verterok> LarstiQ: it can be done? or is a one way conversion?
<jelmer> verterok: can't be done
<verterok> jelmer: LarstiQ: thanks a million!
<jelmer> LarstiQ: While you're here... I'm considering adding /etc/init.d/bzr file to start the readonly smart server
<jelmer> does that sound sensible?
<LarstiQ> jelmer: what will it read from?
<LarstiQ> jelmer: And I'd disable starting it by default.
<LarstiQ> jelmer: other than that, I'm missing context :)
<jelmer> LarstiQ: yeah, it would require some variables in /etc/default/bzr
<jelmer> (directory to share and enable/disable)
 * LarstiQ nods
<LarstiQ> jelmer: how about when people want to share multiple directories? SOL?
<jelmer> They'd just have to add symlinks/bind mounts inside the directory they're sharing
<LarstiQ> does that work? :)
<jelmer> there's only a single namespace anyway
<jelmer> bind mounts definitely work, not sure about symlinks
 * LarstiQ is thinking of branches symlinked into that namespace, and their repository being outside of it
<LarstiQ> I'm rather sure that would break
<jelmer> yeah, that would definitely break
<LarstiQ> hmm, maybe wait till that happens and then note it
<LarstiQ> jelmer: what protocols would it be reachable on?
<jelmer> LarstiQ: just bzr://
<jelmer> it'd just run "bzr serve ..."
<LarstiQ> hmja
<LarstiQ> jelmer: if it's disabled by default, why not
<LarstiQ> jelmer: svn-push is the right command to use to push a new branch, right?
<jelmer> LarstiQ: yep
<jfroy|work> jelmer: morning
<jelmer> jfroy|work: hi
<jfroy|work> So my patch has allowed me to bypass the bad properties (which I cannot remove) by globally changing the bzr-svn prefix. That's a hack of course, but the next course of action would be to add a new property, bzr:prefix-override, which could be set on the root directory of an svn branch, which bzr-svn would read first and act accordingly. Or perhaps it would be better to have that as a repository option in subversion.conf for example.
<LarstiQ> jelmer: you might need more information for #301763 ?
 * LarstiQ goes home
<jelmer> LarstiQ: can you perhaps print the variables in that assert?
<LarstiQ> jelmer: sure
<LarstiQ> jelmer: except, I shut down that machien leaving work, and from another machine I don't get the assert (still diverged branches though)
<jelmer> LarstiQ: any particularly interesting messages in ~/.bzr.log ?
<LarstiQ> jelmer: hmm, Guessed repository layout: TrunkLayout(0), guess layout to use: CustomLayout(['branches/spitfire/spitfire5'],[]) maybe
<Peng_> Bundle Buggy's queue has gotten a bit long.
<LarstiQ> jelmer: after that, it's just the DivergedBranches error
<mwhudson> 'pull -d' is awesome
<mwhudson> more commands should support -d though
<LarstiQ> yes, they should
<LarstiQ> although I'm not sure what `bzr init -d a b` would do
<mwhudson> i think that init and init-repo can probably get away without it
<mwhudson> (i guess init -d a b should create a branch at b/a?)
<mwhudson> um a/b
<LarstiQ> I suppose so
<mwhudson> but i don't think it's a good idea :)
<LarstiQ> mwhudson: any other commands that should not have a -d?
<mwhudson> LarstiQ: actually, further to init, it's not really clear how it would interact with commands that also take a relpath
<mwhudson> like 'add'
<mwhudson> or 'revert', which is actually what i wanted it for
<mwhudson> i don't think 'alias' needs it ;-p
<LarstiQ> haha :)
<LaserJock> anybody know if it's possible to see if a branch has been updated (i.e. there's something to pull) without doing a pull?
<pickscrape> bzr missing
<LaserJock> pickscrape: thanks
<LaserJock> now I need like muli-missing :-)
<LaserJock> *multi-missing
<dwt> hey guys, I'm trying to find the equivalent of "hg addremove" in bzr - that is autodetecting a file move
<dwt> but I don't seem to be able to find the right keywords for google and the help system :/
<jelmer> I think there was a plugin that can do that
<LarstiQ> dwt: what exactly does addremove do?
<LarstiQ> you could just `bzr add`, but then it wouldn't actually store a move
<LarstiQ> just a remove and an add
<dwt> well the thing about addremove is that it autodetects any moves that did happen
<dwt> which it can also do based on similarity (configurable) and in a demonstration mode so one can see what it detected but it doesn't record it in the repo
<LarstiQ> right
<luks> dwt: http://bzr.oxygene.sk/bzrbrowse.cgi/bzr-plugins/automv
<luks> it works only for files, though, not directories
<dwt> well thats a start
<dwt> thanks
<Peng_> Ooh, my weird error pulling one branch has changed to a "delta references to items not in its repository" one. ...How do I solve that?
<rockstar> Wow.  There's a REALLY good article on bzr in Python Magazine this month.
<jelmer> LarstiQ: were any properties changed in the revision that went kaboink?
<LarstiQ> jelmer: only bzr revisions set by svn (the pushed revisions never existed in svn before)
<dwt> Uhm, another quick question: my autocompletion doesn't seem to work in "bzr shell" anymore
<dwt> is there a new configuratio option that I need to turn on?
<mamatat_> hi do people use rpush? i just tried push-and-update and you need to type password 3x each push :S
<LarstiQ> mamatat_: I doubt it.
<LarstiQ> that is, I doubt people use it.
<mamatat_> what rpush?
<LarstiQ> mamatat_: I think it's likely it asks often :)
 * LarstiQ nods
<hiredman> uh
<mwhudson> what is rpush?
<hiredman> passwords? people still use those?
<jelmer> mwhudson: rsync-based push
<jelmer> IIRC
<mwhudson> oh right
<mwhudson> i thought that was rspush
<derekS> so i think i know the question (and i htink i have asked before), but i just want to be sure. Is there any current way to branch a subfolder of a bzr branch?
<dwt> I'm not getting this, there should be autocompletion in "bzr shell" right?
<dwt> the documentation seems to mention it - but whenever I type a "tab" it just shows up verbatim
<dwt> I'm on mac os x
<dwt> is this maybe a known bug?
<bob2> derekS: bzr split, but it won't save you any space (the branch will contain the history of the whole original branch)
<derekS> bob2: but logically it will make more sense right?
<bob2> does os x include readline?
<derekS> bob2: i don't have big repos, i use this as a personal system. I write tons of scripts for work and I modify them a lot, to the point where i ahve to  versions
<derekS> *multiple versions
<poolie> jelmer: could you merge the fix attached to bug 215674, since you gave it a tweak?
<ubottu> Launchpad bug 215674 in bzr "uncommit needs an option for saving commit messages" [Medium,Confirmed] https://launchpad.net/bugs/215674
<jelmer> poolie: sure, I'll have a look
<jelmer> lifeless: hi
<jelmer> poolie, lifeless: I'm still looking for feedback about https://lists.ubuntu.com/archives/bazaar/2008q4/049564.html; some quick comments about it would be really appreciated.
<poolie> i'll look
<poolie> done
<jelmer> poolie: Thanks!
<poolie> np
<poolie> i'd be interested to hear (maybe in the branch mixin rfc thread) about what would make our base classes easier to derive from
<jelmer> I'll reply there as well, but in short: it's already very easy to derive from the base classes
<jelmer> it would be nice to have get_inventory_xml() / get_revision_xml() and the like be specific to BzrBranch
#bzr 2008-11-25
<poolie> ok
<lifeless> jelmer: hi
<meoblast001> why isnt the bzr server at launchpad.net working
<mwhudson> it's not?
<indigo> is there a command to pull uncommitted changes from one working tree to another?
<indigo> say i started to make some changes and decided i should have made a branch
<indigo> my memory says yes, but not enough to find it in the docs.
<bob2> merge can
<bob2> you could also 'switch' that working tree to a branch
<beuno> bzr merge --uncommitted
<indigo> that's the one
<indigo> thanks
<Spaz> o_O
<Spaz> /usr/lib/python2.6/site-packages/Crypto/Hash/SHA.py:6: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
<Spaz>   from sha import *
<Spaz> /usr/lib/python2.6/site-packages/Crypto/Hash/MD5.py:6: DeprecationWarning: the md5 module is deprecated; use hashlib instead
<Spaz>   from md5 import *
<Spaz> with bzr
<Spaz> has this been fixed yet?
<spiv> Spaz: I think so; certainly bzr.dev seems to try hashlib first.
<mwhudson> Spaz: that looks like a problem in pycrypto, not bzr
<Spaz> huh
<spiv> mwhudson wins today's prize for reading comprehension
<spiv> Arguably bzr should be suppressing all DeprecationWarnings.
<spiv> They aren't much use to end users, they're really messages to developers.
<spiv> So it'd be reasonable for "bzr selftest" to report them, but maybe nothing else should.
<spiv> (unless you look in ~/.bzr.log or pass a -Ddeprecations flag)
 * spiv finishes for the day
<vila> hi all
<poolie1> hello vila!
<vila> hi poolie ! I thought you were already gone in vacations...
<poolie1> i was yesterday, but just for one day
<vila> haaaa, ok
<schizoschaf> is there a book on bazaar?
<bob2> no
<AfC> Is somebody working on a book on bazaar?
<noodles_20> AfC: not that I'm aware of.
<loxs> hello folks, does bazaar provide a way for customized user permissions, like this is possible with svn?
<AfC> loxs: Execute bit has been supported since the beginning.
<AfC> loxs: are you looking for more than that?
<spiv> loxs: you mean access control on the repository itself?
<AfC> spiv: (oh, right)
<loxs> yes. the central one... I want to be able to give various users permissions to only commit code to a particular directory/file
<spiv> loxs: the simplest solution is to use ordinary user accounts and filesystem permissions to restrict write access per branch. (or per project, if you use a shared repository per project, as is common.)
<spiv> loxs: depending on what you're looking for, you *might* be interested in using a tool like PQM (https://launchpad.net/pqm) as a gatekeeper that vets commits to a central branch, e.g. to make sure all commits pass "make check"
<spiv> loxs: I don't know of any out-of-the-box ways to restrict write access of just particular directories/files within a branch.  You could probably configure or extend PQM to do something like that, if PQM's workflow suits your use case.
<spiv> loxs: but it'd probably be simplest to make separate branches for those parts of your tree, and use regular filesystem permissions.
<spiv> If commits to the central branch are exclusively done over bzr+ssh, you could write a plugin for the server that installs a pre_change_branch_tip hook function to vet the commit.
<spiv> While a server-side pre_change_branch_tip hook should work well in theory, I don't think there's much infrastructure to make writing those sorts of hook functions convenient yet.  (it's not well documented how to write a hook function that gets a list of files that are touched by the proposed revision, for instance)
 * spiv -> bed
<loxs> thanks folks
<lfaraone> hi, what's the difference between branch and checkout?
<luks> lfaraone: the commands or the terms in general?
<lfaraone> luks: both.
<luks> let's start with the terms first, then :)
<luks> a checkout is the area you work with, it's basically the working tree with some local metadata
<luks> every checkout is linked to a branch, and this branch can be either local or remote
<luks> so that if you commit the working tree, it will update the linked branch
<luks> and it's also possible to have 'bound branch', which is a branch that will update another remote branch on commit
<lfaraone> ah.
<luks> so, when you run 'bzr checkout --lightweight', it will create a local checkout bound to a remote branch
<lfaraone> Now a more practical question: I'm trying to do work on a svn branch, but it has 6959
<lfaraone> revisions, and this is over ssh. can I check out the most recent rev?
<luks> and 'bzr checkout' will create a local checkout, local branch and the branch is bound to another remote branch
<lfaraone> s/branch/repo/
<luks> with bzr-svn?
<lfaraone> luks: yeah.
<luks> then just 'bzr branch svn+ssh://host/path/to/svn/repo'
<luks> (or whatever is the scheme svn uses for ssh named)
<lfaraone> luks: I don't want to download the complete branch history, I only need the most recent rev.
<lfaraone> luks: it's going to take an age that way.
<luks> lfaraone: you can try 'bzr checkout --lightweight ...', but I doubt it will be any faster
<luks> lfaraone: or just use svn, if you don't intend to commit to it :)
<lfaraone> luks: heh...
<luks> bzr-svn needs to know the metadata about the whole history
<luks> so at minimum that needs to be downloaded
<luks> how do you want to use bzr with no history, though?
<Tak> why is it that sometimes I can just pull, and other times I have to pull and then update? (for source-level changes to be reflected in my working branch)
<jelmer> that should only happen if you are pulling into a remote branch
<jelmer> or if "bzr pull" crashes
<Tak> does it make a difference if I'm using bzr-svn?
<jelmer> no
<Tak> how about olive?
<jelmer> You use olive to pull, you mean?
<Tak> yes
<Tak> well, in this latest instance
<jelmer> perhaps it's a bug in olive then
<Tak> I've had it happen before as well; can't remember whether I used olive on the previous occasions or not
<loxs> is there a way to tell bzr to "destructively" update my working tree? I mean, overwrite all the conflicts with the upstream branch?
<luks> working tree or branch?
<loxs> working tree.... I don't want any conflicts. I just want to synchronise with the upstream branch
<luks> what command did you run?
<luks> (that produced the conflicts)
<loxs> bzr up
<luks> oh, I don't know then
<loxs> I had changed files and I don't want the changes
<luks> I think just bzr revert should do the job, but I don't use checkouts much, so Im not sure
<loxs> ah, you are right
<loxs> thanks
<jelmer> asabil: hi
<asabil> hi jelmer
<jelmer> asabil: What happened to your "branch description" patch?
<jelmer> Did it make it in?
<asabil> I don't remember so
<asabil> that was over a year ago
<asabil> the main issue was that it was handled in the same way as branch nicks at that time
<jelmer> nm, just found it: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C6b4de4d80709132323o2c9603ebscce92c066f473919%40mail.gmail.com%3E
<asabil> :)
<jelmer> looks like it's mainly waiting for formatting fixes
<jelmer> do you intend to finish it?
<asabil> jelmer: well I cannot promise anything
<awilkins> slashdot.org
<awilkins> oops
<jam> vila: ping
<vila> jam: pong
<jam> How's it going?
<vila> fine :)
<jam> I BB:tweak'd your --forward patch
<jam> And was wondering what you thought of the feedback
<vila> About to call it a day, but deep into content conflicts while a bug bzr check is sucking my CPU cycles :)
<vila> s/bug//
<vila> Just a sec
<vila> "direction" into 'get_view_revisions': I agree with your doubts, but the results are correct...
<jam> as long as you have tested it directly I'm happy enough with that
<jam> I can see how it would work because of the "by-depth" stuff
<vila> but still, reverse_by_depth make heads explode when coding _:?
<vila> otherwise, full agreement with the other remarks and thanks for catching them !
<vila> This is where review rocks IME, you hack-hack-hack and the result becomes clearer... for the reviewer :)
<vila> anyway, thanks for the review, I'll recheck filter_revisions_touching_file_id before submitting (playing with it right now for another need :)
<loxs> is cygwin the only way to allow windows machines to connect to bazaar repositories vie sftp?
<loxs> or ssh+bzr
<jam> no
<jam> loxs: If you have 'paramiko' installed we don't need cygwin at all
<jam> (and it is bzr+ssh, for what it's worth)
<jam> The standalone win32 installer should include paramiko
<jam> Available here: https://edge.launchpad.net/bzr/1.9/1.9
<jam> or as a direct link: http://edge.launchpad.net/bzr/1.9/1.9/+download/bzr-setup-1.9.exe
<Tak> is bzr-svn part of the windows installation now?
<noodles_20> Any bzr people who knows how to restore a branch when seeing "Supplied history does not follow left-hand parents" errors? splodge has a question on #launchpad...
<jam> noodles_20: 'bzr reconcile' fixes it (albeit it also tries to fix a bunch of other stuff at the same time). I think you can also "bzr push --overwrite ." to have the local branch clean itself up. Though it also sounds like it is an older format branch, so "bzr upgrade" may be recommended.
<noodles_20> thanks jam.
<Tak> splodge: are you the same splodge from UDC forums?
<splodge> Yep
<Tak> sweet!
 * Tak <=
 * splodge feels popular all of a sudden.
<jam> Tak: it should be in the newer installers, yes
<jam> (only the all-in-one installer, not the "install into an existing python install")
<Tak> I'll give it a try, then - I've been sitting on bzr 1.4 because that was the latest one with a bzr-svn installer
<jam> I think 1.7 has it, but I'm sure that 1.9 does as well
<Tak> bzr-svn does indeed appear to Just Work with the 1.9 win32 standalone installer
<derekS> has anyone ever seen this error: UnicodeEncodeError: 'ascii' codec can't encode character u'\xae' in position 103: ordinal not in range(128)
<derekS> i am trying to pull
<jam> derekS: Presumably you are updating to a revision which now includes a non-ascii character
<jam> but your system claims that the filesystem doesn't support it.
<jam> derekS: As part of the exception, I would expect us to report what we think fs_enc is
<jam> do you see that line?
<jam> I believe I've also seen at least something similar when fs_enc is UTF-8, but you have a file that is in latin-1 encoding
<jam> we fail because we can't understand the filename, as it isn't actually valid given your fs_enc
<derekS> jam: checking
<derekS> not seeing it, i lost it in the scroll buffer when i looked at the bzr.log
<derekS> let me try to pull it again
<derekS> btw this is the cygwin build
<derekS> version 1.8
<synic> how can you tell what repository is being accessed in a hook?
<jam> derekS: cygwin only supports ASCII, so we can't add support for anything else on top of it
<jam> I think there are some random patches out there to update cygwin to support utf8
<jam> My suggestion would be to use the windows native build
<jam> It is significantly faster because it doesn't go through the cygwin overhead
<jam> (bzr status is 2s for me under cygwin, and 0.5s using the win32 native client)
<jam> I generally use cygwin as a shell, and normally don't have problems running native bzr at the same time
<jam> The only problems are when I would type ~/path/from/home since that breaks between win32 native and cygwin
<mwhudson> synic: usually the hook takes arguments that let you find out, which hook are you interested in?
 * mwhudson grrs at bzrlib's docstrings
<synic> mwhudson: post_psuh
<synic> er.. push
<mwhudson> synic: well push_result.source_branch.repository ?
<mwhudson> as in http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#hooks
<synic> thanks
<asac> hi. bzr-svn + authentication? is there any trick to make that work?
<synic> a post hook is supposed to run on the server if the connection was started with bzr+ssh, right?
<synic> er,, a post_push
<synic> I can't seem to get this one to work
<mwhudson> i think post_push is a client side hook
<synic> hrmm
<mwhudson> post_change_branch_tip runs on the server though
<mwhudson> (pre_change_branch_tip too)
<synic> alright
<loxs> is there any problem if I use one repository to store branches from different projects?
<hsn_> loxs: no
<loxs> hsn_, so then it's ok if I give all my developers their own repository, and they can store all their branches from all our projects in that repository?
<hsn_> loxs: yes. just `bzr check` operation takes some time on large repos
<loxs> thanks
<synic> mwhudson: when printing branch.repository, I get KnitPackRepository('chroot-166445772:///send-admin/.bzr/repository/')
<synic> how can I programatically get the "send-admin" from it?
<mwhudson> um, i guess from repository.transport.base
<mwhudson> (which i think will be the string 'chroot-166445772:///send-admin/.bzr/repository/'
<mwhudson> then parse it as a url, take the path and strip .bzr/repository off it
<mwhudson> synic: but mostly educatedly guessing here, not really sure
<synic> yeah, that works
<synic> but I have to use repo._transport
<Kobaz> is there a way to combine all your local branch commits into one commit, before doing a push
<mwhudson> Kobaz: well, i guess you can merge your new commits onto a fresh copy of the push target before you push
<Kobaz> that works
<phoenix3051> Is there away to limit the amount of bandwidth bzr using when branching across a network?
<poolie> jam, spiv, call in a minute?
<pygi> hi hi
<synic> anyone about?  I've written a plugin to limit who can access a repository via bzr+ssh.  Right now, an exception is thrown (errors.PermissionDenied) if the user doesn't have access, but it creates an InternalError on the client side
<synic> is there a way to tell the server just to send something like: bzr: ERROR: Not a branch:
<mwhudson> synic: _usually_ a permissiondenied on the server side is correctly translated to one on the client side (these days)
<mwhudson> synic: can you pastebin the client side traceback?
<synic> yeah
<synic> http://rafb.net/p/bLjMHZ58.html
<mwhudson> synic: maybe check with spiv, but it looks like a bug
<synic> well, it accomplishes the goal, but yeah, it does appear to the user as a bug within bzr
<synic> and asks them to file a bug report
<synic> probably because of how I designed the plugin
<mwhudson> synic: you might also want to try with a newer bzr client
<mwhudson> there have been related bugs fixed since 1.6.1 i think
<synic>  ah.
<synic> well, all in all, though, that gitosis port works.
<mwhudson> cool
<spiv> synic: I'm pretty sure bzr.dev (and probably 1.9) will handle that better.
<synic> yeah, trying it now
<synic> bzr: ERROR: Permission denied: "test": : You do not have read access for this repository.
<synic> yeah, that looks tons better
<mwhudson> cool
<synic> thanks :)
<slangasek> jelmer: have you had any luck yet with that bzr-svn bug (grub merge)?
<spiv> synic: you're welcome :)
<synic> man, the bzrlib code is so cool ... compared to what I'm used to reading anyway.  Hah.
<mkanat> After a cvsps-import, I'm getting: bzr: ERROR: Revision {('cvs-1:lpsolit-20081021203555-abgb5fh0dqaorsib',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0xb797eb6c>".
<mkanat> What's up with that?
<mkanat> Anybody? :-) jam?
<mkanat> I also get: /usr/lib/python2.4/site-packages/bzrlib/lockable_files.py:110: UserWarning: file group LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///home/mkanat/cvs-import/selenium-import/bzr/selenium/.bzr/repository/>) was not explicitly unlocked
<nekohayo> ping, lifeless?
#bzr 2008-11-26
<poolie1> mkanat: the warning is harmless
<poolie1> mkanat: is that an imported branch on launchpad, or elsewhere?
<mkanat> poolie1: Yeah, I figured.
<poolie1> nekohayo: he's away this week probably
<mkanat> poolie1: I imported it locally. The problem seemed to be that I was importing into a rich-root-pack repo.
<mkanat> poolie: When I used the default repo type instead, it worked.
<mkanat> poolie: It also could have been some old bug, since it was bzr 1.5.
<poolie> ok
<nekohayo> poolie: .... this "week"?! he leaves IRC on for weeks on end? :)
<nekohayo> oh well too bad I guess
<jelmer> asac, hi
<jelmer> asac, authentication should work out of the box with bzr-svn
<jelmer> asac, http or https authentication doesn't work with bzr itself, so you may have to specify "svn+http://" or "svn+https://" to get it to bypass the standard bzr http transport.
<asac> jelmer: oh. cool. thank you!
<grettke> Hi. You guys had any luck running a bzr smart-server on Vista?
<spiv> AFAIK the TCP server works fine.  I think I recall hearing about someone using it over HTTP with NTLM auth at some point, I'm not sure which version of Windows though.
<grettke> Thanks. Strangest thing, Vista seems to be blocking the smart server. It allows Perl echo servers to run, and I can access bzr locally, but it doesn't show up over the netwoek. It is Vista that is doing something weird.
<spiv> grettke: try explicitly using the external IP address in the --port argument?  e.g. --port 1.2.3.4:4155
<grettke> spiv: Will do.
<grettke> spiv: That does it. Why is this necessary? There is something with which I am not familiar because it didn't occur to me to bind it in that manner.
<AfC> (is that the IPv6 bug again?)
<AfC> grettke: (we had to do that, but in our case it was a problem of `bzr serve` not starting (blowing up) and this forced it to think of the address as IPv4 only which made it work right)
<spiv> grettke: good question, it might be to do with IPv6
<spiv> Or it might be that passing None as the host to Python's socket.listen method is choosing the wrong interface for some reason.
<spiv> grettke: it might be related to https://bugs.edge.launchpad.net/bzr/+bug/293697
<ubottu> Ubuntu bug 293697 in bzr "bzr serve shows error TypeError: not all arguments converted during string formatting" [High,Confirmed]
<AfC> grettke: (this was on a Linux server, so even more tangential to what you're asking about)
<spiv> Hmm, actually, I don't think that's the bug I was thinking of.
<spiv> Ah, https://bugs.edge.launchpad.net/bugs/286871 is what I was thinking of.  That's also what AfC is referring to.
<ubottu> Ubuntu bug 286871 in bzr "IndexError raising CannotBindAddress error starting bzr serve" [Medium,Confirmed]
<grettke> spiv, AfC, ubottu: I had pretty much ruled out the router, the switch, the other computer, and even bzr since I can access from the server box itself, just not other computer; the last thing about which I wondered was whether or not I should disable IPv6 completely on the card.
 * AfC {chortle}s at the addressee list in the above line
<AfC>  grettke: I imagine you can just specify a 4 byte IPv4 address as Andrew suggested and move on. I haven't the faintest whether Microsoft uses IPv6 internally in its operating system (if it did, then turning it off might make things go splat) or for the E.T. phone home "feature".
<grettke> Thanks everyone, now I can sleep well again; this has been a thorn in my side I tell you!
<spiv> grettke: you could try --port 0.0.0.0:4155 to further narrow down what's going wrong.  If that works, it suggests that it's trying an IPv6 address.
<spiv> grettke: if it doesn't, it suggests for some reason passing None as the host is causing it to bind to the wrong interface (or perhaps simply that it's not binding to all interfaces).
<spiv> grettke: either way, a bug report with the details would be good I think.
<grettke> spiv: That does work: bzr serve --port 0.0.0.0:4155
<grettke> spiv: Will do.
<grettke> bye guys
<mtaylor> help? "bzr: ERROR: [Errno 14] Bad address"
<mwhudson> mtaylor: that's a new one
<mtaylor> mwhudson: well that's not what I want to hear . :(
<mwhudson> mtaylor: what were you doing?
<spiv> mtaylor: which version?
<spiv> mtaylor: and which OS?
<mtaylor> mwhudson: I get it doing just about anything - bzr diff , bzr commit
<mtaylor> spiv: opensolaris
<spiv> mtaylor: I think this may be a bug that was recently fixed in bzr.dev
<mtaylor> and version is...
<spiv> mtaylor: ah, yep, then it probably is that bug.
<mtaylor> spiv: 1.9
<mtaylor> ok
<mtaylor> phew. I'll just update then
<mwhudson> oh, the chdir('') one?
<mwhudson> that makes sense
<spiv> mwhudson: right
<spiv> mtaylor: https://bugs.edge.launchpad.net/bzr/+bug/297831 if you're curious
<ubottu> Ubuntu bug 297831 in bzr "EADDR inside pyrex readdir on x86 Solaris" [Medium,Fix released]
<spiv> mtaylor: a workaround would be to delete the _readdir_pyx.so, although that will impact performance a bit
 * spiv heads off
<mtaylor> nah. I'm running a pre-release version of opensolaris anyway - I might as well upgrade bzr to bzr.dev :)
<mtaylor> spiv: thanks!
<spiv> mtaylor: :)
 * mtaylor stabs solaris in the face
<vila> hi all
<GPHemsley> (fullermd:) What's the deal with the new repo format, 1.9?
<Peng_> What about it? It has a faster and more space-efficient index format.
<GPHemsley> How would I use it?
<GPHemsley> Is there documentation on it somewhere?
<Peng_> If you don't need your repo to be compatible with bzr 1.8 or earlier, you'd run "bzr upgrade --1.9".
<GPHemsley> Peng_: And how is 1.9 better?
<Peng_> GPHemsley: Like I said, it uses a smaller and faster index format.
<Peng_> GPHemsley: If your project is pretty small, it probably won't make a huge difference.
<loxs> hello, is there any installer that has "everything included" to install bzr with everything needed to be able to access ssh+bzr repositories from windows?
<Peng_> Can't the Windows installer do that?
<Peng_> Though you might want to install putty anyway.
 * Peng_ leaves. Sorry, but I don't know much about Windows anyway.
<loxs> well, I installed bzr and it tells me that ssh+bzr is illegal protocol
<luks> sounds like a serious bug in the installer
<loxs> is it possible the reason to be that I previously had python installed?
<loxs> well, I uninstalled python and installed a "fresh" copy... and it still can't connect to ssh+bzr repositories
<loxs> I installed the latest version from 1.7 series. Now it doesn't tell that it's illegal protocol, but the connection times out
<loxs> and there is no networking problem, because I can connect via putty without any problems
<loxs> same with 1.8 series :(
<loxs> OK, it's possible I'm doing it wrong
<loxs> is bzr co bzr+ssh://user@some.address.com/some/directory/ valid syntax?
<loxs[]> luks, any idea?
<luks> loxs[]: yes, it's a valid syntax
<luks> no idea about the problem though
<luks> it would be probably useful to file a bug report
<loxs[]> yes, now I'm searching for a similar thing
<loxs[]> the problem is that I can't provide any useful information :)
<loxs[]> and I am not sure that something is not wrong with my settings
<loxs[]> my windows I mean (i have no windows knowledge)
<Odd_Bloke> poolie1: lifeless: My ~bzr membership is about to expire, the emails keep telling me to poke one of you about it. :)
<matkor> What it means:  Contents conflict in <file> ?
<matkor> How can I resolve it ?
<matkor> ah bzr mv ...
<skam> hi everyone
<spiv> matkor: "bzr help conflicts" might be helpful
<skam> i have to "split" a bazaar repository into three parts: a big repository should be split into three smaller ones (due to some changes in our company). is this possible?
<vila> skam: If your big repositories contains 3 independents projects, yes. You can create one repository by project, and pull all project branches in their specific repo
<vila> s/big repositories/big repository/
<ras0ir> im using ftp (vsftpd) to push, however .bzr dir umask is shown as "drwx------", and i cannot clone because of "bzr: ERROR: Transport error: Server refuses to fulfill the request (403 Forbidden)" message.
<fta2> hiredman, any plan to update bzrtools in jaunty ? bzr is stuck to 1.6.1 instead of 1.9 because of this.
<fta2> hiredman, nm
<fta2> i meant "hi," (damn xchat)
<jelmer> fta2: iirc James had requested a sync for bzrtools as well
<james_w> nope, I forgot
<james_w> looks like we need bzrtools and bzr-gtk, anything else?
<fta2> bzr-builddeb is stuck too
<vila> jam: ping
<james_w> fta: stuck?
<fta2> well, i mean, upgrading bzr removes bzr-builddeb and bzrtools
<james_w> ah, ok
<james_w> that will take an upload, need to check that it works first though
<fta2> thanks
<quicksilver> is there a more recommended protocol than sftp these days?
<fta2> bzr+ssh
<quicksilver> does that work better over slightly higher latency links?
<quicksilver> fresh branch checkouts are a bit painful over adsl.
<LarstiQ> bzr+ssh has 1/3rd the roundtrips of sftp
<LarstiQ> quicksilver: so you'll notice with high latency links
<quicksilver> excellent.
<quicksilver> Hmm, well bzr+ssh is making much more substantial use of my network connection, but it's not saying much while it does it.
<quicksilver> no funky progress bar
<jelmer> yeah, progress reporting sucks a bit atm :-/
<quicksilver> sftp was 14 minutes to check out 604 revision, 70 megabyte repo
<quicksilver> bzr+ssh was 2 minutes 40 seconds.
<quicksilver> woot :)
<vila> LarstiQ: hi ! Where did you get that 1/3rd ?
<LarstiQ> vila: here from what lifeless has said, I suppose
<vila> ok, it's for bzr branch without shared repos I presume then
<LarstiQ> I think so, yes.
<vila> For a split second I thought you had implemented some effort tests to compare sftp vs bzr+ssh without telling us :-)
<LarstiQ> no no, sorry :)
 * LarstiQ goes to his mom for dinner, ciao
<Dvyjones> How do I set up bzr for launchpad?
<Tak> set up?
<Kobaz> mmm
<Kobaz> so what's the preferred repo layout
<Kobaz> i was trying to do like, repo/project/trunk repo/project/branches, etc
<Kobaz> what would the /project/ be... making it a branch doesn't seem to work
<Kobaz> ie: branch within a branch
<james_w> Kobaz: if you want then it can just be a plain directory
<Kobaz> k
<james_w> I would advise you make repo/ a plain directory
<Dvyjones> How do I set up SSH keys with Bazaar? It seems like it isn't detecting my key...
<james_w> each /project/ a shared repository
<Kobaz> yeah
<james_w> then branches underneath that
<Peng_> Dvyjones: What OS?
<Dvyjones> Linux
<Peng_> Dvyjones: There is absolutely no magic involved. It just calls out to OpenSSH. If "ssh foo@bar" works, it will work with bzr.
<Dvyjones> So it's probably me specifying the wrong SSH key in launchpad, or it hasn't updated yet...
<Peng_> Probably, yeah. Or your SSH key suffers from the OpenSSL vulnerability.
<Peng_> Or you made some sort of mistake when pasting it into the box on LP.
<Dvyjones> It was generated just a couple of days ago on Ubuntu 8.120, so I guess not :P
<Peng_> heh, ok
<Peng_> I don't know what's wrong, then. Sorry.
 * Dvyjones copied it again, and it worked
<Kobaz> er
<Kobaz> whoops
<Kobaz> how do i do an unpush
<ras0ir> can someone explain me why chmod values are different in bzr push sftp:// and bzr push ftp:// ?
<cody-somerville> How do I configure who it says made the commit?
<cody-somerville> Right now it is using my hostname
<beuno> cody-somerville, bzr whoami
<cody-somerville> thanks
<danser> I accidentally did some commits without having my whoami configured. is there a way to change the committer's names afterwards?
<jelmer> danser, only by redoing the commits
<danser> jelmer: ok, thanks
<Peng_> Unless your default username is really embarrassing, it's probably best to just live with the mistake.
<danser> it's only about two recent commits, and I'm still the only author, so I don't mind redoing these :-)
<Tak> is it possible to encode a password in a location? or noninteractively at the commandline at all?
<jelmer> Tak, yes, "bzr://username:password@hostname/path"
<Tak> hmm - I get: ERROR: Invalid url supplied to transport: "invalid port number (part of password) in url
<Peng_> Maybe supply a port too?
<Tak> I am, actually
<Tak> the entire url looks like: sftp://user:pass@host:port/path/
<Tak> do I need to urlescape the password? (the url is already in single-quotes for the shell)
<seb_kuzminsky> i'm thankful for the vcs-imports team
<seb_kuzminsky> but i have a question
<seb_kuzminsky> i'm trying to branch this: https://code.launchpad.net/~vcs-imports/emc/trunk
<seb_kuzminsky> if i branch it into its own, new repo (ie, i run bzr branch in a directory which is not initialized) it works nice & fast
<zephyr> is there anything special i have to do to push files from olive to a website through ftp?
<seb_kuzminsky> but if i try to branch into an existing shared repo, with some other locally-created branches, it's awfully slow
<seb_kuzminsky> it says "Transferring 0/4", then stops & bzr pegs the CPU, and it just sits there
<luks> seb_kuzminsky: your repository is probably in a different format and it has to convert it
<seb_kuzminsky> ah
<luks> try bzr info on both
<seb_kuzminsky> new branch of lp: pack-0.92
<seb_kuzminsky> branch into existing repo: rich-root-pack
<seb_kuzminsky> thanks luks!
<seb_kuzminsky> i'm a bit confused by the different repo formats
<luks> you are not the only one :)
<seb_kuzminsky> i guess i should stay on the default pack-0.92, but it kept bugging me to "upgrade my repo"
<seb_kuzminsky> :-/
<zephyr> hi. i just started using bzr through olive - i am trying to push some test files to my server through ftp, i dont get an error, but nothing happens
<hiredman> I grabbed bzr-git from launch bad, I see "TypeError: 'Tree' object is not iterable" when I try to branch from a git repo
 * mwhudson points at jelmer
<mwhudson> hiredman: what version of bazaar?
<hiredman> 1.9
<mwhudson> hmm
<hiredman> python 2.5
<mwhudson> hiredman: are there bug reports for bzr-git?
<hiredman> http://gist.github.com/29575 is the output
<jml> hi
<jml> I just got bit by a UI bug in loom.
<jml> but it's a pretty subtle one.
<mwhudson> hiredman: hm, fairly mysterious
<jml> I was submitting threads to a PQM via exported branches, I ended up having one of the threads rejected because of a text conflict caused by one of my lower threads.
<hiredman> :(
<jml> I feel that loom should have warned me about this.
 * james_w waves to jml
<jml> james_w: hello.
<james_w> mwhudson: thanks again for loggerhead, just set it up on a site and it was painless and works beautifully
<mwhudson> james_w: glad it worked for you!
<james_w> jml: presumably they didn't conflict before you started exporting?
<jml> james_w: they did!
<jml> james_w: the interesting thing here is that the lower thread had commits that were not yet merged into the upper threads.
<james_w> ah, that'll do it
<james_w> so you're able to export threads from above your current position in the stack?
<jml> thing is, the only way to find that out with loom is to go to the bottom thread and merge all the way up.
<jml> james_w: I think export-loom just does the whole stack -- not sure though.
<jml> james_w: I might have switched to a higher thread also, again not sure.
<james_w> ah, I haven't used export-loom, I see that would be a problem
<james_w> what warning would you have liked?
<james_w> "You are exporting a loom that hasn't been fully merged. The resulting branches may conflict"?
<jml> james_w: I guess what I would like is something akin to "bzr status" that shows me if any threads have revisions that haven't been merged into the higher threads
<jml> and also what's changed since the last record (hah!)
<james_w> it sounds like they are things that bzr-loom should provide
<james_w> representing it obviously won't be easy, as you indicate
<jml> yeah.
<jfroy|work> Hello people
 * jml shakes his fist at combine-thread
<jfroy|work> I was wondering if there was an semantical equivalent of "svn mv" something out of a branch into a new one.
<jfroy|work> That is, I have a project that has grown way too large, and I'd like to refactor a sub-component of it as a sub-project, with its own set of branches.
<jfroy|work> Is there a way to grab a sub-tree of a branch and turn that into a branch, or branch a sub-tree of a branch. Or is the infamous "move the file manually into a new branch" the way to go.
<jml> anyone know how I can get info from the last record?
<jelmer> beuno, hi
<jelmer> mwhudson, hi
<mwhudson> jelmer: some bzr-git queries from hiredman
<jelmer> hiredman, pong
<jelmer> mwhudson, we (and by that I mean Lo-Lan-Do) are working on also getting loggerhead up and running on alioth
<mwhudson> jelmer: nice
<james_w> jelmer: cool
<james_w> jelmer: does the version of loggerhead you are using include the serve-branches script? Is that what you are using?
<jelmer> james_w, no, we're the standard loggerhead package - which uses start-loggerhead
<james_w> using serve-branches can display the hierarchy nicely
<james_w> going by one of the bug reports it sounds like that is what would be preferred
<jelmer> ah, wasn't aware they're actually doing different things these days
<mwhudson> serve-branches -- new, perhaps a little dwimmish, liked\
<mwhudson> start-loggerhead -- old, crappy, i personally hate it
<james_w> I'm not sure where the extra port is coming from, do you have the public URL setting in loggerhead.conf?
<jelmer> mwhudson, but serve-branches doesn't use loggerhead.conf, does it?
<mwhudson> jelmer: no, you have to use --style options
<jelmer> it would be nice if there was a way to just get the stylistic improvements by setting some variable in lgogerhead.conf
<mwhudson> you mean the serving from directories stuff?
<mwhudson> because there isn't any real difference in appearance, i thought
<jelmer> I'd like to get the hierarchy that serve-branches has
<mwhudson> what else can't you get with serve-branches?
<jelmer> That's the only bit I'm aware of that's differnet (but I may not be very well informed)
<mwhudson> then why not use serve-branches?
<mwhudson> i realize you can't use loggerhead.conf so neatly, but a little shell script with --port this and --host that doesn't seem so hard
<jelmer> mwhudson, this is for the debian package, which already uses start-loggerhead
<mwhudson> jelmer: now you've lost me
<mwhudson> which part of the debian package?
<jelmer> the init script
<mwhudson> oh right\
<mwhudson> did you see that trunk loggerhead has one of them too now?
<jelmer> the alternative is for me to allow the user to configure a choice between start-loggerhead and serve-branches
<jelmer> and to confuse users since their configuration for address/port to listen on is in different places
<mwhudson> ah
<james_w> the loggerhead.conf suits a package really well, and so having an option to turn on the hierarchical browsing would be great IMO
<mwhudson> i'm fine with the idea of configuring serve-branches from a config file
<mwhudson> i'm not really fine with it being the same as loggerhead.conf currently is though
<lifeless> or
<lifeless> nuke loggerhead.conf completely
<lifeless> and let a /etc/defaults/loggerhead set variables
<lifeless> (in the packaging)
<jelmer> mwhudson, serve-branches doesn't necessarily have to support a config file - it can just be a tool to quickly get a loggerhead up
<jelmer> the important thing (for me at least) is that the same functionality is in start-loggerhead
<fullermd> Looks like Dragonfly finished their git conversion.
<mwhudson> jelmer: i don't see why you so want start-loggerhead
<jelmer> mwhudson, it means I don't have to worry about the configuration (since except for enabling it, it is all outside of /etc/default), because it can fork for me as well as log etc, and because it's already there (otherwise I'd have to make sure there's a smooth transition from start-loggerhead to serve-branches)
<mwhudson> jelmer: well if you'd _asked_ me when you were packaging loggerhead, i'd have told you to stay away from it ;-p
<mwhudson> jelmer: when serve-branches is feature compatible, we can do a compatibility shim somehow
<lifeless> mwhudson: or, as some of the features are insane
<jelmer> mwhudson: at that time, serve-branches wasn't even installed by setup.py IIRC..
<lifeless> mwhudson: you could just deprecate it
<mwhudson> there's always going to be a spot of friction though, because the way the branches are specified
<mwhudson> +of
<hiredman> jelmer: ping
<jelmer> hiredman, pong
<hiredman> Yo
<jelmer> hiredman, you were hitting issues in bzr-git
<hiredman> Yes.
<hiredman> I was not able to branch from a git tree, or whatever you call it
<hiredman> I am not even sure how complete bzr-git is suposed to be
<hiredman> http://gist.github.com/29575 was the output
#bzr 2008-11-27
<lszyba1> hello, I did:  bzr tag -r 77 datahub-release-0.7  now how do I push this to launchpad?
<lszyba1> Do I have to recommit and push? "No new revisions to push."
<spiv> lszyba1: no, the push worked
<spiv> lszyba1: the message is confusing (there's a bug open about that), but the tag will have been pushed.
<spiv> lszyba1: $ bzr tags -d lp:datahub
<spiv> datahub-release-0.7  77
<spiv> lszyba1: so you can see the tag is there :)
<spiv> (bug 164450 appears the bug number)
<ubottu> Launchpad bug 164450 in bzr "should show a message when pushing(overwriting?) tags" [Low,Confirmed] https://launchpad.net/bugs/164450
<lszyba1> thanks, is there a command to list tags  bzr lstags  ??
<bob2> just 'bzr tags'
<lszyba1> bzr tags ..found it
<lszyba1> thanks,,updated my manual..http://lucasmanual.com/mywiki/Bazaar
<lszyba1> anybody knows if launchpad shows tags anywhere?
<spiv> Not that I know of.
<jfroy|work> jelmer: ping
<jelmer> jfroy|work, pong
<jfroy|work> jelmer: OK, so I thought I understood, but bzr-svn (or me) just did something I'm not sure I understand.
<jfroy|work> Basically, what are you supposed to do again when bzr pull from the subversion branch tells you the branches have diverged? I did a merge, commit, push operation.
<jfroy|work> And although that mostly worked, bzr-svn committed, as far as I can tell, the same set of changes that someone else had committed via svn (which caused the branches to diverge in the first place).
<jfroy|work> Is that expected, or did I do something wrong?
<jelmer> jfroy|work, yes - see the bzr-svn FAQ
<jelmer> you may want to use bzr rebase rather than merge
<jfroy|work> Ah right, I remember that...
<jfroy|work> Hum, I see, I forgot I wasn't working with a Subversion checkout, but rather a branch
<jfroy|work> (since committing on a checkout is broken in 1.9)
<jfroy|work> A checkout would not have normally allowed by commit which caused the branch to diverge.
 * jfroy|work is unconfused
<jfroy|work> *allowed my
<jfroy|work> The amazing thing is, no conflicts were generated.
<jfroy|work> It's as if the same set of changes were applied twice without a problem.
<jelmer> yes, that's correct - the revision that was moved to the right hand side is no longer on mainline
<jfroy|work> indeed, it got moved to the right-side of the merge commit.
<tetha> uhoh. "Device not ready" while trying yo read the kernel is no nice greeting in the morning
<poolie> spiv, still around?
<spiv> poolie: yeah
<poolie> i'm going to finish up in a bit, about 5:30 or 6, and go out
<spiv> jelmer: if I have the latest stable branch of bzr-svn installed I can't branch from http://bzr.arbash-meinel.com/branches/bzr/1.10-dev/revision_stream
<poolie> mwh reported a new bug with those checks i put in for stacked branches
<poolie> i'm just thinking about whether to get on to that now or keep going with john's merges
<poolie> probably the second is better, as it's already work in progress
<poolie> and then i can take an uinterrupted go at 302968
<poolie> how did you go?
<spiv> 302968?
<poolie> correction bug 302698
<ubottu> Launchpad bug 302698 in bzr ""BzrCheckError: Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0x2e23f90> has delta references to items not in its repository:" on pushing a stacked branch" [High,Confirmed] https://launchpad.net/bugs/302698
<spiv> I saw mwh's bug, it seems to still be noticing the problem a bit too late.
<poolie> yeah
<spiv> Sooner than the next push, at least :)
<poolie> right
<poolie> i'm happy with the check there
<poolie> and it should be fairly possible to just work backwards and see what should be done
<spiv> It's weird that the autopack's _check_references trips over, but the push itself didn't.
<spiv> Oh, unless an earlier pack that's part of the autopack has the dud record(s).
<spiv> If that's the case then it might just be a matter of waiting until a report of that error comes in that isn't from an autopack.
<spiv> I agree that at the moment doing work that will make the rc1 tomorrow better is probably the best bet.
<poolie> indeed, but what would that be? :)
<spiv> Heh.
<poolie> i'll look at your tweak for 'avoid extracting revision texts' and merge it
<spiv> Landing already reviewed/proposed patches.
<poolie> the patch makes sense to me
<spiv> I'm doing that one atm, actually :)
<poolie> oh ok
<spiv> Just waiting for my push to finish then I'll hit pqm-submit (so only a few seconds)
<poolie> then i'll look at 'retry 2/3', as no one has reviewed that yet
<spiv> That'd be good.  I took a glance at it but the diff seemed a bit odd, and merging bzr.dev gave some irritating criss-cross conflicts.
<spiv> ("odd" as in "looks like it shows unrelated changes that are already in bzr.dev")
<poolie> i might try that merge then
<spiv> poolie: oh, and Mary would be happy if http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C418c22640811181423hc9a2628y4b0bae4dd1f6e7fd%40mail.gmail.com%3E makes it into 1.10
<spiv> poolie: there's a newer patch that makes _get_nick into a public get_nick as suggested by the review, but that newer patch is stalled while waiting for tests to be written for that new public API.
<spiv> poolie: so probably we should just merge the initial patch (with _get_nick) for 1.10
<poolie> +1 from me
<spiv> poolie: I can do that if that sounds -- great :)
<vila> hi all
<poolie> hey vila
<poolie> ok, i've fixed up jam's retry patch and sent it to pqm, and now i'm signing off
<vila> pfeww, finally the fix for bug #277537 is ready to be used or should I run yet another mammoth 34h bzr check ? :-/ :-) :-\
<ubottu> Launchpad bug 277537 in bzr "annotate says revision modified file, "bzr diff -c" widly contradicts" [High,Fix committed] https://launchpad.net/bugs/277537
<spiv> poolie: cool.  I've got jam's pack re-order patch with PQM too, so I think we've merged all the important stuff he wanted to have merged.
 * spiv goes for a swim
<loxs> folks, bzr+ssh doesnt work with the setup installer for windows. So I decided to install python and paramiko and then bzr. Paramiko now works on its own. I try to install with the "simple" installer, but now bzr is not in the system path. And I can't find the exe. Where is it installed?
<speakman> how is nested trees developing going?
<_mathrick> hey
<_mathrick> what is the best repo structure to have a dev branch, and another branch which is dev + local conf (DB/host settings in this case)?
<_mathrick> ideally, all changes would be pushed into dev unless I specifically say not to
<_mathrick> ie. I'd like to avoid manual sync as much as possible
<SteveA> poolie, spiv: hi.  do you need any help getting the branches that are still causing a problem for online services?
<spiv> SteveA: more details certainly wouldn't hurt
<spiv> SteveA: is it easy to make a tarball of the offending branch(es) + plus instructions to reproduce the problem with the tarball?
<_mathrick> um, how can I export a shelf?
<SteveA> spiv: I think we only see it when talking to Launchpad
<SteveA> spiv: best thing is if I give you access to the private branches, I think
<SteveA> spiv: I just added you as a member of a team.  You should be able to get the branches now.
<james_w> jelmer: hey just discussing how to make --export-upstream work better for someone, and I think we may be able to solve your problem at the same time
<Lo-lan-do> Hey there
<Lo-lan-do> Can I get bzr branch (or bzr checkout) to not create a working directory but only to fetch the revisions?
<Lo-lan-do> I'm trying to setup a "mirror" repository on my laptop with branches bound to those on my server's repository.
<james_w> hey Lo-lan-do
<james_w> you can do it if you create a --no-trees repository
<Lo-lan-do> But even though the local repository is --no-trees, bzr branch creates working copies :-/
<james_w> oh
<james_w> that's odd
<Lo-lan-do> (This is bzr 1.5-1.1 on Debian unstable, by the way)
<Lo-lan-do> But anyway, I'll do some shell magic with bzr reconfigure.
<james_w> I'm pretty sure --no-trees should work
<james_w> you might have found a bug
<james_w> Lo-lan-do: thanks for working on loggerhead for alioth
<Lo-lan-do> You're welcome.  You'll probably notice it doesn't Just Work quite yet :-)
<Lo-lan-do> (I reported the bugs last night)
<Lo-lan-do> I'm off to lunch, but I'll be back to discuss them afterwards :-)
<jelmer> james_w, ah, cool - how?
<james_w> jelmer: do you use export-upstream in merge mode, or not?
<jelmer> james_w, no, I don't use merge mode anymore these days
<james_w> jelmer: to add a new mode, so one can just re-use the tarball if already present
<james_w> we could also make it a but easier as well, as when you are not in merge mode the upstream branch is not necessary to retrieve the revision in question, as you will have merged it
<james_w> though noting the upstream branch will still be useful
<james_w> I haven't thought it all through yet though
<phoenix3051> anyone know why on ubuntu hardy, bzr depends on  python-central (>= 0.6.7) but only 0.6.5ubuntu1 is available
<jelmer> james_w, Is there a good use case for "export-upstream" without "export-upstream-revision" ?
<james_w> jelmer: it was intended for nightly build
<CardinalFang> Three lines:  $ bzr upgrade \nFormat <RepositoryFormatKnit1> for file:///blah/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance \nbzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.\n
<CardinalFang> "please change!  sorry, nothing to do!"  Why?
<beuno> CardinalFang, maybe the repo is old format?
<beuno> are you using shared repos?
<CardinalFang> Yes, I am.
<beuno> CardinalFang, then you have to upgrade bith the branch and the repo
<CardinalFang> Hrm.  Ugly.  Okay.
<goshawk> hi
<goshawk> is there a command to remvoe unknow files?
<goshawk> from the repo?
<goshawk> *remove
<Odd_Bloke> goshawk: `bzr clean-tree`, though that may be in bzrtools.
<goshawk> tahnks
<goshawk> thanks
<goshawk> works great!
<goshawk> :)
<goshawk> wait... it deleted the whole repo...
<Odd_Bloke> goshawk: That's surprising.  Are you sure that you had added the files you were expecting to keep?
<_mathrick> goshawk: repo or tree?
<goshawk> wait
<_mathrick> also, bzr serve just tried to murder my RAM, why does it hate my RAM?
<_mathrick> it used up above 500M or so, unsure how much exactly, because I was too busy killing it before it took all the mem
<_mathrick> the repo has only 2 revisions, although it has quite a few files
<_mathrick> 10K files, ~150MB working tree
<_mathrick> how do I find out what's up?
<goshawk> Odd_Bloke: it was my fault
<goshawk> how can i revert before deleting?
<goshawk> done :)
<CaMason_> hi guys. About to try about bzr for the first time
<CaMason_> does bzr support keywords at all? I namely want to use the $id $ feature of svn if possible
<james_w> CaMason_: not currently, it is in development though
<CaMason_> james_w: ok. It's not that important for me at the moment :)
<CaMason_> I love the fact this is portable. I can now continue my dev and commits whilst on the train :D
<CaMason_> I did like tortoiseSVN though. I'm on vista x64, so I can't use the gui
<CaMason_> although the eclipse plugin seems good
<Lo-lan-do> I thought there was a TortoiseBZR too?
<CaMason_> yes but it doesn't support x64, I believe
<Lo-lan-do> Ah.  Pardon me for being ignorant of these things, I haven't touched Windows for years.
<CaMason_> there's only a couple of things holding me back in windows, and thats the Adobe suite, and better multi-monitor support
<CaMason_> I need access to the Adobe stuff, and there's no elegant working solutions for the suite. Also, I use 3 or 4 monitors, and the support with distro's like ubuntu isn't as good as the windows implementation, yet
<Lo-lan-do> I wasn't tryng to elicit a discussion on that subject, just apologising, really ;-)
<CaMason_> Lo-lan-do: I was just voicing my dissapointment with Adobe's lack of linux builds, as usual :)
<CaMason_> hrm.. I've got a couple of symbollic links in my project. I just did a bzr add, and commit. Now 'bzr status' shows those 2 links as 'unknown' with @ appended
<CaMason_> Any ideas on the best approach now?
<james_w> CaMason_: what happens if you "bzr add <symlink>"?
<CaMason_> it seems it added the folder, but not contents (desired)
<CaMason_> and commit succeeded :)
<CaMason_> What's the preferred mechanism for seperating lines/sentences with a commit message?
<james_w> CaMason_: I like to do a one line summary, a blank line, then paragraphs explaining it
<CaMason_> sorry for my lack of understanding. How would I insert a newline when I'm typing at command line? (linux)
<james_w> that works well with things like bzr log --line, loggerhead etc.
<james_w> oh
<james_w> don't pass -m
<james_w> and don't type a message
<james_w> it is possible at the command line, but if you do that you will be given an editor in which to type
<CaMason_> oh I see! and thanks to uncommit, I can go back and try it on a real commit :D
<CaMason_> liking bzr already
<LaserJock> james_w: congrats on the Ubuntu package branches
<sohail> hi, anyone know the status of bzrp4? Is the bzr -> perforce functionality available to test/hack?
<james_w> thanks LaserJock
<LaserJock> james_w: I was looking at a failure and see:   UnicodeDecodeError:Â 'utf8'Â codecÂ can'tÂ decodeÂ bytesÂ inÂ positionÂ 286-291:Â unsupportedÂ UnicodeÂ codeÂ range
<LaserJock> james_w: isn't that a common problem?
<james_w> yeah
<james_w> it assumes debian/changelog is valid utf-8
<james_w> I'm going to try and remove that assumption or relax it somehow
<Dvyjones> Is there anything like SNV's $Id$ (I think that's how it is in SVN at least) in bazaar?
<james_w> Dvyjones: not currently, but it's in development
<Dvyjones> And there's nothing like CIA(.vc) in Bazaar?
<beuno> Dvyjones, sure, check out the CIA plugin: http://bazaar-vcs.org
<beuno> er
<beuno> http://bazaar-vcs.org/BzrPlugins
<LaserJock> james_w: this one seems a bit weird: bzrlib.errors.NoSuchTag:Â NoÂ suchÂ tag:Â upstream-ubuntu-0.12
<Dvyjones> Do oyu know any good PHP software management softares / CMSes that support showing last bazaar pushes?
<james_w> LaserJock: yeah, that's the most common one, it's a logic error I haven't had chance to look in to yet
<LaserJock> james_w: something about the way it figures out what the upstream release is I suppose
<poolie> hello
<pygi> hello poolie
<thumper> poolie: hi
<thumper> poolie: I was trying to remind myself of the --fixes syntax, and went `bzr help bugs`
<thumper> poolie: I was somewhat surprised not to see a launchpad example in there
<thumper> poolie: it had three or four other examples, but no lp :(
<poolie> that sounds like a bug
<poolie> i wonder why
<poolie> ah so it does talk about lp, but doesn't give a good example
<grettke> Hi guys. I've got a shared-repo with a project in it that I no don't need. I want to delete it. Should I just rm -rf it, or use bzr commands to do so? It has never been branched, just created is all.
<poolie> if it has nothing else in it that you want, you can just rm it
<grettke> Ok.
<grettke> If I were to delete and recreate that project, as far as the shared repo is concened, it is not the same as the old one?
<poolie> right
<grettke> thanks poolie. bye.
<spiv> poolie: huh!
<poolie> mm?
<spiv> poolie: that change used to pass tests, but now it trips on your new consistency chekc
<poolie> ah
<spiv> (the change to remove "len(self.target._fallback_repositories) > 0")
<poolie> yes, that's what i understood you to mean
<poolie> good thing that check was there i guess
<spiv> I guess that makes sense, it can't be a straight pack-to-pack copy, some delta records have to be fulltexts.
<poolie> thumper, spiv: just <http://pastebin.ubuntu.com/77542/> or anything more?
<thumper> poolie: fixes rather than addresses perhaps?
<thumper> but yes, that is all I was looking for
<poolie> i'd kind of like to say what effect this will
<poolie> have
<poolie> but, that's mostly defined server side and may go out of date
<poolie> and i'm not sure off hand what will happen
<spiv> poolie: that looks reasonable to me
<poolie> thumper: i just got subscribed to a very active project using code reviews etc
<poolie> so, congratulations on your feature's popularity
<spiv> Off hand I believe --fixes lp:NNNN causes that branch to be associated with the bug, and that association's status is set to "Fix Available".  I think "addresses" is an ok way to summarise that ;)
<poolie> but it's also an eyewatering amount of email
<poolie> and i don't really really care about it
<poolie> possibly i should fix this in my mail client
<poolie> but i wonder, if i unsubscribed (if i can) whether I'd get a good replacement through the web
<poolie> basically a timeline view of all merge proposals, comments, and landings
<spiv> poolie: so I've updated my original InterPackRepo.fetch hack for bug 294479 to add a comment and a NEWS entry.
<ubottu> Launchpad bug 294479 in bzr "Vast number of round-trips pushing stacked branch" [High,In progress] https://launchpad.net/bugs/294479
<spiv> poolie: I'm just running a full test suite now, in case there's something unexpected, but I don't expect there to be.
<poolie> so this is setting it through a callback?
<poolie> i think a comment about why we're doing it, and maybe also something on the constructor parameter to say we don't really want it would make sense
<poolie> i sent that doc patch to pqm
<spiv> poolie: right.
<spiv> poolie: I'll add a comment to the constructor too.
<jml> you know what would be great?
<jml> being able to re-order threads in a loom
<jml> (I guess doing it properly depends on proper cherrypicking, but I'd be happy with a half-arsed solution that was a joy to use)
<Glenjamin> hey guys, i've just installed bzr1.9 on windows, and i'm getting the error "Unable to load bzr-svn extensions - did you build it?" "cannot import name client"
<Glenjamin> anyone know what this actually means?
<lifeless> jml: its in todo I think, file a bug, yada yada yada
<awilkins> Glenjamin: It's a packaging bug
<awilkins> Glenjamin: You installed the python2.5 version?
<Glenjamin> yes
<awilkins> Glenjamin: Delete c:\python25\lib\site-packages\bzrlib\plugins\svn
<awilkins> Unless you actually want to use bzr-svn, of course
<Glenjamin> and if i want svn i should just install it?
<awilkins> "just install it" is relative on windows
<awilkins> It's rather tricky to get it built
<Glenjamin> ah
<Glenjamin> i probably dont need it for now
<awilkins> For windows I think you are going to be looking at prepackaged binaries
<Glenjamin> yeah, i'm fine with that
<Glenjamin> while i'm here, i dont suppose anyone knows how to get tortoisebzr working on 64bit windows?
<spiv> poolie: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081127231800.GH23611%40steerpike.home.puzzling.org%3E is the updated patch, btw
#bzr 2008-11-28
<poolie> spiv, hi
<poolie> approved
<spiv> Thanks1
<thumper> poolie: which project was it using reviews?
<poolie> stevea's project
<jml> ok. so how exactly should I do this again (switching the order of a pair of adjacent threads)
<thumper> a quick question about bzr send
<thumper> if using `bzr send --mailto foo@example.com` and thunderbird
<thumper> does the attachment get added for others?
<thumper> I'm trying to debug a weirdness
<poolie> how do you mean 'for others'?
 * jml walks away to think about the problem.
<poolie> jml, i don't know
<jml> poolie: behold, I show you a mystery
<spiv> jml: edit your .bzr/branch/last-loom file? ;)
<poolie> spiv, i'm reading john's pack-names patch
<spiv> jml: More reasonably, pull --overwrite probably gives you the hammer you need.
<jml> spiv: hmm. maybe. there are a bunch of merges that I need to work around.
<jml> spiv: I'll have a play, anyway.
<spiv> jml: ah, so it's more fundamentally that you need cherrypicking, rather than the ordering of the loom threads?
<jml> spiv: yeah, probably.
 * jml does uncommit and shelve shenanigans
<poolie> spiv, ok, i'm going to send up john's patch, what next?
<jml> and look, there's a criss-cross merge. what a shock.
<spiv> poolie: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20081117065938.GA18818%40steerpike.home.puzzling.org%3E perhaps?
<poolie> yeah
<poolie> there are some nontrivial conflicts, i'm just working through them
<poolie> so you're both pretty confident in that interdiffing one
<spiv> Yeah.
<spiv> Oh, I should land my already approved improvement item_keys_introduced_by's signatures calculation.
 * spiv does that
<spiv> Not sure why I didn't notice that sooner, I guess the rapidly shrinking list of things in bundle buggy made it more obvious :)
<james_w> poolie: "either 1.6 (from hardy)" <- did you mean Intrepid?
<poolie> i did
<spiv> poolie: I'm going to land the interdifferingserializer improvement (I'm confident and the bb:comments were essentially positive), and then I think I'm out of changes for 1.10
<poolie> ok
<poolie> i've just finished resolving the pack-names thing
<poolie> i'm going to send that up, then have lunch, then roll 1.10rc1
<spiv> Woo
<mwhudson> poolie: getting anywhere on that bug of mine?
<poolie> mwhudson: tbh not yet, we're trying to finish off work that's already queued and to get a release out
<mwhudson> ok
<poolie> but after that, it's top of the list
<poolie> i'm not totally sure this is the right approach but things have gone for us when we try to fix just one more bug before releasing
<poolie> spiv, mine merged, when yours does i'll start packaging
<spiv> poolie: cool.  I'm off to lunch to now.
<mwhudson> huh, i managed to push https://code.edge.launchpad.net/~mwhudson/launchpad/manual-stacking-on-launchpad-branches-bug-272372 via devpad
<mwhudson> which has bzr 1.9
<poolie> so are you saying your bug may be to do with the server code?
<mwhudson> no
<mwhudson> i pushed locally with bzr 1.9 --> boom
<mwhudson> i pushed to devpad, then from devpad i seem to be able to push with bzr 1.7
<spiv> poolie: how's the releasing going?
<poolie> hey
<poolie> i'm uploading bzr-svn, and working out how it uses bzr builddeb
<poolie> did your things all land?
<spiv> Apparently so!  http://bundlebuggy.aaronbentley.com/?selected=pending&unreviewed=n is almost unrecogniseably shorter :)
<toytoy> hi guys, i was doing 'bzr uncommit' then did bzr commit, then in the other pc, i did bzr update, but I see that the last log that was part of the 'bzr uncommit' became a pendig merges. is that normal? or I want to remove that pending merges since that's no use
<poolie> assuming you don't want to keep that uncommitted revision, you should revert the other checkout
<spiv> toytoy: that's an interesting case.  I think that is probably a bug, although not a surprising one.  You can clear pending merges with "bzr revert --forget-merges".
<poolie> This release of Bazaar focusses on performance improvements when pushing
<poolie> and pulling revisions, both locally and to remote networks.  The popular
<poolie> ``shelve`` and ``unshelve`` commands, used to interactively revert and
<poolie> restore work in progress, have been merged from bzrtools into the bzr
<poolie> core.  There are also bug fixes for portability, and for stacked branches.
<poolie> how's that
<spiv> Sounds good, although shelve/unshelve was rewritten rather than merely merged.
<spiv> I'm not sure the distinction matters for that text, though.
<poolie> to use internal merge, rather than patch and diff?
<spiv> Yeah.
<spiv> poolie: I'm off to SLUG.  I'll have a play with the rc1 when I get home tonight :)
* poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test 1.10rc1 released 28 Nov | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<poolie> spiv, ok, cheerio - btw (i should have reminded you earlier) i have a holiday on monday again
<poolie> but john and robert will be back
<spiv> poolie: I'll be on leave (OSDC that week), but pretty easy to contact.
<poolie> ah, right
<poolie> hm, maybe i should move it
<poolie> have a fun conference anyhow
<poolie> and btw it's great how many things you landed into 1.10, and that insert_r_s is coming along
<vila> hi all
<robin_dewd> ls
<GPHemsley> Is there any way for me to merge the history of two branches that don't share a common ancestor within Bazaar, though they do share a common ancestor file-wise?
<GPHemsley> fullermd: Would you happen to be around?
<GPHemsley> poolie: You still around?
<jamesh> GPHemsley: you can merge the two branches in a way that will give you the files from both branches
<jamesh> GPHemsley: but it won't merge contents of files from the two branches
<jamesh> "bzr merge -r 0.. otherbranch" should do it
<GPHemsley> hmm...
<jamesh> as the branches don't share history, it has no way of knowing that two files with the same name should be merged (you'll get a naming conflict), let alone how to merge the contents
<GPHemsley> hmm
<GPHemsley> darn
<AfC> Haven't actually done it, but if you  `bzr add --file-ids-from` the files into the new branch, then do the merge, it might work?
<GPHemsley> It's alright
<GPHemsley> it's not that important
<GPHemsley> but thanks
<GPHemsley> jamesh, AfC: What's the proper syntax for `bzr init-repo` via SFTP?
<GPHemsley> nevermind, got it
<GPHemsley> jamesh, AfC: Whats the difference between `bzr init ; bzr pull` and `bzr branch`?
<maco> is it safe to install bzr 1.6 in ubuntu 8.04?
<maco> im not sure if i should ask that in an ubuntu place or here
<maco> i just dont know if it'd be unhappy with library versions or something
<poolie> maco: yes, it's fine
<GPHemsley> poolie: What is rich root?
<poolie> you can get a package from launchpad.net/~bzr/+archive
<maco> poolie: ok, thank you
<poolie> GPHemsley: it's a series of alternate repo formats that support primarily svn interoperation
<GPHemsley> Is that their only benefit?
<poolie> just about
<GPHemsley> ok
<jamesh> GPHemsley: the only real difference between init+pull and branch is the format of the resulting branch: the first will use bzr's default format, while the second will use the format of the source branch
<maco> jamesh: ooo i was wondering that
<spiv> poolie: yeah, it's very satisfying watching stuff land :)
<abeaumont> is it possible to set commands configuration in a configuration file or similar? e.g: i'd like to use --line switch in bzr log by default
<abeaumont> configuration topic in help does't talk about such possibilities...
<spiv> abeaumont: yes
<spiv> abeaumont: create an alias
<abeaumont> thanks spiv
<abeaumont> much better than what i had in mind :D
<CaMason_> What's the best way to set up a SFTP user that will point to /srv/bzr/myrepo ?
<rocky> jelmer: which  version of bzr-svn should i be using for bzr-1.10rc1 ? :)
<jelmer> rocky, nothing yet - 1.10 breaks API compatibility for 0.4.15 but I hope to release 0.5.0 at some point before 1.10
<rocky> jelmer: don't suppose it's safe to use a branch of bzr-svn then?
<jelmer> well, it won't corrupt your repository or anything but some operations may give tracebacks
 * rocky reluctantly sticks with bzr 1.9 for the time being... :)
<CaMason_> hi guys. I've had a project under bzr control just from bzr init. Now, I've just set up a SFTP connection, and I'd like to make my current repo a central repo on the SFTP server
<CaMason_> how do I go about doing this?
<jelmer> CaMason_, bzr push the branch to the sftp server
<jelmer> after that, you should be able to "bzr checkout" it
<CaMason_> jelmer: thanks, I'm just reading that bit now
 * rocky loves that every bzr repo can be used as-is by merely hooking up network access to it for someone else
<rocky> i don't think svn was like that right?
<CaMason_> rocky: nope
<CaMason_> you know, I think I can use a folder under both SVN and .bzr control..
<CaMason_> i.e. my local project has a single folder that I want to put on a SVN server elsewhere (for others). If I ignore the .svn files with bzr, it shoudln't cause any conflicts, if I think correctly?
<rocky> CaMason_: you can probably do something a little slicker with bzr-svn, but jelmer would be the one to poke for that ;)
<CaMason_> I think I've pushed my current repo to a central location. However, the file sizes are different
<CaMason_> the central repo seems to be about 500kb big, but my local one is about 700kb
<KangOl> hi
<CaMason_> well, I managed to checkout the central branch. so..
<CaMason_> I assume everything is ok!
<beuno> CaMason_, bzr optimizes repos, so I wouldn't be surprised
<KangOl> why doing a merge between 2 branches without common ancestor with cherrypicking doesn't keep the history ?
<CaMason_> and it seems I've bound my working copy to the central repo now. This is brilliant :)
<CaMason_> and I can unbind.. brillian. I can now work on the train offline :D
<beuno> yes, the magic of bzr
<CaMason_> I have to say, compared to SVN, the setup process has been very painless
<beuno> CaMason_, blog about it!  the world needs to know!  ;)
<CaMason_> I will as soon as I get my blog up
<KangOl> someone can explain me this behavior ?
<KangOl> ~$> bzr clone -q <urlA> A
<KangOl> ~$> bzr clone -q <urlB> B
<KangOl> ~$> cd A
<KangOl> A$> bzr merge ../B/
<KangOl> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
<KangOl> A$> bzr merge -q -r 0..-1 ../B/
<KangOl> A$> bzr st | grep pending
<KangOl> pending merges:
<KangOl> A$> bzr revert -q
<KangOl> A$> bzr merge -q -r 0..-1 ../B/somedir/
<KangOl> A$> bzr st | grep pending
<KangOl> A$>
<uws> jelmer: bzr-svn seems to think subtrees of my svn checkout are are in different svn repos
<uws> jelmer: refusing   'bzr commit dir1/somefile dir2/somefile'
<uws> jelmer: note that this is a svn checkout, not a bzr-svn checkout
<jelmer> uws, what's the exact error?
<uws> ERROR: dir1/dir/somefile is not in the same branch as dir22/dir/someotherfile
<uws> jelmer: ^
<uws> jelmer: "bzr root" in dir2/dir gives dir2/, instead of 2 levels up)
<jelmer> uws: Ah, that's actually correct. It's fixed in 0.5, you can workaround it in 0.4 by explicitly setting a branching scheme and setting it to be mandatory
<uws> jelmer: how?
<uws> jelmer: what value should I use for  bzr svn-branching-scheme --set svn+ssh://.... ?
<uws> jelmer: repo layout is  /project/{trunk,branches/tags}
<uws> jelmer: my svn checkout is from  /project/trunk/
<jelmer> uws, that should be trunk1 (in ~/.bazaar/subversion.conf)
<rotty> hmm, I've a strange problem when using bzr+ssh:
<rotty> nathot:~/src/spe/systems% bzr branch sftp://delenn/home/rotty/src/spe/systems/xitomatl
<rotty> rotty@delenn's password:
<rotty> bzr: ERROR: Not a branch: "/home/rotty/src/xitomatl/
<rotty> (erm, that's with sftp, but bzr+ssh yields the same error)
<rotty> (note the difference between the path names specified on the command line, and in the error message)
<rotty> (also, when doing the same on delenn, using 'localhost' as hostname, it works without a flaw)
<rotty> arghl! bzr stores the absolute directory inside .bzr/branch/location -- so if you move the dir, this info becomes bogus.
<rotty> I think storing locations globally in ~/.bazaar/locations.conf and inside ~/.bzr is a real misfeature
<Odd_Bloke> rotty: What version of bzr are you using?
<rotty> 1.5
<Odd_Bloke> Weird.
<Odd_Bloke> I'm not seeing a ~/.bzr/branch/location...
<rotty> in the repo: /path/to/repo/.bzr/branch/location
<Odd_Bloke> Sorry, I didn't mean to put the ~ there.
<Odd_Bloke> My fingers betrayed me.
<Odd_Bloke> I'm not seeing one in my branches.
<rotty> i've been bitten by stuff like that on several occassions -- no other dvcs I've used has problems when you move repos around
<Odd_Bloke> rotty: Are you talking about repositories or branches?
<rotty> Odd_Bloke: aren't those the same in bzr?
<Odd_Bloke> rotty: No.
<Odd_Bloke> A repository is Just a Bunch Of Revisions.  A branch is a pointer to one of those revisions (which in turn point to their parents and so on, giving you history).
<Odd_Bloke> rotty: Often, the repository and the branch will be in the same location, but not necessarily.
<Odd_Bloke> For example, when using shared repositories.
<rotty> I just have repos and branches that share location
<rotty> (btw, removing that .bzr/branch/location file makes the branch not work anymore)
<rotty> (and trying to correct it also doesn't work)
<Odd_Bloke> rotty: I'm afraid I'm not sure what's going on.
<Odd_Bloke> Perhaps a ML post would be in order.
<rotty> well, running "bzr branch" locally, and using the newly created branch instead, worked
<Odd_Bloke> rotty: Yeah, that's the recommended way of doing it.
<Odd_Bloke> Sorry, it should have occurred to me to mention that. >.<
<beuno> vila, going to be working on improving log performance?
<beuno> you become my instant personal god if you are
<vila> beuno :-)
<vila> I have a problem with log, but not only a performance problem, so I'm reviewing the related bugs, tagging them along the way
<vila> But out of curiosity, what is your use case (there are several ways log performance can be improved)
<beuno> vila, loggerhead
<beuno> so bzr log -v  ;)
<vila> log -v is quite a big hammer, you use it without limiting the revision range ?
<beuno> vila, no, I do limit it
<beuno> it's the only remaining thing we *have* to cache in loggerhead
<beuno> the changed files per revision
<vila> beuno: can't you use tree.iter_changes directly ?
<beuno> vila, IIRC, the problem is that we have to get all the files changed for a revision in mainline, with all it's sub-revisions
<beuno> for 20 (mainline) revisions at a time
<beuno> on a big tree (20k revs), you think using inter_changes would be fast to get that info?
<beuno> I don
<beuno> I don't remember atm how we get that information
<vila> beuno: oh, your context is a bit too complicated to be definitive :-/ (Except that iter_changes will only give you the delta between two arbitrary revisions and I don't think that address your "for 20 (mainline) revisions at a time"
<vila> Do you need (or use) the revnos ? That can make a difference, and if you use them, you'd better *not* call log -v multiple times
<beuno> vila, right, I need it per mainline revision
<beuno> I only use revnos for the mainline, so it's fine
<beuno> vila, http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/changes
<beuno> that's the page
<beuno> all the information you see there is what we need to get
<beuno> and, if you're interested in peaking at the file: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/annotate/247?file_id=history.py-20061211064342-102iqirsciyvgtcf-5
<beuno> vila, maybe it's _get_deltas_for_revisions_with_trees?
<beuno> it says "This is copied from bzrlib.", but I suspect that comment is from the 1980's
<beuno> (sept 2007, actually)
<vila> beuno: right, you don't use log -v :-) You use bzrlib :)
<beuno> right
<beuno> but I'm hoping that improvements to one will trickle down
<beuno> :)
<beuno> wishful thinking?
<vila> No, you're right. But my remark about revnos doesn't apply then.
<vila> and changes_from calls iter_changes 2 levels down :)
<beuno> right
<beuno> so, "I'm screwed"
<vila> beuno: nooo, just be patient ;-)
 * beuno hugs vila and goes back to the launchpad bug sprint
<beuno> will I see you at UDS?
<vila> beuno: no
<beuno> ay...
<beuno> we need a bzr sprint soon then!
<Kobaz> sprinting eh
<Kobaz> what do you guys use for tracking your scrums
<beuno> always!
<Kobaz> we use scrumworks
<beuno> we use... wikis and drawings?
<Kobaz> ah
<Glenjamin> hey guys, i'm looking at setting up a smart server, and i'm hoping to get some sort of authenticating system where various branches can be read-only, private or public
<Glenjamin> is there any existing wsgi sorta thing i can just drop in?
<Glenjamin> ie: something a bit like lp, where if you push to ~user/project/branch, it knows what to do
<tristil> Does anyone use nested trees? I've had trouble getting a straight answer googling around, so I'm guessing no.
<Kobaz> i like little forests
<beuno> tristil, bzr doesn't support nested trees yet
<beuno> LarstiQ is the mastermind behind it
<beuno> but hasn't finished yet
<tristil> Kobaz, I thought I liked subtrees but nested trees appears to be the best I can get.
<tristil> beuno, Thanks the various references on the web and the different formats are confusing.
<tristil> So people use configmanager instead for composite projects?
<Kobaz> i dont even know what i want yet
<Kobaz> so far i've got
<Kobaz> projectcontainer/project/repo/trunk
<tristil> Kobaz, but what's in projectcontainer? Is it a bzr repo/branch?
<Kobaz> it's just a directory
<Kobaz> like, a second order grouping of projects
<Kobaz> like
<Kobaz> web/mainwebsite/core/trunk
<Kobaz> web/mainwebsite/modules/trunk
<Kobaz> web/internal/core/trunk
<tristil> Oh, well, what I really want is just svn:externals. I guess I can just keep adding, removing and exporting my subprojects.
<Kobaz> aww, there's no externals in bzr?
<tristil> That's what I thought nested trees were.
<tristil> Of course, in Rails/Ruby they use a tool called piston to check in the externals anyway.
<tristil> So you can freeze at a revision.
<Kobaz> ah
<Kobaz> dustybin: lvextend is a safe operation
<Kobaz> er
<dudus> is there a way to make nautilus integration work under ubuntu?
<jelmer> dudus, the bzr-gtk ubuntu package is b0rked
<jelmer> there's an open bug about it
<dudus> yeah I just subscribed to it
<dudus> jelmer: I think it may be solved on debian
<dudus> I think It's broken since gutsy
<jelmer> Yes, it is solved in Debian
<jelmer> dudus, nautilus-bzr was not enabled in gutsy intentionally iirc
<dudus> jelmer: why?
<jelmer> dudus, it slowed down nautilus too much
<dudus> ahn the good old synchronous programming
<jelmer> nautilus-bzr isn't any better now, but we added a button to allow users to disable it
<jelmer> the main problem is that the nautilus extension API is just too poor
<dudus> jelmer: nice
<LeoNerd> I'd like to split apart the files in a branch, into two branches. There's no particular logic to which goes where, other than my judgement... I could just branch it twice, then delete half the files in each side, and go on from there.. but is there a nicer way?
<lifeless> LeoNerd: what you described is appropriate
<LeoNerd> I've also seen 'bzr split'.. not sure about that
<jelmer> LeoNerd, that splits out a specific directory, so would require you to move all of the files for one of the branches into a directory first
<LeoNerd> Ahh... Hrm.. I suppose I could do that
<jelmer> LeoNerd, and the result is similar to what you described
<LeoNerd> Ohright
<LeoNerd> OK.. So.. I've now created my two new branches on my server, each with their respective halves of the files... How to "close" the original branch, disallow further commits?
<jelmer> chmod?
<LeoNerd> Ooh. that'd work
<lifeless> LeoNerd: or rm
<lifeless> LeoNerd: but someone can always branch from the old branch and do commits; fortunately bzr will merge happily into both new branches
#bzr 2008-11-29
<spiv> abentley: it looks like bundlebuggy's mail queue is growing without any new mail getting processed?  http://bundlebuggy.aaronbentley.com/mail
<abentley> spiv: fixed.
<ToyKeeper> Hmm...   I could have sworn there was a "--date" option for commit.
<ToyKeeper> Looks like this will be as fun as setting the mtime on a symlink.
<Enisseo> hello everyone!
<Enisseo> I have a problem Google could not solve
<Enisseo> does anyone ever tried to post/publish a bzr directory (sub directory of a branch) to a ftp server?
<Enisseo> did* try*
<CaMason> I was wondering.. say somebody committed a huge file, would it be possible to remove that file from the repo?
<CaMason> I know that's near impossible with svn
<Enisseo> maybe using bzr remove YOUR_FILE --force
<Enisseo> CaMason: (never done that, but I would say it is technically possible, so maybe this "--force" option would do the trick, or a plugin)
<CaMason> Enisseo: ok. I work with large flash / photoshop files quite often, and sometimes my designers can input a 400MB FLV file by accident. It would be great to be able to remove that to keep the repo size to a minimum
<Enisseo> CaMason: if you do not want any .flv (or .psd) file to be committed, you can use the bzr ignore command
<Enisseo> CaMason: but if you only need to limit the size of committed files, I don't know (plugin? configuration file?)
<CaMason> Enisseo: It's not an exact science, as we DO need to add certain FLVs and PSDs of varying sized. It's things like placeholder/test items that were accidently placed in, that are of the wrong size
<CaMason> usually the FLVs are embedded within the .fla files when testing, and these are sometimes accidently added
<Enisseo> CaMason: if you can't find a "pattern" (subdirectory, extension, file size...) the files you do not want to add (or want to add) follow, the filter can not be made
<Enisseo> CaMason: anyway, the bzr ignore command prevent - I think - adding files accidentally, but you still can add them if you do it explicitly
<Enisseo> CaMason: for example, to prevent committing files with huge size (psd, flv), you set a ignore rule on .flv and .psd files
<Enisseo> CaMason: but if you need to add some .psd or .flv files, you can still commit them
<Enisseo> CaMason: this will work fine if you don't often need to commit PSD and FLV
<Enisseo> (I'm not sure you can add files that match an ignore rule, but tests will tell you)
<CaMason> Enisseo: sure, I understand you. But that wont help for my current workflow :)
<CaMason> It's not a problem for me atm.. I'll read up about it another time. Thank you
<Enisseo> CaMason: sorry I could not help you... maybe someone will, another day ;)
<hmeland> "bzr add foo" will add foo, regardless of whether it matches an ignore rule or not.  "bzr commit" will commit all added files, regardless of ignore rules.
<Enisseo> thank you :)
<Enisseo> My problem: I want to publish files of my branch to a ftp directory
<hmeland> To remove files from history, you'd have to "rebuild" that history, while omitting the parts that you don't want.  Bazaar doesn't have any built-in support for such operations.
<hmeland> The "rebase" plugin is somewhat handy, though.
<CaMason> hmeland: ok, nice :) I'll read up about it later on
<Enisseo> The files are mostly PHP files, so I want bzr to act like a "website publisher"
<Enisseo> Is this possible?
<CaMason> Enisseo: http://bazaar-vcs.org/BazaarForWebDevs
<hmeland> Enisseo: AFAIK, bzr works on the full tree; if you want to publish just a subtree, you're free to do so using other mirroring tools.
<hmeland> Depending on what you mean by "publish", I guess...
<Enisseo> I mean "copy files", not publishing a branch
<Enisseo> In fact, I could do so "manually" by uploading an exported directory (export) of my branch
<hmeland> Ok, then what I said above stands -- I'm not aware of anything in bzr that will help you with that publishing operation.
<Enisseo> but I thought bzr would do that, only committing changed files
<hmeland> Uhm, are you saying that you want to _automate_ publishing of that subtree whenever you commit?
<Enisseo> no
<Enisseo> Well, my workflow would be:
<hmeland> Then you've lost me. :-)
<Enisseo> 1. I commit files locally
<Enisseo> 2. I finish adding features and fixing bugs so I could release a new version of my project
<Enisseo> 3. => I "push/publish" the project into a prototype directory on my ftp server
<Enisseo> 4. I fix last bugs that appear while testing the prototype
<Enisseo> 5. => I "push/publish" the project into the production directory on the ftp server
<Enisseo> 6. I tag the branch
<Enisseo> the push/publish operation is manually "launched", but yes, indeed, I want bzr to automatically copy files that have changed between two publishing operations
<bob2> bzr-upload plugin
<Enisseo> bob2: the name sounds nice :)
<AfC> Yeah, you want the upload plugin
<AfC> (orthogonally, do you *really* need to tag every time you publish?)
<Enisseo> AfC: Hmmm... no
<Enisseo> AfC: But what do you think is wrong with that
<Enisseo> ?
<AfC> Manageability
<AfC> Enisseo: if you have several thousand tags it gets out of control
<Enisseo> AfC: I do not want to tag every commit I made, only when I publish what I think is a new version
<Enisseo> 0.1, 0.2, 1.1, 1.2...
<bob2> why bother?
<AfC> Enisseo: and there may be scaling problems with hundreds of thousands of tags, I can't remember if that was addressed; it strikes me as the sort of thing that isn't really wise because it's going to be high O()
<bob2> just have a branch where each commit is a "publish" state
<bob2> all done
<AfC> Enisseo: if you're just doing "versions" then that's fine, of course
<AfC> Enisseo: I've seen people do an automated tag with a date string or some other nonsense, and then complain that the 14,000 tags they have are in the way.
<AfC> bob2: well, if the history is linear that won't quite cut it
<AfC> a merge isn't necessarily a prerequisite to Enisseo publishing.
<AfC> but that saidm
<AfC> said,
<AfC> for people that really are desperate to have huge numbers of "tags", an alternative is
<AfC> to just make an empty (no changes) commit with a commit message indicating $whatever.
<AfC> THAT will scale just fine, of course.
<Enisseo> what's the difference between tagging and branching with bazaar?
<AfC> er
<bob2> mostly unrelated
<bob2> branch is a, well, branch, tag is just a label pointing at a particular commit on a branch
<Enisseo> I thought a tag in bazaar was just a branch
<bob2> no
<Enisseo> well, a named branch
<AfC> no
<Enisseo> ok
<bob2> svn is the only system like that, afaik
<AfC> {sigh}, Subversion screwing up the name space strikes again
<AfC> Enisseo: you can take a branch from any revision
<Enisseo> I must have read that from svn, indeed
<AfC> Enisseo: there are many ways to _identify_ revisions
<AfC> Enisseo: tags are one of them.
<AfC> (dates are another, etc)
<AfC> I commonly do stuff like
<AfC> $ bzr diff -r tag:v4.0.9
<Enisseo> so, if a tag is a label of a commit, many tags are just hard to manage, but it does not affect performances, does it?
<AfC> to find out what I've changed from the last release
<AfC> another *really* useful one is
<AfC> $ bzr diff -r ancestor:../mainline
<AfC> to see what is different about this branch (from a contributor, say) without worrying about what has moved on in 'mainline' in the mean time.
<Enisseo> the "bzr diff -r tag:v4.0.9" command is what I have in mind
<AfC> Enisseo: sure... but if you're only doing one or two revisions per release, and *frequent* releases, then I imagine you can see the utility dropping.
<AfC> on the other hand if you don't do that many "releases" then you're all fine.
<AfC> Enisseo: hard to manage (lots of tags), definitely (where lots >>> 100)
<AfC> Enisseo: I can't say off hand what the performance impact is
<Enisseo> ok, thanks for the advice ;)
<AfC> I have a nagging feeling that someone was complaining about it, but I also recall they had like 100,000 tags
<AfC> and were upset that bzr log was slow :)
<AfC> if you're not already at hundreds of thousands of revisions, and gigabytes of repository, and tens of thousands of tags, I doubt you'll notice any performance problem.
<mathrick> jelmer: hmm, why does bzr init in a directory below an svn checkout (but not versioned itself) invoke bzr-svn?
<jelmer> mathrick, what version of bzr/bzr-svn ?
<mathrick> jelmer: how do I check bzr-svn version?
<mathrick> (it's not my copy y'see)
<jelmer> mathrick, if you know the bzr version, that should be sufficient
<mathrick> ok, it's 1.9
<mathrick> jelmer: btw, it seems to segfault on bzr init after upgrading to (python-)subversion 1.5.1 (from 1.4.6)
<jelmer> mathrick, so you have a svn-versioned directory and one of the children paths has a .bzr directory?
<mathrick> jelmer: no, I have a svn-versioned directory, and it has a non-versioned subdir that I (or my friend, actually) wants to init as a bzr repo
<jelmer> mathrick, in that case, this is expected behaviour
<mathrick> he doesn't care about the svn-versionedness of the parent
<mathrick> jelmer: what purpose does it serve?
<mathrick> and, how can I disable it?
<jelmer> mathrick, sorry, forget that
<jelmer> mathrick, I can't reproduce this
<mathrick> jelmer: hmm
<mathrick> jelmer: I'll try to get a reproducible example for you, sec
<mathrick> jelmer: okay, I have a minimal dir structure that segfaults for me as well
<mathrick> (bzr 1.6.1 / svn 1.5.1)
<jelmer> mathrick, Have you tried 1.9 ? Several things have changed since then
<mathrick> jelmer: yes, said friend runs 1.9
<mathrick> jelmer: http://sei.meidokon.net/files/foo.tar.gz
<mathrick> unpack it, go to foo/bar/, try to bzr init there
<mathrick> it segfaults
<jelmer> mathrick, works fine here
<mathrick> in earlier svn (1.4.6), it'd say the subversion client is too old
<mathrick> humm
<mathrick> are you running ubuntu?
<jelmer> no, debian
<mathrick> then it seems like something is broken in ubuntu packages
<mathrick> jelmer: is it invoking bzr-svn at all for you?
<marcus-b> Hi, I upgraded from bzr 1.3 in Ubuntu 8.04 to bzr 1.6.1 in Ubuntu 8.10, and now I get weird upgrade notices and errors on upgrade: http://pastebin.com/m15418d7  What should I do?
<jelmer> mathrick, no, it doesn't touch bzr-svn
<jelmer> I'm running bzr 1.10 though, not 1.9
<beuno> marcus-b, try:  bzr upgrade --rich-root-pack
<marcus-b> thanks, that seems to work.  was it a mistake to use rich-root?  what's the recommended format for new repositories?
<beuno> marcus-b, also remember to upgrade both your branches and your shared repository
<beuno> why did you choose rich-root?
<marcus-b> I don't remember.  I think I just chose the latest/greatest at the time
<marcus-b> I want to go with the masses, no special requirements
<beuno> jelmer, there's no way to go rich-root -> packs, is there?
<jelmer> beuno: rich-root-pack
<jelmer> beuno: there's no particular reason to go back from rich-root though
<james_w> jelmer: you patch allows you to upgrade an svn checkout to be a bzr branch?
<beuno> well, PITA, but yes  :)
<marcus-b> so the new cool kid on the block is packs? :)
<jelmer> james_w, It's one of the required steps - I'm not sure whether bzr-svn's implementation of Converter works well enough yet
<james_w> jelmer: madness :-)
<beuno> marcus-b, actually, it's "1.9" format, but I'd say you take it a step at a time  ;)
<marcus-b> yeah, thanks ;)
<marcus-b> so how about I go to 1.6.1-rich-root ?
<jelmer> marcus-b, any reason for going with 1.6.1-rich-root rather than 1.9-rich-root?
<marcus-b> well, ubuntu 8.10 ships with 1.6.1
<marcus-b> so, if there isn't a strong reason for a manual update or override...
<marcus-b> ok, I am taking the ppa ubuntu repository, that's convenient enough for me
<beuno> that's what I do  :)
<marcus-b> can I move away from rich-root?
<bpierre> hi
<gerel> hey all, short question, if I have changes in one file in this order, rev1 => rev2 => rev3, when I try to see changes between rev1 and rev3, all is fine, now when I try to see, whether the changes were made between rev1 and rev2 or rev2 and rev3, bzr outputs nothing!, does that make sense?
<gerel>  shouldn't there be a transitive property ?
<gerel> well, solved, the thing is that "-rREV1 -rREV2" isn't the same as "-rREV1..REV2", I thought it was
<Flimm> How can I tag a commit with a launchpad bug?
<beuno> Flimm, maybe what you're looking for is: bzr ci --fixes=lp:1111
<beuno> or maybe it's  --fixes lp:1111
<Flimm> Thanks bueno, you're always here when I need help!
<CaMason_> if I need to move my central branch to a different server, can I just copy/paste it?
<bpierre> if it's a standalone branch, yes, it should work
<CaMason_> time to try, then :)
#bzr 2008-11-30
<CaMason_> ack I just did a revert when I didn't mean to. Can I undo that?
<CaMason_> nv I found a way to fix it
<ym1> I would like to know if there is a place where the installation/configuration of loggerhead is documented
<ym1> In fact I am looking for a bzr branch explorer
<ym1> Based on what I read on Internet it seems that loggerhead is the defacto standard for this
<GPHemsley> is there a way to convert an existing repository to use --no-trees?
<evarlast> yes, bzr remove-tree
<ryanakca> Could one have a ``safepoint'' commit that doesn't show up in the commit log, but only acts as an ``Oh !&^#%, why did I do that... at least I can revert to what I had 5 minutes ago instead of having to revert to the previous commit''... or should I just commit more often?
<ryanakca> Use case: When you're trying to fix something through trial and error
<spiv> ryanakca: well, you can commit and then later uncommit then commit again.
<spiv> ryanakca: But really, why not just keep the commit?
<ryanakca> spiv: well, if you're going by trial and error, you might endup with 3-4 ``safepoints'' that are absolute rubbish and have no use in a commit log, at least not in a public one :)
<spiv> ryanakca: maybe.  They might not be totally worthless, and there isn't much harm from leaving them there.
<ryanakca> spiv: *nod*
<spiv> ryanakca: especially if this is happening on a branch, when the branch is merged to trunk the details of how that branch evolved aren't very prominent in the history.
<spiv> If you're working directly on trunk then that's a different matter, but then I'd argue you should be taking advantage of a DVCS and using branches instead :)
<spiv> You could even manage your experimental work on your branch as another branch, but that workflow is probably a bit too heavyweight for what you're after.
<ryanakca> spiv: well, I'm the only one working on it at the moment... but it will eventually end up being used in my school, and most likely other schools in my school board...
<ryanakca> spiv: Anyways, I probably ought to branch when I go by trial and error :)
<ryanakca> G'night :)
<spiv> ryanakca: g'afternoon ;)
<spiv> (It's a bright and sunny 4pm here in Sydney)
 * thumper votes for default log to be short (no merge details)
<spiv> thumper: bzr alias log="log --short"
<thumper> spiv: yes I know#
<spiv> :)
<thumper> spiv: I'm thinking of all the new users
<thumper> all those people who go "gee bzr log is slow compared to xyz"
<spiv> "Won't somebody think of the newbies?"
<thumper> spiv: that way people can go "bzr log --merges" to show merges (or something)
<spiv> (Sunday afternoon perhaps not the best time to get a completely serious opinion from me)
<thumper> and they can take the hit of the graph sort or whatever
 * thumper was reading traceback
<spiv> We don't get many people saying the log is slow (although we do get some).  And arguably the solution there is to make it fast, not change the output.
<thumper> spiv: yeah, but one is easier and allows for better comparison of apples
<spiv> I do think the default log should make the existence of merges visible, so that the way merges are tracked is reasonably discoverable.
 * thumper goes to make brownies
<spiv> Well, we're not trying to build a tool that's the same as $other_vcs, we're trying to build a better tool :)
<spiv> So I don't think that's automatically a good reason to change how we work.
<hiredman> a better tool that interoperates so I can pull stuff from github?
<spiv> Personally I use --line most of the time.
<thumper> I think someone should check to see who actually cares to see the merges by default
<thumper> spiv: I use --line too
<thumper> hiredman: that is in progress
 * thumper really leaves now
<hiredman> I know
<hiredman> I am just being an asshole today
<spiv> And then "bzr viz" for more in-depth exploration of history, but not every user will have the bzr-gtk plugin (or the ability to install it).
<epsy> Hi, how do I cleanup the .~n~ files?
<AfC> $ find . -name '*~*'
<AfC> $ find . -name '*~*' | xargs rm
<marcus-b> better: find . -name "*~*" -print0 | xargs -0 rm
<epsy> brb
<LarstiQ> beuno: hmm, I wouldn't say I'm the mastermind
<LarstiQ> marcus-b: hey! :)
<LarstiQ> epsy, marcus-b: `bzr clean-tree --detritus` would also remove the .~n~ files
<marcus-b> LarstiQ: I don't know bzr well, but I do know my unix tools :)
 * LarstiQ nods
<pygi> hi hi
<DimmuR> Hello i'm trying to run bzr+ssh. I've created directory on server, and i have entry in authorized-keys to copy files without giving passwords, but when i try to init repo i get error: http://wklej.to/MV3 (when i use scp to copy files it works)
<CaMason_> I just got a commit error regarding x11 initialisation whilst commiting via SSH
<CaMason_> I installed extdiff earlier. Perhaps that's causing the issues?
<dash> I've got a large branch I've cloned from a remote source, and now i'm wishing I'd created a repository for it to go in. Is too late? Can I create a repo without having to re-fetch all that history?
<pbor> create a new repo and then fetch from the one you cloned locally
<dash> oh. of course :)
<CaMason_> my commit actions etc are causing "X11 initialization failed" errors when used via SSH
<pbor> CaMason_: no idea, sorry
<CaMason_> it was a problem with dbus. Removing it, as I don't use it
<ryanakca> marcus-b: <offtopic> 'find . -name "*~*" -print0 | xargs -0 rm'    vs    'find . -name "*~*" -exec rm {} \;'    ? </offtopic
<dash> Hmm =/
<dash> I am attempting to branch from an svn repo on sourceforge, using bzr-svn
<dash> and i'm consistently getting "Could not read response body: Connection reset by peer" after several minutes
<dash> is there something I can do to make bzr not give up so easily? :)
<jelmer> dash, it's the svn libraries that are giving up
<jelmer> dash, are you fetching over https?
<dash> jelmer: no.
<jelmer> your best bet is probably to wait until the sf svn servers are less heavily loaded
<dash> I suspect a contributing factor is that /trunk (which I am branching from) in this repository was moved from a different url in an early revision
<dash> different path, I mean
<jelmer> that shouldn't be relevant
<dash> well
<dash> it looks like bzr-svn does a lot of PROPFINDs for nonexistent paths
<dash> I didn't know if that mattered.
<jelmer> you mean it's actually getting 404's back?
<dash> yes
<jelmer> what's the URL you're trying to import?
<dash>  http://posterita.svn.sourceforge.net/svnroot/posterita/trunk
<dash> so i'm seeing a lot of things like "PROPFIND /svnroot/posterita/trial/posterita"
<dash> to which 404s are given
<dash> I'm just guessing that this is making it take longer, so make it have more chance to disconnect :)
<jelmer> it doesn't ignore unexpected errors like that, I suspect that's all happening deep down in the svn libraries
<dash> right
<jelmer> dash, it seems to be working with the 0.5 branch for me, though it's very slow because of sf
<dash> aha, the secret version ;)
<dash> well i'm not in a hurry, I just want to get it eventually.
<dash> hmm if that were true I would just wait until 0.5 was released
<dash> I guess I am in a hurry, a little.
<dash> jelmer: so, think I should try 0.5?
<lifeless> moin
<thumper> ah lifeless, you back this week right?
<thumper> lifeless: can I have a quick voice call with you?
<lifeless> sure
<lifeless> skype, now?
<thumper> ok
<lifeless> ?win 38
<lifeless> Peng: I wonder if I could convince you to do me a favour?
<Peng_> lifeless: I dunno. What's the favor? :)
<lifeless> Peng: to decide on a good batch size, I need a graph with two measurements, for different batch sizes, and different project sizes
<lifeless> the measurements are memory peak, and time
<Peng_> I did that for a few different sizes on a copy of bzr.dev.
<lifeless> the axes are group_size and project_size
<lifeless> Peng_: yah, which I am thankful for, and is why I know I need to fix it
<lifeless> Peng_: but I don't currently know things like 'how bad is it at 1000 on openoffice'
<lifeless> Peng_: nor what the minima for bzr.dev is.
<Peng_> OpenOffice.org? I imagine that's "Peng's machine would die swapping" bad. :P
<lifeless> Peng_: so I'm thinking of a little script to reindex a branch several times with a different group size, and report the results in csv or similar output
<lifeless> Peng_: of course, I'll run this on a canonical datacentre machine
<lifeless> Peng_: the favour is to write the script
<Peng_> Ah.
<lifeless> then I can throw it at ooo, at mysql, at bzr, at bzrtools
<lifeless> Peng_: if you are interested this would be really useful.
<Peng_> I'm sure I could write some little hack of a script, but I dunno if you'd like it. :P
<Peng_> I guess it would need to be possible to set group_size. I just edited index.py a bunch of times.
<lifeless> Peng_: just has to work. Heck, I was considering a massive printf to replace the index.py file
<lifeless> Peng_: sed would probably be nicer :P
<Peng_> Or making it an attribute on Index objects that you could change from Python.
<lifeless> hi poolie
<lifeless> Peng_: sure.
<lifeless> Peng_: or even - shock - a global
<lifeless> so you don't have to get access to a specific index
<Peng_> Oh, different methods have different group_sizes.
<lifeless> yeah there are two
<lifeless> there is 'how many revisions', where the inventory text size will chew up memory
<lifeless> and there is 'how many file versions at once', where text sizes (isos!) will chew up memory
<Peng_> I've never changed it in _terms_for_file_terms.
<lifeless> sure
<lifeless> whats in my head is to not guess about what works well for users
<lifeless> but to graph it out, and choose the place that works best
<lifeless> the two group sizes are independent
<lifeless> well, not quite.
<Peng_> Well...do you want to test both, or just the _index_revisions one?
<lifeless> the file terms is capped by the index revisions one (can't index morefile changes than occured in a given set of revisions)
<lifeless> I'd start with the index revisions one, that should give plenty of data
<lifeless> though it may be confounded (a large index revisions one might use little memory, if the file terms one is driving the peak)
<mwhudson> does anyone have any recommendations for good conflict resolution tools?
<lifeless> guns
<lifeless> lots and lots of guns
<lifeless> It worked in the matrix.
<mwhudson> hmm
<mwhudson> i think i want meld and a much larger monitor
<bob2> sdiff/ediff in emacs is nice if you already use emacs
<mwhudson> ediff confuses me a bit
<mwhudson> what's sdiff?
<mwhudson> i think the problem is that one branch has moved things around and the other has made small edits to the things being moved
<bob2> simple mode that highlights in-file conflicts, with some keybindings to pick one or the other or both for each hunk
<bob2> ah, out of that league, then
<lifeless> spiv: shall we converse?
<poolie> lifeless: spiv is away at osdc today
<poolie> you and i could talk though
<lifeless> oh!
<lifeless> didn't realise osdc was here
<lifeless> should I go down?
<lifeless> poolie: you're on leave no? but perhaps a quick call could be useful
<lifeless> poolie: I'll ring your house?
<spm> poolie: osdc doesn't start till tomorrow? Or is spiv on the org committee or similar?
<poolie> yes, call
<mwhudson> osdc starts for realz on wes
<mwhudson> weds
<mwhudson> spiv just took the week off anyway i think
<poolie> planning to look at bug 302698
<ubottu> Launchpad bug 302698 in bzr ""BzrCheckError: Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0x2e23f90> has delta references to items not in its repository:" on pushing a stacked branch" [High,Confirmed] https://launchpad.net/bugs/302698
<Peng_> lifeless: OK, I wrote an evil little script for the bzr-search thing. I hope you weren't joking about running "sed" over index.py. ;)
<Peng_> lifeless: Also, if it gets interrupted, things will probably be left in a horrible mess.
<mathrick> hmm, does anyone here know (and is willing to explain) the difference between a transplant and a normal merge, or do I need to pester #hg?
<Peng_> mathrick: AIUI, transplants can cherrypick, but it'll create a different revision with different revids and parents and whatever.
<Peng_> (if we're talking about hg)
<mathrick> Peng_: hmm, I'll guess I'll just ask the hg guys then
<Peng_> Good idea. :)
<lifeless> Peng_: thanks!
<lifeless> poolie: I need to shoot off to the doctors too today, I forgot to mention it in all the kufuffle
<mathrick> any idea how hard it'd be to implement "add-on branches" (as mentioned in https://lists.ubuntu.com/archives/bazaar/2008q4/050022.html )? It strikes me as something you'd really want to have to keep your distro work in sync with upstream
<mathrick> or is there something I'm not seeing that makes it not a good / redundant idea?
<Peng_> lifeless: http://paste.pocoo.org/show/YkaM3FCdH5ILeNUOlV0h/ -- did I mention that it's an evil dirty hack and you probably won't like it? :)
 * Peng_ is trying to lower expectations as much as possible.
<poolie> mathrick: it's probably not technically super hard, more a matter of deciding how you want it to work
<poolie> robert's idea of having marks of files or regions would probably be good
<mathrick> poolie: oh, link?
<mathrick> also, I was thinking about strands of development a'la threads in loom
<mathrick> just with the opposite effect on your working area
<lifeless> mathrick: using a loom and cherrypicking down would do it
<mathrick> lifeless: could you elaborate? I tried to use loom, but decided it does exactly what I don't want with the history when I change threads
<lifeless> mathrick: well the root problem you have is that its impossible to do a full merge/push from 'development' to 'mainline' *excluding data*.
<mathrick> yes
<lifeless> full merge/push always include everything committed
<lifeless> so you have to cherrypick repeated - do merges specifying paths to merge, or specific revisions
<mathrick> yup
<mathrick> I could do it using loom by hand, but it'd require me to switch between threads to get "development" and "testing" views all the time, which is a pain
<lifeless> Peng_: sweet
<mathrick> ie. I couldn't actually run any code when in development thread, and I couldn't edit any when in testing thread
<lifeless> mathrick: I don't understand why you couldn't run code
<mathrick> lifeless: sec, lemme sketch that
<mathrick> lifeless: http://pastebin.com/m23f854c8
<lifeless> mathrick: edit and commit in testing
<mathrick> lifeless: but then the changes will be only visible in testing, which means the pushes won't see them. They will be treated as if they were my local conf changes
<lifeless> mathrick: when you are done, you can go to main, merge -r testing path1 path2
<mathrick> hmm, lemme parse that
<mathrick> what's path1 and path2?
<lifeless> mathrick: you have to cherry pick testing to main, regardless of the toolchain you use, for your stated desire
<lifeless> paths that you want to merge within the branch
<lifeless> another way of spelling it is
<lifeless> switch main; merge -r thread:testing
<lifeless> bzr revert --forget-merges
<lifeless> bzr revert server.conf
<lifeless> bzr commit -m 'whatever'
<lifeless> mathrick: have you considered 'shelve' though?
<mathrick> right, but that's exactly what I wanted to avoid. It's heaps of manual work, and if I forget it only once, I have unwanted commits in the mainline I have to deal with
<mathrick> hence the desire to have a tool which keeps track of what I want and don't want to merge for me
<mathrick> loom is very nice for when you only merge downstream, but it fails to enable a nice workflow for pushes to the upstream without polluting them with distro patches
<lifeless> mathrick: so, loom isn't finished; I think this would be great to have streamlined in loom
<lifeless> there are missing components in bzr core to do a *great* job, but a servicable one should be doable
<mathrick> lifeless: right, I'd love to have it in loom, although it'd really turn it upside down in some regards
<lifeless> the current theory is that you would keep one or more threads for 'never send upstream'
<lifeless> as for how you do the commits, I'd like a commit like 'commit -t main'
<lifeless> to commit a change to a specific thread
<mathrick> right
<lifeless> it probably would want to merge-it-up on the fly
<mathrick> what does merge-it-up mean?
<mathrick> now, for something completely different, I have a repo that bzr serve completely dies on -- it uses 500+ MB RAM, then dies with some exceptions when clients try to access the repo. How do I debug it?
<lifeless> merge each thread to the one above, so that the change does not appear as a change any more
<mathrick> I guess I'll start for finding 1.9 debs for intrepid
<lifeless> mathrick: well, firstly, newer bzr has fixed some memory issues from 1.6/1.7/1.8
<lifeless> mathrick: file a bug with the exceptions though
<mathrick> lifeless: you mean before I upgrade to 1.9?
<lifeless> yah
<mathrick> ok
<lifeless> if the server side is dying
<lifeless> (and the server is already running 1.9)
<mathrick> no, that's the 1.6
<lifeless> upgrade the server first then
<mathrick> I'm trying to serve from my machine
<lifeless> there are debs in the bzr ppa
<mathrick> oh, interesting
<mathrick> it dies right away now
<mathrick> http://pastebin.com/d73b4f039
<lifeless> mathrick: ugh
<lifeless> mathrick: uhm, can you run with BZR_PDB=1
<mathrick> sure
<lifeless> then you can print self._sockname
<mathrick> (Pdb) self._sockname
<mathrick> ('::', 4155, 0, 0)
<mathrick> humm
<lifeless> I'd certainly start by filing a bug, but it does look ... odd
<mathrick> it's getting an ipv6 socket?
<lifeless> yeah that would fit
<lifeless> definitely file that bug
<mathrick> will do
<mathrick> still, it'd be useful if I could serve in the meantime :)
<lifeless> comment out that line, or just print the _sockname, rather than prettyising it
<lifeless> e.g.
<lifeless> return "%s" % self._sockname
#bzr 2009-11-23
<maxb> igc: Hi. When you have a moment, could you take a peek at my fastimport MP?  https://code.edge.launchpad.net/~maxb/bzr-fastimport/branch-mapper-stuff/+merge/14594
<igc> hi maxb: shall do.
<maxb> thanks
<igc> james_w: what's the timeframe for changes landing into bzr-builder's trunk? Are you back home now or still travelling?
<lifeless> igc: hes on leave for a week
<lifeless> igc: and there is a backlog :P - I have a month old patch now :(
<igc> james_w, lifeless: I've got some doc and minor code changes ready to go in. I'm asking because if that backlog :-)
<james_w> things will be leapfrogging rob's change as I have time to merge them
<igc> lifeless: maybe I should submit them over a non-trunk branch?
<james_w> I reviewed some on the plane yesterday, but as LP doesn't send you a merge proposal I couldn't merge them
<igc> hi james_w
<james_w> hi igc
<igc> james_w: https://code.edge.launchpad.net/~spiv/bzr-builder/merge-subdirs-479705 looks like it builds on Rob's patch
<james_w> I'll make it ~bzr-core owned or something one day
<lifeless> igc: it does
<igc> james_w: is that still to be reviewed?
<lifeless> igc: that builds on one of my patches. the really old one is more complex and not relevant for the lp daily builds project
<james_w> I'd just like to play gatekeeper for a while so that we can learn what the project is
<james_w> it is still to be reviewed
<james_w> I have some comments that will make it resubmit, but I asked for the merge proposal early anyway, so we could discuss whether merging subdirs is something that should be supported
<igc> james_w: my doc tweaks can go over trunk easily
<igc> james_w: my code changes are pretty trivial so I'll submit those over trunk as well
<james_w> please do
<igc> james_w: I just wanted to minimise merge pain for both of us if you were about to release a new trunk
<igc> given six branches are more recent than trunk, I thought it was worth asking. Anyhow, enjoy your break james_w!
<james_w> oh, this new prerequisite branches feature is confusing
<james_w> it's cool and all
<james_w> but I reviewed this diff I was sent, the mail said nothing about prerequisite branches, and then the diff I got when I merged was a lot larger than I reviewed
 * james_w goes the other way
<lifeless> james_w: start at the branch with no prerequisite
<james_w> well, yeah
<james_w> when was permit_dir added?
<lifeless> context?
<lifeless> oh, the test suite?
<lifeless> a few months back now
<james_w> time to make dinner anyway
<thumper> james_w: please file a bug about the prerequisite info missing the email
<idnar> how do I figure out what merge algorithm bzr merge is using?
<lifeless> idnar: default is 3-way, anything else is what you told it
<idnar> ah, okay
<idnar> the help should probably mention that
<AfC> I have http://paste.pocoo.org/show/152361/ in my .vimrc; on Gentoo it used to work that when `bzr commit`ing it would [among other things] set tw=70.
<AfC> For some reason having switched to Ubuntu this doesn't work anymore, though other things in .vimrc are being picked up.
<AfC> Anyone have even the vaguest notion of why this might not be working, and what I might try doing to re-enable it?
<lifeless> you might need set nocompat at the top o the .vimrc
<AfC> lifeless: Hm. Well, /etc/vim/vimrc seems to suggest that Debian has compatible on. I'll try your suggestion right now, though
<idnar> I think by default, "vi" will run vim in vi-compat mode, whereas "vim" won't
<idnar> but I could be confused
<AfC> idnar: really? oh, that could be the problem
<lifeless> I've found that I need set nocompat at the top for things to consistently work right
<AfC> aside: vim.basic, vim.tiny... is there a third I should have installed, vim.kitchen_sink? :)
<spm> AfC: that's vim.scripts I think you mean... ;-)
<AfC> spm: just extrapolating from what `update-alternatives --display vi` had to say :)
<spm> heh
<lifeless> spiv: note that stuff submitted on the 20th is still on your watch ;)
<AfC> Ok. Well,
<AfC> $ export EDITOR=/usr/bin/vim
<AfC> caused things to behave, but prefacing ~/.vimrc with "set nocompatible" does not seem to have had any effect
<idnar> maybe .vimrc isn't even parsed when it's invoked as "vi"
<AfC> so idnar seems to be on the right track, but I'd like `vi` to work properly, not to assume I have some nostalgia for the 1980s vi that we all loved to hate.
<AfC> Is there a Debian way to make `vi` be Vim as Vim? I thought that was the whole point of the alternatives system
<lifeless> vim is special
<lifeless> because the vi/vim behaviour is not separate packages, its 'how was I invoked'
<spm> AfC: "set nocompatible" in your vimrc - I believe should do the trick
<spm> alternately; just alias vi=vim for a Q&D override
<AfC> spm: as I just said above, that had no effect
<spm> gah. soory - missed that. bummer!
<AfC> spm: yeah, I'm trying to do this "right" (in Debian terms) rather than fighting the system
<AfC> spm: [I would have _hoped_ compatible / nocompatible would have done the trick, seeing as how that was originally [&upstream] the way to take vim and ask it to dumb itself down to classic behaviour]
 * AfC digs some more
<spm> AfC: strace it on startup? it may be trying an old style vi rc file. name eludes me atm. ??
<AfC> I guess I could set EDITOR
<spm> ew
<AfC> [better than alias, but still somewhat dirty unless done persistently system wide]
<lifeless> you should set EDITOR
<idnar> setting EDITOR seems reasonable to me
<idnar> I'm not sure why it would need to be system-wide, it's just a user setting
<idnar> I mean, setting EDITOR=vim isn't much different to, say, EDITOR=emacs
<AfC> idnar: why don't you just pretend for a minute that all the other users on the system want it to be the same
<AfC> [notably, that root fellow]
<AfC> lifeless: if that's what you recommend, that's what I will do
 * AfC goes off to learn about how Debian is handling /etc/profile these days
<lifeless> I set EDITOR so that I get the editor I want
<phcoder> Hello all. How can one prevent replacement of one branch by another on the server?
<AfC> lifeless, spm, idnar: thanks for your help
<lifeless> phcoder: do you mean 'make push prevent push --overwrite' or do you mean 'stop rm -rf' ?
<phcoder> lifeless: both in preference however I suppose for the second one would need bzr+ssh
<phcoder> (bzr+ssh only server I mena)
<phcoder> *mean
<lifeless> so filesystem permissions are the answer there
<phcoder> lifeless: but how exactly? We still want people to be able to do a non --overwrite push
<lifeless> oh
<lifeless> so you can set append_revisions_only in branch.conf - see bzr help configuration
<phcoder> lifeless: thanks
<Peng> Of course, people can do anything if they *really* want to.
<mwhudson> where's that no-vfs smart server
<phcoder> Peng: they can send a missile on server, sure ;)
<Peng> phcoder: Well yeah, but firing up hitchhiker or bzrlib and turning off append_revisions_only or outright manipulating files through the VFS is trivial.
<phcoder> Peng: if one has only bzr+ssh access can't one instruct daemon to ignore such activity and send a notification e-mail?
<Peng> phcoder: The VFS is necessary for some normal operations.
<phcoder> Peng: like? Couldn't one adjust bzr+ssh to handle it as well?
<Peng> phcoder: Examples? ...I don't know.
<Peng> phcoder: Of course it's possible (and ideal) to make everything use smart methods, but the work hasn't been done yet.
<lifeless> even if everything is smart
<lifeless> append_revisions_only is settable through the smart API
<Peng> \o/
<spiv> Though presumably it'd be easy to add a hookpoint that could restrict changes to branch config objects.
<Peng> When you run with -Dhpss, can you grep for VFS operations?
<spiv> Not trivially.
<Peng> Aww.
<spiv> Basically, they are the verbs without '.' in them.
<Peng> Ah. Yeah, that's bad.
<spiv> So something like "hpss call.*?'[^.]*?' I guess.
<Peng> Looks like 2 of the 3 VFS operations on one push I did were getting .bzr/branch-format and .bzr/checkout/format.
<Peng> Ah, then getting .bzr/bzr-search/format at the end.
<spiv> Well, that one would be bzr-search's fault ;)
<Peng> The others could've been the fault of plugins, too.
<spiv> Probably not :(
<spiv> You could try -Dhpssvfs if you're really keen.
<Peng> I'm kind of keen. Is that enough?
<spiv> Peng: try it and find out :)
<Peng> I just tried it on a different push. There was only the bzr-search one. :\
<lifeless> -Dhpss_vfs
<Peng> No underscore.
<Peng> (I don't care enough to reproduce the conditions of the original push. It's a bit complicated.)
<Peng> (Although I'll probably change my mind in a minute.)
<Peng> Just did it. push_branch tries open_workingtree calls has_workingtree calls _ensure_real.
<Peng> Dunno about the other one.
<Peng> I bet it didn't happen in my other test because the destination branch didn't exist.
<spiv> Peng: Hmm, I thought I fixed the open_workingtree/has_workingtree case.  Ah well.
<lifeless> spiv: with my fix you can see it ;)
<lifeless> spiv: different trigger I think, but yeh still bust
<lifeless> spiv: you're still piloting the things filed on friday, right?
<Peng> spiv: I still can't reproduce it with a test branch, though.
 * igc lunch
 * Peng unhappily munches on Cheerios
<spiv> lifeless: I guess so, although I'm not sure what a good way to track that is
<spiv> lifeless: possibly we should keep that info on the PatchPilot wiki page?
<lifeless> spiv: I'd say 'I'm piloting this' in a merge proposal you're piloting
<spiv> Hmm, yeah.
<phcoder> Thanks guys. Good night
* spiv changed the topic of #bzr to: Bazaar version control system | 2.0.2 and 2.1.0b3 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/ | Current pilot: lifeless
<poolie> hi spiv
<poolie> thanks for the report
<spiv> No problem.
<poolie> i think we should mention it, at a broader level, on the blog too
<poolie> OldAl: hi, still here?
<OldAl> poolie: Yes, apparently :)
<OldAl> (Actually, I was away - shame on me for not telling.)
<OldAl> menesis: Labas, biÄiuli (Koks graÅ¾us Å¾odis - "biÄiulis", nieko panaÅ¡aus neÅ¾inau kitose kalbose).
<OldAl> poolie: I am off to an afternoon nap - good for my. and all mine, health!  Be back in an hour or so.
<poolie> OldAl: i was just going to say
<poolie> you made a page about yourself called /wiki
<poolie> i'm just going to rename that to OldAl
<poolie> just so you know
<OldAl> poolie: That's b. disgraceful... Thanks for telling me. It was meant to be called "OldAl". Thanks for telling me.  The name probably can not be changed, can it?  If it is a problem to "move" it, just delete it, please.  I will need to read up on how to name a page.
<poolie> it's no problem
<poolie> it's now here
<poolie> http://bazaar-vcs.org/OldAl
<poolie> edit away
<poolie> possibly we should move all of them into /People/ though
<OldAl> poolie: That sounds a good idea. I probably can do that - just make a link to it and then copy via clipboard the contents of them; start with my own.
<OldAl> poolie: In about an hours time, please...
<DarkwingDuck> I have a question...
<DarkwingDuck> I'm getting an error when I try to branch a project.
<DarkwingDuck> Permission denied (publickey).
<DarkwingDuck> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<DarkwingDuck> This is only on my desktop. when I try it with my netbook it works just fine.
<poolie> DarkwingDuck: there's probably an error from ssh further up?
<DarkwingDuck> So, redo my ssh?
<spiv> DarkwingDuck: the "Permission denied (publickey)." is from ssh, saying that it couldn't log in
<DarkwingDuck> ahh. Okay.
<spiv> Are you trying to branch from Launchpad?
<DarkwingDuck> Yes
<DarkwingDuck> I had it working a couple days ago and now it wont work on my desktop
<DarkwingDuck> However, my netbook connects just fine
<spiv> In that case, you can either configure your desktop's SSH so that it can connect to Launchpad (possibly by generating a public key and adding it to your account on https://launchpad.net/), or you can reconfigure bzr to connect to Launchpad anonymously (assuming read-only access is fine)
<DarkwingDuck> Okay, thanks
<OldAl> igc: I looked and qrun with regard to "too verbose explanation".  I can not reproduce anything like what you quote.  Would it be too much to ask you for more detail?
<OldAl> igc: not "and qrun" bat at "qrun and pull"
<OldAl> igc: A really serious flaw - bug - the GUI quits quietly if it encounters and error, viz. pull from a directory that is not a branch and the like.  It tells nothing to the user, nothing at all - just quits...
<OldAl> igc: You seem to be absent, so I will leave it at that and go to try to do something else.
<OldAl> poolie: Thanks for moving my "wiki" page to OldAl.  It is a flat file system, no?  Do you want me to create a "People" page and link to it my own CV page?
<poolie> oldal, it is possible to create a People page and move yours to People/OldAl
<poolie> you can do that if you want
<OldAl> poolie: There is always a chance with an old timer that he will make a mess of it... So I do ask!
<OldAl> poolie: Thanks for the advice - I will go away and give it a go.
<OldAl> poolie: "go away" as in next desktop...
<poolie> biab
<igc> hi OldAl
<OldAl> igc: Hi, igc!
<igc> OldAl: try "bzr qpull --ui-mode" to keep the dialog open when a problem is encountered
<OldAl> igc: I will do that and see what happens.
<OldAl> igc: I just could not reproduce any kind of advice how to use the qpull or pull. Nothing like what you quote.
<igc> OldAl: to reproduce my bug, grab a simple branch from lp, cd to the created directory and run "bzr qpull --ui-mode"
<igc> OldAl: you can try it in a branch of qbzr say :-)
<OldAl> igc: OK: so it seems that --ui-mode is the magic command?
<OldAl> igc: So why would anybody want to use it in general?
<igc> OldAl: nearly all q* commands take a --ui-mode parameter
<igc> explorer, TortoiseBzr and qbzr-eclipse all call the q* command that way
<igc> i.e. with that option turned on
<OldAl> igc: What turns the ui-mode on?
<igc> OldAl: sending error messages to the console isn't helpful to most users (unless they run every q* command from the console)
<igc> OldAl: I don't get the question. Using the --ui-mode option turns that mode on
<OldAl> igc: So if I call from CLI "bzr qpull"  that will be in ui-mode?  Or does one give this with every command to get feedback?
<OldAl> igc: I will go to the next desktop to try - be back RSN
<OldAl> igc:   p, li { white-space: pre-wrap; }  Run command: bzr "pull --ui-mode" bzr: ERROR: unknown command "pull --ui-mode"  I see where the *Run command* comes from. It is not really helpful with "pull", however.  "qpull" maybe?
<igc> OldAl: yep, --ui-mode is onyl for q* commands
<OldAl> igc: Well, with wrong data (no reference to where mirror is) the gui gives "unknown command".
<spiv> OldAl: the quotes in  'bzr "
<igc> OldAl: let's try again ...
<OldAl> igc: I still fail to reproduce your "too verbose" reply.
<igc> 1) bzr branch lp:qbzr qbzr
<igc> 2) cd qbzr
<igc> 3) bzr qpull --ui-mode
<spiv> OldAl: the double-quotes in  'bzr "pull --ui-mode"'  are odd, I'm not sure why you put them in.  Generally you want to do 'bzr cmd --option', with no quotes.  Quotes change the meaning quite dramatically.
<OldAl> igc: All from CLI, right?
<igc> yes
<igc> OldAl: if you already have a qbzr branch, skip 1
<OldAl> igc: I only use the "xxx" here to show it is an item that was put into GUI.
<OldAl> igc: No, I don't mind the branch bit - not at all.  Good stuff.
<OldAl> igc: It (the PC) is pulling the qbzr - step 1.
<OldAl> igc:   p, li { white-space: pre-wrap; }  Run command: bzr pull bzr+ssh://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/ --directory /dat/work/dummy/qbzr No revisions to pull.  Sort of success...
<igc> OldAl: yep -that's success
<igc> in reproducing the bug
<OldAl> igc: It is a naughty message, I must say.  OK, so I better go and try to get a fix on that.  The freshly made branch would be useful.
<OldAl> igc`Has anybody told you that you are a born teacher?
<igc> OldAl: I write lots of documentation so I don't need to answer questions so .... no
<OldAl> igc: (I come from a family of teachers, or persons engaged in some form of teaching.)
<OldAl> igc: Thanks for your patience with an old man - me!
<OldAl> igc:  Hope to repay you in some small way!
<igc> OldAl: no problem. In return, I expect you to find every retired people who and program and get them submitting patches to Ubuntu using bzr and launchpad. :-) :-)
<igc> and -> can
<OldAl> igc: I confess that I was not looking at the CLI interface with qpull.
<poolie1> spiv, i am about 50% of the way to automatically marking reviews that need to be signed
<poolie1> s//need the contributor agreement to be/
<OldAl> igc: Typical misunderstanding - I was really interested and looking at [bzr qrun], which has a potential to compete with ... bzr-explorer. At least in some areas. I will now switch to looking at qpull - thanks again.
<spiv> poolie1: nice.  Marking them in what way?
<igc> OldAl: I'm happy for you to work on qrun. qpull is a gentle introduction to the qbzr code
<poolie1> i think i'm going to make it post into the review thread
<poolie1> assuming there's an api for that
<spiv> There's always email ;)
<igc> OldAl: qrun will help explorer 10x more than compete with it IMO
<igc> OldAl: if it's good enough for a class of users, great
<OldAl> igc: I could not agree more.  You need several GUI implementations.
<OldAl> igc: Preferably different from each other more than a skin.
<OldAl> igc: All the best. Buy for now.
<igc> OldAl: bye
<OldAl> igc buy -> bye  :-D :'(
<maxb> Is there a better way to write:    graph.heads((a, b)) == set((a,))  ?
<maxb> it doesn't feel very nice
<lifeless> in a test ?
<maxb> in rebase's actual code
<lifeless> b not in graph.heads((a,b))
<lifeless> I guess
<maxb> Oh, excellent point :-)
<maxb> I was so tied up in checking that it had length 1 as well
<maxb> oh
<maxb> but no, because sometimes a and b are equal
<igc> lifeless: maybe you could add your thoughts on how to do what james is after in https://code.edge.launchpad.net/~ian-clatworthy/bzr-builder/fix-find-branches/+merge/15137
<lifeless> igc: I've discussed it with vila already
<lifeless> we need a change to the plugin path infrastructure
<igc> lifeless: cool. Thanks.
<poolie1> spiv, if you're still here, can you add people who signed the agreement for you to that team?
 * igc dinner
<poolie1> also spiv, i blogged about it
<poolie1> corrections welcome
<MvG> Hi! For trac-bzr, does anyone here have an opinion about what a revid without a branch name should mean? I'd like feedback on https://bugs.launchpad.net/trac-bzr/+bug/486795 for this, or directly here on IRC.
<ubottu> Launchpad bug 486795 in trac-bzr "Clarify semantics for revid without branch" [Undecided,New]
<chx> MvG: hi
<chx> MvG: I am just a user , nothing more
<chx> MvG: but how can a changeset exist without a branch?
<lifeless> MvG: you could synthesis a branch for it, with it as the tip
<chx> lifeless: following up on a discussion yesterday, I would believe that http://freshmeat.net/projects/fl-cow this can be of interest to bzr users.
<chx> lifeless: this makes the --hardlink option much more useful
<lifeless> chx: it makes it safer ;)
<lifeless> theres another thing like that around somewhere.
<chx> oh?
<chx> I am rather curious
<lifeless> I don't recall the other projects name offhand
<chx> see, our svn checkouts eat more than 100MB each (wowsie)
<chx> so when we migrate to bzr, I would like to see this stop.
<poolie1> chx: how about using one tree and switching between branches?
<poolie1> i guess if you wanted that, you'd do it in svn too
<chx> poolie1: ?
<chx> poolie1: we typically do one checkout per ticket
<poolie1> ok
<poolie1> my point is
<chx> poolie1: so that the QA people can independently check the results
<poolie1> ok
<poolie1> i guess my point is
<chx> if you know a better workflow , i am listening
<poolie1> you can remove the checkout and then people can recreate it from the branch when they need it
<poolie1> for example just bzr remove-tree and bzr checkout
<lifeless> chx: so 50% of that 100MB is the svn cache
<lifeless> chx: which bzr doesn't have.
<chx> lifeless: i presume
<chx> yay
<lifeless> chx: do your QA people have their own machines?
<chx> lifeless: no
<lifeless> ok
<chx> lifeless: this is a web project so they just browse to the developers address , easy (?)
<lifeless> I see
<lifeless> yes, for that you'll want separate checkouts
<chx> also allows for designers , project managers other assorted riff-raff ;) to see etc
<lifeless> but as long as you have a shared repo it will be only your files that show up in terms of space.
<chx> hm?
<chx> a shared repo?
<lifeless> bzr init-repo myrepo
<chx> I was thinking we will use a bzr branch -- local commits -- gatekeeper merges in flow
<lifeless> then do your branching/checkouts within myrepo
<lifeless> its a storage optimisation tool, it doesn't affect merge/push etc
 * chx reads bzr help repositories
<chx> oh i see
<chx> i created a repo, checked in Drupal HEAD, branched it and now i see that the repo .bzr is 5MB but the branches .bzr are only 440 and 500kb respectively
<chx> that's a good trick indeed
<MvG> Sorry, didn't realize I got replies here...
<MvG> chx: while revisions without a branch are possible, e.g. when you remove the branch from which they originated, the issue at hand is a different one: trac-bzr is a bzr plugin for trac, and offers several ways for trac to name revisions. One is "branch,revno", one is "branch,revid" and one is simply "revid".
<MvG> chx: so the question is, if you don't know the branch a revid is supposed to belong to, how to you treat this in trac.
<bialix> hello all
<bialix> hello MvG
<poolie1> hello bialix
<MvG> Hi there, bialix!
<bialix> :-)
<bialix> hello poolie1
<poolie1> and good night...
<MvG> 10am here...
<bialix> poolie1: just yesterday read about five whys: http://www.startuplessonslearned.com/2008/11/five-whys.html
<bialix> maybe it could be interested for pilot improvements
<bialix> and good night
<bialix> MvG: this channel dancing arounf the world. aussies going to sleep
<bialix> *around
<MvG> So I guessed...
<MvG> Just have to resist the temptation to join in just yet...
<MvG> ;-)
<bialix> :-)
<doctormo> Hey again, I'm re-looking for a way to express the progress of branching and checkout options to a GUI, so far I can either popen the bzr command with a thread and hack together the progress from the stderr output, I'd prefer to use bzrlib, is there any way to do this?
<poolie1> bialix: yes i think that would be relevant
<poolie1> we shouldn't just do stuff to work around the current problems, we should dig in to them
<bialix> agreed, and spiv report make me think this way
<bialix> glad it maybe useful for you
<lifeless> doctormo: sure, you can see what bzr-gtk does (uses the API), or qbzr does (wrapps the command line) or bzr-eclipse does (uses the bzr-xmloutput plugin to control it)
<doctormo> lifeless: Looking at all of those, bzr-gtk doesn't seem to do anything, it's magic.
<bialix> doctormo: look at qbzr
<doctormo> bialix: Is wrapping the command line to prefered way of getting progress status?
<lifeless> doctormo: I'm not sure why you'd say its magic :)
<doctormo> lifeless: magic == I don't understand it
<lifeless> doctormo: Not to me; install a ui_factory is what I think is preferred.
<lifeless> doctormo: but opinions about 'preferred' are, by definition, subjective.
<bialix> doctormo: no, the point not about wrapping
<doctormo> lifeless: yes I can tell the ui_factory is involved, it creates by default a TextProgress class
<bialix> doctormo: there is good example of how to install your ui_factory and how to tie it with GUI
<lifeless> bialix: oh cool, I'll remember that
<doctormo> bialix: In qbzr? thanks
<bialix> lifeless: is it irony?
<bialix> or sarcasm perhaps
<lifeless> bialix: neither.
<bialix> ok, nm
<doctormo> bialix: lifeless believed that qbzr wrapped the command line output, if I understand, so your correction about it using the ui_factory is interesting.
<bialix> doctormo: actullay we do both
<bialix> but for you is relevant ui_factory part
<bialix> it's just very closer to wrapping command-line
<bialix> you can omit the latter and use the former as example
<doctormo> thanks bialix
<bialix> doctormo: it's in qbzr/lib/subprocess.py
<doctormo> bialix: I'm going tomake a simple QUIFactory copy, I assume that's involved too
<bialix> yes, that's correct
<doctormo> ui.ui_factory = QUIFactory() <- this part I think
<doctormo> brilliant, got a simple thing up and running.
<maxb> Does bzr-explorer "Advanced Commands" work on Windows? It does nothing when I click it.
<lifeless> does anything? :P
<bialix> maxb: yes
<maxb> hmm
<bialix> until recently it invoked console shell
<bialix> now it launch qrun dialog from qbzr
<bialix> maxb: if you have black console window behind -- look there
<maxb> oh, there it is
<bialix> I suggest to use latest bzr-explorer version from trunk to get qrun instead
<bialix> this console thing is a bit buggy
<maxb> Gladly, for my own use on Linux. But I'm briefly evaluating it on Windows for my less technical colleagues
<bialix> that's why I'm suggesting using version with qrun
<RenatoSilva> Is there a way to customize annotation colors? I want to distinguish clearly with colors the lines below and the lines above a certain revision.
<hsn> do i have to uninstall old bzr in windows before installing a new one?
<bialix> hsn: as usual Start -> Settings -> Control Panel -> Add/Remove Programs
<ryanhaigh> hi all im having a problem with the bzr add command
<ryanhaigh> for some reason when i run bzr add without any arguments it doesn't add one of my subdirectories
<RenatoSilva> check bzr log
<RenatoSilva> clean it, then add
<ryanhaigh> if i try to add the directory or any file in it explicity, it is also not added
<ryanhaigh> clean it?
<bialix> ryanhaigh: is this directory ignored?
<ryanhaigh> no
<bialix> check output of bzr ignored
<ryanhaigh> i have done that the output is blank
<bialix> does this directory holds another branch inside?
<ryanhaigh> no
<RenatoSilva> ryanhaigh: if you try to add that specific directory you don't get any error, but the directory is not added?
<bialix> can you check this with `bzr info /path/to/dir/which/refuse/to/add` ?
<ryanhaigh> thats right, it remains unkown
<bialix> this cannot be true
<bialix> either you discover very interesting bug (but I doubt) or you have something unusual with your directory
<RenatoSilva> ryanhaigh: open the bazaar log and delete the content, then run bzr add dir and check what's outputed there, it may tell you what's happening
<ryanhaigh> how do i open the bzr log to delete the content?
<bialix> in your favorite editor
<bialix> check output of bzr version to see where the log located
<ryanhaigh> ahh ok, sorr
<ryanhaigh> sorry
<bialix> I bet you have another branch there
<RenatoSilva> if so bzr should say something anyway
<ryanhaigh> bialix: you are correct there is another branch
<bialix> bingo!
<ryanhaigh> thanks
<bialix> I'm WON! hoorah!
<bialix> :-)
<fullermd> Graah.
 * fullermd stabbies LP
<fullermd> Every damn week, it comes up with some new way to send mail I have to filter out, usually into oblivion...
<bialix> hello fullermd :-)
<MvG> If someone is interested in reviewing a bit of trac-bzr code: https://code.launchpad.net/~gagern/trac-bzr/bug274609/+merge/15148 removes some unreachable code, as described in the corresponding bug report. Comments?
<MvG> bialix, https://code.launchpad.net/~gagern/trac-bzr/bug177683/+merge/15149 might be of special interest to you, as you first merged the original patch regarding bug 177683. Now I've added some str conversions and proper parsing for revids without a branch name. Will you have a look?
<ubottu> Launchpad bug 177683 in trac-bzr "All revisions and changesets starts with a comma sign" [Low,Triaged] https://launchpad.net/bugs/177683
<bialix> MvG: I need some time to recall what I've doing in the past
<bialix> MvG: thanks, I'm really interested in trac-bzr stuff, I'll look into your code tonight
<MvG> bialix: That's great!
<MvG> Thanks a lot.
<bialix> thank *you* a lot!
<MvG> cd wo
<MvG> (wrong window...)
<bialix> cd wrong window - lol
<bialix> MvG: ping
<MvG> bialix: pong
<bialix> MvG: from time to time I'm thinking about speed up of trac-bzr operations
<bialix> do you have any plans on this front?
<MvG> Not yet.
<bialix> I'm mulling idea of some sort of cache
<MvG> There are already some caches in place.
<MvG> And I believe bzrlib itself does some caching as well.
<bialix> for me is the worst case is to get Timeline with "Repository checkins" selected
<bialix> for my server it takes several minutes
<bialix> MvG: I'm not sure bzrlib cache help here
<MvG> OK, that's a thing that should be fixable.
<bialix> that will be nice
<bialix> MvG: do you have any hints re debugging trac-bzr plugin?
<bialix> how you do development actually?
<MvG> Debugging performance?
<bialix> bugs in first place
<bialix> performance is second
<MvG> As of last friday, I've got a dedicated apache for this, running as my user on a non-privileged port, so I don't have to worry about matching IDs.
<MvG> On the python part I've discovered virtualenv, so I've set up two different python environments, one for trac 0.10 and one for 0.11.
<bialix> no, I'm asking how you get info about what's going on inside plugin?
<MvG> So far performance hasn't been of interest, so I'm running trac as cgi, which ensures I'm always running the latest code.
<bialix> in bzrlib there is .bzr.log where one can print debug info
<MvG> There is a similar log for trac.
<MvG> Every trac component has self.log which provides this.
<MvG> Only trac-bzr doesn't use it for the most part.
<bialix> ok, I'll try to use it
<bialix> is there special reason for this?
<bialix> reasons for not using logs?
<MvG> Oh yes, and BzrRepository.sync even overwrites this log with None. No clue why that's the case, doesn't seem related to the rest of the commit that introduced it.
<bialix> weird
<bialix> MvG: another question: do you think running Trac with built-in server tracd is bad idea?
<MvG> Should fix this in trunk soon. Do you want to review such a fix?
<MvG> Depends on the environment.
<bialix> MvG: I'd like to review, but I need to dive deep enough into the code first
<bialix> I'm not good hacker re trac-bzr
<MvG> Apache has some nice features for cleaning up malicious requests, which tracd might miss.
<bialix> tracd is much easier for me, as dev environmenbt
<bialix> tracd is much easier for me, as dev environment
<MvG> Other than that, I always want to embed trac inside a larger page, so I wouldn't use it as a production env.
<bialix> ok, understand
<MvG> For development it certainly has benefits, and shouldn't hurt in most cases, unless you want to explicitely test something depending on the frontend.
<bialix> btw, currently I'm using trac+bzr trunk revno.34 with custom patch applied
<MvG> What custom patch? SOmething suitable for trunk?
<bialix> I hope so
 * bialix pastebins
<bialix> MvG: http://pastebin.com/d29e24ad1
<bialix> I'm not sure, maybe it already in trunk
<bialix> I'm stuck with revno 34 and bzrlib 1.5 because later versions does not work well for my case
<bialix> I have many shared repo and branches on my server
<MvG> In a modified version: authors = ";".join(self.revision.get_apparent_authors())
<bialix> yep, modified version is more correct for newer bzrlib
<MvG> Multiple shared repos for the same trac env cause trouble.
<bialix> what kind of trouble?
<MvG> Well, locking for instance. There seems to be code that only locks the whole repo once.
<bialix> :-/
<MvG> Existence of revid checks in some places.
<bialix> locks locks locks
<bialix> heh
<MvG> Both of these I encountered in code that was broken in some other way as well, and which I plan to remove,
<MvG> So it might coincidentially work with multiple repos as well, but I wouldn't rely on it yet.
<MvG> There is a whishlist for it, iirc.
<bialix> For me multiple shared repo is critical feature
<bialix> we have many components in our project
<bialix> keep all components in one big shared repo proved to be a *bad* idea
<eydaimon> is it possible to just merge only the changes of a particular revision, and not changes of some previous revisions? let's say repo A has revision 100, and repo B has revision 98. I want to merge in only changes in revision 100 to B, not 99. Can I merge in, and then at a later time merge the changes for 99? Does that require a special syntax?
<bialix> (performance) of smart server
<bialix> eydaimon: bzr merge -c100
<eydaimon> bialix: and then next time I do bzr merge, then c99 will get merged automatically?
<bialix> yes
<eydaimon> thanks
<bialix> always happy to help
<chx> MvG: so you are the trac+bzr developer?
<MvG> chx: I'm the newest member of the trac-bzr-team, i.e. recently got commit permissions on the trac-bzr trunk.
<MvG> Other than that, I'm mostly busy writing bug fixes for issues I encountered myself, and pushing these for review. Haven't made a single commit to trunk yet.
<bialix> MvG: re splitting support for 0.10 and 0.11: I'd create new series (say "0.10") and use it for 0.10-specific branch
<eydaimon> is it possible to merge several changes using -c? I tried range, but it said it's not possible
<MvG> bialix: Dunno... series are usually for feature-stable releases of the component itself, and I'd wish to include as many new features into the 0.10 branch as possible.
<eydaimon> would I have to merge twice?  (I actually want to merge 386 and 387)
<bialix> MvG: hm? I think they can be used more flexible
<eydaimon> or do I have to merge 386 first, commit, then merge 387?
<bialix> eydaimon: if youo want merge from X to Y you need to use: bzr merge -r (X-1)..Y
<MvG> eydaimon: bzr merge -r 386..387
<bialix> -r385..387
<bialix> -r386..387 is equal to -c387
<eydaimon> oh, so now the -r syntax as opposed to -c?
<eydaimon> ok, thanks
<bialix> eydaimon: -c is syntax sugar
<bialix> -cN means -r (N-1)..N
<NfNitLoop> whoah.  didn't reailze 'bzr init' in a svn directory would comlplain that it's already a (svn) branch. :p
<bialix> NfNitLoop: --no-plugins :-)
<eydaimon> ok thanks much guys :) appriciate it
<chx> MvG: sounds awesome
<chx> MvG: i am about to use trac+bzr :)
 * bialix using trac and trac+bzr 2+ years now and found it very nice tool
<MvG> chx: Don't hesitate to file any bug you encounter with latest trac-bzr.
<chx> bialix: really.
<bialix> Trac has very rich plugins system
<bialix> on this front it outperform even Redmine
 * bialix heavily using IncludeWiki macros
<MvG> I find the current state of trac-bzr to be somewhat lacking - which is the reason I'm filing that many bug reports, and writing that many fixes... :-)
<bialix> given in mind there is not much activity around trac-bzr development...
<bialix> MvG: today is only barely usable
<bialix> MvG: what version of Apache do you recommend?
<MvG> abentley: http://bazaar.launchpad.net/~trac-bzr-team/trac-bzr/trunk/revision/28.1.146 indicates that you committed the line which sets self.log = None for trac-bzr. Can you recall your reason for this? I know, it has been 3 years ago, but still worth asking, I guess.
<MvG> bialix: Using 2.2 myself, and would suggest that to others as well.
<bialix> MvG: thanks
<MvG> But my main reason for 2.2 is content negotioation fo static content, so the choice isn't that important for trac.
<abentley> MvG: Sorry, I don't remember.
<MvG> abentley: Understandable. Thanks for looking. Will simply remove that line, as it doesn't seem to make sense in current code.
<matt_pi> Hi. I have a terminology problem. REVISION is a name for the currently commited data, or a name for all the data commited before a certain commit (including this commit).
<abentley> matt_pi: revision refers to the current state at commit time.  This includes files that were not modified in this commit, but doesn't include old data for files that were modified in this commit.
<MvG> I just realized that I can't seem to have a lightweight checkout tree of a heavyweight checkout without a tree. Would be useful, though: the lightweight checkout would be my working tree, which i switch from branch to branch as need arises. The heavyweight checkout would be simply a bound branch to ensure that commit and push become atomic, that my trunk will never diverge from upstream trunk unless I explicitely ommit locally.
<jelmer> mvg: in general you can't have checkouts of checkouts
<MvG> Is there a good reason for this?
<matt_pi> abentley: I think I understand. So in a revision are also included other files that werent changed in a commit. In other words: revision is a status of the whole branch, not only a few files.
<abentley> matt_pi: Yes, but I would say "whole tree", not "whole branch", because the branch includes all of the past revisions.  "Snapshot" vs "changeset" is a common distinction.
<matt_pi> abentley: OK, many thanks.
<abentley> matt_pi: np
<stuartpb> How do I set up bzr-git on Windows?
<stuartpb> How do I set up bzr-git on Windows?
<stuartpb> How do I set up bzr-git on Windows?
<LarstiQ> ehm, same as usual?
 * LarstiQ uses neither bzr-git or Windows
<LarstiQ> stuartpb: are you hitting a snag?
<stuartpb> well yeah
<stuartpb> i can't figure out how to install Dulwich for it
<LarstiQ> ah
 * LarstiQ wonders if there is any C code in Dulwich
 * LarstiQ acquires a copy
<LarstiQ> stuartpb: yeah, there is C code in there
<LarstiQ> stuartpb: so if there isn't a binary for Dulwich, you'll need to have a functioning Python-extensions-compilation toolchain
<chx> i just set up my first bzr server. that was not particularly hard. if i want permissions the easiest is to use bzr+ssh and ssh keys isnt it?
<LarstiQ> chx: yes
<LarstiQ> chx: and posix acls
<chx> (however, the inetd instructions are outdated , seemingly most distributions use xinetd (?). standalone is easy.)
<RenatoSilva> verterok: hi
<Peng> beuno: Copyright assignments for Loggerhead? That's new.
<mwhudson> not really
<beuno> Peng, it hasn't been as public as it should have been  :)
<Peng> "(Last modified 14 May 2009)" I guess it isn't new... Huh.
<Peng> I didn't see it on the list last time I looked at that page.
<Peng> Most of Loggerhead's code is copyrighted by specific people.
<beuno> Peng, does this create a problem for you?
<Peng> Or at least...some large portion.
<Peng> beuno: I dislike copyright assignments, but I'd rather do that than stop contributing.
<Peng> Or...it's not a copyright assignment? I don't remember. Anyway.
<beuno> Peng, unfortunetly, laws are complicated
<beuno> so we've been asked to do this for all Canonical projects
<Peng> Oh yes, it is a copyright assignment.
<LarstiQ> can't Canonical invest some money in simplifying laws the world over?
<beuno> the FSF strongly suggests this approach
<beuno> LarstiQ, if it was feasible, it would probably be money well spent  ;)
<beuno> (and hi!)
<LarstiQ> beuno: yes :)
<LarstiQ> heya! :)
<LarstiQ> there are also jurisdictions where you can't sign (all of) your copyright away
<LarstiQ> ah well
<Peng> LarstiQ: The agreement covers that.
<LarstiQ> Peng: ok
<Peng> I already signed it for Bazaar; should I do it for Loggerhead too?
<beuno> Peng, I think it's the same
<Peng> Hmm. The contributor agreement says "The term 'Software' refers to all computer programs created as part of a Canonical programme listed at http://canonical.com/contributors ...", so I guess I unintentionally signed it over for everything, not just Bazaar.
<RenatoSilva> Peng: you'd rather assign copyright than stop contributing. How about the company stoping asking contributors to do that?
<Peng> RenatoSilva: Oh. Yes, that would be better.
<RenatoSilva> beuno: FSF suggests what approach, the assignment? For a trustable organization afaik (like themselves)
<beuno> RenatoSilva, yes. I may be very naive, but I expect Canonical to be trustable
<beuno> you know, considering they are trusted with basically root access to all Ubuntu users' computers
<Peng> Haha, that's a good point.
 * Peng is scared of Canonical now
<beuno> if you don't trust Canonical, you probably have bigger problems than the Copyright assignement
<luks> beuno: well, I think FSF and Canonical have different reasons for it
<luks> I'm not sure which reason is better though :)
<RenatoSilva> beuno: I'm afraid FSF doesn't consider any commercial organization trustable
<LarstiQ> I'm reasonably sure the FSF has a nuanced stance on that
<Peng> I suppose I trust Canonical to behave well with their control of my computer, but I do not necessarily believe they'll do what I want with source code.
<Peng> I already feel funny about how they can and do make it available under other license terms.
<Peng> It's _probably_ all for a good cause, but _I_ don't know that.
<Peng> (Well, not necessarily "and do". I don't know that.)
<RenatoSilva> I think the assignment to FSF or related organizations is like "GPLv2 or later". You trust FSF is compromized with certain principles and that they won't leave it. So you trust that any later version of GPL is better according to what you believe regarding FOSS. The same way, I think when you disclaim copyright to FSF, you believe that if e.g. they decide switch from GPL to LGPL, that's because they have a good reason.
<Peng> RenatoSilva: Not everybody does the "or later". :D
<LarstiQ> same thing with Canonical
<lifeless> Peng: there is only one now; we used to have many seperate ones but consolidated
<RenatoSilva> Peng: many do afaik. I think the best reason to not assign copyright to a commercial organization is that because of its nature, there's no guarantee that the company will only use the source code for community benefit rather than its own
<Peng> lifeless: OK. :)
<lifeless> RenatoSilva: thats like saying 'there are no guarantees'
<LarstiQ> RenatoSilva: there are no guarantees with FSF either.
<LarstiQ> RenatoSilva: it comes down to trust, and I trust Canonical with the Bazaar source.
<Peng> I'm kind of an untrusting person. :\
<LarstiQ> whether someone else trusts them with the same thing is up to them.
<luks> LarstiQ: I've seen many posts on the ML lists that suggested that you can talk to Canonical to get a difference license conditions
<luks> I haven't seen such posts from FSF on FSF software
<LarstiQ> luks: so there is a level of trust etc.
<RenatoSilva> Peng: another good reason is to ask the company a good reason for doing that. That is, why do you want to TAKE my code from me? What's bad about the source code belonging to "all people in the earth". It makes difficult to change license? Well, that's reasonable to accept if we're talking about FSF or any non-profit organization, but not for a commercial company.
<lifeless> RenatoSilva: No one takes the code from you. And updating to newer licences that work better in court as the law changes is a pretty important thing to be able to do.
<lifeless> or even just to add compatibility with another open source project - like the openssl exception that GPL projects using openssl need.
<RenatoSilva> LarstiQ: FSF and Canonical have different natures. I trust FSF much more than Canonical. Actually, I would not trust any commercial company that much, or at all.
<LarstiQ> RenatoSilva: that's your choice, and that's fine.
<luks> note that I care about the Bazaar agreement much, but this why I'd have trouble signing it
<luks> I signed a similar agreement for Qt/Nokia, but they were pretty open that they want it because they want to provide a commercial version
<beuno> luks, do you feel Canonical is not open about it?
<LarstiQ> luks: right
<luks> beuno: everybody here is claiminig that it's because they want to keep the code free
<LarstiQ> beuno: about wanting to offer a commercial version of bzr?
<beuno> they *will* use it in other scenarios if the situation comes up
<luks> beuno: but tell me that Canonical doesn't offer a non-GPL version of Bazaar
<beuno> luks, I am not aware that they do
<RenatoSilva> lifeless: ok, so why not Canonical disclaims copyright to FSF or some non-profit organization? Because they like to have control and be free to do whatever they want in the future, regardless of that meaning that the actual code authors can't do anything about it
<lifeless> luks: Canonical does not offer a non-GPL version of Bazaar
<lifeless> luks: have a look at our website; we offer support and training.
<luks> lifeless: well, I've seen posts on the bzr ML telling people to talk to Canonical about such posibilities
<lifeless> luks: http://www.canonical.com/projects/bazaar
<Peng> The Bazaar website *used* to mention it before the redesign.
<luks> (posts by Canonical employees)
<lifeless> Peng: perhaps; nevertheless we've never done it, and its not suggested now AFAIK
<Peng> lifeless: Interesting.
<lifeless> RenatoSilva: I don't really follow your logic there. This has been discussed on the mailing list very recently too.
<Peng> http://web.archive.org/web/20080527233931/http://bazaar-vcs.org/: "If you want to embed Bazaar into your products under a different license, please contact us."
<Peng> That's what it said.
<Peng> FYI.
<RenatoSilva> luks: withy that single copyright, they can embed Bazaar into commercial software at any time, for own benefit or any other reason (and without notifying the community -- I'm afraid the agreement doesn't even cover this). I don't like this idea, and others don't either (hg users seem to not like this aspect of bazaar)
<lifeless> Peng: yup.
<lifeless> Peng: To the best of my knowledge it never happened.
<luks> RenatoSilva: I know why are they doing it :)
<lifeless> RenatoSilva: I think you mean 'proprietary' rather than 'commercial'
<Peng> I think this was the third time i started a copyright argument in this channel. :D
<RenatoSilva> lifeless: yes, as commercial software anre usually proprietary. But what I strictly mean is any derived work that the author would not agree with. For example, I think Bazaar contributors would not like to see their code being distributed as BSD for some customer.
<RenatoSilva> s/anre/are
<lifeless> do you really think we'd do that?
<luks> RenatoSilva: Bazaar contributors always had to assign the copyright to Canonical, even if without a signed agreement, I think they would be fine with it
<RenatoSilva> the commercial nature is a negative point in that matter. It's the same as saying that you don't trust Chrome binaries, then one says you shouldn't trust FF's either. However, Mozilla foundation is far different from Google, and that makes a big difference in which you trust more (or suspect less)
<bialix> what's the point?
<RenatoSilva> luks: I would not be fine. I would not like to see my free time spent for the benefif of all people in a work that now I have no control, and that now is delivered as BSD which may become easily a proprietary software making them (not me) gaining money with my work whose initial intention was to benefit everybody, not someone (and worse, someone *else*).
<lifeless> RenatoSilva: Even if Canonical went evil and did something like that, the current GPL code would stay GPL, everyone would still be getting the benefit from it.
<lifeless> but we're not evil - as stewards of Bazaar I think we do pretty well
<RenatoSilva> lifeless: ok but as we said, we have no control behind the scenes, unless Canonical includes a compromise in the agreement of informing teh world of anything different they do with the contributions, which would make things less interesting commercially, which makes me wonder if they would do such a thing.
<RenatoSilva> lifeless: I don't know if you are evil :) But just like we say here in my country, we stay with one feet behind :)
<lifeless> you have no control with any assignment anywhere (even FSF).
<luks> but the chances of FSF selling your code are pretty thin :)
<luks> well, "your"
<RenatoSilva> lifeless: but FSF is not Canonical, they're different natures.
<RenatoSilva> yes, can anyone imagine Stallman in some TV commercial selling "hey GNU/Hurd for only $99"
<LarstiQ> RenatoSilva: yeah, for one thing, Canonical employees actually wrote the vast majority of bzr
<LarstiQ> and RMS certainly has nothing to do with the Hurd
<RenatoSilva> maybe Bazaar should be maintained by a non-profit organization with legal commitment to public interests
<RenatoSilva> about selling the code, that's much more easy to imagine with a commercial company than with that crazzy man
<chx> I have a technical question. For trac+bzr i would like to point to one place but if that's one branch then it's not possible to check out / commit parts . I would like to get something like an svn repo (and bzr init-repo is not a branch either)
<chx> how do people use trac+bzr to support multiple branches?
<mwhudson> lifeless: btw i would be interested what a test for https://code.edge.launchpad.net/~mwhudson/bzr/bytestring-environment-variables/+merge/15113 would look like
<mwhudson> lifeless: or more particularly i guess, where it would go
<mwhudson> hm, i guess TestTestCaseWithMemoryTransport
<bialix> chx: I'm not quite understand your question
<chx> bialix: nevermind
<lifeless> mwhudson: seems relevant
<lifeless> mwhudson: perhaps higher up
<bialix> chx: ?
<lifeless> chx: this is one of the problems with trac; its got a _very_ svn specific model.
<chx> bialix: I now read the trac-bzr README and it says "Allows a collection of branches to be treated as a "trac repository", regardless of whether they are related or in the same bzr repository."
<bialix> luks: evening
<bialix> chx: yes
<mwhudson> lifeless: overrideEnvironmentForTesting, the method i'm patching is on TestCaseWithMemoryTransport
<lifeless> mwhudson: then ttwmt is right
<lifeless> :)
<luks> hi bialix
<chx> I am fine, i am fine, sorry for asking and not RTFMing
<bialix> luksL how are you?
<bialix> luks: I have question about lazy_register in qbzr
<luks> is there a problem with it?
<bialix> luks: register_lazy_command deliberately don't use plugin_cmds.register_lazy
<bialix> luks: no, not the problem, I just trying to figure out how to slightly change it
<luks> I think it should only use plugin_cmds.registry_lazy now
<bialix> luks: that's my guess as well
<luks> there was the problem with overwriting commands
<luks> but I see that's now commented how, so it no longer overwrites merge
<luks> the custom function was mainly necessary to provide lazy registration before bzrlib supported that
<bialix> luks: I want to put all lazy commands definitions into big tuple and iterate over it inside one function instead of calling it again and again
<luks> that seems good
<luks> I think bzrtools does something like that, right?
<bialix> luks: yes, we have conflicts with pipeline plugin about overriding merge
 * bialix looks into bzrtools
<bialix> luks: yes, bzrtools using dict as map between cmd names and aliases
<luks> ah
<bialix> I'd prefer keep them as tuples (as it looks now)
<luks> yep
<bialix> ok, thx :-)
<luks> didn't help much :)
<bialix> well, you said yes two times where I need
<bialix> this helps
<bialix> luks: if you still want to get notifications about new revisions in qbzr trunk you may want to subscribe to trunk2a branch
<mwhudson> lifeless: https://code.edge.launchpad.net/~mwhudson/bzr/bytestring-environment-variables/+merge/15136 has a test now, who can we hassle into being the second reviewer?
<luks> heh, I've been busy enough last weeks that I didn't even notice :)
<luks> thanks
 * bialix hopes it was not too much shameless
<luks> heh, I see jelmer is also working on bzr-hg
<luks> I wonder in what state it is
<mwhudson> luks: it'll probably a code import option on lp in a couple of months
<mwhudson> maybe even in december i guess
<luks> cool
<luks> do you think dpush works/will work soon?
<mwhudson> i don't know, but would guess on "soon" if it doesn't work yet
<luks> I need to try it out
<luks> I really don't get what people like about hg
<luks> I've tried hard to work with it, but I find my way around it
<luks> +can't
<luks> speaking of the devil :)
<luks> hi jelmer
<meoblast001> hi
<meoblast001> i set up a bzr repository on my system, how can i make it public?
<meoblast001> it uses SSH
<lifeless> mwhudson: Do you have commit access yet?
<bialix> luks: I don't know why, but I can't force myself to use hg longer then 15 minutes
<mwhudson> lifeless: no
<luks> bialix: I have hard time understanding how they work with multiple branches
<lifeless> poolie: ^ mwhudson for commit access?
<luks> bialix: it seems multiple clones is the way to go, which is just weird
<jelmer> hey luks
<bialix> meoblast001: serve it via http perhaps?
<luks> jelmer: I was wondering, does dpush work in bzr-hg?
<meoblast001> hm :/
<jelmer> luks, no, not yet
<meoblast001> so just put the repository in /var/www?
<meoblast001> or make a symlink to the directory? (is that possible)
<jelmer> luks: well, it might sortof work if you don;t add any new files
<bialix> luks: multiple branches is not worse, multiple unnamed heads is nightmare
<luks> jelmer: ok, no problem, I just noticed that you were working on it
<luks> (on bzr-hg)
<bialix> what's the cool tool to check python sources for unused imports? pyflakes?
 * bialix don't remember
<bialix> hmm, it seems what I'm looking for: https://code.launchpad.net/~mwhudson/pyflakes/support-lazy-imports
<bialix> mwhudson: your branch still not merged to upstream? hm?
<chx> oh btw. thanks for using python. i am not python coder. but , that does not stop me from coding in python when there is a need.
<mwhudson> bialix: i haven't proposed it, it seems a bit bzrlib specific
<chx> (I wrote a two way skype-konversation gateway in less than 40 min when i first tried .py coding earlier this year. easy...)
<bialix> mwhudson: um, ok
<bialix> chx: it's strange but I've chose bzr mostly because it was written in python (initially)
<meoblast001> i want to make my repository accessible via HTTP, but i don't want to have to type bzr push bzr+ssh://blah.com/var/www/bzr
<meoblast001> the /var/www shouldn't be necessary
<chx> bialix: I picked bzr when meld began to support it (yes. that was very very long ago)
 * bialix not using meld unfortunately
<chx> bialix: now I am migrating my team to it four years later because a) yes, python. we are php guys but I know we won't stuck in a corner because of python b) it's atomic. and it means it. really. one dir , one commit. no messing with less c) easy to learn.
<bialix> d) it has good GUI
<chx> svn and git with its staging area fails b) and after i needed to abandon an svn branch because it got so messed up with subdir commits -- I do not want to be there any more
<bialix> mwhudson: anyway your branch is cool: `commands.py:22: import of 'sys' could be lazy` -- cool
<mwhudson> bialix: yeah, it's ok
<bialix> thanks mwhudson
<lifeless> meoblast001: You can use a bookmark to make 'myserver:' mean 'bzr+ssh://blah.com/var/www/bzr', then you could do 'myserver:foo'
<lifeless> meoblast001: (install bzr-bookmarks)
<mwhudson> bialix: though it's a bit trigger happy -- not much reason to import sys lazily...
<meoblast001> lifeless: better question.. how does Launchpad do it?
<meoblast001> i want a familiar design
<lifeless> meoblast001: custom ssh implementation
<bialix> mwhudson: I'm mostly happy about it's overall behavior
<meoblast001> :/
<meoblast001> lifeless: where can i get this custom ssh implementation?
<lifeless> meoblast001: in the launchpad source code
<meoblast001> and can i run it and a normal ssh at the same time?
<lifeless> not on the same port
<meoblast001> on different ports
<lifeless> you'll have to do some development, or run a pretty big subset of launchpad itself
<bialix> mwhudson: just one nitpick: `pyflakes -h` don't want show me even smallest help
<luks> does it really matter if you type /var/www or not, it's only once
<meoblast001> lifeless: can you symlink directories?
<meoblast001> perhaps that is an option
<mwhudson> bialix: that's a pyflakes thing, it doesn't do any option processing at all
<mwhudson> bialix: and it sucks, yes
<bialix> mwhudson: bzr teached me to use -h all the time :-/
<bialix> so now all other utilities that does not react on -h just look sweird
<lifeless> meoblast001: yes you can
<meoblast001> lifeless: that would work perfectly
 * bialix loves pyflakes
<poolie> hello bialix
<poolie> lifeless: mwhudson++
<bialix> hello poolie :-)
<poolie> lifeless: also, remember, you can use your discretion as to whether a second review is needed
<lifeless> poolie: yes, I am.
<lifeless> poolie: I've made too many mistakes myself on equally small things to be inclined to short circuit review trivially.
<poolie> fairy nuff
<poolie> iwbni launchpad made it more clear which reviews i could vs should do
<meoblast001> bzr: ERROR: Server sent an unexpected error: ('error', "Unknown repository format: 'Bazaar RepositoryFormatKnitPack6 (bzr 1.9)\\n'")
<meoblast001> that's 1.9.. shouldn't the Jaunty version of Bazaar work with that?
<meoblast001> or wait.. i think i have hardy on my server >.<
<poolie> meoblast001: there's a hardy 2.0 in the ppa
<meoblast001> ah, ok
<mwhudson> hnngh
<mwhudson> spiv: hello
<lifeless> poolie: code.launchpad.net/bazaar/+activereviews is a useful page.
<poolie> it's a great page
<poolie> i wouldn't say it's optimal though
<bialix> 2.0.2 and 2.1.0b3 is not annonced yet? where is jam?
<mwhudson> b3 got announced, i thought?
<bialix> mayb channel topic needs tuning then?
<mwhudson> spiv: nm
 * bialix waves and disappear
<lifeless> spiv: have you pushed your pqm-submit fixes to trunk?
<meoblast001> lifeless: another question.. how does Launchpad manage permisions?
<meoblast001> SSH works using the UNIX filesystem, and permisions are done with groups
<mwhudson> lifeless: how does commit access relate to "not having to get two reviews" ?
<lifeless> mwhudson: as a committer you count ass one of the two reviews.
<lifeless> and also get to land your own things. I'm bored of ferrying things for you :)
<mwhudson> lifeless: ok
<Peng> meoblast001: Launchpad runs a custom SSH server.
<meoblast001> oh
<meoblast001> ok
<mwhudson> lifeless: i was aware the two were related, but not sure that they were precisely the same
<lifeless> mwhudson: oh and it also means you can be the +1 on other peoples merges.
<mwhudson> lifeless: ah right
<mwhudson> lifeless: so, to be sure, you're ok with me landing that bytestring-environment branch?
<lifeless> yes, with poolies concerns addressed.
<spm> lifeless: I've only added him to bzr, not bazaar_releasemgr - that was the intent y/n?
<lifeless> spm: yes, its fine
<spm> coolio
<lifeless> james_w: ever seen this:
<lifeless> bzr merge-upstream ../lptools-0.0.1.tar.gz bzr+ssh://bazaar.launchpad.net/~dobey/lptools/trunk/ --version=0.0.1
<lifeless> ~bzr9
<lifeless> Using distribution karmic
<lifeless> gzip: stdout: Broken pipe
<lifeless> tar: Child returned status 1
<lifeless> tar: Exiting with failure status due to previous errors
<lifeless> running tar xzf ...ptools_0.0.1.orig.tar.gz -C /tmp/tmphzmaq2 --strip-components 1 by hand works
<mwhudson> lifeless: oh, i hadn't seen his review yet
<james_w> lifeless: please file a bug, I think I know the cause
<lamalex> Does anyone know about the bzr integration for monodevelop?
<spiv> lifeless: not yet, I still haven't gotten around to looking at the tests
<lifeless> james_w: if you can give me a hint I'd love to fix it - am a tad blocked.
<james_w> lifeless: search for preexec_fn in the source
<james_w> something like that anyway
<james_w> subprocess doesn't reset SIGCHILD
<james_w> so you have to do it for it
<james_w> it might be something else, but it looks sufficiently similar
<lifeless> james_w: tar is invoked using 'os.system'
<lifeless> import_dsc.py _extract_tarball_to_tempdir
<james_w> well, maybe that is affected too
<lifeless> so, you change SIGCHILD in bzr builddeb ?
<james_w> no
<james_w> except to reset it when something else is execed
<lifeless> do you mean SIGPIPE ?
<james_w> yeah, sorry
<james_w> http://bugs.python.org/issue1615376
<james_w> http://bugs.python.org/issue1652
<lifeless> thanks
<lifeless> I'll submit a branch shortly.
<igc> morning
<mwhudson> perhaps dumping this comment into irc isn't super appropriate
<mwhudson> but from launchpad's pov it would help to know at connection time whether bzr ever intended to write to the thing being opened
<lifeless> mwhudson: it would help bzr too in some ways
<mwhudson> i guess it would be quite an upheaval
<lifeless> james_w: linked
<lifeless> james_w: so bzr-builder -> 2a. spm has a script that can upgrade everyones branches.
<spm> I do?
<lifeless> spm: jkakars thing
<spm> didn't work :-)
<lifeless> spm: data problem, not script
<lifeless> spm: remember the old bug with bzr branches not having enough data?
<spm> heh; doesn't ring a bell....
<eric_f> anyone have a script (that will work on OS X) to do a "bzr status" on multiple project's in a workspace? I had CD'ing into each folder and running bzr status!
<lifeless> eric_f: for dir in `ls $1` ...
<lifeless> spm: bug 364 something
<ubottu> Bug 364 on http://launchpad.net/bugs/364 is private
<spiv> Bug 354036
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory (unfixable by users) error when pulling a branch from the mirrored area" [Undecided,Confirmed] https://launchpad.net/bugs/354036
<eric_f> lifeless: just type that in the console?
<spm> spiv: that scares me when you do that. ;-)
<spiv> spm: that bug number has been etched into my brain.
<lifeless> jkakar: ^
<spiv> I actually checked the NEWS file just in case, but no, I remembered it all too clearly :)
#bzr 2009-11-24
<spm> Oh THAT one. right. /me recalls the pain. oh the pain. shared pain at that.
<jkakar> lifeless: I should package autolp if the upgrade-branch-format command is something you're recommending to others.
<Peng> Having lots of RAM to throw at Loggerhead is fun.
<jkakar> Though, if it's only something spm can usefully use, maybe it's not a big deal yet.  It only has that feature right now, so not terribly useful to package it yet.
<lifeless> jkakar: I'm pointing people at spm :)
<lifeless> spm: anyhow, that the most likely cause for the failed branches; reconcile won't fix it.
<jkakar> lifeless: Excellent. :)
<lifeless> jkakar: running the fix script the bug has attached to it when a missing rev error happens would be nice (or even just do it to all stacked branches before starting the upgrades)
<jkakar> lifeless: Would it be worth making the script catch missing revision exceptions and continue on, or should it blow up and stop?
<jkakar> lifeless: Ah ha, okay.  I'll look at doing that.
<lifeless> the fix script is 10 lines of python or so
<jkakar> Cool.
<lifeless> so for branch in branches: if branch.get_stacked_url(): fixmenow;
<lifeless> for branch in branches: upgrade...
<Peng> I think it's "get_stacked_on_url". :P
<maxb> Are there any rebase users around? I'm seeking someone to discuss my "bzr rebase: Change behaviour to be as if --always-rebase-mergesspecified, remove outright the current default mode" email with
<lifeless> maxb: discarding merges can be very useful
<lifeless> we support that in bzr core; I'm not sure why you'd want to remove it from rebase (also are you aware its now 'bzr-rewrite')
<SWAT> q: is it adviseable to use the 'smart-server' in a high-volume production environment? The advantage of bzr+ssh = speed/encryption and the advantage of bzr+http(s) = encryption/flexible user management, correct? I'm thinking about setting up bzr+http (ro) and bzr+https (rw) and connect apache to a small db (test) or ldap (production) instead of using bzr+ssh and just would like a small piece of advice _before_ I start setting it up.
<lifeless> SWAT: the smart server can work over http
<lifeless> SWAT: so you've presented a false dichotomy ;)
<maxb> lifeless: The problem with the feature as currently implemented is that it discards revisions solely based on ancestry. What it should/could do, to be correct, is discard revisions only if a merge results in there being no changes to commit.
<lifeless> maxb: perhaps
<lifeless> maxb: though I don't think I agree
<maxb> You don't think that it's wrong that rebase is lossy by default?
<lifeless> rebase is by definition lossy
<lifeless> its its raison d'etre
<maxb> Well... far more lossy than the basic concept of rebasing inherently includes
<lifeless> anyhow, a merge that includes something from the branch being rebased *on* should be discarded.
<lifeless> whether or not there are textual changes is perhaps a case for a warning.
<maxb> Yes.... but only if there aren't relevant textual changes remaining on merging it
<lifeless> maybe
<lifeless> I think it really depends on the exact change
<lifeless> and what it means semantically.
<SWAT> lifeless: ah, right, thanks. Let me put it differently: is it adviseable to use bzr+http(s) instead of bzr+ssh or is it all neglectable?
<lifeless> maxb: it probably needs to be put way down at the bottom of the rebase in fact, for the case of a merge already in the base.
<lifeless> maxb: OTOH a merge from a branch not merged to base, should be kept.
<lifeless> SWAT: shouldn't be any significant differences in performance.
<lifeless> SWAT: if there are, they are bugs
<SWAT> lifeless: thanks a lot. I'll leave you to your other discussion(s). Cheers
<maxb> I don't think it makes sense to try to replay merges out-of-order if that's what you're suggesting - the merge is on top of other changes on your branch being rebased, and is likely to have textual dependencies on them
<lifeless> maxb: I'm not sure I was totally clear about the case being discussed
<maxb> Well, I'm approaching this from the PoV of "It's never OK to discard a merge revision purely based on ancestry, you have to see if there are relevant textual changes" - because the act of resolving conflicts when the merge was done may include making valuable changes.
<maxb> By way of a specific example: we had a Launchpad branch for a newer python version. When a new script was added on trunk, the shebang had to be changed as part of merging the addition to the branch.
<maxb> A purely ancestry-based approach would silently lose that sort of change
<lifeless> maxb: but thats my example
<maxb> ?
<lifeless> maxb: if you have the rev merged earlier you need the shebang earlier too
<maxb> hmm. The idea of reordering changesets instead of just replaying the graph maintaining its shape is scary
<lifeless> maxb: rebasing anything where revisions merged higher up that are already in the new base is non trivial.
<lifeless> maxb: (consider the typical loom usecase)
<lifeless> maxb: where what you are rebasing is just a non-linear but still discrete subgraph, its easy.
<lifeless> this is one of the problems with merges and rebase.
<lifeless> spiv: can I beg you to fix pqm-submit today? It would save me reinventing yoour changes.
<spiv> lifeless: ok
<spiv> lifeless: although I would hope you'd choose to build on my changes, rather than reinvent them...
<lifeless> spiv: So would I.
<eric_f> lifeless: thanks for the tip on: for dir in `ls $1`; I got it working, but can't get it to work as a Bash alias. Any ideas?
<lifeless> eric_f: I'd make a small bash script
<lifeless> you might also look at 'bzr-removable', it might fit your needs (if I'm guessing right)
<Peng> Wow. "bzr check" on a 1.14 copy of MySQL is using more than 4 gigs of RAM.
<eric_f> lifeless: I'm doing this:
<eric_f> for dir in `ls $1`; do if [ -e ${dir}/.bzr ]; then echo ${dir}; echo --------------------; bzr status ${dir}; echo; fi done;
<spiv> Peng: it checks your RAM *and* your branch!
<eric_f> i want to alias that so I don't have to type it all the time
<lifeless> eric_f: put it in a script in your path
<lifeless> then you don't have to type it all the time
<Peng> spiv: It's checking my swap, too.
<lifeless> mem
<lifeless> disk
<lifeless> content
<lifeless> \o/
<lifeless> profit
<Peng> But I don't want to pay for more RAM.
<Peng> This is really amazing, though. On a 32-bit machine with a 2a repo, checking MySQL isn't a big deal. Maybe 500-600 MB of RAM.
<Peng> 2a rocks.
<Peng> How did we ever live with the pre-2a formats? :P
<Linkadmin> is there any way in a central repository setup to have the repository automatically update its tree on commit? the push-and-update plugin looks like a local hook, and the automirror plugin seems to only want to push to a second repo
<Peng> Currently RAM+swap is approaching 7 GB.
<fullermd> Peng: Machines get more memory all the time.  If we don't keep up with that increase, how will we ever compete with Windows?
<Peng> Can Canonical send me $70 so I can buy enough RAM to check this repo? :D
<Peng> Actually, only $50. I have a little money in my wallet. :P
<fullermd> Shoulda bought memory back in June like I did, before it shot back up in price   :p
<lifeless> Linkadmin: not really.
<lifeless> Linkadmin: generally that suggests you are trying to do something in an unusual way
<Linkadmin> i just want the working tree to be updated when i do a commit...
<Peng> Linkadmin: Why does the central repo need a tree at all?
<Linkadmin> Peng: sorry, i meant the branch needs a working copy
<Linkadmin> not the repo
<Peng> Linkadmin: Why does the central branch need a tree?
<Linkadmin> Peng: because i'd like to set up a webserver to point to the docs I'm keeping in version control
<Linkadmin> so if i do i.e., bzr init-repo repo ; bzr init repo/branch and then remotely commit to repo/branch, i don't seem to see my updated docs in repo/branches on the server
<Peng> Oooh.
<Linkadmin> and when I do bzr push, it tells me something about the remote tree not being updated  :S
<spiv> Linkadmin: working trees are designed for local use, bzr can't update them over remote connections like sftp
<spiv> Linkadmin: you may be interested in the bzr-upload or bzr-push-and-update plugins
<Linkadmin> spiv: yeah i was looking at that, but those seem to be local hooks, not run on the central repository
<spiv> Right.
<Linkadmin> which means that the plugins need to be installed on every collaborator's computer, and they all need to use the plugins' commands
<spiv> Well, push-and-update hooks into regular bzr push, but yes.
<spiv> The simplest solution is to put a cron job on the server that runs "bzr update" every 10 minutes or so.
<Linkadmin> i think i'll probably set up a second branch and have automirror push to that branch. Since automirror is post_commit, that means it's run from the central repo, right?
<spiv> If the central branch is only written to via a smart server (e.g. bzr+ssh), then in principle you could write a simple plugin to hook the Branch.post_branch_tip_change event and then run "bzr update" from that.
<spiv> But I wouldn't be surprised if there are a bunch of annoying details that make that harder than it should be...
<Linkadmin> i was thinking about doing that too yeah
<spiv> I'd be happy to help if you want to do that, though.
<Linkadmin> but it sounds like automirror would be a safer choice if it can run on commit on the repo, and not on individual systems
<spiv> post_commit is run where the commit happens -- i.e. the computer where 'bzr commit' is running, not on the repo.
<Linkadmin> oh man
<spiv> The right server-side hook is Branch.post_change_branch_tip
<Linkadmin> but wait...
<Linkadmin> https://bugs.launchpad.net/bzr-email/+bug/307988
<ubottu> Launchpad bug 307988 in bzr-email "Central repository email?" [Undecided,Invalid]
<Linkadmin> this runs from the central server
<Linkadmin> oh i see
<Linkadmin> different hooks, ok
<spiv> Yes, bzr-email uses that hook
<Linkadmin> do you know if automirror does? I'll go look for the code, brb
<spiv> (Although it will fallback to post_commit for ancient bzr versions)
<spiv> It appears not, but it's probably not hard to update it.
<spiv> Linkadmin: give me 10 minutes, I'll whip up a patch, this looks pretty straightforward
<Linkadmin> w00t w00t
<spiv> Linkadmin: lp:~spiv/bzr-automirror/use-new-hook
<Linkadmin> i was just looking at that  :)
<Linkadmin> i'll try it out right now
<Linkadmin> just to recap my plan, i'll bzr init-repo repo ; bzr init repo/branch1 ; bzr init repo/branch2, then in branch1/.bzr/branch/branch.conf i'll tell it to post_commit_update (or whatever the setting is) to branch2, and when I commit over bzr+ssh remotely, that hook will run properly?
<lifeless> sure. Dunno why you need a second branch thouh.
<Linkadmin> well because i don't think automirror will properly push the branch into its own working copy without problems, right?
<lifeless> uh
<lifeless> so I would just call tree.update() from the post tip change hook on the server
<spiv> lifeless: the "just" there hides a few details, but sure :)
<spiv> I guess params.branch.bzrdir.open_workingtree().update() would probably work.
<Linkadmin> then why doesn't bzr do that by default? It does it for local branches but won't do it on remotes...
<lifeless> with try: except errors.NoWorkingTree:pass
<lifeless> Linkadmin: because in the general case it won't work.
<lifeless> Linkadmin: if you have conflicts, or the tree is locally edited, there is no UI for the person pushing to fix issues with it.
<Linkadmin> gotcha
<spiv> And we'd need to define the network protocol for reporting those issues, etc.
<Linkadmin> makes sense
<Linkadmin> so it will probably come at some point i guess
<spiv> In your case, you're always expecting tree.update() to work because there should never be any local changes.
<lifeless> Linkadmin: I doubt it.
<lifeless> Linkadmin: its not on anyones todo list, and I know of plenty of cases where doing it would be very much the wrong think.
<Linkadmin> is there a roadmap for features for future development?
<lifeless> s/think/thing/
<poolie> lifeless: as part of patch piloting, please chase up contributor agreements where needed
<poolie> and add them to that team
<mwhudson> http://pastebin.ubuntu.com/326532/ <- is that ok for NEWS entry?
<Linkadmin> thx a ton for the help guys. Gonna try out that hook spiv.
<lifeless> poolie: I know
<poolie> i know you may already know this
<poolie> mwhudson: itym UNICODE(tm)
<poolie> :-)
<mwhudson> heh
<lifeless> mwhudson: looks fine to me
<poolie> but seriously, good, except that I'd drop the final . from the url
<mwhudson> putting the tm mark in would have a certain irony
<poolie> to stop lp spazzing out
<spiv> Or wrap the URL in <>
<poolie> yes
<mwhudson> what should i set public_location and submit_to to?
<lifeless> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev
<lifeless> submit branch
<lifeless> public_location should be something like:
<lifeless> actually
<lifeless> it should default to push_location
<lifeless> which is fine
<lifeless> if it doesn't
<lifeless> public_branch = lp:~mwhudson/bzr
<mwhudson> oh sorry
<lifeless> public_branch:policy = appendpath
<mwhudson> i meant the email address
<lifeless> pqm@bazaar-vcs.org
<mwhudson> thanks
<mwhudson> that didn't work
<mwhudson> All lines of log output:Sender not authorised to commit to branch bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
<mwhudson> oh
<mwhudson> trailing slash ftl
<mwhudson> nope
<mwhudson> All lines of log output:Sender not authorised to commit to branch bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev
<poolie> igc: do you have a specific definition of "gateway pattern"?
<mwhudson> spm: halp
<spm> mwhudson: yo
<spm> oh right. I see. hrm.
<mwhudson> spm: i can't seem to commit to bzr
<lifeless> mwhudson: do a dry run and pastebin it
<spiv> mwhudson: http://, not bzr+ssh:// ?
<mwhudson> http://pastebin.ubuntu.com/326540/
<poolie> lifeless: i suspect that until lp has a concept of mp assignee
<poolie> it will be easier not to have pilots carry over responsibility for things they started on
<mwhudson> spiv: ah, seems happier
<lifeless> poolie: I think we should try it and see.
<lifeless> poolie: handoffs are expensive and will likely fragement discussions
<spiv> mwhudson: I also use http for my branch in the pqm submission too, because pqm keeps having trouble with it.  I honestly can't remember if that's been sorted or not.
<mwhudson> spiv: mine seems to be getting somewhere
<spiv> mwhudson: that good :)
<igc> hi poolie
<igc> poolie: I need to get lunch right now (with my sick daughter) but I'll bbiab
 * igc lunch
<mwhudson> woot, my patch landed in bzr
<brmassa> guys, how could i create a plugin that automatically format the commit messages in a given way? is there a easy tutorial to create plugins?
<mwhudson> it's certainly possible but i don't know how
<brmassa> mwhudson: thanks. but now i need to know the "how" part :P
<spiv> brmassa: there are some docs
<mwhudson> yes, i was aware i was't being very helpful
 * spiv tries to dig them up
<spiv> brmassa: http://bazaar-vcs.org/WritingPlugins seems to be the most helpful link, but I'm sure there's more somewhere, but I'm having trouble finding it :/
<spiv> Well, there's http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/writing_a_plugin.html, but it's pretty short.
<brmassa> spiv: hmmm thanks! i ll take a better look. i will report back if i get something...
<spiv> Ah, there's http://doc.bazaar-vcs.org/developers/plugin-api.html, but it doesn't seem to be linked from anywhere.
<spiv> Oh, via Specifications, I see.
<spiv> Hmm, the way the docs try to be both sphinx and not-sphinx is a bit confusing.
<lifeless> poolie: https://code.edge.launchpad.net/~mbp/bzr-usertest/trivial/+merge/7532 - just push :)
<poolie> k
<poolie> lifeless: i'm going to ask for an sru for all of 2.0.2 into karmic etc
<poolie> to get some practice, and to get those fixes in
<lifeless> cool
<poolie> do you want to talk about it first?
<lifeless> if you like
<poolie> not especially
<poolie> i thought i'd just file it and then people can comment if they want
<poolie> it's been discussed a few time before
<poolie> the big question is whether they'll be ok with one sru taking multiple fixes
<poolie> and also i guess whether it's sufficiently conservative
<lifeless> the key thing is 'auditable'
<lifeless> someone will read the diff
<spiv> Hmm, 2.0.0 -> 2.0.2 diffstat: 54 files changed, 1562 insertions(+), 487 deletions(-)
<spiv> But about half of that is in bzrlib/tests/
<lifeless> poolie: can I borrow the LEAN book when you've finished it ?
<poolie> yes
<poolie> lifeless/igc: how about upgrading bzr-usertest to 2a? any objections?
<igc> poolie: sure
<igc> poolie: I've done it locally last week iirc
<igc> poolie: maybe I didn't finish doing the lp dance at that end
<poolie> oh maybe not
<fullermd> 2a comes with lap dances?!
<lifeless> poolie: JFDI
<lifeless> our community is all dependent on 2a anyway to get bzr itself
<poolie> igc, oh, maybe you wanted to make https://code.edge.launchpad.net/~ian-clatworthy/bzr-usertest/trunk the new trunk?
<poolie> suggest you reassign ownership too
<igc> poolie: I'll take a look
<poolie> thanks
<poolie> igc, ping me when you're done and i'll do that merge for robert
<igc> poolie: ok
<igc> poolie: new trunk pushed but I don't think it went smoothly
<igc> poolie: the old branch disappeared? Did you rename it?
<igc> poolie: maybe lp eat it while I was changing the development focus
<igc> ate
<igc> poolie: ah. It's still there under trunk-old and things look ok now
 * lifeless really prefers in place upgrades
<lifeless> they seem smoother to me
<poolie> igc: i haven't looked at the releases yet; there's meant to be one this week, but with john sick and on holidays maybe someone else should do it
<igc> poolie: did you want to do our weekly call today?
<poolie> sure
<poolie> in 2m is good for me
<igc> poolie: how does 10 minutes sound?
<MTecknology> So... bzr-fastimport
<MTecknology> how do I go about using this?
<poolie> igc, cup of tea loaded, call when ready :)
<igc> poolie: now is fine :-)
<MTecknology> I guess I'll need to play with fastimport tomorrow - it looks like it won't be fun
<poolie> igc, no, not mine i guess
<igc> done
<igc> poolie: ^
<poolie> k
<bialix> igc: are you still here?
<bialix> it seems not, I'll send a mail then
<lifeless> spiv: and where is your pqm-submit work?
<spiv> lifeless: a happy coincidence, just pushing an update now that adds tests
<lifeless> spiv: just land it then. /me rs's the tests.
<spiv> lifeless: ok, will do.  Thanks!
<lifeless> spiv: how do you use it though
<spiv> lifeless: set pqm_email in locations.conf for the public_location
<igc> hi bialix
<lifeless> spiv: oh! so I need to edit locations.conf to send in gordon's merge remotely?
<spiv> lifeless: then use --ignore-local and specify the submit branch and public branch explicitly via the relevant options.
<spiv> (or you can put the pqm_email in your global config...)
<lifeless> spiv: what do you think of looking up pqm_email on the target branch location ?
<spiv> lifeless: I have this in my locations.conf:
<spiv> [lp:~*/bzr/]
<spiv> pqm_email = Canonical PQM <pqm@bazaar-vcs.org>
<spiv> lifeless: that sounds reasonable on the face of it.
<lifeless> ok, that will do. I'll file a bug for the other point.
<spiv> lifeless: I can't really remember why I did it this way, to be honest.
 * igc dinner
<spiv> lifeless: enjoy!  and file bugs, of course :)
 * spiv -> off the evening.
<lifeless> spiv: thanks
<Peng> OK, let's try "bzr check" again with 8 GB of RAM. And I'm not going any higher.
<lifeless> poolie: did you land that usertest branch? because of the branch dance lp won't say
<vila> hi all !
<lifeless> vila: hihi
<lifeless> vila: --no-strict! :)
<vila> :)
<lifeless> (as in, I'm hoping you can fix that bug today :P)
<bialix> hello vila! you're back!
<vila> lifeless: yeah. got that. No promise, babune is almost red even in its reduced config...
<vila> bialix: hi :) Still fighting jetlag, but getting there, hopefully I'll be able to stay awake today :)
 * bialix hopes you fly from warm sea and good rest ;-)
<bialix> vila: I won't ping you today, I promise; just glad you're back
<vila> :)
 * bialix wonders why igc don't use lazy_register for explorer commands
<OldAl> igc: Hi!
<OldAl> bialix: Hello! What time is it now in Kiiv?
<bialix> OldAl: hi, there is noon now, we're live in +2 timezone
<bialix> igc is not here right now
<OldAl> bialix: Well, left a "hi" for igc, but no reply.
<OldAl> bialix: OK, 1200 where you live; 2100 in Canberra   1200 +900 = 2100.  What part of Ukraine are you at? What is the nearest city?
<OldAl> bialix: So you are near the Black Sea?
<igc> hi bialix, OldAl
<bialix> evening igc
<MvG> What is a revision key? I found that term looking at the bzr source code...
<OldAl> igc: Hi, igc
<bialix> igc: I'd like to land my patch for lazy-commands in explorer. I found some use cases for it. I'll wait till weekend if you find the time for review.
<OldAl> igc: Just had a chat with bialix.
<bialix> MvG: revision key? maybe revision-id?
<MvG> bialix: No. The one-element tuple (revid,) seems to be /one/ possible form of a revision key, but I assume not the only one.
 * MvG is reading Repository.get_parent_map
<bialix> where isone-item tuple, there is possible multiple-items tuples
<MvG> yes, but with what meaning?
<bialix> direct meaning
<bialix> get several revisions from repo
<bialix> in a batch
<OldAl> igc: I've downloaded the docs about bzr-plugins from your lp +/junk address, did  make html, got the result in _html directory (I think).  Lots of complaints from Sphinx about missing parts.
<MvG> I doubt it's treated as a list, because get_parent_map even deals with lists of revision keys.
<OldAl> igc: Do you expect the documenters to know Sphinx?  Or how much you think we should attempt to learn Sphinx?
<bialix> can't say off-hand
<igc> bialix: that patches looks good and I've just approved it
<igc> bialix: are you happy to land it?
<bialix> igc: thanks
<bialix> yes, I am
<bialix> igc: should I write some special NEWS item?
<igc> OldAl: you need to know ReST. Sphinx adds a small amount over that
<igc> bialix: it's mostly internal isn't it?
<igc> bialix: add a NEWS item is there's an external impact
<bialix> igc: yes, it's internal thing
<OldAl> igc: OK, I go to my home moinmoin (desktop version I use to keep records) and will change lots of pages to reST.  I thought that moinmoin uses flat file system.  Is that not so?
<igc> OldAl: flat file system?
<igc> moin supports it's own markup language and ReST
<lifeless> igc: moinmoin is plugable these days. We do use the flat file backend, but its not exposed on the web.
<lifeless> OldAl: ^
<OldAl> igc: Most wikis are "flat file system"; They look structured, but internally they are flat file (all in one huge b. directory..).
<OldAl> igc: moinmoin may be smarter - have not looked in detail.
<OldAl> igc: Should be able to find out RSN, but thought you might know off hand.
<OldAl> lifeless: what does ^ mean in irc lango?
<lifeless> OldAl: that the line above also was addressed to you
<OldAl> lifeless: Oh, I see that - so my desktop moinmoin is probably flat file system, but not visible on launchpad version?
<OldAl> lifeless: It's ability of plugins is great for things like reST, listing of Python code, etc.
<OldAl> lifeless: My moinmoin desktop is kind of scratch pad.  It is great for a guy with failing memory for record keeping...
<OldAl> lifeless: I get this message each time I connect: freenode-connect: Received CTCP 'VERSION' (to oldal) from freenode-connect.  What does CTCP mean and what does the message say?
<jelmer> lifeless, ping
<lifeless> pong
<jelmer> lifeless: One of the sprint notes said you were working on uploading a bzr-rewrite package to Debian/Ubuntu
<lifeless> jelmer: its been uploaded to the bzr beta ppa I think
<jelmer> lifeless: Is that still true, any news in that regard?
<lifeless> I need to pull, audit and push to debian
<lifeless> packaging branch will be on lp:ubuntu/karmic/bzr-rewrite/*
<jelmer> lifeless: Ah, thanks
<lifeless> jelmer: if you want to do that,  I won't say no :)
<jelmer> Maybe :-) I have some long-overdue sponsoring of qbzr and bzr-explorer packages to do first.
<lifeless> gnight
<jelmer> 'night
<bialix> what is correct way to check if file actually ignored?
<bialix> tree.is_ignored(path) does not check versionning info
<bialix> so if the file in the tree is versioned but match ignored pattern?
<ryanhaigh> hi all, i have an existing project from when i first tried bzr and it contains a few revisions with a significant number of large binary files that aren't really related. in later revs i ignored them but they are still in the rev history and so checkout/branch take a LONG time and uses a lot of space. what is the best way (if its possible) to remove those files from the revision history?
<igc> night
<bialix> ryanhaigh: rewriting the history makes new and old branches incompatible. if you're OK with this you can use either rebase (rewrite plugin) or fast-import-filter
<bialix> hi GaryvdM
<GaryvdM> Hi bialix
<bialix> thx for fast review
<bialix> GaryvdM: do you have any ideas how to debug and fix Bug 487115?
<ubottu> Launchpad bug 487115 in qbzr "qcommit: (warning?) message in console when files grouped into directory" [Medium,Confirmed] https://launchpad.net/bugs/487115
<GaryvdM> Pleasure. I thought that we behave the same as cli commit, but we were different.
<GaryvdM> bialix: re 487115 - Not sure off hand, but I will take a look
<bialix> GaryvdM: actually it seems tree.is_ignored() is misleading API
<bialix> I think this function should be named as is_match_ignore_pattern()
<bialix> interesting, the patch with such change will be rejecting in first 15 min or so?
<GaryvdM> bialix: I've been working on https://code.launchpad.net/~garyvdm/qbzr/better_text_display
<bialix> that's nice
<bialix> GaryvdM: if you have any opinion on qshelve, I'd like to hear
<bialix> (recent discussion with john szkameister)
<GaryvdM> bialix: Yes - the stuff that I'm working on is very related. I'm busy reading your mail carefully, and then I'm going to reply
<bialix> I did not write my mail
<bialix> actually I think we can and maybe should create line-based side-by-side editor for shelve
<bialix> something like qannotate now
<bialix> when every line easily identified
<GaryvdM> Yes - That is my plan
<GaryvdM> bialix: Your mail from this morning
<bialix> yes, I did not finish it in morning -- have to run to work
<GaryvdM> Well - There is a mail in my inbox from you re qshelve. May be you sent if by mistake
<GaryvdM> *uit
<GaryvdM> *it
<bialix> no, I've sent it debilerately
<bialix> I've write second part tonight, about editor'
<GaryvdM> ok
<bialix> *I'll write, sorry
<bialix> GaryvdM: we have many good user-visible improvements in this release, I like it. Right for new year :-)
<GaryvdM> Thats cool
<bialix> yeah
<bialix> I've starting working on change of code layout
<bialix> I hope to finish it and land after 0.17
<bialix> GaryvdM: I want to blog about new encoding selector in qbzr
<bialix> I remember in the past you've published some of qbzr screenshots in main bzr blog?
<GaryvdM> Yes - poolie made me a author on there. Send Him a mail, and I'm sure he will do the same for you.
<GaryvdM> bialix: One of the things I want to do with qdiif, is make it possible to set the encoding per file.
<bialix> GaryvdM: me too, did you saw the thread in bzr ML about versioned preperties?
<GaryvdM> Sorry - No
 * GaryvdM reads the mailing list selectively
<asabil> hi all
<jelmer> hey asabil
<asabil> is there any way to get a prettier output in bzr qlog when viewing the launchpad code ?
<asabil> I mean I want to filter out the [r=...][...][...] tags in the commit message
<asabil> hey jelmer
<GaryvdM> asabil: you can hide the bottom plane, by draging it smaller.
<asabil> GaryvdM, that's not what I meant
<asabil> I mean in the log tree
<GaryvdM> asabil: The latest trunk version has some self-improvement to the display of
<GaryvdM> opps - pressed enter by mistake - that should read
<GaryvdM> asabil: The latest trunk version has some improvements to the display of parents and children in the message box
<asabil> I am running trunk
<GaryvdM> asabil - So you want to hide bugs and tags in the log tree?
<asabil> GaryvdM, the problem is that the launchpad history is polluted with some PQM specific tags I think
<asabil> all the commit messages are prefixed with some gibberish
 * GaryvdM goes to look at the launchpad history
<bialix> asabil: screenshot?
<bialix> asabil: there is custom replace feature for qlog messages
<bialix> qlog_replace see README.txt
<asabil> bialix, http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/changes
<asabil> oh ok thanks, I will check that
<GaryvdM> bialix: I forgot about that.
<asabil> wow that's a cool feature !
<GaryvdM> funny - I've never used it.
<bialix> qlog_replace does not help for main window
<bialix> I guess, Gary may know better
<bialix> GaryvdM: I've never used it too, just read about it
<GaryvdM> asabil: Please let us know if there are any bugs with it. I don't think many people use it, and there are no tests for it, so I'm worried that it might be broken.
<asabil> GaryvdM, it doesn't seem to work for me
<MvG> bialix: the other day you pointed me at http://starship.python.net/crew/mwh/bzrlibapi/ . Now I find it's lacking documentation of members. Do you perhaps know of a documentation that does include members besides functions?
<MvG> Does bzrlib.inventory.InventoryDirectory.parent_id behave differently depending on the absence or presence of a rich root?
<GaryvdM> asabil: Ok - I'll take a look. Please could you log a bug so that it does not slip through the cracks.
<asabil> GaryvdM, yeah sure, I will do that later
<asabil> thanks for your help
<bialix> MvG: what do you mean?
<GaryvdM> Pleasure
<MvG> bialix: http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.inventory.InventoryDirectory.html e.g. doesn't list "parent_id", the one I mentioned in my question above. pydoc does.
<bialix> MvG: I'm sure mwhudson is master of that doc
<bialix> MvG: ah, hmm, there is used custom tool for building these docs, called pydoctor IIRC
<MvG> I see.
<MvG> thx.
<MvG> Don't feel like filing a feature request for such tools just now.
<bialix> the doc generated automatically, so if there is nothing than most likely either original sources lacking it or bug in pydoctor
<bialix> you may want ask mwhudson
<MvG> The members are undocumented.
<bialix> that's bad, sorry, I can't help here
<MvG> His name has been mentioned often enough, I guess if he's available and feels like answering, he will.
<bialix> he's from land of kiwi IIRC, so right now he's sleeping
<MvG> Maybe will read logs...
 * jelmer hugs jam
<jelmer> meliae ftw
<jelmer> oh, also
 * jelmer hugs mwhudson
<MvG> mzz: Do you wish to review https://code.launchpad.net/~gagern/trac-bzr/bug484983/+merge/15199 regarding the removal of the get_previous method we talked about the other day?
<mzz> MvG: did you check that the generated history for the root node is at least as sensible compared to the history for a subdirectory as it was before?
<MvG> jelmer: as you write such an encouraging comment about having bzrlib deal with dotted revnos, would you have a look at https://code.launchpad.net/~gagern/trac-bzr/bug487529/+merge/15201 and comment?
<MvG> mzz: Yes.
<MvG> mzz: Root of the branch you mean, right?
<MvG> It's way more sensible now.
<MvG> At least in the cases I encountered.
<mzz> MvG: yes (which was supposed to be returning all ancestry unconditionally both now and before)
<mzz> I'm just a little worried about there being off by ones in one if you're fixing them in the other
<mzz> but if you've tested them that's definitely good enough for me.,
<MvG> mzz: All ancestry up top the current rev. It returned all ancestry up to the tip of the branch before.
<jelmer> MvG, you probably want to catch ValueError as well in revid_from_dotted
<jelmer> MvG: and return None
<MvG> jelmer: Would happen if the tuple has an invalid number of elements?
<jelmer> MvG: if there are non-integers in the string
<MvG> jelmer: The caller ensures that for now. If it doesn't, I guess I'd rather consider that an error on the part of the caller.
<MvG> Of course, I could as well drop the check for the caller...
<jelmer> MvG: ah, never mind then
<jelmer> also, any particular reason for assigning a variable and returning that rather than returning directly?
<jelmer> seems fine otherwise
<MvG> jelmer: Easier to insert a debug statement in between, or some further processing step.
<MvG> mzz: Thanks for the review!
<mzz> sure, but it really doesn't mean much since I really have not looked at this code in ages
<mzz> this is more like me getting the impression you know at least as much about what's going on than I did when I wrote all this than me understanding the changes
<Morbus> i don't suppose anyone uses trac-bzr in here?
<MvG> mzz: and that I made no obvious flaws, or recreated errors you did back then and still remember.
<jelmer> Morbus: we were just talking about it :-)
<MvG> :-D
<Morbus> oh great. i have a newb support question! ;)
<Morbus> heh, heh
<MvG> Let's hear it.
<jelmer> mvg: Anyway, the changes seem fine in general
<Morbus> just grabbed the latest lp main, made an egg of it, installed it into local Trac, and made the changes per the README directory.
<Morbus> my repo directory is set to [11:42]  <Morbus> repository_dir = /ebs/repositories/bzr
<Morbus> which contains a single branch - but eventually with more.
<Morbus> when i head to trac/browser, i receive:
<Morbus> NoRepositoryPresent: No repository present: "file:///ebs/repositories/bzr/examiner-d7/"
<Morbus> so, it's seeing the (only) branch there, but not getting much further.
<MvG> jelmer: I'm just debugging a strange incident where a dotted revno won't get accepted as a revision. Requires my fix for bug 274609 as well, otherwise you won't even get that far.
<ubottu> Launchpad bug 274609 in trac-bzr "Strange code -- needs cleanup" [Undecided,New] https://launchpad.net/bugs/274609
<Morbus> i have a traceback too, if you'd like it.
<MvG> Morbus: Never did a single-branch setup yet, but wait a few minutes, and I'll try to reproduce.
<MvG> Morbus: Yes, please pastebin the traceback.
<Morbus> well, i have a need for a second branch already, so maybe i should just make one of those first.
<Morbus> lemme do that first, then i'll paste.
<Morbus> *pastebin
<MvG> Morbus: I'd like the pastebin in any case, even if you don't need a fix,.
<Morbus> sure.
<Morbus> MvG: http://pastebin.com/m5ca7dcfe
<mzz> Morbus: what's the "bzr info" output from inside that branch?
<Morbus> bzr: ERROR: No repository present: "file:///ebs/repositories/bzr/examiner-d7/"
<Morbus> i blame chx.
<Morbus> lemme move this outta the way and test with the brand new repo i just made.
<mzz> I don't see off the top of my head how you'd get that in trac-bzr unless there really is no repository (you did something weird like manually copying a branch out of a shared repository?)
 * Morbus sighs.
<chx> um
<jldupont> Anyone using the Bazaar plugin under Eclipse?  How can I "ignore" a file from a directory under revision control ?
<jldupont> I keep getting an "*" and it is annoying.
<Morbus> mzz/MvG: well, so far, so "good". moved the examiner-d7 outta the way, made a new repo per the tutorial, and now:
<Morbus> AttributeError: 'Revision' object has no attribute 'get_apparent_authors'
<Morbus> which is likely as i did not whoami, perhaps?
<MvG> Morbus: Use newer version of bzr.
<mzz> yeah
<mzz> I don't know which bzrlib version added that, but that definitely sounds like bzr being too old
<Morbus> i'm using the install docs from the site - annoyingly, centos 5/rhel extras only has 1.3. crazy.
<MvG> bzr has changed a lot since then, you want to update manually if there are no newer packages for your distro.
<mzz> Morbus: your assumption that the version requirement in README is up to date may be overly optimistic
<Morbus> well, for bzr in general, not just trac-bzr ;)
<MvG> note to self: update README one fine day...
<jldupont> anyone with some help?
<mzz> jldupont: not for Eclipse, sorry.
<mzz> jldupont: manually adding the path to .bzrignore might work, of course.
 * MvG doesn't use Eclipse.
<GaryvdM> chx: I think Morbus was talking about chx records, not you. :-)
<chx> GaryvdM: def me
<jldupont> @mzz: and this .bzignore is relative to the project directory?
<chx> GaryvdM: I am workin with him
<mzz> jldupont: relative to the branch root
<GaryvdM> oh
<jldupont> @mzz: oh yes, of course... thanks!
<mzz> (I'm guessing those are the same thing, but hey, I really don't speak eclipse)
<jldupont> mzz: so I put a .bzignore in the .bzr folder?
<mzz> jldupont: no, in the same directory .bzr is in
<jldupont> mzz: thanks for the help!
<mzz> np
<jldupont> .bzrignore works like a charm!  Eclipse stops showing annoying "*" all over the place!  Thanks @mzz!
<mzz> jldupont: eclipse may well have a friendly click-and-point way of adding paths to that file
<mzz> I just don't know what that is
<jldupont> mzz: I did look around **a lot**
<chx> Morbus: oyu moved the branch outside of the repository, i wash my hands
<jldupont> mzz: but of course, I am infallible
<jldupont> I mean not infallible !
<Morbus> chx: i told you in the other channel i had moved it outta the way *after* it was determined, above, that it "wasn't a repo" according to bzr info.
<chx> Morbus: the repository is a holder of branches nothing is visible for most commands its just saving save for simialr branches
<mzz> chx, Morbus: I suspect you copied over a branch using cp -r while you wanted bzr push
<mzz> err, or branch
<chx> mzz: nevermind
<mzz> the bzr commands can deal with shared repos, manual filesystem ops won't
<Morbus> heh. curse you compile from source!
 * Morbus googles.
<Morbus> mzz, MvG: well, i've got the latest bzr installed now. and the error is AttributeError: 'module' object has no attribute 'FormatRegistry'
 * mzz frowns
<mzz> Morbus: what's giving you that? I don't see tracbzr using that
<Morbus>  /trac/browser
<mzz> Morbus: traceback?
<Morbus> http://pastebin.com/m1aa9997b
 * MvG is off for dinner.
<Morbus> enjoy!
<MvG> I probably won't be back today. If any trac-bzr bugs arise and can't be fixed, file bug reports.
<Morbus> mzz: any ideas?
<mzz> sorry, missed your link, reading...
<mzz> Morbus: which bzr is that?
<Morbus> 2.0.2
<Morbus> tracbzr main as of an hour ago
<mzz> I have to wonder if something glitched when installing bzr itself. Sec.
<mzz> Morbus: your line numbers don't match the bzr 2.0.2 source tarball
<Morbus> o_O.
<Morbus> how do i make clean for python? i'll do it again.
<mzz> Morbus: how did you install? If this was a manual install consider killing off the existing bzrlib in site-packages completely before running "setup.py install"
<Morbus> oh, nevermind. i already deleted source
<Morbus> wget http://launchpad.net/bzr/2.0/2.0.2/+download/bzr-2.0.2.tar.gz
<mzz> no, hold
<mzz> I think I misread something
 * mzz forgot about demandload
<Morbus> mzz: well, you know...
<mzz> still can't explain the traceback though.
<Morbus> i actually did just reinstall bzr 2.0.2 fresh, and restarted apache (i run trac through it).
<Morbus> now i'm geting an entirely different error
<Morbus> fun!
<Morbus> NoSuchRevision: CHKInventoryRepository('file:///ebs/repositories/bzr/examiner-d7/.bzr/repository/') has no revision ('vcs-imports@canonical.com-20091124053541-iw4cu21x2aa935fs',)
<mzz> that doesn't sound trac-bzr-related either. Does "bzr log" in that examiner-d7 branch work?
<Morbus> ok. gimme a few minutes.
<Morbus> examiner-d7 is a lp branch, which we're currently upgrading. waiting for it to finish.
<Morbus> sorry. two people working on it at same time.
<mgedmin> I'm trying to shelve some unrelated changes, sadly, some of them are too close to related changes and bzr joins the two patch hunks together into one big hunk with two unmodified lines of context in the middle
<mgedmin> any way to split that?
<jelmer> mgedmin, not afaik
<mgedmin> is shelve part of the core, or does it come from bzrtools?
<mzz> mgedmin: yes.
<mgedmin> dpkg -L bzr|grep shelve tells me it's core
<mzz> mgedmin: (there's one in each)
<mgedmin> oh, fun!
 * MvG is back for a very short while
<MvG> Is there a way to merge several (i.e. >2) branches into a single working tree without committing anything?
<MvG> I want to experiment with the interaction between different fixes but not clobber my repo with throw-away merge revisions.
<Morbus> mzz: fyi, after the bzr upgrade, everything's working dandily. so at this point, there's nothing wrong with trac-bzr. it was all dependency problems.
<Morbus> MvG ^^
<mzz> ok!
<MvG> Glad to know.
<chx> is it possible to change  a branch to --no-tree
<MvG> Will merge two fixes into lp:trac-bzr in a few minutes...
<MvG> chx: bzr reconfigure --branch
<jfroy|work> Good morning.
<jfroy|work> bzrlib API question: is there a recommended API for getting the diff of a commit in a post-commit hook?
<bialix> morning igc
<bialix> not yet
<bialix> anybody here? need help in English
<zsquareplusc> i have a BZR repo at sf.net enabled and something fishy is going on there... their loggerhead gives me an error about a revision that was never in one of my branches.
<zsquareplusc> is something knwon about the bzr installation there? loggerhead bug? maybe related to the fact that i never ran an init-repo but stored multiple branches?
<bialix> igc has used slogan for bzr-explorer: Version Control for Human Beings
<zsquareplusc> bialix: i'm here but my guess is i can't help you ;-)
<bialix> I need help in translate this
<bialix> zsquareplusc: so I need somebody else :-)
<bialix> zsquareplusc: what's the error?
<zsquareplusc> bialix: well, you could just try and ask anyway maybe someone is willing to help. (or maybe you did and i did not see it as i just joined)
<zsquareplusc> bialix: see http://mspgcc.bzr.sourceforge.net/bzr/mspgcc/changes  it just says error / KeyError
<bialix> zsquareplusc: thanks. I know how this channel works
<zsquareplusc> a search with google shoes the same error for many other repos too
<zsquareplusc> s/shoes/shows :-)
<zsquareplusc> bialix: ah you want to translate igc's slogan? from english to an other language?
<Peng> zsquareplusc: Right now that page says "no revisions".
<zsquareplusc> Peng: interesting i saw that also from time to time... but most of the time i get a KeyError. ok after reloading i get that no revisions now too.
<zsquareplusc> but there were about 10 branches...
<bialix> my connection was interrupted
<bialix> zsquareplusc: I don't see error
<bialix> zsquareplusc: there is message: No revisions!
<bialix> fullermd: hi
<zsquareplusc> bialix: yes i get that too now. it happens to change from time to time :/   however there should be about 10 branches...
<bialix> that's bad
<zsquareplusc> init-repo doesn't work when there is already a .bzr . there seems to be no --force option, so i need to have local filesystem access on the repo?
<zsquareplusc> i think i'll start over with the server an upload the branches again
<bialix> zsquareplusc: you should have ssh access, no?
<zsquareplusc> yes, complicated. searching the docs on their site..
<bialix> try hitchhicker
<zsquareplusc> what's that?
<bialix> launchpad.net/hitchhicker
<bialix> I have a question about "for Human beings": is it closer to say just "for Humans" or better use "for mere mortals"? If you can answer please do, I'll read logs tomorrow
<zsquareplusc> <- not native english speaking. maybe a bit of both. i guess it goes mostly in the direction, "easy to use" also for non programmers or "you don't have to be a geek/nerd"
<bialix> maybe "plain humans" or "ordinary people"?
<bialix> the latter sounds fine for me in Russian
<GaryvdM> bialix: Hi  - Yes - I think "ordinary people" synonym.
<GaryvdM> * is a good synonym
<bialix> good
<GaryvdM> jfroy|work: I'm not sure if someone has answered your question re diff in post-commit hook.
<bialix> because current translation is just "for Humans" -- it does not sound so cool as in English
<bob2> it's more like "mere mortals", but "ordinary people" would work too
<jfroy|work> GaryvdM: I pulled some code out of bzr-email that seems to work fine
<GaryvdM> jfroy|work: Ok - cool
<bialix> bob2: mere mortals is stable idiom in my language, thanks for tip
<GaryvdM> bialix: I think Bug 487115 may be a win32 or qt version specific bug.
<ubottu> Launchpad bug 487115 in qbzr "qcommit: (warning?) message in console when files grouped into directory" [Medium,Confirmed] https://launchpad.net/bugs/487115
<jfroy|work> But actually I could use a quick code review, see if I'm doing something stupid.
<bialix> GaryvdM: hmm
 * jfroy|work pasted http://pastie.textmate.org/713396
<hsn> is somewhere bzr.dev tree available via bzr protocol? http seems to be pretty slow
<beuno>  hsn on Launchpad?
<beuno> lp:bzr?
<beuno> if you have your launchpad username specified, it should use bzr+ssh
<hsn> hmm, i cant login to lp, ssl cert error from curl. is there way to ignore certs?
<Peng> hsn: On Ubuntu, it should work if you install ca-certificates. Probably.
<Peng> hsn: Or stop using curl.
<bialix> pycurl
<hsn> its on windows
<bialix> download ca-perm from Mozilla if you need pycurl
<bialix> but better just uninstall it
<hsn> https://bugs.launchpad.net/bzr/+bug/82086 its seems to be known bug with pycurl
<ubottu> Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Triaged]
<zsquareplusc> poolie: i'm fighting with one of your old programs... gnu keyring on the palm...
<poolie> :)
<zsquareplusc> it worked well but as i don't really use the palm any more i wanted to export the database. but no success so far. and the app keeps deleting the DB starting over with an empty one :/
<zsquareplusc> and a bzr related question. i just uploaded a branch that's obsolete to a shared repo. should i just delete the folder in the repo? is there a "cleanup" command to get rid of the unused change sets?
<poolie> just delete the branch folder
<hsn> my bzr segfauls at AppName: python.exe	 AppVer: 0.0.0.0	 ModName: _groupcompress_pyx.pyd ModVer: 0.0.0.0	 Offset: 00005cfb
<Peng> zsquareplusc: There is no cleanup command. If you really really wanted to (like if you committed an ISO), you could create a new repository and branch all of your current branches into it, but it's usually not worth bothering.
<zsquareplusc> well i'm now uploading the branch that merged the other two so in fact there should not be many "floating" change sets left. OK
<zsquareplusc> poolie: you don't happen to have a export tool for gnu keyring for the old 1.0 database format?
<poolie> zsquareplusc: not on me; i think there may be one though
<poolie> i haven't worked on that for about 7 years
<poolie> check on the site or ask on the list
<zsquareplusc> poolie: yes i saw someone else took over later. but i was stuck on the version from 2000 anyway ;-) i tried the two java tools from the site, both give errors ("null"?? and "negativearrayindex") the 3rd site is unavailable.. oh well i'll probably end up exporting each one separately to a note and copying those..
<lifeless> hsn: please file a bug
<zsquareplusc> is there an "ls" for shared repos (listing the branches)? qlog can do it but i'd prefer a console only solution w/o history :/
<Peng> zsquareplusc: The bzrtools plugin provides a "branches" command.
<Peng> zsquareplusc: You can even run it on URLs, but it might be horrifically slow.
<maxb> Is there any way to make bzr diff purely based on filename, ignoring file-ids?
<Peng> maxb: Ehh. Why would you need that?
<maxb> Dealing with less-than-perfect imports from svn, etc.
<zsquareplusc> Peng: thanks that works. i'm using it with bzr:// and it is SLOW. but at least it shows whats requested
<Peng> zsquareplusc: Running with --no-plugins /might/ make it faster, but I dunno.
<Peng> zsquareplusc: (if you have any plugins like bzr-svn installed, anyway)
<lifeless> poolie: where, when for lunch?
<chrispitzer> i'm getting a fun rich-root error...
<chrispitzer> (pasting 3 lines)
<chrispitzer> chris@geordi:~/dev$ bzr push
<chrispitzer> Using saved push location: bzr+ssh://bar.com/srv/foobar/www/
<chrispitzer> bzr: ERROR: RemoteRepository(bzr+ssh://bar.com/srv/foobar/www/.bzr/)
<chrispitzer> is not compatible with
<chrispitzer> CHKInventoryRepository('file:///home/chris/src/dev/.bzr/repository/')
<chrispitzer> different rich-root support
<lifeless> you need to upgrade foobar/www
<chrispitzer> the repo?  or the bazaar instance?
<lifeless> the repo
<chrispitzer> chris@zim:/srv/bar/www$ bzr upgrade
<chrispitzer> bzr: ERROR: The branch format Meta directory format 1 is already at the most recent format.
<chrispitzer> is that the upgrade method you're talkign about?
<lifeless> sounds like you need to upgrade that bzr install as well
<lifeless> to 2.0 or newer (thats what you have on @geordi, and why you are getting this error)
<chrispitzer> i just ran apt-get upgrade bzr ... but that didn't seem to do it... is that correct?
<lifeless> well, what OS are you using?
<zsquareplusc> Peng: i do have some plugins like bzr-svn but --no-plugins also disables bzr tools itself :/
<lifeless> if its a release of ubuntu or debian you can use our PPA. If you are using a development version of Ubuntu or Debian you should have 2.0 already (but may need to apt-get update first to make it visible)
<poolie> hi jam
<Peng> zsquareplusc: Haha, good point. Sorry.
<zsquareplusc> Peng: there should be an additional option to selectively allow some plugins :-) (don't know if there is already)
<Peng> zsquareplusc: Yeah, that'd be nice.
<jam> hey poolie
<jam> I'm only around a bit, finally caught a bit of a break
<poolie> just wanted to say hi
<poolie> and that we're scheduled to do 2.1b3 i think this week
<poolie> maybe someone else could do it
<jam> poolie: 2.1.0b3 is cut
<jam> "gone gold"
<jam> win32 installers are built
<jam> just needs ... anouncment?
<jam> I was probably going to announce yesterday, but didn't even open my laptop
<jam> and now, I'm probably going to be done in about 10 min
#bzr 2009-11-25
<poolie> k
<poolie> i may do the announcement, or perhaps igc can
<igc> hi jam. I hope you're feeling a bit better
<igc> jam: enjoy your break
<igc> jam: sorry if I email re 'no announcement' came across as critical - it wasn't meant to be
<igc> s/I/my/
<lisarex> Would love it if someone could point me in the right direction... I get 'bzr: ERROR: Target directory "drupal" already exists.' when I enter bzr branch lp:drupal. I've previously used parent branch: bzr://vcs.fourkitchens.com/drupal/7/ but awhile back I started getting 'bzr: ERROR: [Errno 13] Permission denied' I don't know how to fix either but I do need an up-to-date copy of Drupal 7.
<spiv> lisarex: 'bzr branch lp:drupal' wants to create a local directory called "drupal", but you already have a directory called "drupal".
<lisarex> spiv: yes that's probably the case (not sure how to check)
<spiv> "ls" will list the files and directories in the current directory
<spiv> Also, what command were you running that was producing the "bzr: ERROR: [Errno 13] Permission denied' error?
<bob2> 'ls drupal'
<lisarex> spiv: ok, yes there is a drupal directory within my 'root' web folder I'm calling d7 ... not sure how I missed that
<lisarex> spiv: can I just delete that drupal directory?
<lisarex> spiv: was running bzr pull
<spiv> If you don't want the directory, the sure you can delete it.  I don't know if you care about its contents or not.
<spiv> You can also do 'bzr branch lp:drupal drupal-copy' to branch it to a directory other than 'drupal' (in that example 'drupal-copy').
<lisarex> spiv: thanks, trying that now
<lisarex> spiv: cool. downloaded the files. Just need to ensure that the files I've downloaded are updating my d7 directory too (I may end up starting over :))
<lisarex> spiv: OK it has. Thanks so much for the help :)
<poolie> spiv, hi
<poolie> which of bug 437626 and bug 445171 do you think is more important? maybe the first?
<ubottu> Launchpad bug 437626 in bzr/2.0 "exceptions.AssertionError: second push failed to complete a fetch set" [High,Fix released] https://launchpad.net/bugs/437626
<ubottu> Launchpad bug 445171 in bzr/2.0 "ObjectNotLocked doing 'bzr log -r 199 path/to/file'" [High,Fix released] https://launchpad.net/bugs/445171
<lifeless> poolie: hi
<poolie> hi
<poolie> hungry?
<lifeless> poolie: reminder: lunch. Also can you add niel to the contributor team - I don't have accecss to do that.
<poolie> hm
<lifeless> neil, I mean.
<poolie> remind me niel who?
<poolie> oh ok
<lifeless> Neil Martinsen-Burrell
<lifeless> he mailed in the agreement yesterday
<poolie> i understand now
<poolie> i thought you meant 'niel'
<poolie> done anyhow
<lifeless> poolie: you've added me?
<poolie> yes
<poolie> i was going to try to make you an admin
<lifeless> oh
<lifeless> so really we should just change the owner to a team
<poolie> but i failed; see #launchpad
<poolie> probably
<lifeless> rather than having us in it.
<lifeless> as we haven't strictly signed it.
<lifeless> I've sent mail
<spm> is this something that you want me to fix? or... ?
<spiv> poolie: yeah, I think I'd say the first.
<poolie> spm, we could ask you to steal ownership but at this point that seems like overkill
<poolie> spiv, thanks, underway
<spm> poolie: oki
<spiv> poolie: yeah, definitely the first, compare the number of duplicates.  More users were hitting that.
<lifeless> poolie: so seeing you soon?
<poolie> going to finish bug 437626 sru process then leave
<ubottu> Launchpad bug 437626 in bzr/2.0 "exceptions.AssertionError: second push failed to complete a fetch set" [High,Fix released] https://launchpad.net/bugs/437626
<poolie> so pretty soon
 * mwhudson remembers that there was a bzr bug that resulted in repos being very fragmented across many packs
<mwhudson> (a) am i right (b) is it fixed (c) which version has the fix?
<lifeless> mwhudson: no, there was a bug where inside a pack we didn't consolidate properly.
<lifeless> mwhudson: any 2.0+ is fine.
<mwhudson> lifeless: ah ok
<mwhudson> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/.bzr/repository/packs/ has 26 packs, is that more than i should expect?
<lifeless> mwhudson: no
<lifeless> mwhudson: you could get at at 999 revisions, for instance.
<lifeless> mwhudson: dump-btree on the packs-name index will tell you if you have stale packs
<mwhudson> lifeless: seems we do
<lifeless> mwhudson: the number of packs you have is dependent on the exact operations that have taken place. The way it works is that there is an upper bound.
<lifeless> and when the bound is exceeded by a transaction, an incremental pack is triggered, which consolidates the smallest (by rev count) packs into one, stopping at the point that will be under the upper bound.
<lifeless> mwhudson: the upper bound is sum(int(digit) for digit in str(repo.revision_count()))
<mathiaz> Hi - Is there  a way to find the revno of the common ancestor for two branches?
<mwhudson> lifeless: right, that's what i thought
<lifeless> mwhudson: so 998 revisons == 26 as upper bound
<mwhudson> i guess i was too lazy to work out what that is for launchpad :)
<lifeless> and in general, upper bound ~= 10*log10(revcount)
<lifeless> mathiaz: not really, no. there is show-ancestor I think.
<mathiaz> lifeless: ok found a workaround for ubuntu package branches
<mathiaz> lifeless: bzr log -rancestor:../squeeze (in the lucid branch)
<mathiaz> lifeless: ^^ that gives the revno of the common ancestor
<_habnabit> Is it possible to only merge part of a revision, without merging the whole revision?
<Peng> I suppose you can shelve or revert some of the changes.
<Peng> History-wise, you can either record that the revision was merged or not (a cherrypick).
<_habnabit> So, merge that revision, shelve the changes, and commit?
<Peng> If you want to.
<Peng> What are you trying to do?
<spiv> _habnabit: yes, that works.  But if that records as a merge, it means future merges will not try to merge the bits you left out.
<_habnabit> I'm trying to backport changes from a fork of a particular project, but one revision has some changes I don't want to backport.
<spiv> Which may be what you want?
<spiv> Ok, my guess is that is what you want, then :)
<_habnabit> I'm not sure what the exact connotations of what you said are, so.
<spiv> Well, after you 'bzr merge' but before you 'bzr commit', look at 'bzr status'; it (usually) will show "pending merges"
<jam> igc: not critical at all, just genuine. I haven't had time because of X and Y and Z, and if someone else *has* the time, I'm really far behind
<jam> and it would be great
<jam> its a fair amount of work to announce
<jam> and I didn't open my laptop really until this evening for a little bit
<spiv> _habnabit: commit records the contents of the files, but it can also record "revision X was merged in at this point".  If it does, then the next time you 'bzr merge' in that branch bzr will know that the changes in that revision have already been merged and will not merge them again.
<_habnabit> spiv, ah.
<_habnabit> I did the merge, but it doesn't show that there are any pending merges.
<spiv> _habnabit: so the question is basically, "the next time you merge from that branch into this one, do you want bzr to try merge all these changes again, or assume they have been merged (so only newer changes should be considered)"
<_habnabit> There were conflicts, though.
<_habnabit> (And I resolved the conflicts.)
<spiv> Conflicts don't affect that; but if you do 'bzr merge -r X..Y' or 'bzr merge subdirectory/of/branch' or something like that, it won't record a pending merge in the working tree.
<_habnabit> Ahh, I see.
<_habnabit> Yeah, I did merge -r.
<spiv> Because the merge record is just "this revision ID is another parent of this revision"
<spiv> Which can't track revision ranges or merging just some files, etc.
<spiv> We'd like to track these more complicated cases, but we haven't implemented that yet.
<lifeless> poolie: http://amp.carboni.ca/
<mwhudson> wow, that sounds fairly insane
<Peng> Rewriting Bazaar? That's not going to be fun.
<mkanat> That sounds like a general waste of time, in fact.
<LaserJock> is there an equivalent to git gc in bzr?
<Peng> LaserJock: Removing unreferenced revisions? No.
<Peng> LaserJock: Recompressing the repository? "bzr pack". But, a side from a couple old bugs leading to bad compression, you don't need to run it yourslf; bzr autopacks frequently enough to keep things healthy.
<Peng> s/a side/aside/
<Peng> s/yourslf/yourself/ damn.
<Peng> (Actually, the bugs aren't that old, but they weren't frequently hit: you would have to have been using the 2a format before bzr 2.0.)
<Peng> LaserJock: BTW, unless you'r using the 2a format, "bzr pack" doesn't even do all that much: it combines the pack files into 1, bit it doesn't recompress them.
<Peng> s/bit/but/ What's wrong with my typing tonight?
<LaserJock> Peng: but there's the obsolete-packs dir, right. Does bzr pack get rid of that?
<LaserJock> I was just comparing .git to .bzr sizes on a branch and I noticed that .bzr was huge
<mwhudson> LaserJock: no, obsolete-packs is probably still there
<LaserJock> ok, well I just rm'd the contents of obsolete-packs
<Peng> LaserJock: Every time the repo is packed (whether an auto-pack or "bzr pack"), obsolete_packs is emptied, then afterwards, any now-unnecessary packs are moved into it.
<Peng> LaserJock: Why?
<LaserJock> Peng: ok, that doesn't make a ton of sense to me but I believe you
<LaserJock> because I don't know how to get rid of it otherwise
<Peng> LaserJock: It'll be automatically emptied later. Why do you need to do it now?
<LaserJock> 1) because i'm trying to figure out repo sizes
<LaserJock> 2) I don't know when it will be emptied
<LaserJock> it was an extra 100+MB sitting in my branch
<Peng> LaserJock: obsolete_packs is used because OSes can't be trusted to immediately write files to the disk. It'd be unfortunate if you had a power failure right after a "bzr pack" and lost all of your data because the file was really sitting in a buffer. This way, you still have the old packs around to recover.
<LaserJock> having almost 200MB for a 20MB working tree doesn't seem very space-efficient to me
<Peng> LaserJock: Which repo format? ("bzr info")
<LaserJock> 2a
<Peng> Aww.
<mwhudson> what does bzr thing about \r in commit messages these days?
<LaserJock> if you tell me I need a newer format I'm going to kill myself
<Peng> LaserJock: Sadly, there isn't another new format yet. :P
<LaserJock> how can this be?!
<LaserJock> I thought the 2.0 format was supposed to get much closer to git with respect to size
<Peng> It usually does.
<mwhudson> LaserJock: how big is git for this branch?
<LaserJock> mwhudson: 22MB
<LaserJock> bzr is 45MB after rm'ing the obsolete packs
<LaserJock> most of the branches I've tried bzr seems to run around twice the size
<mwhudson> LaserJock: converted with bzr-git?
<LaserJock> on that one yeah
<LaserJock> other's have been git-svn vs bzr-svn
<LaserJock> *others
<Peng> mwhudson: Wasn't bzr recently changed to remove \r from commit messages, at least on Windows and/or at least in XML-based repos?
<mwhudson> Peng: doesn't look like it
<mwhudson> Peng: bzrlib.repository.CommitBuilder._validate_unicode_text
<Peng> mwhudson: r4783
<Peng> mwhudson: It's only done at a high level, when you use "bzr ci -m".
<Peng> mwhudson: Other than that, I've got no idea what the \r situation is. :D
<igc> LaserJock: try converting with git fast-export + bzr fast-import instead. I think you'll see a smaller size
<igc> LaserJock: than conversion via bzr-git gives you
<LaserJock> interesting
<mwhudson> the revids will me much shorter :-)
<mwhudson> *be
<LaserJock> 22MB vs 45MB isn't too bad, I just thought 22MB vs 200MB was a bit excessive
<igc> LaserJock: Bzr's compression is sensitive to the rev-id and file-id scheme used. fast-import uses the native bzr schemes while bzr-git uses a custom scheme
<igc> ditto for bzr-hg and bzr-svn
<LaserJock> I see
<vila> hi all
<poolie> hello vila
<poolie> hello vila
<vila> hey poolie ! Sotty, had to go to school for Juliette who is sick
<poolie> np
<poolie> sorry to hear that
<vila> s/sotty/sorry/
<vila> That doesn't seem too bad, a bit of rest will hopefully be all that is needed
<bialix> igc here?
<bialix> hello all
<igc> hi bialix
<bialix> hi igc
<bialix> is it possible to say "Version control for Human beings" as "Version control with human face"?
<bialix> I'm still trying to find the good translation for you slogan
<bialix> igc: ^
<GaryvdM> Hi bialix
<bialix> Hi GaryvdM
<GaryvdM> Hi all
 * bialix needs to reboot, bbiab
<igc> bialix: Ubuntu's slogan is "Linux for Human Beings"
<igc> bialix: maybe translate "Human Beings" to "Everyone"
 * bialix back
<bialix> igc: for everyone is good
<bialix> thx
 * igc dinner
<fullermd> bialix: Howdy.  You pung the other day?
<bialix> fullermd: hello
<bialix> pung? how's funny word
<bialix> it's not relevant today
<fullermd> Oh, sorta I guess.  Putative past tense of 'to ping'.
<bialix> I've just tried to ask anybody of native English to ask meaning of "...for Human Beings"
<fullermd> Ah, 'k.
<bialix> ÐµÑÑ ÑÑÐ½ÑÑÐ½ Ð-)
<bialix> thx anyway :-)
<lifeless> igc: has https://code.edge.launchpad.net/~mbp/bzr-usertest/trivial/+merge/7532 landed? the renamed branch means lp can't tell
<bialix> who has moderator right re bzr ML?
<bialix> can you accept mail from Henning Eggers?
<spiv> bialix: done, thanks
<bialix> thx spiv :-)
<lifeless> vila: could you review https://code.edge.launchpad.net/~doxxx/bzr/quiet-serve/+merge/15112 ?
<vila> lifeless: done
 * fullermd pours some extra coffee for vila.
<vila> fullermd: yeah !
<fullermd> 'course, you're not _here_, so I guess I'll have to drink it for you.
<vila> fullermd: that should give it a better taste anyway :-)
<fullermd> vila: Incidentally, did you ever get around to looking over that Fasces stuff?
<vila> ECONTEXT Fasces ?
<fullermd> My colocated branch-ish dofligger.
<vila> ouch, no :(
<fullermd> Ah, 'k.  I guess that field of endeavor isn't percing up anybody's todo yet anyway.
<fullermd> Just wondering if silence meant that, or that it was so perfect nobody had anything to add   8-}
<vila> Well, I think colocated branches should resurface soon (for some value of soon up to six months)....
<maxb> I have an svn repository containing multiple projects, each in its own directory with its own trunk/tags/branches setup. How do I teach bzr-svn to cooperate with this?
<yoavmoshe> hey, what's the command to use if my bzr server changed it location?
<beuno> yoavmoshe, --remember
<beuno> bzr COMMAND LOCATION --remember
<yoavmoshe> oh okay, thanks beuno!
<yoavmoshe> umm... bzr says 'no such option: --remember', runinng bzr 2.0.1..
<beuno> yoavmoshe, when running which command?
<yoavmoshe> update
<beuno> hm, I don't know how to change what branch it's bound to
<yoavmoshe> beuno: okay thanks. I'll keep trying and post here if i'll find something.
<yoavmoshe> well i'm not supposed to do it, but i just edited .bzr/branch/branch.conf and it went just fine
<vila> yoavmoshe: 1) You're not supposed to do it indeed :) 2) That was the right thing to do 3) Please file a bug
 * beuno waves at vila
 * vila warmly waves back
<yoavmoshe> vila: you're sure? i'm thinking that there's probably a way to do it but i just don't have the time to figure what is it... I can fill a bug but i don't want to create some fault 'bug' just because i didn't RTFM.. :p
<vila> yoavmoshe: better a duplicate than no bug at all, I'm pretty sure you're using a lightweight checkout (i.e. the setup used for a central server that rarely (never) moves) and as such you can't: unbind, pull --remember, bind :pull
<vila> hmm, or maybe just 'pull --remember' would have worked...
<yoavmoshe> vila: um actually i use a full checkout, but some of the other clients use a lightweight one. I'll fill a bug
<vila> yoavmoshe: can you undo your edit and try 'pull --remember <bew_url>' ?
<yoavmoshe> i'll revert my changes and see, it it doesn't i'll fill a bug
<vila> s/bew/new/
<vila> yoavmoshe: great, thanks
<yoavmoshe> bzr pull doesn't work. it connects the new server, but it fails giving me an error for the old one. I'll fill a bug
<yoavmoshe> vila: i did 'bzr unbind' and then 'bzr bind $newserver' and it worked. You sure you can't do that on a lightweight checkout?
<vila> you can't unbind lightweight checkouts
<yoavmoshe> okay.
<bialix> evening vila :-)
<vila> bialix: ghaa, as if jetlag wasn't bad enough, now you make me wonder even more about what time it is :)
<bialix> just saw you're here, so decided to say hello
<kostja_osipov> \o/
<bialix> privet kostja
<kostja_osipov> hello all
<abentley> vila: switch --force works with heavyweight checkouts.
<abentley> vila: (and also with lightweight ones)
<lifeless> vila: thanks
<Peng> So, uh, how bad is "inconsistent details in skipped record"?
<lifeless> it indicates a different view of history between two repos.
<lifeless> how bad it is depends on the difference ;)
<Peng> :D
<AfC> "Crushed by a giant packfile"... what a great Subject: line.
<Peng> Huh, one version of the record uses StaticTuples, and the other tuples and lists.
<lifeless> Peng: more fallout perhaps
<Peng> Pastie: http://paste.ubuntu.com/327982/
<Peng> The contents of the records themselves are different. Dunno if it's in a meaningful way, though.
<Peng> Maybe bzr is angry about my abuse of stacking. :P
<lifeless> Peng: looks bogus to me
<Peng> lifeless: Bogus? So...nothing's wrong?
<lifeless> well something is
<lifeless> it may be in the warning code
<Peng> Well, I'm running "bzr check". We'll find out in a few days. :P
<lifeless> Peng: thanks
<poolie> hi lifeless
<dOxxx> poolie: I've been looking into building the bzr installer for Mac OS X. Not easy... :P
<poolie> :/
<poolie> did you find any documentation about it?
<poolie> jfroy worked on it a bit before
<dOxxx> yeah I was reading his messages on the bzr-mac mailing list
<dOxxx> I also found some older wiki pages
<poolie> it would be nice to get those wiki pages up to date with whatever is expected to be the best method
<dOxxx> I'll give it a go in the next day or two when I can borrow the laptop from its owner
<poolie> i think guilermo worked on this too
<poolie> and he's sometimes on irc
<dOxxx> yes
<dOxxx> I'll probably bug him if I run into a tricky situation
<poolie> spiv, hey, nice bug work recently :)
<dOxxx> anyway, gotta run for a train. seeya later.
<Peng> lifeless: Should be done in about 34.5 hours, FWIW.
<lifeless> hi poolie
<lifeless> igc: ping
<igc> hi lifeless - just looking at your Q now
<igc> lifeless: nope, it has landed. I'll do it now
<igc> has *not*
<lifeless> igc: be sure to manually mark it as done
<igc> shall do
<lifeless> thanks (this is why I don't like the rename-branch approach to upgrading, its disruptive)
<poolie>  igc, hi
<igc> hi poolie
<poolie> igc, could you take over the task of proposing a merge to add graphs of the bzr bug count etc?
<poolie> mwhudson has done the database queries
<poolie> i'm asking you partly because you can actually test it against staging
<poolie> so it needs hooking into the graph system, and then for a merge to be proposed
<poolie> probably by copy&paste of configuration that's already there
<poolie> apparently losas can't do it any time soon
<poolie> i can forward the thread if you don't have it
<igc> poolie: I guess so. It's all new to me
<igc> poolie: please
<igc> poolie: or just point me into the mailing list archives if it's there
<poolie> sent
<poolie> not necessarily right now, i just want to take it out of their queue
<poolie> it would be interesting to see if the mp queue length changes
<igc> right
<igc> poolie: the more interesting metrics IMO are ...
<igc> 1. average/median time to go from 'patch submitted' to 'patch landed'
<igc> 2. Average # of changes to bzr's mainline/week
<igc> i.e. are we decreasing delays and are we increasing velocity
<poolie> patches welcome :)
<poolie> i'd like to see them too
<lifeless> igc: I think your 1 needs some sort of normalisation w.r.t. to size
<poolie> anyhow
<poolie> i think breaking the ice as far as adding graphs would be nice
<igc> lifeless: it does. Or even a cutoff - patches below 500 lines say - would do to start with
#bzr 2009-11-26
<spiv> igc: want to take a second look at https://code.edge.launchpad.net/~patrick-regan/bzr/lp-quicktutorial/+merge/15073?  I think it looks good now.
<igc> spiv: done
<spiv> igc: thanks!
<lifeless> spiv: I have a suggestion for pqm-submit
<lifeless> spiv: let it take a lp merge request url.
<spiv> lifeless: +1
<poolie> lifeless: any comments on bug 488544
<ubottu> Launchpad bug 488544 in launchpad-code "unclear meaning of resubmit action" [Undecided,New] https://launchpad.net/bugs/488544
<lifeless> poolie: yes, commented.
<poolie> heh
<poolie> expected you to say "yes, that bug has comments" :-)
<lifeless> I'm not quite that harsh:)
 * igc lunch
<Peng> Heh, I made push default to --no-strict, and it just bit me. :D
<mwhudson> bzr alias oops='merge --uncommitted ../trunk'
<mwhudson> getting bzr revert ../trunk in there would also be good
<lifeless> mwhudson: this is another reason to use a single checkout :)
<mwhudson> yes, i guess that's true
<mwhudson> lifeless: do you prefer merge proposals to already have NEWS in them, or is best to add that at the last minute, given the potential for conflicts?
<lifeless> the former
 * mwhudson proposes a merge
<lifeless> poolie: I have a suggestion for your lp scripts
<poolie> mwhudson: you can always resolve it later
<poolie> ok
<lifeless> poolie: 'add an approve for folk in the bzr team'
<lifeless> so that e.g. your proposals show up with 1 approval by default, once the script runs.
<poolie> non-canonical people in ~bzr?
<poolie> hm, i might be confused
<poolie> which script?
<lifeless> well you're writing lpapi scripts to help bzr get more out of lp, right?
<poolie> ok, this is a new but similar script?
<lifeless> yes
<poolie> interesting
<lifeless> thats the policy we still have that LP doesn't know about.
<poolie> alternatively the robot could just complain about things that have had N reviews but not changed status
<lifeless> thats also interesting to do, and different.
<lifeless> so I wouldn't say its an alternative.
<poolie> would just adding those votes really add value?
<lifeless> poolie: I think so. At the moment I have to read two columns: author and votes.
<lifeless> if I knew that proposals from committers would have the committers vote present in the votes column,I could scan faster.
<poolie> hm
<poolie> i'll think about it
<poolie> you can prototype this by manually voting +1 on your own things
<lifeless> its only a suggestion ;)
<lifeless> hmm, the script would have to run as 'root-alike' I guess.
<lifeless> because it would want to impersonate the committer.
<lifeless> thumper: ^ would be nice to be able to do the above experiment.
<mwhudson> lifeless: thanks for the review
<poolie> lifeless: quick call?
<lifeless> sure
<bialix> hello all
<Peng> Hi. :)
<lifeless> poolie: btw https://code.edge.launchpad.net/~lifeless/testtools/0.9.1/+merge/15256
<lifeless> poolie: thanks for the review.
<poolie> thanks for doing it
<lifeless> poolie: I think I was more saying 'this is the outcome'
<lifeless> do you think its more tasteful like this?
<poolie> i do
<lifeless> cool
<poolie> i think it's less likely to lead to that kind of failure
<poolie> i guess we can see if jml agrees
<lifeless> I discussed doing a point release with him before doing the change.
<lifeless> I'm confident he won't object to the content of the change.
<poolie> lifeless: do you have any ideas about https://bugs.edge.launchpad.net/ubuntu/+source/devscripts/+bug/434987
<ubottu> Launchpad bug 434987 in devscripts "chdist fails with "E: Internal Error, Could not perform immediate configuration (2) on libattr1"" [Undecided,New]
<poolie> ideally, a way to work around it
<vila> hi all !
<fullermd> Whoop, that must mean it's time for me to go   :p
<vila> hehe, enjoy your night fullermd :)
<fullermd> Oh, it's hardly night, not for many many hours yet...
<fullermd> I just got through my post-breakfast stuff.
<vila> oooh, you meant go *to* work, sorry for the misunderstanding
<poolie> hi vila
<vila> hey :)
<poolie> vila, so how about if you add the comments for shelve-no-tty and merge it?
<vila> poolie: fair enough, I'll do that (<- spiv)
<igc> ping jml, spiv
<igc> jml, spiv: can we get the emacs mirror on LP updated?
<igc> see https://code.edge.launchpad.net/~vcs-imports/emacs/trunk
<igc> the new url is http://bzr.savannah.gnu.org/r/emacs/trunk/
<jml> igc, what should it be updated to?
<igc> jml: how would I change that?
<igc> jml: do I need to join some team?
<igc> to get permission?
<jml> igc, you need to be in ~vcs-imports. I've changed it.
 * jml is not here
<igc> jml who is not there, can you re-enable that import too? It says Next mirror: Disabled
<jml> igc, I have re-enabled it.
<jml> but then it gets disabled again very quickly
<jml> something is fishfy
<jml> fishy
<mwhudson> wtf
<mwhudson> why
<mwhudson> is that owned by ~vcs-imports?
<MvG> Hi! While it's still some time off, I'm starting to think about trac-bzr 0.3.x releases. Have just registered a series in lp.
<mwhudson> (it doesn't seem like it is an import branch though)
<MvG> Now I wonder: should there be beta milestones before the official releases? Would there be enough of a user base to get actual beta-testing done?
<MvG> Or would simply asking people around here to give latest checkouts a try be enough of a test so I could simply start with 0.3.0?
<bialix> MvG: hi, are you about trac-bzr?
<MvG> bialix: Yes.
<bialix> given in mind there was no release at all in the past, I'd say you can just cut tarball and move forward.
<bialix> i.e. do release, or don't
<bialix> beta is overkill right now
<MvG> Glad you think so. Will certainly serve me a lot of worries.
<bialix> those who used trac-bzr already used to use trunk
<bialix> (how's bad I said :-/)
<jml> mwhudson, I might have changed the owner way back when
<jml> mwhudson, a more interesting question to me is, "why does it apparently retry and then still fail with an error message referring to the old branch location"
<mwhudson> jml: yeah, that's a bit odd
 * jml drinks something awesome that rhymes with "banoffee"
<jml> mwhudson, I'm torn between investigating it, and not.
<poolie> hi jml
<mwhudson> jml: https://code.edge.launchpad.net/~vcs-imports/emacs/trunk seems happier now
<mwhudson> not happy
<mwhudson> just happier
<jml> mwhudson, looks happyish
<mwhudson> let's leave it for 6 hours and see what happens :-)
<mwhudson> or kill it and start again
<jml> mwhudson, the dates on the 'recent revision' thing seem a little off :)
<mwhudson> yeah
<jml> (weird, years used to begin with a 1 and no one cared)
<jml> poolie, hi
<mwhudson> jml: loggerhead seems to have a more plausible idea of the revisions
<mwhudson> i wonder if it's choking the scanner
<jml> poolie, fwiw, I think that food prepared from _Lobscouse and Spotted Dog_ makes more sense over here.
<jml> mwhudson, I'll bet its choking the scanner.
<jml> it's
<poolie> jml, i bet
<lifeless> poolie: re: devscripts, not offhand, let me have a look
<poolie> nm
<poolie> i'm sending a mail summarizing where i got up to
<lifeless> anyhow, I'd be using schroot fwiw
<jml> lp devscripts?
 * bialix hates to get random errors in the tests with sftp testing server like this: PermissionDenied: Permission denied: "lock/held": [Errno 13] Permission denied
<kostja_osipov> Hello
<kostja_osipov> could somebody help me with bzr gannotate?
<kostja_osipov> what I actually need is to find out the revision id of a changeset that deletes lines
<kostja_osipov> since the lines are not in annotate output, I can't find the revision
<kostja_osipov> what is the procedure for that in bzr?
<bialix> I'm doubt there is simple way to find deleted lines
<bialix> they are deleted
<bialix> maybe hgrep plugin will help?
<bialix> or log -p?
<kostja_osipov> oh well... there of course is. you scroll back in the revision history, till you find the changeset that still has the lines
<kostja_osipov> the next changeset removes them
<kostja_osipov> but it can be quite tedious
<bialix> I won't call this way "simple"
<kostja_osipov> would be nice if I could see all revisions in a file  on a time line so that I could do binary search on it
<bialix> you're need weave representation it seems
<bialix> you may want to ask jam when he'll be here
<vila> kostja_osipov: bzr qannotate provides the per-file graph, i.e. displays all the revisions that modify a file one way or another
<lifeless> gnight
<bialix> vila: it's not quite true: this graph is sorted and represents only revisions which modified lines in currently annotated version. but if you go back in history and annotate older versions you'll get more graph
<bialix> bonjour vila, btw :-)
<vila> bialix: hi !
<vila> bialix: you're right, I keep forgetting the difference :-(
<vila> bialix: I should really talk to garry about *not* using that graph but presenting the real per-file graph instead, I'm pretty sure the performance penalty will be lost in the noise
<bialix> vila: sometimes I have the same needs as kostja_osipov, I'm still not found easy way to bisect this
<bialix> vila: you can, but actually this feature done not from performance point of view
<bialix> I guess it's intended
<bialix> but as we see, sometimes this approach has flaws
<bialix> file a bug!
<bialix> please
<jml> hello
<stanman246> lol
<stanman246> sometimes i work on a project with someone else. Now i'd like to do some kind of version control, he's been looking into bzr already.
<stanman246> It's a webbased project (cakephp) and we're working on the same files every now and then, can this be controlled with bzr?
<jml> yes
<jml> in a variety of ways
<stanman246> ok, will need to go into some tuts i guess
<jml> probably.
<jml> stanman246, have you used a version control tool before?
<stanman246> no
<jml> stanman246, the big difference from just editing files is that rather than just hitting "save", you can group changes together in a single "commit", which generally also has a short description of the change
<stanman246> come across Git, hows that?
<jml> stanman246, roughly speaking it has feature parity with Bazaar. I find it's UI more complex and less helpful.
<stanman246> jml: yes, so i saw
<stanman246> ah
<stanman246> but... bzr is working with .bzr folders locally right?
<jml> stanman246, yes, kind of, but that seems an odd question to ask.
<stanman246> really need to tut first, before asking, sry
<jml> stanman246, are you and your colleague editing PHP files on the web server itself?
<stanman246> not at first
<jml> stanman246, ok.
<jml> that's good :)
<stanman246> we used to use winscp to get the files, edit them and then up them
<stanman246> but with bzr we could edit the files on the server right?
<stanman246> I don't feel really comfy with that thos
<jml> it's not a good way of doing things.
<jml> VCS makes it slightly easier to separate changing the code from doing a release, IMO.
<jml> and changing files onto the webserver in the web area is basically doing a release
<jml> anyway, here's what I'd do to start with:
<jml> make a copy of your code.
<stanman246> local
<stanman246> right
<stanman246> ?
<jml> for now, anywhere.
<jml> just make sure you have a copy in case everything goes horribly wrong
<jml> but also have a copy that you can change into and run 'bzr init' then 'bzr add' and then 'bzr commit'
<jml> this makes a branch that you can play with
<jml> if you put that branch onto the server (either by copying it or running 'bzr push' or something) then you can either check it out ('bzr checkout') or branch it ('bzr branch')
<kostja_osipov> vila: thanks, I actually used bzr log -p and was able to dig up the changeset i need
<vila> kostja_osipov: cool, did you succeed with your cherry-picks yesterday ?
<kostja_osipov> vila: i'm still in progress.
<kostja_osipov> I am reapplying the first patch in a series, and it touches 40 files and each file has conflicts.
<kostja_osipov> our problem yesterday was a bit of a bit larger puzzle :)
<vila> hmm, so you're back to doing the *first* merge without using patch -p0 ?
<yuval> hey all, I'm seeing the error "not installing http[s]+webdav:// support (only supported for bzr 1.12 and above)" on every command i run. any ideas why this is happening and how to fix? running bzr 2.0.0
<marek_> hi i have a question
<marek_> i have two repos one or locally connected server
<marek_> and other on my local host
<bialix> maxb: ping
<maxb> pong
<bialix> maxb: do you remember your patch for qlog to preserve leading spaces?
<maxb> yes
<marek_> and the problem is:
<bialix> does it still work for you with latest qbzr trunk?
<marek_> i first branched from server to my localhost
<marek_> than edited few files
<marek_> then comited locally
<bialix> maxb: when I've merged your patch I've added the test. Now this test started to fail
<maxb> bialix: oh. no, it doesn't
<marek_> and i can see status "unknown" in olive ide... do you know what does that mean?
<bialix> maxb: you've asked me why I want test for such small thing. that is.
<maxb> bialix: Your point is proven! :-)
<bialix> can we pair to fix it?
<maxb> I need to grab lunch now. I will look at it in a few hours
<bialix> ok, ping me when you'll have a time
<bialix> marek_: any reason to not use bzr-explorer?
<marek_> no reasons
<marek_> :)
<bialix> marek_: I don't see a log of your questions but I can help with explorer, not with olive
<bialix> maxb: when you'll back: here is my branch with updated test: lp:~bialix/qbzr/htmlize-nbsp
<MvG> To anyone interested in trac-bzr: I've got 7 propesed merges waiting for review at https://code.launchpad.net/~trac-bzr-team/trac-bzr/trunk/+merges . I'd be glad if at least some of them would have a second pair of eyes looking at them before I commit them to trunk. Thanks!
<MvG> abentley, mzz: of course past contributors are particularly likely candidates for such reviews, so if you can spare the time...
<abentley> MvG: sorry, but I have no interest in trac-bzr anymore.
<MvG> abentley: all right, noted. Won't bother you with this in the future.
<bialix> maxb: I found the root of problem, but the fix is not so trivial...
<bialix> maxb: fixed and pushed to trunk2a. testing are welcome
<stanman246> hi, i've got ubuntu 9.04 running and installed bzr
<stanman246> but the version is 1.13.1 and my colleague has the repository set up on v 2.0, can i upgrade my bzr version?
<vila> stanman246: you can use the bzr PPA
<maxb> stanman246: There is a bzr PPA that carries the latest released version of bzr, bzrtools and a few other things
<vila> stanman246: https://launchpad.net/~bzr/+archive
<vila> stanman246: or you can upgrade to 9.10 :)
<stanman246> haha
<stanman246> thinking of that...
<chx> hey, 9.10 is awesome
<vila> the later is a couple of clicks away while the former requires a bit more work :)
<chx> it drives my T400s just fine
<chx> I think the only feature of the laptop that does not work is the "silence the mic" button
<chx> but i bet i could make that work too if i would care :)
<stanman246> hmm... on my hp 6720s 9.10 didn't work with compiz..
<stanman246> just did the ppa upgrade to 2.0.2!
<stanman246> ok, now i'm gonna read some! Thanks for the info!
<MvG> bialix: Are you still working on https://bugs.launchpad.net/trac-bzr/+bug/327508 as that report is assigned to you?
<ubottu> Launchpad bug 327508 in trac-bzr "[wishlist] add Bazaar Location link to the contextual navigation under Browse Source" [Undecided,New]
<bialix> MvG: oh, no sorry, I'm not
<MvG> bialix: I guess I'll then reasissign to nobody.
<beuno> vila, email2blog: http://beuno.com.ar/archives/168
<bialix> yes, please
<bialix> MvG: too bad for me, I was too busy since 2009/03 until now
<vila> beuno: hehe
<bialix> push --no-strict :-P
<bialix> bzr upload-files FILES --no-strict :-P :-P
<beuno> bzr upload-files --jfdi?
<bialix> --jdi? perhaps
<bialix> oh, got it
<beuno> :)
<beuno> it's the ruder version
<vila> And the subliminal message is: vila,  http://beuno.com.ar/archives/168, now, jdfi
<vila> :-D
<beuno> vila, I'm glad that got through  ;)
<vila> ha ha ha
<MvG> bzr clone lp:~rocky-burt/trac-bzr/bug-263300 fails for me. Seems that the launchpad bzr server for some reason isn't happy:
<MvG> bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for ('TREE_ROOT', 'bialix@ukr.net-20090118015300-t997i4a3wn3jjpr2')")
<MvG> Any ideas? Is this a launchpad issue or a bzr issue?
<bialix> vila: Bug #488824
<ubottu> Launchpad bug 488824 in qbzr "qannotate: don't filter log of revisions" [Medium,Confirmed] https://launchpad.net/bugs/488824
<vila> bialix: lp:~bialix/bzr/shelve-no-tty make the test suite fail :-/
<bialix> details?
<bialix> shelve --all / shelve --list ?
<vila> blackbox.test_shelve.TestShelveRelpath.test_shelve_in_subdir blackbox.test_shelve.TestShelveList.test_shelve_destroy
 * bialix looks
<vila> it took me a while to notice because pqm send me a truncated mail for the first failure and I didn't notice the mail at first either
<bialix> shelve --all
<bialix> so....
<bialix> vila, I think plan B then
<vila> hmm, weird, pqm fails for the second one only while both fail here..
<vila> what is plan B /
<vila> what is plan B ?
<vila> oh and thanks for filing that bug, I went to lunch and forgot :-/
<bialix> you reject my patch and I provide new patch which will check tty presence in osutils around lines     def getchar(): return msvcrt.getch()
<bialix> vila: shame on you
<bialix> but lunch is the most important, so ok
<bialix> vila: but I'll need your help for testing linux-specific getchar()
<vila> hmm, I don't think that will work, there are cases where we want to read from stdin being a file and that's a valid use case
<bialix> msvcrt.getchar() never read from stdin
<bialix> this is direct access to keyboard buffer
<vila> but it's windows specific
<bialix> so what?
<bialix> this is the root of my problem and why this patch is created
<vila> so that doesn't match the cover letter of your patch that wasn't windows specific
<bialix> vila: because I have no way to test shelve in qrun on non-windows
<bialix> can you?
<bialix> anybody?
 * bialix screams: HEEELP
<bialix> vila: osutils.py around line 1900
 * bialix has no idea how linux part works, tty and termios not his area of expert
 * bialix trying to prepare non-qt test
<vila> bialix: how about transfering your patch to shelf_ui.Shelver.prompt instead ?
<vila> so you don't have to check at two different places... or in getchar() but making the os specific versions pushed down to _getchar() ?
<bialix> this is possible
<bialix> I'm clearly get lost in shelf_ui
<bialix> usage of sys.stdout makes me nervous
<vila> getchar() is used only prompt() but it seems to require a real terminal anyway
<vila> hi GaryvdM
<bialix> privet Gary
<bialix> that means hi
<GaryvdM> Hi bialix, vila
<bialix> hi GaryvdM
<bialix> vila: your chance to say about log in annotate!
<vila> hehe
<bialix> joke
<bialix> I've just stumbled with it myself
<vila> GaryvdM: bialix just filed bug #488824 about qblame not using a true per-file graph
<ubottu> Launchpad bug 488824 in qbzr "qannotate: don't filter log of revisions" [Medium,Confirmed] https://launchpad.net/bugs/488824
<vila> GaryvdM: can you remind me why ?
<bialix> vila: so ok, I'm agree moving my tty check to prompt
<vila> err, I mean
<GaryvdM> vila: Performance
<bialix> vila: so I need resubmit or you reject or how?
<GaryvdM> vila: maybe have a right click - "Show all revisions that change this file" option
<bialix> GaryvdM: I'm agree to have knob
<vila> bialix: just pushing the change to your branch should be enough
<GaryvdM> bialix: knob?
<GaryvdM> I want a plugin that has a  pre_change_branch_tip hook, that I configure to run a test suit before I push to a specified location
<GaryvdM> That will be like a mini pqm that I can use for qbzr
<vila> GaryvdM: that shouldn't be a perf problem, we do that for bzr log FILE by finding the relevant keys in the index
<bialix> GaryvdM: checkbox
<GaryvdM> vila: Yes - but it is still slower than just taking the list of revisions from the annotate
<GaryvdM> bialix: ok - I see
<bialix> GaryvdM: or context menu -- does not matter
<bialix> GaryvdM: hook? I can do it
<vila> GaryvdM: hmm, faster but incorrect :-) It will be nice if you could do it in the background after displaying the first page :-D
<GaryvdM> Does such a plugin exist, or should I write one from scratch?
<bialix> GaryvdM: it would be pretty trivial
<bialix> vila: can I ask about tree.is_ignored?
<GaryvdM> vila: Yes - I can do it after the annotate has been shown.
<vila> But I'm still a bit surprised that querying the index only makes such a difference compared to the annotation time... anyway, you know better, but we had a use case this morning that your current implementation doesn't help (I thought it was):
<bialix> it was afternoon
<vila> searching for deleted lines can be done only if all revisions are displayed in the graph
<GaryvdM> vila: yes
<vila> bialix: before my lunch is morning :-)
<vila> bialix: even if I take it at seven PM :D
<bialix> yep, I'm a bit distracted
<bialix> :-D
<bialix> LOL
<vila> bialix: what about trees.is_ignored ?
<bialix> I think the name is awfully misleading
<bialix> so I think is it worth to starting patch or just forget
<bialix> this method does not check is file actually ignored
<bialix> it returns matching ignore pattern only
<vila> that's what the docstring says
<bialix> so if file versioned but matches ignore pattern -- this function name is wrong
<vila> >-/
<bialix> docstring said: Check whether the filename is ignored by this tree.
<vila> What will be a better name ?
<bialix> this is not true
<vila> bialix: look at the workingtree one
<bialix> better name: something about ignore pattern
<vila> Check whether the filename matches an ignore pattern.
<bialix> ECONFLICT
<bialix> but anyway, my point still valid
<bialix> function name is not correct
<bialix> it's counterintuitive for API users (QBzr)
<bialix> I've just yesterday fixed serious bug because of this
<vila> I don't follow. What are you searching for ?
<vila> There is no such thing as an ignored file. If you want to be pedantic you should say: will that file be ignored if I try to add it *now*.
<vila> That's what wt.is_ignored() answers
<GaryvdM> vila: we understood it to be "is this file ignored"
<vila> Hmm, not even
<vila> But what does that mean ?
<gioele> wt.would_be_ignored() vs wt.is_being_ignored() maybe?
<GaryvdM> vila: The bug fix that bialix was taking about = "is_ignored = not versioned and tree.is_ingored()"
<GaryvdM> gioele: yes
<bialix> vila: WorkingTree subclass MutabkeTree which in turn subclass tree.Tree
<bialix> tree.Tree is therefore defined interface IIUC
<bialix> and interface in tree.Tree said that is_ignored checks is file actually ignored
<bialix> I suppose somewhere along the road original meaning has lost
<bialix> and now is_ignored means is_matches_ignore_pattern
<vila> Sounds right
<bialix> so to remove confusion in weak minds like mine and I have proposal to change method name
<vila> bialix: good, you understand that means taking care about deprecating the old name right ?
<bialix> yes,
<bialix> that's why I'm trying to talk with some of core devs first
<bialix> IIUC such change is too big for 2.1.0rc
<bialix> so better to make it after 2.1.0 gone glod
<bialix> right?
<vila> That's for the 2.1 RM to decide, don't worry too much about it, that's why we have deprecations for
<bialix> this function is very heavily used
<bialix> and not only inside bzrlib
<bialix> but and by 3rd party tools, I guess
<bialix> at least in QBzr definitely
<bialix> I will worry too much
<vila> Then maybe only the doc should be fixed ?
<bialix> mmmm, no. all or nothing
<bialix> the name is misleading in my humble opinion
<vila> lol, is that how you negotiate ?
<bialix> no :-)
<vila> ha, good :)
<bialix> but writing such patch only to change docstring in tree
<bialix> is too trivial
<bialix> and this was real WTF for me
<bialix> I guess name is wrong today
<vila> hmmm, I'm not a native english speaker, so when in doubt, I either write a test or read the code :)
<bialix> as you see there is 2 places to read
<vila> I have no idea about other implementations....
<vila> tree.is_ignored() returning False sounds.... arbitrary, wt.is_ignored() implementation is obviously tied to .bzrignore (both the user one and the global one),
 * bialix inspecting qannotate for tree.py
<vila> the misleading bit is that the temporal indication is nowhere to be seen
<vila> also, revisiontree inherits from tree so is_ignored() returning False is understandable there
<bialix> what's the sense of is_ignored in revisiontree?
<bialix> according to annotation Tree.is_ignored has added by lifeless in 2255.7.97 revid:robertc@robertcollins.net-20070305031021-ypbakvagbivyw5mu
<bialix> but this revision does not use this api, and don't test it
<bialix> no, sorry, I'm wrong
 * bialix looks on Gary with prayer to search in qdiff/qannotate
<bialix> GaryvdM: idea: what you think about adding grep to qbrowse?
 * bialix gave up
<GaryvdM> bialix: Search in diff/annotate - Soon
<GaryvdM> bialix: for browse: I was planning to use bzr-search.
<bialix> bzr-search?
<GaryvdM> bialix: like qlog
<bialix> no, I mean search in files of specific revision
<bialix> bzr-search will going through all history?
<bialix> vila: back to shelve-notty: do you have good comment for me so I can use it when I'll rework my patch?
<GaryvdM> bialix: but you can filter it for a specific revision easily
<bialix> I don't understand yet
<GaryvdM> bialix: maybe grep would be better
<GaryvdM> bialix: anyway - I'm not plaining to work on that any time soon - sorry
<vila> bialix: yup, see lp:~vila/bzr/shelve-no-tty
<GaryvdM> bialix: but search in diff/annotate soon
<vila> bialix: the tests are passing here, please test that is still works for you
<bialix> GaryvdM: I don't asking you to work, I'm asking your opinion
<bialix> ideas bouncing as you said other day
<GaryvdM> bialix: I see - To be honest, I'm not too familiar with grep
<bialix> vila: branching
<bialix> GaryvdM: heh, I'm even manage to write something like ack in python for fun
<vila> ack or awk ?
<bialix> grep just searching in files for pattern
<bialix> vila: ack
<vila> oh, yes, ack, I keep forgetting about it, the perl thing ?
<bialix> yep
<GaryvdM> bialix: What I'm unsure of is how you could get grep to read the text of a revision tree.
<bialix> because I have no desire to install Perl on Windows only for one utility it was fun to rewrite it (partially)
<bialix> GaryvdM: I will do it via python
<bialix> I said grep-like not grep itself
<bialix> there is hgrep plugin
<vila> I don't think hgrep works
<bialix> I'm just bad to remember too much things
<vila> bialix: that's why grep is good for you :-D
<bialix> ?
<bialix> perhaps I'm said not precisely what I want to say
<bialix> I have very long memory about things no more relevant
<GaryvdM> vila: There is a grep plugin on http://bazaar-vcs.org/BzrPlugins, which you are the author of. Is is able to grep a revision tree?
<vila> To say the truth, I'm the maintainer only because I upgraded it long ago to the current bzr version at that time,
<bialix> vila: http://pastebin.com/d33dd960e
<vila> I think I remember that it worked only for the working tree and the plans were to enhance it to work with revision trees, but the internals weren't good enough to do that trivially, there may be some FIXME there...
<bialix> vila: running full test suite takes 3 hours for me
<vila> bialix: no worries,
<vila> I wasn't clear: can you test that with qrun where it was previously failing (as in before your patch)
 * bialix -> now
<vila> if that works, then push that to your branch and add a comment in the mp when done so I can merge from there
<vila> err, I mean merge and submit from there
<vila> pfff, forget that, that's silly, tell me if it works and I'll submit from here :)
<bialix> vila: http://imagebin.ca/view/9ptrtg_B.html
<bialix> it works
<vila> hehe, I love Add-Art (the FireFox plugin), even if the art is not always that good, it's always a pleasure to realize that I avoided yet another ad :)
 * bialix using NoScript
<vila> Yeah, I really should do that too, but I'm lazy and they say there is no virus on Linux :-D
<GaryvdM> I use adblock plus. I'm all ways surprised how many ads there are when I work with out it :-O
<vila> GaryvdM: Add-Art is on top of adblock :)
<GaryvdM> vila: Oh - I see
<bialix> so vila you don't see my wonderful screenshot? :'-(
 * bialix crying
<vila> I see you screenshot, not the ad at the top of the page ;)
<bialix> I don't see AD either
<vila> meh, soory for the confusion,  the ad was on the pastebin
<bialix> I understood
<vila> gnight all
<bialix> bye
 * bialix will go home too
<bialix> bye all
<GaryvdM> bye
<jono> hi all
<GaryvdM> Hi jono
<jono> hey GaryvdM
<jono> when merging I see an M next to files but one has a * - what does that mean?
<jelmer> jono: IIRC some of its metadata changed (perhaps it become executable or is no longer executable?)
<jelmer> *became
<jelmer> yep, looks like it - see "bzr help status-flags"
<jono> thats the one
<jono> :)
<jono> it was a perms change :)
<GaryvdM> jono: Sorry - My connection went down. The * most likely the execution permission bit changed.
<jono> np :)
<jono> figured it out
<jono> thanks!
<GaryvdM> cool
<ronny> jelmer: dulwich seems to have a set of methods that look duplicate on the fist look
<ronny> om, mom, pulling the most recent to be sure
<ronny> jelmer: ah, right, at least the from_file/from_string classmethods are unnecessary at each class
<lifeless> moin
<GaryvdM> Hi lifeless
<lifeless> hi GaryvdM
<ronny> jelmer: and i really dislike the exception hierachy now that i take a look at it, i'll try to make a patch
<jelmer> ronny: That's for historical reasons
<jelmer> ronny: patches are welcome, but I'm not very keen on breaking backwards compatibility..
<jelmer> ronny: btw, there is a #dulwich now
<ronny> jelmer: i dont intend to break the backward compatibility
<brmassa> Guys, on C/C++ projects, do you normally track the entire project directory or just the source files?
<AfC> brmassa: "entire"?
<brmassa> AfC: including the "/bin", "/includes" and other possible directories.
<AfC> brmassa: well, if bin/ is _build product_ then no
<AfC> brmassa: ie, no need to version control things that your build creates.
<brmassa> AfC: its useful coz it will track the directories changes (where the project is going to be build), but it also polute the bzr status with tons of files that doesnt need to be versoned
<AfC> brmassa: (I suspect you know that, which is why I'm trying to figure out the nuance of what you're asking)
<brmassa> AfC: yep,.
<lifeless> brmassa: you could 'bzr add --no-recurse bin; bzr ignore bin'
<AfC> brmassa: bzr understands how to ignore things
<AfC> brmassa: but you want to do:
<AfC> $ bzr help ignore
<brmassa> AfC: the makefile/projectfile generally include information that is a little beyond the /src dir, like where to build the project. so it would be nice to track the entire project dir, excluding the content of certain dirs.
<AfC> brmassa: that said, I'm not sure why you'd need to version the directory bin/ if it is a temporary (or final) output of the build. Surely your Makefile (or whatever) knows how to mkdir bin
<brmassa> AfC: my question was more like the common practice than a howto. what people normally do.
<AfC> brmassa: right. So version control Makefile.
<AfC> brmassa: ah. Well, I can't speak for anyone else, but in the GNOME world we don't version control build artifacts.
<brmassa> AfC: hmmm not even the directory structure needed to build a given app?
<AfC> brmassa: there is a *horrible* tendency in the Windows centric side of the Java world to whack .jar files the project depends on into version control
<AfC> (partly because they don't have a proper package management system they can query & reply on, and partly because they're just doing the wrong thing out of sheer bloody mindedness :)
<AfC> brmassa: sure, you can do that, but why not have your Makefile (or whatever) mkdir your temporary & output structure for you?
<lifeless> brmassa: if you need a directory structure, and your toolchain doesn't create it automatically, versioning the structure would be a good idea.
<lifeless> brmassa: what toolchain are you using ?
<AfC> [thereby making it just the sort of thing that can be a) `bzr ignore`d and b) `make {dist,}clean`ed
<AfC> brmassa: other than that, listen to lifeless :)
<Peng> If you have to version e.g. bin, you could still "bzr ignore bin/*".
<AfC> brmassa: [as indeed this isn't the place to talk about comparative merits of different toolchain strategies; bzr can do what you're asking if that's the way you wish to do it]
<brmassa> lifeless: im programming using Qt's qmake. well.... it does create directories if i tell so, but i was wondering to just track the myproject/src dir...
<AfC> Oh, there's a gem: on #cairo, "git has erased all history of that merge"
<lifeless> brmassa: you should track the things that are both: things other people will need to build the software AND things they can't get elsewhere
<brmassa> lifeless: hmmm nicely put
<lifeless> directories that the toolchain can make for you aren't in that set, IMO :)
<AfC> lifeless: that _was_ nicely put
 * AfC takes a quote of that, and then wonders how to properly cite an IRC discussion in a footnote :)
<brmassa> its because i use a specific dir structure on all my projects, like myproject/src, myproject/includes, myproject/bin, myproject/tests, myproject/media, so i was wondering to just version the part of it instead the whole structure...
<brmassa> but for new developers, who wil download the bzr tree, it might help to just see the BIN dir...
<AfC> brmassa: {shrug} they will after they type `make` :)
<brmassa> AfC: yep. maybe u r right.
<AfC> brmassa: in most projects I'm maintainer of, things are structured so that with the exception of a Makefile fragment called .config created by our [custom] top level ./configure,
<AfC> brmassa: *all* the build output runs out into directories under a top level tmp/ that the build creates for itself
<brmassa> AfC: nice. it seems to be the right thing to do. well thank all you guys.
<AfC> brmassa: [with one further exception that there's an entire source tree created during the first step of the build, and so the build mkdir's a tree called generated/ for that]
<AfC> brmassa: [but in this case generated/ is a peer twin of src/ so it rather made sense]
<AfC> [it could have been tmp/generated/ too]
<lifeless> AfC: thanks
<thumper> lifeless: any idea on bug 485318 ?
<ubottu> Launchpad bug 485318 in launchpad-foundations "POSTToNonCanonicalURL error using bazaar client" [Undecided,Incomplete] https://launchpad.net/bugs/485318
<lifeless> looks like a bug to me
<thumper> lifeless: should I add a bzr task?
<thumper> lifeless: or reassign?
<lifeless> let me have a look
<lifeless> what is %20 - ' ' ?
<lifeless> yeah
<thrope> hello - I was following loggerhead and noticed there have been no changes since may... my branch is following %7Eloggerhead-team/loggerhead/trunk/ but I had a look on launchpad and I think they moved to trunk-rich
<thrope> can I do bzr switch in my tree? or will it mess everything up
<thrope> or can I pull from the trunk-rich
<lifeless> thumper: bzr pull lp:loggerhead
<lifeless> thrope: ^
<lifeless> thrope: and if that errors, run 'bzr upgrade' before pulling ;)
<thrope> ERROR: KnitPackRepository('file:///home/robince/src/loggerhead/.bzr/repository/')
<thrope> is not compatible with
<thrope> CHKInventoryRepository('http://bazaar.launchpad.net/%7Eloggerhead-team/loggerhead/trunk-rich/.bzr/repository/'
<thrope> maybe my bzr on this machine is too old
<lifeless> thrope: do you have 2.0?
<thrope> no 1.16 on here I think... just upgrading
<Peng> If it knows about CHKInfoRepository, it has to be at least 1.18, no?
<poolie> hello lifeless, peng
<Peng> poolie: Good $timeofday. :)
<thrope> its ok now
<lifeless> Peng: 1.16.1, but see my mail about emacs for why thats not enough
<lifeless> hi poolie
<Peng> 1.16.1, eh?
<lifeless> poolie: you might like to add #launchpad-dev to your channel list
<poolie> oh as opposed to lp-code?
<poolie> my config is out of date
<lifeless> and, not xor
<Peng> #launchpad-code?
<lifeless> Peng: lp-code is on irc.canonical.com
<lifeless> Peng: its where dev discussion happened before the open sourcing
<Peng> Oh.
<Peng> Is irc.canonical.com open to the public (i.e. me)?
<lifeless> no
<lifeless> unless you get a job with us :)
<Peng> :D
<thrope> so I finally got loggerhead running through my apache proxy with serve-branches since the start/stop scripts are deprecated
<thrope> I can see host.net/nn_review/files  fine with css etc
<thrope> but basically every link is broken
<mwhudson> that seems surprising
<thrope> changes, annotate/head%3A/nnreview.py
<thrope> all give Not Found
<mwhudson> if the css/js links are right, i'd expect the other links to be right too
<thrope> I am using RewriteEngine instead of ProxyPass
<thrope> could that be it?
<thrope> I couldn't get ProxyPass to pass the front page properly
<thrope> (I dont want a prefix, just bzr.host.net/
<mwhudson> thrope: do the links look wrong, or are urls you would expect to work not working?
<thrope> not sure about the colon above
<thrope> ah wait
<thrope> they are to http instead of https
<mwhudson> oh right
<mwhudson> thrope: you might be able to use proxypassreverse to fix this
<thrope> how can I tell loggerhead that?
<mwhudson> but i don't know how that works
<thrope> ah ill try proxypass again
<mwhudson> thrope: i don't think you can, i could add a --https flag to serve-branches
<mwhudson> but i don't think i did, just thought about it
<thrope> yeah the proxy pass didnt make any difference
<mwhudson> ah
<mwhudson> i misunderstood how that works
<thrope> do you know if theres somewhere in the code I can add the 's' in... actually now I think about it I think I did that before with the older version
<thrope> but it looks like its got more complicated since then ;)
<mwhudson> i should just give up and generate relative links
#bzr 2009-11-27
<Peng> mwhudson: Doesn't help for redirects.
<mwhudson> Peng: but proxypassreverse does
<awilkins> Should it really take over 6 minutes to branch the Launchpad repository from one local disk to another?
<lifeless> 'maybe'
<awilkins> It's throwing a lot of CPU at it when I think it would be relatively quick to just... copy the folder.
<awilkins> Now, that's just lazy. But still.
<lifeless> branch validates data
<lifeless> we don't know if its e.g. removable or network or trusted or not
<lifeless> if you just want to copy the folder, I suggest you copy the folder.
<awilkins> It just seems a lot of CPU time for a repo of ~ 300MB
<lifeless> do you have the C extensions?
<awilkins> Should do, it's from the PPA
<thrope> mwhudson: links from the landing page with the list of repos all have https, but links from within a served repo dont any more
<mwhudson> thrope: links in directory listings are *really* relative
<mwhudson> <a href="$foo">foo</a>
<Peng> ...But they still invoke HTTP redirects cuz they leave off the trailing/. :D
<mwhudson> Peng: you can fix that if you like
<Peng> Hmm.
<Peng> Oh. It's totally trivial to fix. Doing so now. :D
<mwhudson> thrope: try bzr+ssh://bazaar.launchpad.net/~mwhudson/loggerhead/relative-links
<thrope> mwhudson: great - it works! thanks a lot!
<mwhudson> thrope: awesome
<mwhudson> thrope: you'll need to use proxypassrequest to handle the redirects
<thrope> you mean proxypassreverse? or something else (dont know what proxypassrequest is)
<Peng> Darn, it's a little bit trickier to add trailing slashes to breadcrumbs, cuz you have to avoid making the root link to //.
<mwhudson> thrope: i mean that yes, sorry
 * mwhudson needs lunch
<thrope> there are a few problems poking around
<mwhudson> ah ok
<thrope> view branch changes goes to nn_review/changes/14start_revid=14
 * mwhudson can believe it
<thrope> gives internal server error
<thrope> but https stuff is ok
<mwhudson> thrope: where is that?
<thrope> and "view changes to this file" button leads to nn_review/changesfilter_file_id=nnreview.py-20091126142852-yobx026pq984w1a0-1 which gives not found
<mwhudson> thrope: ah stupid mistake
<thrope> sorry nn_review is my branch, from nn_review/files/13 i click the view branch changes button
<thrope> it works with the ? in by hand
<mwhudson> thrope: pull again?  you want r397
<mwhudson> i forgot to put the ? in
<thrope> ah breadcrumbs (I think thats what their) called at the top are still non https (root)/nn_review at top of changes page
<thrope> funny thing mouse over is https but actual link is http
<thrope> anyway thanks a lot - I have to head off now
<thrope> happy thanksgiving to any us folks (normal day here!)
<mwhudson> Peng: can you review/test https://code.edge.launchpad.net/~mwhudson/loggerhead/relative-links/+merge/15298 ?
 * mwhudson lunches
<Peng> mwhudson: I'll test it, at least.
<Peng> mwhudson: I have been fortunate enough to avoid learning anything about URL handling. :)
<Peng> lifeless: Check finished. 945 inconsistent parents, but nothing worse.
<Peng> Only took 26.5 hours. Nice.
<lifeless> Peng: cool. check with vila - he has history there - but I suspect 'reconcile' is in order.
<fullermd> bzr's pretty impressive; *I* was never able to reconcile my parents' inconsistencies...
<Peng> lifeless: How do you reconcile something on LP, though?
<lifeless> Peng: pull, reconcile, sftp/hitchiker and nuke the repo; push
<lifeless> Peng: this is for the candidate converted maria, right?
<lifeless> or 'spmdo reconcile url'
<lifeless> spm: ^ :)
<Peng> Heh.
<Peng> lifeless: Yeah, it's for Maria.
<Peng> lifeless: How do you reconcile a stacked branch?
<lifeless> Peng: same same
<Peng> It'll automatically reconcile the stacked-on repos just fine?
<lifeless> no
<lifeless> it reconciles the stacking branch and repo only
<Peng> Oh.
<Peng> Well, that's still OK.
<Peng> I don't know which repo the inconsistent parents are in, though. :\
<lifeless> you did 'bzr check' locally though,right ?
<Peng> Yeah.
<lifeless> so they are local
<lifeless>  :)
<Peng> But I have copies of everything locally.
<lifeless> check checks only the local repo/branch
<lifeless> gotta eat
<Peng> And, actually, I don't think I've added any revisions to my MySQL repo since I last checked it, and there weren't any inconsistent parents then...
<Peng> lifeless: If it only checked the...1400 revisions in the stacked branch, why the heck did it take 26 hours?
<Peng> I'm reconciling LP over ssh, just to see how awful it is.
<lifeless> Peng: not branch, repo
<Peng> s/stacked branch/stacked branch's repo/, then.
<Peng> ...One reconcile died with a KeyError.
<lifeless> Peng: check has issues ;P
<Peng> When reconcile says it's repacking, does that mean it's done reconciling?
<Peng> Or is that part of reconcilnig?
<Peng> Now another reconcile has crashed with the same KeyError.
<Peng> And there goes the last one.
<Peng> Yeah, _that_ makes me confident about the integrity of my repo. :P
<spm> 'spmdo reconcile url' rofl
<Peng> Oh hi. :D
<spm> hey Peng, so what's up - am trying to put 2+2 together from the backscroll?
<Peng> spm: I'm just reconciling a branch or two (lp:~mnordhoff/maria/5.1-2a and lp:~mnordhoff/maria/5.2-2a), including the copies on LP.
<Peng> But reconcile crashes now. :\
<Peng> Ah. It's bug #441125.
<ubottu> Launchpad bug 441125 in bzr "bzr: ERROR: exceptions.KeyError: ('makefile.am-20080508221105-rbs9wugi1qq76gcs-2', 'scott@netsplit.com-20090702173125-4nayj8jp8h4f8jnq')" [High,In progress] https://launchpad.net/bugs/441125
<spm> ew
<poolie> where does this "20 characters message" come from?
<Peng> Maybe I'll stop using stacking, locally and maybe even on LP.
<lifeless> poolie: ?
<Peng> lifeless: It's in one of the recent mailing list messages about emacs.
<spm> hrm. oki, digested that bug report. So I'm guessing this is going to need me to fiddle with backups or some such?
<lifeless> Peng: if you're pushing up a fresh mainline thats been converted, you won't want it stacked.
<Peng> lifeless: I pushed up lp:~mnordhoff/mysql-server/mysql-5.1-2a non-stacked, and then have all of my other branches (including Maria) stacked on it.
<Peng> spm: Well, originally the "spmdo" was just to run "reconcile" on the two branches on LP. Then it turns out reconciling them fails, so it's moot.
<spm> Peng: ahhh. bummer. ok.
<Peng> I hate stacking. :(
 * igc lunch
<poolie> spiv, around?
<poolie> i have some python weirdness for you:
<poolie> http://pastebin.ubuntu.com/329072/
 * spiv looks
<poolie> i think in 2.5 and up 'exitfunc' is not a real method anymore, and
<poolie> probably logging is causing the compatability method aluded to in http://bugs.python.org/issue2356
<poolie> to activate
<poolie> and if i remove that, it breaks
<spiv> poolie: hmm, the stdlib docs do say it might not be set
<poolie> oh?
<spiv> poolie: file:///usr/share/doc/python2.6/html/library/sys.html#sys.exitfunc
<spiv> (And that it's been deprecated since 2.4, but we knew that already I think)
<poolie> mm
<poolie> ok, this is it
<spiv> poolie: so I suppose the correct thing to do is actually "exitfunc = getattr(sys, 'exitfunc', None); if exitfunc is not None: exitfunc()"
<poolie> or to run atexit._run_exitfuncs()
<poolie> or we can just say that there is nothing like that
<poolie> but the getattr is probably a safer change
<spiv> Yeah, we're stuck with either a deprecated interface (sys.exitfunc), or an undocumented one (atexit._run_exitfuncs).
<poolie> yay
<poolie> when in doubt, prefer the smaller diff
<poolie> the good thing about this is that this patch is avoiding loading at least one file (atexit)
<spiv> Although the *implementation* of atexit is actually to install _run_exitfuncs as sys.exitfunc.
<spiv> So in practice it's the same thing.
<poolie> probably not enough to matter, buta  small chance you'd have to wait until the disk head got to it
<spiv> But getattr avoids an import ;)
<poolie> exactly
<poolie> thanks
<igc> poolie: didn't you put the explorer website into the list of automatically refreshed ones?
<poolie> i thought i did
<igc> poolie: I pushed a change there an hour ago
<igc> and it's not appearing yet
 * poolie checks
<poolie> at the moment it only runs once per day
<poolie> it can be more
<poolie> but now that it does the sphinx generation it actually takes a fair amount of work to do all of them
<poolie> so i turned it down
<igc> poolie: once a day ought to be fine for the core docs. Maybe bzr-migration-docs and bzr-explorer-website could be hourly. They ought to be far more lightweight
<igc> poolie: I maybe I just need a way to do it on demand
<igc> s/I/or
<poolie> i'll just make it hourly for now
<poolie> it'll kick off soon
<poolie> we should probably move it all into a role account that you can get at but i don't really want to do that right now
<Rotaerk_> can bazaar handle having a branch of one repository nested inside a branch of another repo
<Rotaerk_> I'm thinking that I'd like my dependencies handled that way
<Rotaerk_> i.e. one repo per solution.  if the main project in solution A depends on the main project in solution B, I create a branch of solution B's repo inside a folder in the branche of solution A's repo
<Rotaerk_> that way the version of B that A depends on can be updated whenever, and easily
<spiv> Rotaerk_: I don't know precisely what you mean by "solution", and I suspect what you mean by "repository" isn't quite what bzr means, but I think the answer may still be yes.
<spiv> Rotaerk_: if you have branch of one project at foo/, and a branch of another project at e.g. foo/libs/bar, then that's fine by bzr.
<Rotaerk_> hmm okay sounds good, thanks
<Rotaerk_> "solution" and "project" are part of the visual studio code organization model
<spiv> Rotaerk_: bzr won't keep track of which version of libs/bar you happen to have in foo/, but it won't get confused or anything like that.
<Rotaerk_> hmm
<spiv> Rotaerk_: so you can do "bzr pull" or "bzr commit" etc inside foo/libs/bar, and the fact that it's inside foo/ will be irrelevant
<spiv> And similarly you can pull, commit etc in foo/ without disturbing the branch in libs/bar
<Rotaerk_> okay time to try it
<spiv> Yeah, that's the best way to figure this out I think :)
<Rotaerk_> just didn't want to screw up my current repo if bazaar would be confused by it
<poolie> igc: how now?
<igc> poolie: excellent. thanks!
<igc> poolie: http://doc.bazaar-vcs.org/explorer/en/tutorials/open-source-dev-gnome.html
<poolie> very nice!
<poolie> igc, i wonder if not specifically mentioning emacs would be sound better?
<poolie> after all we'd be willing to provide site policy for any hosting site
<poolie> it would make it look more like you're using emacs & savannah just as an example
<igc> poolie: I'm not sure I understand what you're saying
<Rotaerk_> if i created a branch and want to get rid of it, can I just delete the folder it's in, or is there a command I need to use
<igc> the doc is explicitly aimed at the Emacs developers
<igc> but generalised to be useful to others
<poolie> i'm saying the document seems to have some tension about whether it's specifically for emacs, or just using emacs as an example
<Rotaerk_> hmm nm, I guess I can just delete it... since bzr has to scan to find branches, it must not actually track them
<poolie> it's just an observation, not a big problem
<igc> poolie: it's meant to be general with Emacs as an example ...
<igc> but good enough to show Emacs developers the "right" way to get started
<igc> poolie: should I take out the note re savannah push policy perhaps?
<poolie> given what you just said i'd probably write it as something like this
<poolie> "explorer knows about the right way to publish to different hosting sites, but at the moment not how to publish to Savannah where emacs branches are hosted.   (Patches or information on how it should work gratefully accepted.)  Therefore we have to manually tell it where to push this branch...."
<igc> poolie: ok
<Rotaerk_> hmm darn
<Rotaerk_> given branch of repo A at aaa, and branch of repo B at bbb, if I create a branch of bbb at aaa/bbb, I can't do "bzr add bbb" from aaa
<Rotaerk_> it remains unknown
<Rotaerk_> was hoping that revisions of A could contain snapshots of branches of B
<spiv> Rotaerk_: no, unfortunately.  We'd like to support something like that, but it hasn't gotten past the experimental stage yet.
<Rotaerk_> hmm I wonder if git or mercurial can do that
<spiv> Rotaerk_: that's what I was trying to say when I said "bzr won't keep track of which version of libs/bar you happen to have in foo/"
<Rotaerk_> ah I see
<Rotaerk_> is there any other way to go about what I'm wanting to do?
<Rotaerk_> i.e. have particular revisions of A dependent on particular revisions of B
<Rotaerk_> i think SVN can handle this using "externals"
<Rotaerk_> though I've only heard about it
<spiv> Rotaerk_: there are some plugins and add ons that might help
<Rotaerk_> ah this is actually listed as a limitation on the bazaar site
<spiv> Rotaerk_: http://bazaar-vcs.org/ScmProj is one, there was also a mailing list thread touching on this recently
<spiv> Rotaerk_: it starts at https://lists.ubuntu.com/archives/bazaar/2009q4/064637.html
<Rotaerk_> hmm thanks
<igc> poolie: how does one get permission to upload to our +downloads page. Is it joining ~bzr?
<poolie> i think so
<poolie> showing the current transfer rate is geeky provicialism (according to sjt)?
<igc> poolie: can we add the guys making mac packages into there then?
<poolie> of course
<poolie> um
<poolie> if you just add them to that team they'll get a lot of mail
<poolie> it may be better to work out what lp role controls access, and then make that a different group
<poolie> it may not be possibly
<poolie> possible*
<poolie> it's probably better also to add them to bzr-core
<igc> poolie: the PPA packaging guys are in bzr, not bzr-core. hmm
<igc> downloads sounds similar to PPAs conceptually wrt permissions?
<poolie> so
<poolie> the ppa is an example of one thing that sends a fair amount of mail to its owners
<poolie> i trust the guys doing packaging of course
<poolie> i don't mind adding them to any group
<poolie> perhaps the easiest thing is to just add them to ~bzr and then if that's not working, try something else
<Rotaerk> meh, I only wanted to nest revisions of B within a revision of A so that I could setup a reference from project A to project B, but instead I'll just build B and copy B.dll into A
<vila> hi all
<Peng> Hi. :)
<spm> hey vila!
<bignose> âbzr branch lp:fooâ is agonizingly slow. what protocol is being used when I specify the scheme âlp:â?
<Peng> bignose: If you've run "bzr launchpad-login", bzr+ssh. Otherwise, http.
<bignose> I don't have a Launchpad account. can I easily make âlp:fooâ use âbzr+httpâ?
<Peng> LP doesn't support bzr+http.
<bignose> argl
<bignose> why on earth not?
<Peng> Probably cuz all of the LP developers use bzr+ssh, so it's not important to them. :P
<lifeless> bignose: time
<lifeless> Peng: no
<lifeless> Peng: we want to. Needs TUITS
<bignose> it's not simply a matter of upgrading the Bazaar instance on Launchpad?
<Peng> lifeless: TUITS?
<Peng> bignose: It's a matter of...setting it up.
<bignose> Peng: specifically, round tuits.
<lifeless> http://www.myrtlewoodgallery.com/get_a_round_tuit.htm
<lifeless> Peng: ^
<bignose> as in, âWe haven't got a round tuitâ.
<lifeless> bignose: its a deployment/testing issue
<Peng> Ohhhhhhh.
<bignose> hmm, perhaps there is something in Stephen J Turnbull's somplaints about the degree of difficulty in setting up a Bazaar server.
<lifeless> Peng: a better one - http://www.stosyth.gov.uk/default.asp?calltype=sep03roundtuti
<lifeless> bignose: its about 5 lines of apache config
<lifeless> bignose: but we have loggerhead, which is fragile at scale, and we really don't want to destabilise that
<lifeless> and they have to coexist on the same space.
<bignose> okay. well, I can only agree with Stephen that it's a black eye for Bazaar when one's first likely interaction â branching an existing projectâ is dreadfully slow by default.
 * igc dinner
<lifeless> bignose: setting up is in fact documented - 'running an http smart server'
<AfC> I can't agree. Setting up a bzr:// server was easy.s
<bignose> right, but that doesn't affect that Launchpad doesn't have it enabled, which immediately raises the question of why it's difficult for the experts to do. (and most people asking that question are likely to come to the âbecause it's too difficultâ conclusion)
<lifeless> bzr+http is a little more fiddly, but not much.
<bignose> um. what protocol does âbzr://â run over? is it different from âbzr+http://â, âbzr+ssh://â?
<bignose> it seems to me the read-only one is the important one for PR.
<AfC> bignose: it runs over the bzr protocol
<lifeless> omg the doc search is slow
<Peng> bignose: bzr:// servers listen directly on TCP port 4155; they aren't tunnelled over SSH or HTTP or anything.
<bignose> oh okay. well, that raises the question: if *that*'s the easy one to set up, why doesn't read-only âlp:fooâ use that protocol by default instead of slow âhttp://â?
<lifeless> bignose: because lp isn't a typical deployment.
<lifeless> theres a db with virtual filesystem and 'stuff'
<lifeless> as well as private branches to consider
<AfC> lifeless: (which is a shame, because otherwise it would promote bzr:// quite well)
<bignose> but it's the most public one. âlet's see how Bazaar performs over the networkâ is highly likely to lead to branching a project from Launchpad without an account there.
<lifeless> http://doc.bazaar-vcs.org/bzr.2.0/en/user-guide/http_smart_server.html documents how to run a bzr+http setup
<lifeless> running bzr:// from inetd is ridiculously simple for straight forward environments (and savannah is AFAIK - its no where near as complicated a setup as LP's production environment)
<bignose> and hence branching from âlp:fooâ, which leads to HTTP without specifically asking for it, which leads one to think that Launchpad and/or Bazaar are very slow over the network.
 * fullermd still vaguely wishes he could setup bzr+http on a non-trivial setup...
<lifeless> bignose: as I said, we want to do it. the team that is responsible also has a bunch of other things to do.
<bignose> so I think this ties directly into Stephen's observations about PR and what Bazaar (and Launchpad, and Canonical, etc.) can do to improve image: get the most obvious Bazaar site working very fast by default.
<lifeless> is it hard? not any harder than the other bugs they are working on. But they haven't gotten to it.
<bignose> naturally. so perhaps, since Ian has published a guide, in response to Emacs developers needing to learn more about Bazaar, and specifically using Launchpad as a demonstration ... now is a good time to raise the priority of setting up a fast protocol by default for âlp:fooâ branch URLs.
<bignose> to forestall a whole lot of Emacs developers, who might have otherwise been on the fence, having an abysmal first experience with Launchpad.
<lifeless> I think that you should make this observation on the list.
<bignose> okay, shall do.
<lifeless> THe folk that need to see it are out drinking beer at the moment. ;)
<bignose> lifeless: done, thanks.
<bialix> hello
 * fullermd waves at bialix.
 * bialix waves back
<bialix> hi fullermd :-)
<Torty> hello
<Peng> Hi.
<stanman246> hi, not a bzr question, but i guessed i'll drop it anyway... Anyone using Krusader for filetransfers?
<Torty> i have a question: it is possible to include the current Rev.number into my source files?
<Torty> i.e. in sourcefile "###bzr-rev###" and bzr replace this with the current Rev. number?
<Torty> i know in CVS/SVN it its possible
<Torty> i think this replacement should be done by commit command
<Torty> because only the currently commited files should be became the new rev.number
<Torty> any idea?
<Peng> Torty: Generally you make your build system do "bzr revision-info >version.txt" or somesuch.
<Peng> Torty: But there is the bzr-keyword plugin if you want it.
<Peng> Or is it "bzr-keywords"? I don't remember.
<Torty> i think i dont know what you mean (advice: write simple english *g*)
<Peng> Torty: The usual practice is to make your build system do it, using a command such as "bzr revision-info".
<Peng> Torty: But there is a plugin that does what you want. See http://bazaar-vcs.org/KeywordExpansion
<Torty> ok i read
<Torty> ok it seems to be what i searching :-D thx
<Peng> Torty: That page looks a little out-of-date. It might be better to start at https://launchpad.net/bzr-keywords
<Torty> k
<fullermd> The plugin functions more like PoC than usable code, for various reasons.  Some of the changes needed to really use it are only in 2.1, and I'm pretty sure some aren't anywhere yet.
<Peng> Ah.
 * vila cries, testtools doesn't support python2.4 (it requires functools) :-( <- lifeless
<lifeless> vila: https://code.edge.launchpad.net/~lifeless/testtools/2.4
<jml> has bzr's auto-resolve behaviour changed recently?
<lifeless> jml: I don't think so
<jml> vila, lifeless: actually: lp:testtools
<lifeless> vila: but you probably want that branch + my 0.9.1 branch.
<jml> ungh
<jml> Using '=' to underline things confuses the auto-resolver.
<lifeless> jml: oh yeah, sorry.
<lifeless> use ---- perhaos
<jml> problem for another day, I think.
<lifeless> or ++++ actually, that shouldn't be used there and should be unique
 * vila sends love to lifeless, jml and checks
<fullermd> vila: By the by, 8.0 final release was finally cut.
<vila> fullermd: Great, thanks for telling me, I'll upgrade asap
<vila> jml, lifeless: lp:testtools still has the problem, trying 2.4 + 0.9.1 branches now
<jml> vila, oops. pushed to wrong location
 * vila jumps on the brake pedal
<jml> vila, lp:testtools should have 2.4 now
 * vila laughs at the commit message and wishes all commit messages were like that :)
 * vila confirms --parallel=fork works again with 2.4  \o/
<vila> 11 mins between tears and joy, who said bzr was slow ?
<vila> yes, I know, that's a totally unfair reasoning :-D
<fullermd> Man, that's pathetic.  CVS can go from joy to tears in SECONDS.
<lifeless> jml: push 0.9. to trunk ? :)
<jml> no, not now
<lifeless> no?
<jml> lifeless, I was writing the release announcement and uploading the tarball. Now I can do the branch bit :)
<lifeless> jml: I would just push 0.9 to trunk again, is aall I meant
<jml> lifeless, rather than merge?
<lifeless> yes
<lifeless> we haven't landed anything on trunk that we haven't also landed in 0.9
<lifeless> if we had it would be different. Just a thought.
<lifeless> I don't intrinsically care.
<jml> done.
<jml> that's a release, I think.
<jml> crap. PyPI
<lifeless> :)
<jml> and setup.py
<jml> dammit, I can't believe I need a release checklist for such a small project.
<lifeless> you always need a checklist.
<lifeless> write a tool.
<fullermd> Sometimes I hate the day I internalized 'write a tool'...
<lifeless> -> fud
<bialix> vila?
<bialix> lifeless: what;s tool?
<vila> bialix: ?
<bialix> vila: hello
<bialix> what I should write in authentication.conf if I want to specify details for bzr+ssh
<vila> bialix: hello :)
<bialix> scheme = bzr+shh
<bialix> ?
<bialix> or just ssh?
<vila> no, scheme = ssh, that's valid for both bzr+ssh and sftp since that's really the same scheme
<bialix> oops
<bialix> nice
<bialix> vila: thanks very much
 * vila thinks the problem has been raised already and a warning is emitted ?
<Torty> Peng: i've installed new bzr and the plugin but i have problems to understand what i have now to do
<vila> Or am I just dreaming that I wrote the fix ?
<Torty> i mean the keywords-plugin
<Torty> on Launchpad the documentation is missing
<bialix> vila: works perfectly!
<vila> cool
<Peng> Torty: Did you see above what fullermd said about the bzr-keywords plugin?
<Torty> on launchpad?
<jml> lifeless, I'll write a tool after I have a checklist, probably.
<jml> lifeless, anyway, release done.
<Torty> ah - fullermd here on irc - no - i have to reboot my system
<Torty> no chat-log active
<Torty> can you paste me what he said
<Peng> Torty: 09:36:46 < fullermd> The plugin functions more like PoC than usable code, for various reasons.  Some of the changes needed to really use it are only in 2.1, and I'm pretty sure some aren't anywhere yet.
<Torty> thx - mom i try to translate ...
<Peng> Torty: Short version: it's still experimental and doesn't work completely.
<Torty> this means the plugin ist useable up from 2.1 version of bzr?
<Torty> aha - but in future this replace-feature (bzr-keywords) will be working
<fullermd> With versions before pretty recent dev head, the keywords won't update all the time when you perform bzr operations.
<Torty> aha
<fullermd> And with any version I know of actually existing, filtering in general can only be configured globally, so you can't turn them on in a single branch.
<Torty> but the feature will be finialize in newer versions
<Torty> good to know
<Torty> what means also: if i want rev.# in my sources i have to do it by hand
<Torty> or (bedder) dont include it in source files
<Torty> ok thx - i wish you a nice weekend
<Torty> bb
<vila> fullermd: And people still don't believe that computers have feelings.... The freeBSD8 VM just crashed...And it runs from a different host than the one I use to do IRC....
<fullermd> vila: 's what you get for running emacs on it   :p
<vila> fullermd: pfff, not even, it was running unattended :)
<vila> fullermd: more seriously, since it crashed, I may as well upgrade now, http://wiki.freebsd.org/8.0TODO is out of date ?
<fullermd> Dunno.  The last edit date is, what, a week and a half back, or something?
<fullermd> Not sure how actively it was maintained during the RC cycle.
<vila> fullermd: it's ok, just found http://www.freebsd.org/releases/8.0R/announce.html
 * fullermd glances at how recently the version control page was updated as long as he's bouncing around the wiki...
<vila> hey ! vbox guest support !
<vila> of course, just when I wanted to start migrating to kvm...
 * fullermd . o O ( Last real update: 2008-01-19 )
<fullermd> Well.  That's almost certainly not much changed since the last few RC's   :p
<vila> .. may be, but it may also mean I need some tweaks I'm not aware of...
<fullermd> I guess the topic fizzled out of major notice after src moved CVS -> SVN.  Owell.
<drmabuse_> Hello! Anyone an idea how stacked branches differ from others (regular ones)?
<Peng> drmabuse_: Stacked branches don't store all of the revisions locally.
<Peng> drmabuse_: They should function exactly the same as a normal branch, more or less.
<GaryvdM> drmabuse_: A stacked branch does not have all the revsions in it's repository. It has a url to the branch that it is stacked on, and if bzr needs any revisions that are not in it's repository, it gets them from the stacked on branch.
<Peng> GaryvdM++
<Peng> You put it very well. :)
<drmabuse_> Ah, thank you!
<GaryvdM> Peng: thanks
<drmabuse_> Great!
 * fullermd blinks.
<fullermd> The heck...   how did I get a modified file in my bzr.dev tree...
<fullermd> OK, what the hell?  log $FILE is showing 1 rev touching the file, log -n0 $FILE is showing 2, and there's no overlap between them.
<fullermd> And none are actually direct edits, they're all merges.
<fullermd> ...  OK, that's even weirder.  I revert it, and it STILL shows modified.
<Peng> Kill dirstate?
<Peng> (well, mv)
<vila> what file is that ?
<fullermd> Oh, I found it.
<fullermd> Just snows to go you the sad state of content filtering.
<fullermd> I still had a ~/.bazaar/rules file turning on keywords on *.txt, and doc/ja/user-reference/index.txt had something that ate.
<Peng> \o/
<fullermd> Of course, on the plus side, that does show that revert Does The [Hypothetically] Right Thing with filters now   :p
<fullermd> Insofar as deleting 372 lines of the file is Right, anyway...
<fullermd> Mmph.  And it compresses things that aren't valid keywords either.
<fullermd> Still freaky what log is doing there, though.
<GaryvdM> fullermd: What file is it?
<GaryvdM> Oh nvm - doc/ja/user-reference/index.txt
<GaryvdM> fullermd: bzr log doc/ja/user-reference/index.txt , and bzr log doc/ja/user-reference/index.txt -n0 work as expected for me.   ?
<fullermd> Well, now that I've updated bzr.dev, both show only 1 rev.  Just different 1 revs.
<fullermd> And still both just merges.
<GaryvdM> fullermd: bzr log doc/ja/user-reference/index.txt -n0 shows me 4 revisions - http://pastebin.com/d100bf598
<GaryvdM> fullermd: bzr qlog doc/ja/user-reference/index.txt also the same
<fullermd> Hm.
<fullermd> How odd.  I get that too, without -v.  But with -v, kaplooie.
<fullermd> That's pretty marfed up.  Why the hell should -v affect ANYTHING like that?
<GaryvdM> fullermd: yhea - thats def a bug IMHO
<GaryvdM> Hi vila
<GaryvdM> vila: Is there a way do detect if some code is being run from a test?
<vila> meh, where should I put the comma ?
<GaryvdM> I don't know?
<vila> GaryvdM: :-) Is it: 'some code is, being run from a test' or 'some code is being run, from a test'
<GaryvdM> vila: I got a test where a exception is being caught by qbzr error reported, which shows a nice gui error report, and the error does not get to the test.
<GaryvdM> vila: so I want to disable qbzr's error handler if it is being run from a test.
<vila> haaa, you want the code to realize it's run by the test ?
<GaryvdM> yes
<vila> Don't ever do that or the code police will come to arrest you
<GaryvdM> lol
<vila> Instead, the test should alter the environment
<fullermd> Nah, as long as they check with log -v, they'll never find it being introduced  :p
<vila> The former is known as 'test code in production code' and very frowned upon :)
<GaryvdM> vila: ok
<vila> the reason being that it's cheating really :)
<vila> log -v can find more revisions touching a file :-/ I don;t remember the details but I think it has to do mainly with file deletions
<fullermd> No, it finds less.  Much less.
<fullermd> Or rather, it finds more, but gives up really quick.
 * vila bangs head to wall
<vila> err
<vila> that's pretty unclear my dear friend :)
<GaryvdM> fullermd: vlia is right, normal log file won't find a revisions that deletes a file
<GaryvdM> -v will
<GaryvdM> vila: compaire bzr log doc/ja/user-reference/index.txt -n0  to bzr log doc/ja/user-reference/index.txt -n0 -v
<vila> fullermd: but log and log -v are on amanica plate again IIUC
<vila> so filing bugs now may be a good idea
<vila> GaryvdM: aaargh, vade retro satanas, I want to go have lunch, don't make me vomit :-(
<GaryvdM> sorry
<vila> that's pretty ugly :(
<vila> err, can I really use pretty and ugly like that ?
<vila> bbl, will have lunch anyway
<GaryvdM> vila/fullermd: I've loged bug 489179
<ubottu> Launchpad bug 489179 in bzr "log file -v misses some revisions" [Undecided,New] https://launchpad.net/bugs/489179
<GaryvdM> vila: when you are back from lunch, would this be an acpetable way to "alter the environment" : http://pastebin.com/d75e9a627 ?
<vila> GaryvdM: with the tweaks http://pastebin.com/m285da0a9 , yes
<lifeless> vila: would like your feedback on assertThat (in testtools 0.9.1)
<GaryvdM> vila: thanks
<vila> and regarding that bug, log -v shows *only* the revisions touching the file, while log, once it found a revision, also displays the ones that merge it (I forgot that case earlier),
<vila> so the bug is presumably about the "right" revision being lost while the merging ones are shown, because 4792.5.5 really add the file and I presume nobody ever touch it since
<vila> lifeless: is that about the matchers I saw mentioned in the commit messages ?
<lifeless> yes
<lifeless> see NEWS and the MANUAL
<thrope> is it possible to share subversion.conf between machines - to the checksums int here come from the svn repository or are they randomly generated (ie does it make any sense) - I guess I was hoping if I accessed the same repo on another machine the checksum would be the same
<vila> lifeless: after reading NEWS and MANUAL, I'm still hungry :-) Now reading matchers.py
<vila> that was quick :)
<vila> I recognize that DocTestMatches as very closely resembling my needs in shell-like tests :)
<lifeless> if you want to see it in use, look at test_testresult.py
<vila> yeah, I see that... making doctest.ELLIPSIS the default sounds sensible... (I did that in the shell-like tests)
<lifeless> vila: I haven't read the shell like stuff yet
<lifeless> vila: did you use the doctest module?
<vila> great minds etc
<vila> yes I did use it
<vila> so, the problem I have with assertThat is that the actual value comes first
<lifeless> read it as an english sentence
<vila> yeah, I know, that's the good part
<lifeless> assert that foo doctestmatches thing
<lifeless> its a bit cutey
<lifeless> but otoh fairly memorable
<vila> but then when I look at the tests, I stop "reading" and go into some matching mode
<lifeless> I think you would adapt quite quickly - bzr already has inconsistency here
<lifeless> the needle, haystack thin
<lifeless> g
<vila> hehe, you used the right words, I can adapt but inconsistencies make adaptation hard in the end
<lifeless> I think its better to make this really nice
<vila> anyway, as long as switching the args is invalid, it can hardly become a problem right ?
<lifeless> so we can effectively argue for
<lifeless> assertThat(thing, equals(other))
<lifeless> yeah, it will blow up, unless thing is a matcher too :)
<vila> hehe, when you start writing tests about matchers, I suspect the parameter order is already wired ;)
<vila> assertThat(thing, equals(other)).... really nice
<lifeless> doing not may require some care
<lifeless> assertThat(thing, is(not(other))) would be nice to be able to write.
<lifeless> but 'is(not(' really would be 'not(is(' in this language. which isn't english (though it is other languages))
<vila> on the feedback front, reading MANUAL was... refreshing, there nothing I want to delete there
<vila> Isn't there an english construct for assertThatNot ?
<vila> failIf >
<vila> failIf ?
<lifeless> in english, 'the horse *is* *not* red'
<lifeless> in this language, 'the horse *not* *is* red'
<lifeless> vila: think bigger, more complex composed matchers
<lifeless> gnight
<lifeless> play. Use. Enjoy.
<vila> :)
<lifeless> was addDetails in the MANUAL?
<lifeless> I forget if I added it there
<vila> no
<lifeless> if so - bzr log files. failed test work areas from disk. Possibilities abound.
<lifeless> ok, I should add that. Please file a medium priority bug on testtools if you would
<lifeless> its referenced from NEWS, I'm sure.
<lifeless> ciao
<jldupont> hi - I keep getting "Unexpected error while decorating: xxx.yyy" when using Bazaar Plugin for Eclipse... any clue?
<beuno> jldupont, verterok is the developer for that plugin, maybe he will know
<jldupont> verterok: I keep getting "Unexpected error while decorating: xxx.yyy" when using Bazaar Plugin for Eclipse... any clue?
<verterok> jldupont: could you check the stacktrace in <workspace>/.metadata/.log ?
<verterok> jldupont: also, what options do you have enabled in the decorator settings?
<jldupont> verterok: http://jldupont.pastebin.com/d5663d1bf
<jldupont> verterok:  I don't believe I have ever touched this... the only option checked at the moment is "Enable Status Overlay Decorator"
<verterok> jldupont: ok, what version of bzr-xmloutput do you have installed?
<verterok> jldupont: bzr plugins should show that
<jldupont> verterok: how do I check that?  Windows->preferences->Bazaar??
<verterok> jldupont: in a terminal: bzr plugins
<jldupont> ok
<jldupont> 0.8.3
<verterok> jldupont: hmm, it's quite old, are you in windows or *nix?
<jldupont> ubuntu
<jldupont> is there a PPA for auto-update of that stuff?
<verterok> jldupont: is the bzr-xmloutput  from the repository?
<jldupont> hmmm... don't remember where I got that...
<verterok> jldupont: "bzr plugins -v" should show the path
<jldupont> what's the best way to install & keep up-to-date on this plugin?
<jldupont> /usr/lib/python2.6/dist-packages/bzrlib/plugins/xmloutput
<verterok> jldupont: ok, it's the package
<jldupont> xmloutput 0.8.3
<jldupont>     This plugin provides xml output for status, log, annotate, missing, info,
<jldupont>     /usr/lib/python2.6/dist-packages/bzrlib/plugins/xmloutput
<verterok> jldupont: try this: 1) uninstall bzr-xmloutput 2) mkdir -p ~/.bazaar/plugins; bzr branch lp:bzr-xmloutput ~/.bazaar/plugins/xmloutput
<maxb> Semi-related, I have heard there are two Eclipse plugins for Bazaar, which one should I use?
<verterok> maxb: qbzr-eclipse use qbzr for the dialogs, bzr-eclipse is a native plugin (pure java+SWT, except the interface with bzr)
<jldupont> " bzr: ERROR: Target directory "/home/jldupont/.bazaar/plugins/xmloutput" already exists.  "
<verterok> jldupont: so you already have it: cd ~/.bazaar/plugins/xmloutput && bzr pull
<jldupont> it blew in my face:  http://jldupont.pastebin.com/d2f611ae9
<verterok> jldupont: oh, you have bzr 1.13.1 and bzr-xmloutput is using a newer repository format :(
<jldupont> where is the PPA for Bazaar again?
<jldupont> is this it: https://launchpad.net/bazaar
<verterok> jldupont: https://edge.launchpad.net/~bzr/+archive/ppa
<jldupont> verterok: ok, thanks!
<jldupont> hmmm... I've added the PPA to my sources but Synaptic doesn't show an upgrade to bzr...
<jldupont> what's wrong?
<jldupont> it concludes that 1.13.1 is latest.
<jldupont> maybe it is taking the "ubuntu" default?
<vila> jldupont: most probably you missed some step while adding the PPA ? You did add the key for it ?
<jldupont> Yes I did add the key.
<jldupont> sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 8c6ce1efd
<vila> hmm, you refreshed the package list ?
<jldupont> "reload" in Synaptic.
<jldupont> yes
<vila> ghaa
<vila> let me start my hardy vm
<jldupont> I went for apt-get update
<jldupont> and back to Synaptic:  1.13.1
<vila> 1.13.1-1 (hardy) or 1.13.1-1ubuntu0.1 (hardy-updates) ?
<vila> boom
<jldupont> vila: I must be Synaptic having the problem:  I do sudo apt-get install bzr  and I got upgraded....
<jldupont> jldupont: vila: I must be Synaptic having the problem:  I do sudo apt-get install bzr  and I got upgraded....
<jldupont> ... and now it shows up in Synaptic !\\
<jldupont> not the first time I've had problems with Synaptic !
<jldupont> note to self:  go with apt-get  if problem with Synpatic *before* bugging people.
<jldupont> THANKS GUYS!
<jldupont> ... and now Bazaar Eclipse plugin complains that bzr-xmloutput isn't found!!!
<vila> weird
<vila> jldupont: you're welcome
<jldupont> what is the approved process for installing bzr-xmloutput ??
<jldupont> it shows in Synaptic!
<jldupont> ... and now "mark for reinstallation" in Synaptic takes care of the problem...
<jldupont> let's just say I do not love Synaptic that much ...
<jldupont> I still get a ton of "decorator" errors: http://jldupont.pastebin.com/m4b23cbe2
 * vila leaves it to verterok :)
<verterok> heh
<verterok> jldupont: did you restarted bzr-eclipse?
<jldupont> ... just did ( you can of course flame me good ! ) ... but now a new problem: http://jldupont.pastebin.com/d2d1e7b81
<verterok> jldupont: could paste the whole traceback? or is just that?
<jldupont> it was only that when I posted it... now, I tried doing a commit:  http://jldupont.pastebin.com/d4d5fb3c9
<verterok> jldupont: looks like bzr-gtk is killing bzr
<jldupont> what's the solution?
<verterok> jldupont: removing bzr-gtk...maybe?
<jldupont> get rid of it?  I just need eclipse pluing and cli
<verterok> vila: do you know what's the status of bzr-gtk?
<verterok> jldupont: yes, I think that removing/uninstalling bzr-gtk is enough
<verterok> jldupont: or updating it
<vila> verterok: what status ?
<jldupont> got right of it... still blows up in my face!
<vila> oh, hum, bzr-rebase seems to be a problem
<jldupont> http://jldupont.pastebin.com/d3af2792e
<vila> bzr-gtk should be upgraded from the PPA I think
<jldupont> bzr-rebase: got rid of it too.
<jldupont> http://i49.tinypic.com/x2lxmp.png
<verterok> jldupont: you still have an old xmloutput installed
<jldupont> maybe my repo of the old version is causing the trouble?
<jldupont> xmloutput: 0.8.3
<vila> \what PPA did you add exactly ?
<jldupont> edgewall one
<jldupont> https://edge.launchpad.net/~bzr/+archive/ppa
<jldupont> jaunty
<jldupont> /usr/lib/python2.6/dist-packages/bzrlib/plugins/xmloutput
<vila> jaunty ??? 1.13.1 is the latest proposed in jaunty by default ???
<MvG> Again I'm asking for someone to review changes to trac-bzr. This time https://code.launchpad.net/~gagern/trac-bzr/bug194277/+merge/15323 in particular, as it removes quite a large portion of (supposedly unused) code. I'd love a second opinion here!
<vila> MvG: I know nothing about trac-bzr, but given the work your putting into it, you clearly seem to be the de-facto maintainer...
<jldupont> vila: yes it seems.
<MvG> And become so in little more than a week, or so it seems.
<MvG> I feel like every time I fix a bug, I find a new one.
<vila> as such, you'd better just take over the trunk and wait for people to complain or, more likely, thank you :)
<MvG> I'll have done unreviewed commits in the past, and will likely do more in the future, especially if I get no reviews here.
<MvG> On the other hand, I've gotten some very useful input from reviews, so I'd at least give people a chance to look things over.
<vila> ha ok, I thought you didn't get any
<vila> jldupont: ok, I misunderstood, I thought you were on hardy :-/
<jldupont> vila: no probs.
<jldupont> vila: I installed the latest xmloutput (from what verterok wrote earlier): still blows up in my face.
<verterok> jldupont: did you removed the system wide installed xmloutput?
<jldupont> verterok: yes.... got Synaptic to do it.
<jldupont> is this ok?
<verterok> yes
<jldupont> I have zapped my .bzr from my project...
<jldupont> rebuilding everything now...
<verterok> jldupont: and did you updated the xmloutput in .bazaar/plugins ?
<vila> jldupont, verterok: that shouldn't matter if the .bazaar/plugins one is loaded, which 'bzr plugins -v' should confirm
<jldupont> xmloutput 0.8.6.dev
<jldupont>     This plugin adds an option (--xml) to log and provides an xml version of some
<jldupont>     /home/jldupont/.bazaar/plugins/xmloutput
<verterok> jldupont: ok, good
<verterok> jldupont: are you getting the same error?
<jldupont> Exception in Decorator. The 'Bazaar' decorator will be disabled.
<jldupont> http://jldupont.pastebin.com/d2908bb17
<bialix> MvG: you may want to set some limit for waiting of review: say 1 day. I fnobody answers, then simply go on and commit your improvements
<jldupont> verterok:  any clue?
<bialix> MvG: thank you for working on trac-bzr btw
<verterok> jldupont: you removed the .bzr dir?
<MvG> bialix: I'm committing when I tire of waiting for reviews...
<bialix> MvG: I'm still have to find a time to test your changes, busy at work too much
<jldupont> verterok: Yes I did.
<MvG> The more central a change, the more I want it in trunk before working on, and the more impatient I am with reviews.
<verterok> jldupont: please add it again, or remove the project from bzr-eclipse control in eclipse
<bialix> MvG: when I know that review in qbzr or bzr-explorer may wait weeks, I clearly say that I will wait no more than week and if nobody subject will land it
<verterok> jldupont: it will fail as eclipse have it mapped to bzr but there is no .bzr
<jldupont> verterok: oh, wait a sec
<bialix> MvG: there is too little people who can and most important want to review your changes
<bialix> MvG: that said you can develop as you wish
<bialix> MvG: i.e. don't wait for review at all
<MvG> Already doing so for minor changes.
<MorbusIff> g'day. i've got bzr log bzr:// working just fine. but a bzr log bzr+ssh:// complains that it's Not a Branch. No error about ssh auth or connecting. Just Not a Branch.
<jldupont> verterok: ()@!_)( Eclipse is all confused now!
<bialix> MorbusIff: what if you try sftp:// instead?
<vila> MorbusIff: what path are you specifying ? '~' support has changed recently between sftp and bzr+ssh
<MorbusIff> bialix: same erorr.
<MorbusIff> vila: i'm specifying the path to a branch in both cases. example.com/branchname.
<jldupont>     Error while executing push
<jldupont>     RemoteRepository(bzr+ssh://bazaar.launchpad.net/~jldupont/tinycouch/trunk/.bzr/)
<jldupont> is not compatible with
<jldupont> CHKInventoryRepository('file:///home/jldupont/workspace/tinycouch_trunk/.bzr/repository/')
<jldupont> different rich-root support
<bialix> so there is really not a branch
<vila> a full path then ?
<jldupont> what do I do now??
<jldupont> delete from LP ?
<MorbusIff> bialix: but when i run bzr://, it works fine, with the same path.
<MorbusIff> bzr://example.com/whee works, bzr+ssh://example.com/whee does not (complaining that it's not a branch)
<bialix> MorbusIff: look into .bzr.log, you'll find there some debug info, maybe it helps to identify problem
<MorbusIff> vila: using a full path causes both bzr:// and bzr+ssh:// to report Not a Branch.
<MorbusIff> bialix: getting a traceback.
<MorbusIff> doesn't personally tell me much though. i don't code python/bzr.
<bialix> edit private urls and pastebin
<bialix> then we can look and suggest something
<MorbusIff> http://pastebin.com/m1aca9352
<bialix> right now you can test via any ssh client if you can read sftp://example.com/whee/.bzr/format
<bialix> perhaps you've got permission denied problem
<bialix> are you sure your local login name and your login name on the server is the same?
<MorbusIff> they are not, but i'm forcing the remote name in .bazaar/authentication.conf.
<bialix> maybe you need to explicitly specify them in URL?
<bialix> just for testing
<MorbusIff> tried that before here, and same error.
<bialix> MorbusIff: can you test via your ssh client if you can read sftp://example.com/whee/.bzr/format
<bialix> ?
<MorbusIff> yeah, i'm getting there.
<bialix> what it means?
<MorbusIff> i'm still in the process of testing that. tlaking to someone else at the moment.
<MorbusIff> yeah, that was it, actually.
<MorbusIff> the full path iw as giving was wrong.
<MorbusIff> so the test failed.
<jldupont> verterok: vila:  just to close the loop:  I deleted the branch on LP, delete my .bzr on my side, closed eclipse, re-init everything by hand through CLI, restarted eclipse... and now it works!
<MorbusIff> when i gave the right full path, bzr log works now under bzr+ssh
<jldupont> thanks for your precious time guys!
<verterok> jldupont: cool :)
<Imperion> um, is anyone willing to lend their Bazaar expertise and help me out with this?
<Imperion> s/this/something/
<bialix> it depends
<Imperion> what on?
<bialix> on your question, of course
<bialix> just ask first
<Imperion> designing and organizing the repository/branches
<bialix> so what is your question
<Imperion> just a sec
<GaryvdM> Hi bialix and vila
<bialix> Hi Gary!
<Imperion> my project consists of a core executable and several modules
<Imperion> the modules depend on files in the core for the interfaces, etc.
<Imperion> what's the recommended way to set this up?
<GaryvdM> bialix, vila: I'm very eger to here what you guys think about lp:~garyvdm/qbzr/just_show_tests
<bialix> GaryvdM: I'm about to look at your branch right *now*
<GaryvdM> :-)
<bialix> gosh, I don't run bzr log for ages, forgot leading q...
<bialix> GaryvdM: ok, I've ran it
<bialix> looks terrible as you expected :-)
<bialix> but I can live with that
<bialix> but maybe if we can made those tests optional or control them somehow -- it will be nice
<bialix> vila: ping
<GaryvdM> bialix: The other option is to just init and run initial_load, but not show the widow.
<vila> bialix: pong ?
<GaryvdM> bialix: this would mean that the paint methods don't get tested.
<bialix> vila: have a couple of minutes for qbzr>?
<vila> bialix: I'm upgrading it to 2a and looking at gary's branch
<bialix> GaryvdM: no, if we can I'd better test all we can
<GaryvdM> ok
<bialix> GaryvdM: this flashing windows is a bit annoying, but I understand the price.
<chx> if i run bzr serve --directory=/reall/long/path is there a way to replace bzr co bzr+ssh://example.com/real/long/path/branch with simply bzr co bzr+ssh://example.com/branch
<vila> GaryvdM: meh, that's 46 revisions on top of trunk ???
<bialix> vila: in the past there were interactive tests for bzr itself
<GaryvdM> vila: no - just 2
<bialix> vila: is it possible to make part of test suite switchable?
<dOxxx> Imperion: Whatever makes sense for the language you are using. If the core executables and modules all make a single logical project unit, then they can all go into a single bzr branch
<bialix> chx: yes
<chx> bialix: And how...?
<vila> bialix: interactive tests make no sense for automation in my mind, what are you talking about ?
<Imperion> dOxxx: okay
<chx> bialix: I read the help for both co and serve and saw no way :/
<chx> bialix: some conf file?
<bialix> chx: you mix bzr serve and bzr+ssh
<chx> oh i do not even need bzr serve when urnning bzr+ssh?
<chx> that ... makes sense, i suppose?
<bialix> chx: no
<bialix> bzr+ssh launch bzr serve via ssh automatically
<vila> GaryvdM: if I run 'bzr qlog trunk just_show_tests' it shows 46 additional revisions, what's up ?
<chx> bialix: aaaaaaah
<bialix> vila: do you have old trunk? new trunk is trunk2a
<vila> bialix: aaaaaaaaaaaaaaargh
<vila> I updated old trunk :-(
<vila> I *upgraded* old trunk
<bialix> that's fine, run pull --remember lp:qbzr now :-)
<vila> right
<vila> only 2 revisions now
<bialix> Imperion: every branch is separate entity
<vila> aaargh again, I ran 'pull --overwrite' and forgot --remember, you guys drive me nuts ;)
 * bialix said --remember, not overwrite
<bialix> vila: we don't want, honestly
 * vila did it before bialix gave the right invocation :)
<bialix> rats, I've late
<chx> bialix: ok then is there a config value like the user=joe in authentication.conf to supply a sort of base bath?
<vila> GaryvdM: so, a couple of remarks
 * GaryvdM listens
<Imperion> bialix: meaning
<Imperion> ?
<vila> instead of doing try/finally, use addCleanup, that avoids errors and indentations
<bialix> chx: mmm, no. But I think you can try to use settings in authorized_keys on the server
<bialix> Imperion: do you want all your modules to live in separate branches?
<chx> bialix: like....?
<vila> GaryvdM: i.e. self.addCleanup(win.close) just after the win is created
<chx> bialix: or set the home directory of the bzr user.
<bialix> chx: look in contrib/bzr_access to get some ideas
<chx> i will
<GaryvdM> vila: we have code that runs when the windows close (like saveing the window sizes.) What would happen if there was and error in that code?
<vila> GaryvdM: don't override trace.report_exception unconditionally, you will regret it one day or another, do that in a setUp() and again use addCleanup to restore the original
<bialix> Imperion: you can put your entire project into one big branch, or use separate branches for every module
<Imperion> bialix: all of the parts depend on the core
<vila> GaryvdM: don't worry, errors are allowed during cleanup methods, but they generally indicate deeper problems
<bialix> Imperion: yes, but do your modules have thevalue by itself? to reuse them in other similar project?
<Imperion> no
<Imperion> they're useless without the core
<bialix> Imperion: then put all modules into one big branch with core
<bialix> Imperion: just think why you call them modules and separate from core?
<GaryvdM> vila: Re overriding report_exception: What would be a good way to make that common among lots of test? (can you think of an example in bzrlib?)
<bialix> Imperion: in bzr world branch is main thing, it's often synonym to repo in other systems
<GaryvdM> vila: The big question is, is it ok to show and hide the gui from the test suit like that?
<vila> GaryvdM: define a base class or a mixing that all test classes that requires the feature will use
<GaryvdM> ok
<Imperion> bialix: they're modules because they're interchangeable with other modules with the same interface
<bialix> GaryvdM: I wonder if we actually can use QtTest
<Imperion> bialix: e.g. multiple video driver modules
<vila> GaryvdM: yes it is, bzr-gtk does that
<vila> or did
<bialix> Imperion: so they have value by itself? with other core?
<Imperion> sorry?
<vila> hmm, let me try a trick or two
<bialix> Imperion: there are several reasons to not put modules into the same branch as core
<bialix> Imperion: because once you put them there you'll have problems to split this branch later
<vila> hehe, it works :)
<Imperion> bialix: modules depend on the core to compile
<bialix> Imperion: but there is one big reasons to do so: much simpler to clone entire project
<GaryvdM> bialix: Yes - QTest will help when we want to test things like clicking on a button.
<vila> GaryvdM: http://paste.ubuntu.com/329520/
<bialix> GaryvdM: In my undertsanding QtTest can help to avoid actually show the GUI?
<bialix> Imperion: what you need called nested trees
<vila> bialix: look at my pastebin, no more windows showing up :-D
<Imperion> bialix: explain?
<bialix> Imperion: but they are not implemented yet
<Imperion> >_>
<GaryvdM> vila: I'm not sure if that will cause paint events to run - I run with --coverage to check
<bialix> Imperion: you can organise several separate branches into complex project
<vila> GaryvdM: could be, let me know
<bialix> and work with such construct as with one big branch
<bialix> vila: hehe, nice
<GaryvdM> bialix: As far as I can see from the docs, no
<bialix> Imperion: there is 3rd party tools to manage this problem though
<bialix> Imperion: config-manager utility; scmproj, externals plugins
<Imperion> mhmm
<bialix> Imperion: I'm the author of scmproj
<bialix> scmproj is somewhat emulation of nested trees
<bialix> Imperion: do you familiar with svn?
<bialix> or CVS?
<Imperion> no
<bialix> Imperion: no other VCS experience?
<Imperion> nope
<bialix> ok
<Imperion> my project is hosted on Launchpad
<Imperion> will this be possible? :S
<bialix> is and will in last 2 sentences are conflict
<bialix> yes, it's possible
<vila> Imperion: why do you want to separate the modules if they require trunk ? (I.e. they make no sense without trunk)
<bialix> what is your project? it's open source as I understand
<Imperion> vila: I don't want anything, I'm asking for advice
<Imperion> bialix: 2D isometric RTS engine, https://launchpad.net/catom
<Imperion> the code currently available is old
<Imperion> I've refactored everything
<bialix> vila: Imerion said the modules can be changed by similar with the same interface, sounds like pluggable architecture for me
<Imperion> bialix: it is
<Imperion> and I'm wondering about improving the organization of it
<bialix> vila, Imperion: therefore I'd suggest to not put plugins into the same branch as core
<vila> Imperion: sry, my advice will then be: don't separate modules from trunk if there is a strong dependency, just keep them in the same branch
<Peng> After 80 hours, "bzr check" on 1.14 MySQL is *still* at "[####\               ] checking commit contents:inventories 0/2". I might give up soon.
<Imperion> dun dun dun
<vila> bialix: that's just asking for trouble if they should always be kept synchronized
<bialix> the truth is: you can merge all your separate modules into core branch easily but not vice versa
<bialix> Imperion: so you need some experiments
<Imperion> I wonder how I'll fix the CMake script to work with this
<MorbusIff> if i checkout a bzr branch, is my commit access to it allowed or unallowed, barring any other configuration?
<vila> haaa, GaryvdM is back !
<bialix> back from Ubuntu
<vila> GaryvdM: why don't you use a VM instead of a double boot ?
<GaryvdM> in ubuntu
<GaryvdM> vila: Yes I should
 * bialix does not know cmake specific, can't say much useful
<bialix> Imperion: single branch with all modules + core would be much simpler to you right now, given in mind lack of good nested trees support
<Imperion> okay
<bialix> I'm working on new design of scmproj, I'm hope I'll have better support of critical features soon
<GaryvdM> vila: The window still flashes for me :-(
<GaryvdM> vila: and the paint methods don't get run.
<GaryvdM> vila: I'm going to make your other changes though.
<vila> GaryvdM: forget about the cheap trick then, we may want to try harder when I add the plugins to babune
<vila> GaryvdM: but even there you may add some feature check to ensure there is a usable display
<GaryvdM> vila: yes - I hope to still find a solution.
<vila> GaryvdM: don't spend too much time on it now, it's better to have tests that requires some feature than no tests :)
<GaryvdM> vila: but for now, it's a start in the right direction I believe.
<GaryvdM> vila: yes
<vila> GaryvdM: definitely !!
<vila> GaryvdM, bialix : gtg, have a nice week-end !
<GaryvdM> Bye vila - Thanks for the help.
<bialix> gtg?
<GaryvdM> got to go
<vila> gotta go
<bialix> bye vila, thanks!
<bialix> GaryvdM: I'm ok with your new flashing tests
<bialix> GaryvdM: btw, one observation about exception dialog reporter
<bialix> if I click X button on this dialog or press Esc then it treats this as Ignore. In most cases the problem too serious and we need to actually close the window
 * bialix going home
<bialix> bye GaryvdM, bye all
<Peng> beuno: ping
<beuno> Peng, hi dude
<Peng> beuno: You approve lp:~deuns-martinez/loggerhead/flup? I'd be happy to tweak and land it.
<beuno> Peng, I do, I think that with the tweaks it's good enough
<beuno> and he's gone to the trouble of signing the contributor agreement, submitting the branch, etc
<Peng> beuno: So...want me to go ahead and do that?
<beuno> Peng, yes!  thank you
<Peng> OK. :)
<Peng> Done.
<beuno> thanks Peng!
<Peng> :)
<servilio> hi! do the karmic versions of bzr & bzr-svn work OK under Ubuntu Hardy?
<beuno> servilio, probably not
<beuno> there are some depenency issues with python-central, if IIRC
<Peng> There aren't Hardy versions you can use?
<servilio> beuno, Peng: just enabled the backports in hardy but didn't see it, now trying to debbuild using karmic source repos, but wanted to quick ask first
<servilio> I'd prefer to build from source packages
<Peng> There's probably a PPA.
<Peng> servilio: Try https://edge.launchpad.net/~bzr/+archive/ppa
<servilio> Peng: looking at https://launchpad.net/~bzr/+archive/ppa?field.series_filter=hardy
<servilio> Peng: thanks for the suggestion1
<servilio> !
<Peng> servilio: Don't thank me until you confirm that the PPA versions of bzr + bzr-svn + subvertpy are all compatible...
<servilio> Peng: shouldn't the source package specify when it could not be built by using minimum versions for its requirements?
<roychri> I created a new test project and I pushed to my server using sftp.  No errors.  When I try to branch off using http, I get : "bzr: ERROR: Unknown working tree format: ''"
<roychri> I searched for that error in google but found nothing :(
<maxb> What a weird error
<maxb> Perhaps you should publish a test repo on your server that people can use to reproduce the bug
<roychri> maxb: I published a test repo on my "dreamhost" account using sftp and I can branch off from there.
<roychri> maxb: I cannot do it from this internal apache web server that the infra team setup.
<roychri> maxb: They did not set it up for me to publish bzr branches so they are not willing to help me out
<roychri> I can do it but I am on my own :(
<maxb> So, to clarify, you are using "dumb" http
<roychri> yes
<roychri> sftp to publish and dumb http to branch from.
<abbec> i have a problem with bazaar on nfs4 share
<abbec> anyone that can help?
<maxb> roychri: Perhaps you could see if using -Derror or -Dhttp shows any useful information
<roychri> passing that to bzr cli?
<roychri> interesting
<roychri> maxb: http://pastebin.com/d5852206f
<abbec> i have a problem with running bzr stat on an nfs4 share... anyone that can help?
<maxb> roychri: bzr 1.3.1? That's like, ancient history! :-)
<roychri> maxb: oh... I simply did "apt-get install bzr".
<roychri> maxb: I did not realized it was archaic
<maxb> Ubuntu or Debian?
<roychri> ubuntu 8.04
<maxb> There is an official PPA carrying the latest release
<maxb> https://launchpad.net/~bzr/+archive/ppa
<Peng> roychri: What does http://server5591.lan/code/testyyy/.bzr/checkout/format look like?
<roychri> Peng: no checkout in .bzr
<roychri> there is a http://server5591.lan/code/testyyy/.bzr/branch/format file however.
<roychri> maxb: Thanks for the PPA, I will give it a try
<Peng> roychri: What happens if you try to visit http://server5591.lan/code/testyyy/.bzr/checkout/format in a browser, though?
<Peng> roychri: Also, is ther eany sort of proxy involved?
<Peng> there any*
<abbec> i have a problem with running bzr stat on an nfs4 share... anyone that can help?
<abbec> if i run bzr stat on the nfs4 share everthing hangs up
<roychri> Peng: hmmm. you might be on to somethnig. I am not getting 404.
<roychri> Peng: nice.  You got it!
<Peng> :D
<roychri> Peng: There was an .htaccess in the parent folder.
<roychri> http://server5591.lan/.htaccess
<roychri> With some rewriterules that was screwing things yup
<Peng> Does it work now?
<roychri> yup
<roychri> Branched 1 revision(s).
<Peng> Perfect. :)
<roychri> Thank you Peng and maxb for your help today.
<abbec> i have a problem with running bzr stat on an nfs4 share... anyone that can help?
<abbec> if i run bzr stat on the nfs4 share everthing hangs up
<Peng> "Hangs up"? Are you sure it's not just slow?
<abbec> yes
<abbec> i am sure
<abbec> every other command works though
<abbec> https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/403697
<ubottu> Launchpad bug 403697 in bzr "bzr hangs trying to lstat dirstate file" [Medium,Invalid]
<abbec> this bug describes the same behaviour
<abbec> Peng: it works with nfs3 and bzr stat works with nfs4 if there has not been any changes
<abbec> Peng: but if there is changes it hangs on bzr stat
<Peng> Sorry, I don't know much about this.
<abbec> anyone else?
<abbec> bzr diff and other commands work
<dOxxx> abbec: you could try emailing the mailing list, you may reach a broader audience and increase your chances of finding somebody who knows something about it
<abbec> dOxxx: ok... how do i do that?
<dOxxx> abbec: https://lists.ubuntu.com/mailman/listinfo/bazaar
<dOxxx> you'll need to subscribe to post
<abbec> dOxxx: thx
<maxb> Anyone knowing lots about bzr-svn layouts here?
<maxb> If I have a repository containing many projects *not all at the same depth from the repo root* what should I do?
<rittyan> Hi all. Can't connect to answers.launchpad.net (some network problem). I am using git for 1,5y and now I am in a company where bzr is popular. I considered switching and I have a question about a feature I use 100% of time in git: interactive add. Is there something like that? I found shelve feature, but it looks like stash in git (i.e. isn't the one I am after)
<GaryvdM> rittyan - Not in the core, but I think there is a plugin.
<GaryvdM> let me search
<maxb> https://edge.launchpad.net/bzr-interactive ?
<dOxxx> rittyan: are you referring to something like the git staging area?
<GaryvdM> maxb: yes that's it
<maxb> jelmer: Hi, is there any bzr-svn layout configuration that will enable it to deal with a svn repository with multiple projects (trunk tags branches in each) *not all at the same depth from the repo root*?
<jelmer> maxb: custom/wildcard branch layout
<rittyan1> (sorry for repeating, I got disconnected) Hi all. I am using git for 1,5y and now I am in a company where bzr is popular. I considered switching and I have a question about a feature I use 100% of time in git: interactive add. Is there something like that? I found shelve feature, but it looks like stash in git (i.e. isn't the one I am after)
<rittyan1> i.e., can I commit hunks or lines I pick from a file, instead of whole file
<maxb> So I'd have to enumerate each project separately in the bzr-svn config?
<dOxxx> rittyan: Somebody suggested trying bzr-interactive
<GaryvdM> rittyan1: https://launchpad.net/bzr-interactive
<jelmer> maxb: You can use multiple asterisks in the wildcard layout
<maxb> branches = */branches/*;*/trunk  ?
<dOxxx> rittyan: also, you can use shelve to accomplish something like git's staging area. you shelve the changes you don't want, commit the rest and then unshelve.
<rittyan1> dOxxx: troublesome
<rittyan1> and that plugin looks... "new", according to bugs
<jelmer> maxb: for example
<rittyan1> also, as I understand, plugin => no support in gui
<jelmer> maxb: asterisks will only cover one directory level
<GaryvdM> rittyan1: I'm one of the devlopers of qbzr. I hope to add support for that soon.
<jelmer> maxb, you might need "*/trunk; */*/trunk; */*/*/trunk", etc
<rittyan1> dOxxx: I do series of commits at once, making them small and per-feature from big changes. Shelving/Unshelving is definitely troublesome with such workflow :<
<dOxxx> rittyan: yeah. although to be honest, shelve -> commit is pretty much the same amount of effort as stage -> commit, if you ask me. :)
<dOxxx> rittyan: if you're using this to separate feature commits, perhaps you should be trying feature branches.
<rittyan1> feature branch is something like creating a branch per feature? Like, `git branch ticket-1234`
<dOxxx> rittyan: yes. usually used in conjunction with a shared repository so as to save disk space and make the branching quick.
<rittyan1> I use that workflow already :) it's just isn't wise to use it to add a function (one commit), then put this function to use (another commit), for example
<rittyan1> damn, I am addicted, it seems :/ without hope to switching
<dOxxx> rittyan: for sure, it's best used in a somewhat coarse manner, like a bug per branch, etc.
<dOxxx> hmmm
<dOxxx> rittyan: comment #10 and #16 on http://tomayko.com/writings/the-thing-about-git are interesting
<dOxxx> rittyan: something that may also be useful to you is bzr-pipeline or bzr-loom
<rittyan1> dOxxx: I don't get what it says. I never had any problems with testing or whatsoever, hm :<
<dOxxx> rittyan1: it's more of a general principle thing. The changes committed using git's staging area have not been tested on their own as you're committing them.
<dOxxx> rittyan1: anyway, I'm just saying it's an interesting perspective. I personally found the staging area quite useful in some cases when I was using git a while back.
<rittyan1> care to share what do you do when you write a function, put it to use, make cosmetic changes (you are on a coding spree) and then you need to make 3 commits of it?
<dOxxx> rittyan1: my usual working environment uses cvs, so in that case I cry. ;)
<rittyan1> what about your after-work life :)
<dOxxx> rittyan1: but using bzr, I would use shelve to separate the changes
<dOxxx> rittyan1: or if the cosmetic changes are closely related to the function I added, I would probably just include it in the one commit
<dOxxx> rittyan1: commit history doesn't have to be an exact replica of the process you went through to make the changes.
<rittyan1> of course, that's why I spent an hour today moving back and forth commits for 3 prev. weeks, squashing or "fixing" then a bit
<rittyan1> before pushing to public
<dOxxx> rittyan1: using git or bzr?
<rittyan1> I am using git
<rittyan1> I never tried bzr yet, but a lot of people at work do
<rittyan1> I am preparing myself :)
<dOxxx> rittyan1: as I understand it, when you merge stuff from one git repo to another, the target repo gets the individual commit messages. so if you commit with messages "1", "2", "3" and then merge to another repo, that repo will have revisions with messages "1", "2", "3", right?
<dOxxx> hmm
<dOxxx> although I think I'm mixing up my terminology. merge is not push. :)
<rittyan1> hmm I am not sure I got it, but what you say looks correct to me. Also, I used merge only once maybe, in 1.5y of using git
<rittyan1> I am rebase kind of user
<lifeless> moin
<rittyan1> (i.e. try to stack commits from one branch on top of another and fix conflicts if there any)
<rittyan1> moin lifeless
<dOxxx> anyway, the point I was trying to make is that using feature branches and merging them into a trunk means that the "messy" nature of the commits on the feature branch are hidden.
<dOxxx> because the merge appears as a single revision with your merge commit message on the trunk
<rittyan1> dOxxx: yes that's why I don't like merging :))
<dOxxx> rittyan1: however, bzr does expose the individual commits of the merge if you want
<dOxxx> rittyan1: check out this example: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/4832
<rittyan1> what at I should take a closer look there?
<rittyan1> ah! got it
<dOxxx> if you follow the link "4831.1.1 integration" on that page, that takes you to the branch vila merged into trunk
<rittyan1> except that I don't see any individual commits there
<dOxxx> on the page for vila's branch you can see 4815.3.8 quiet-serve
<dOxxx> that's *my* feature branch
<dOxxx> if you then click the view history link you'll see the individual commits
<dOxxx> but note that all this info is coming from the bzr.dev trunk repo
<dOxxx> the bzr GUI log tool, qlog, shows it quite a nice way
<rittyan1> I think that I should give it a try
<rittyan1> and see if I like it
<rittyan1> because anyway, sooner or later I will probably have to face bzr
<rittyan1> like it or not :/
<dOxxx> it's not that bad ;)
<rittyan1> and one more question: there must be rebase, I bet. Interactive one? :)
<GaryvdM> rittyan1: Here is a screen shot of those revisions in qlog: http://imagebin.ca/view/IjcR0oL.html
<rittyan1> GaryvdM: looks like typical git log in gui
<rittyan1> except that green node has trailing pink changes that have no parent
<GaryvdM> the parent is off the screen
<rittyan1> this is that? commits existed during merge?
<rittyan1> ah, right
<dOxxx> rittyan1: yes
<GaryvdM> rittyan: note that you can also colapse and expand those merges, like a tree
<dOxxx> rittyan1: there is a plugin for rebase/rewrite
<GaryvdM> rittyan1: Yes - there is rebase, via plugin. See http://bazaar-vcs.org/Rebase
<rittyan1> does it mean that on public repos people will know about my private <s>life</s> commits?
<dOxxx> if it's merged, yes
<dOxxx> you could always email patches ;)
<GaryvdM> Hopefully you don't commit you private life to a public repo ;-)
<dOxxx> brb, disconnecting vpn
<rittyan1> hmm, thanks for help
<rittyan1> honestly it all sounds very limited, no offence... I am just used to something bizzare it seems
<rittyan1> you are great bunch of guys, thank you o/
<GaryvdM> rittyan1: Any time.
<dOxxx> rittyan1: you're welcome
<dOxxx> what's the diomatic way in python to represent an abstract method in an abstract class?
<dOxxx> i.e. as a hint that subclasses must implement this method
<GaryvdM> raise NotImplemented
<dOxxx> aha
<Peng> No, NotImplementedError.
<dOxxx> thanks
<GaryvdM> Yes, sorry thats what I ment.
<Peng> NotImplemented is for use in comparison methods. You return it if you don't know how to compare with the other object.
<lifeless> raise NotImplementedError(self.methodname)
<dOxxx> where 'methodname' is the actual name of the method?
<Peng> dOxxx: Where "self.methodname" is an expression that evaluates to the method object itself.
<Peng> def foo(self): raise NotImplementedError(self.foo)
<dOxxx> Peng: gotcha
<gutworth> when do we get branch specific eol patterns?
#bzr 2009-11-28
<maxb> .....that's a bit special.... "bzr multi-pull" is pulling the same branch over and over again!
<maxb> Too many levels of symbolic links: u'/home/maxb/wc/bzr/bzr-svn/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/1.0/.bzr/branch-format'
<maxb> heh
<maxb> which would be fine, except there's not a symlink in sight
<maxb> oh, yes there is
<beuno> vila, ping
<beuno> vila, what am I missing besides medusa to run all the tests?
<beuno> Missing feature 'FTPServer' skipped 42 tests.
<beuno> vila, http://paste.ubuntu.com/329884/
<lifeless> beuno: python-medusa
<lifeless> not medusa
<beuno> hi lifeless
<beuno> lemme try that..
<beuno> (would make a truck-load of sense)
<lifeless> beuno: (note that you can't run all the tests, ever).
<lifeless> beuno: because windows isn't linux and linux isn't windows.
<beuno> lifeless, I'm going to let other worry about windows for now
<beuno> I get the same thing, sftp tests skipped
<lifeless> beuno: ftp or sftp ?
<beuno> lifeless, sftp
<beuno> actually
<beuno> FTPServer
<beuno> Missing feature 'FTPServer' skipped 42 tests.
<lifeless> python-medusa should have been it
<beuno> it didn't  :/
<beuno> I guess I can TDD anyway, and figure out the FTP part tomorrow
<lifeless> beuno: what are you working on ?
<beuno> lifeless, bzr-upload, going to implement a few new features
<beuno> starting off with a .bzr-upload-ignores
<lifeless> you can check the feature availability test
<beuno> tell me more
<lifeless> grep for FTPServerFeature, I think it is
<lifeless> in bzrlib.transports.ftp
<beuno> ftp/_gssapi.py:    if ftp_server.FTPServerFeature.available():
<beuno> from bzrlib.tests import ftp_server
<beuno> there's a comment: # medusa is bogus under python2.6
<beuno> pyftpdlib...
<beuno> can't find anythin in apt with it though
<lifeless> keep pulling the string
<beuno> hm
<beuno> maybe pyftpd
<beuno> nope
<beuno> vila, https://code.edge.launchpad.net/~beuno/bzr-upload/ignores/+merge/15346
<beuno> I managed to get some decent coding after *months*
<beuno> TDD and everything
<beuno> vila, I'm dissapointed you're not awake at 4:30am on a Saturday to review my branch
<beuno> and I am also dissapointed in how long it takes Launchpad to generate a diff with no feedback at all
<Glenjamin> hi guys, i'm trying to convince the company I work at to choose bzr over git for future projects, and i'm wondering what my options are for a central repository with secure access control
<Glenjamin> is there some way to proxy the dedicated mode of bzr serve through apache or similar?
<jszakmeister> You might want to check out: http://doc.bazaar-vcs.org/bzr.2.0/en/user-guide/http_smart_server.html
<jszakmeister> I've not tried it yet (just don't have enough 'roundtuits)
<thrope> hi - is it possible to pull/move a file from an unrelated repo preserving history?
<thrope> sorry pull or copy I mean
<thrope> I would like to have be able to import a single file with history from another repo
<thrope> I'm guessing not but wondered if there was any trickery with rebase or something that could do it
<jelmer> thrope: You can use merge
<jelmer> thrope, but that'll pull of the contents of the other repo
<thrope> I guess I could branch the source repo, delete everything but the file I want, then merge? (acutally I didn't think you could merge unrelated branches)
<thrope> I get bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.  when I test merging
<jelmer> you can merge unrelated branches by specifying -r0..-1
<thrope> same with bzr merge -r 1 ../a
<thrope> ah
<thrope> great thanks
<thrope> only thing is it pulls the whole history of other branch (i guess obvious) but I only really want to changes of that file
<bing> hey folks.  i'm looking for a volunteer to take a cvs tree, and a svn tree and merge them into a single bzr tree.  i know it can't be much fun, but i figure *somebody* has to like doing this stuff.
<thrope> mwhudson: another minor loggerhead thing... running another public instance at a nonroot url (but still https, apache proxypass)... if I go to https://www.host.net/bzr/ then everything works perfect but if I got to https://www.host.net/bzr (no trailing slash) then the repo links on the browsing page are broken (go to host.net/repo instead of host.net/bzr/repo)...
<thrope> I tried playing with apache settings a bit, and have --prefix set in loggerheadd script; running the relative links patches from the other day
<Glenjamin> we're looking at possibly setting up bazaar for our office, and i'm looking into how to get an access controlled central repository with access only over an encrypted transport - currently i think my options are bzr+https with auth via apache, and bzr+ssh with a wrapper like http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/contrib/bzr_ssh_path_limiter - can anyone offer some...
<Glenjamin> ...advice?
<vila> Glenjamin: Looks like you already found the right bits, do you have more precise questions ?
<Glenjamin> well, what would be the performance implications of one or the other
<vila> The performances should be roughly equivalent AFAIK, you're adding either SSL or ssh encryption anyway
<Glenjamin> i think the second option would allow me to supply per-branch permissions as well - but i'm unsure if this would screw up with file ownership
<vila> Ha
<Glenjamin> my main issue is that i've got to convince our sysadmin that either of these is better than the git equivalent :)
<vila> http[s] implies a single user on the remote host whereas ssh allows you to either use a single one or several, it depends on how you configure things
<vila> What is the git equivalent on the admin side ?
<Glenjamin> well if we were using the https approach, i think we'd have to wrap it with http auth
<Glenjamin> there's either git-daemon, which is pretty much bzr serve, so no encryption
<Glenjamin> or ssh, where there's a git-shell which is a bit like the python script i linked to above
<vila> Right, so both use a single account on the remote host for ssh right ?
 * vila thinks a single right should be enough...
<Glenjamin> well i was mostly expecting that each developer should have their own credentials, in the https case this would be done via apache, and for ssh it'd just be different user accounts
<beuno> vila, hi!
<vila> beuno: hey !
<vila> Glenjamin: so, if you go the several accounts route, you will encounter more problems to share, since the file system persmissions will come into play, what OS is used on the remote host ?
<Glenjamin> ubuntu
<Glenjamin> i suppose one user with multiple keys might be a decent compromise, so that each user has different credentials to log in
<vila> that's a good point ;) What release (just out of curiosity but also to check which bzr version is available there)
<beuno> vila, did you get my messages?
<Glenjamin> i think its jaunty
<Glenjamin> but i might be able to talk him into adding the bazaar ppa
<vila> beuno: not yet I presume, I haven't check my mail yet, but I've seen your messages here, I'll will look at that closely and soon, but may be not right now :-)
<vila> Glenjamin: gee, but you already know all the tricks ! Why are you asking questions :-)
<Glenjamin> because its not me that needs convincing :)
<vila> hehe
<Glenjamin> i've been using bazaar for personal stuff, plus bzr-svn at work for a while
<Glenjamin> we're looking at using a DVCS for new projects, but everyone else is leaning towards git, mainly because of the visibility of github
<Glenjamin> ie. they want to use git because its probably more popular
<vila> Glenjamin: So, IMHP, the safer (as in: simpler, less trouble, hence raising less questions from your admin) is the single ssh account and the additional script
<Glenjamin> makes sense
<Glenjamin> and then loggerhead proxied through apache for web browsing
<vila> yup
<vila> the biggest question may be which workflows you want to allow, is it a single trunk on the host or also the ability for each dev to mirror its own branches or do you want team branches where several dev can commit too, etc
<Glenjamin> i think it'll be a nominated mainline per project, and then all development branches mirrored to the repo
<Glenjamin> and there's no real reason i can see why some dev branches cant be shared
<vila> beuno: regarding pyftpd, I'm pretty sure I documented the URL to download from somewhere, there is no debian/ubuntu package AFAIK, but it's a single .py file
<vila> Glenjamin: then, would you restrict the sharing or should everybody be able to write everywhere ?
<Glenjamin> hrm, ideally we'd want to be able to restrict some repos to certain users
<vila> Did you look at the bzr_access script too ?
<vila> disclaimer: I haven't use either
<Glenjamin> i skimmed it earlier, loggerhead is having a fit any wont show it to me anymore :(
<vila> Glenjamin: Hey ! Are you related to Neil Martinsen-Burell ???
<Glenjamin> i'm not
<Glenjamin> but if i recall he's been doing some stuff on a bug i reported
<vila> gelnjamin.co.uk having trouble with http authenticated access after redirection ?
<Glenjamin> yup
<vila> bug #395714 ?
<ubottu> Launchpad bug 395714 in bzr "Redirect to location protected by HTTP auth fails" [Medium,Confirmed] https://launchpad.net/bugs/395714
<Glenjamin> thats the one
<vila> That's weird, he seems to be able to reproduce the bug and I'm not :-/
<Glenjamin> hrm, i'll update bzr on this machine and have a go
<vila> Regarding your remark about loggerhead, you mean you don't have the bzr sources locally ?
<Glenjamin> i'm aiming to replace the setup we have at the moment which is SVN over DAV with apache, where the devs dont have any other access to that box
<vila> bzr_access should be far enough with a single ssh account then. At least that's how I understand its intent.
<vila> beuno: still there ?
<vila> beuno: good, enjoy your week-end :-D
<Glenjamin> hrm, i think i'd only be able to get per-branch (ie. per-project) access control if i go back to the bzr+https approach
<Glenjamin> the ssh command bazaar sends to start up the hpss using ssh doesnt know which branch its after
<beuno> vila, kind of
<Glenjamin> vila: updated to all the latest bzr releases, and i can still reproduce the bug
<Glenjamin> which version are you using?
<vila> Glenjamin: lp:~vila/bzr/395714-auth-redirect
<vila> the bug is genuine, but Neil said even eith the fix in the branch above he still reproduces the bug
<j85wilson> I have, in my code tree, several directories which contain code which is compiled into executables.  The executables have the same name as the directories.  I want to ignore them, but "Regular expression patterns may not include named or numbered groups."
<j85wilson> Is there another way to do this?
<j85wilson> RE:\(.*\)/\1 in .bzrignore does not accomplish my goal.
<Glenjamin> just be explicit?
<j85wilson> Directories get added frequently.  I don't want to have to, and don't want my users (physicists, we're writing analysis code, so my users are coders) to have to, edit .bzrignore all the time.
<Glenjamin> could you change the build process to put all the executables in one /bin directory?
<j85wilson> I don't think so.  Too much of a break with history-weighted process.
<j85wilson> wait, maybe I've got an idea.
<j85wilson> .*\(/.*\)*
<j85wilson> not sure if I've got the grouping syntax and such correct for python regex
<j85wilson> but RTFMing.
<mathrick> hey
<mathrick> is anyone working on bzr-git currently?
<mathrick> putting up with git is beyond my patience, I'd really like to have a sane frontend to that idiocy
<vila> mathrick: jelmer is
<mathrick> jelmer: my hero!
<mathrick> is it any usable? Last I checked (long time ago), it wasn't
<vila> mathrick: AFAIK, it is, with less and less restrictions (I don't know the details though)
 * mathrick goes to check it out
<beuno> vila, I sumbitted a merge proposal for the ignore feature in bzr-upload. I still can't get the testsuite to tun FTPServer tests though
<vila> beuno: if you're using python2.6 you need pyftpdlib
<mathrick> seriously, git is just retarded
 * jelmer waves
<mathrick> jelmer: hola!
<jelmer> mathrick, everything except for true push should be working
<mathrick> cool, can I use it directly on a git-cloned repo, or do I need to go through bzr-git?
<beuno> vila, where do I get it from?
 * vila searching for the pyftpdlib URL
<jelmer> mathrick: you should be able to use it directly on a git-cloned repo
<mathrick> yay
 * mathrick pants a little
<jelmer> mathrick, although that'll still have some quirks since there is no equivalent of the index in bzr
<mathrick> jelmer: right now just getting me bzr missing with git will be way awesomer than plain git :)
<Glenjamin> i'm having trouble compiling bzr on windows - its saying cannoy find -lzdll, which i'm sure i've seen before and solved
<Glenjamin> does it ring any bells for anyone?
<jelmer> mathrick, that won't work on remote git repositories unfortunately though
<vila> beuno: as mentioned in bzrlib/tests/ftp_server/pyftpdlib.py : http://code.google.com/p/pyftpdlib/
<beuno> vila, where do I put it?
<vila> beuno: no debian/ubuntu packages AFAIK, but it's a simple py file, put it somewhere in your PYTHONPATH
<beuno> aiight
<vila> $HOME/lib/python  :)
<jelmer> mathrick: (it's impossible since the server doesn't provide enough data)
<mathrick> bah
<mathrick> why does it have to be so stupid and so popular?
<vila> Glenjamin: rings a bell too... should be mentioned in setup.py or one of its included files
<mathrick> jelmer: so how does it handle that situation? Or does it not? :)
<vila> Glenjamin: or maybe you have to rename something.... isn't there a wiki page about building on windows ?
<beuno> vila, that worked!  (and they all passed)
<vila> Glenjamin: http://bazaar-vcs.org/WindowsInstall says:     *
<vila>       Zlib - zlib123-dll.zip | Homepage Extract zlib123-dll.zip to temporary folder and copy zlib1.dll into C:\Windows\System32
<vila> beuno: you rock !
<Glenjamin> ah, thanks
<beuno> vila, would be nice to make a package for that  *wink*
<Glenjamin> there's about 6 different wiki pages for bazaar install on windows :D
<vila> Glenjamin: feel free to add comments pointing to the one that works for you ! It's a wiki :D
<Glenjamin> i'll test it first, i get the feeling that this step might be more for VS than GCC
<jelmer> mathrick: it can't unless somebody fixes the git smart server
<jelmer> mathrick, it'll simply tell you "not supported over git://"
<j85wilson> well, I haven't been able to make that regex (or any variant thereof) work properly either.
<Glenjamin> vila: right, finally managed to build the branch - i get a KeyError on 'protocol' now
<Glenjamin> i wonder if it might be simpler to use a defaultdict with None for auth
<j85wilson> does anybody know why "Regular expression patterns may not include named or numbered groups."?  This seems a silly restriction to someone who doesn't know anything.
<vila> Glenjamin: grrr, I don't think so, the problem is I can't figure which codepath is involved in your case, can you provide me with a .bzr.log for a command run with -Dhttp (taking care of removing any auth header that may reveal your credentials (that includes Basic or Dihest related headers)
<mathrick> woah, I haven't visited the bzr page in a long time it seems
 * mathrick wonders at the shiny new look
<Glenjamin> that url isnt a real branch, its just an empty repository with http auth on
<vila> Glenjamin: -Dhttp will tell me :)
<vila> Glenjamin: you can send me the .bzr.log by mail if you prefer, if any credentials are left, at least you'll have only one culprit to track :)
<Glenjamin> http://pastebin.com/m32e6c375
<Glenjamin> i'm fairly sure there arent any valid credentials for that auth config anyway
<vila> bzr-svn !
<vila> jelmer: are you using the _urllib2_wrappers ability to follow redirections ?
<vila> Glenjamin: can you retry that with and additional --no-plugins ?
<vila> s/and/an/
<Glenjamin> yup
<jelmer> vila: no
<Glenjamin> works now
<vila> :)
<vila> :-/
<vila> Glenjamin: ok, at least I know where to search (even if jelmer pretends to be innocent :-D)
<jelmer> :)
<Glenjamin> the issues all stem from trying to access non-existant keys in the auth dict
<vila> Glenjamin: that's the apparent cause, a deeper one is that we shouldn't use that code path but one that create the auth dict correctly,
<vila> http://pastebin.com/m241bae14 jelmer, you lied :-D
<vila> that's really funny because *I* should provide OPTIONS to jelmer so he can use it safely :)
<Glenjamin> _urlib2_wrappers.py line 360
<vila> Glenjamin: look at the comment just above
<jelmer> vila: that's not using the redirections following code though
<Glenjamin> the comment just above says "containing at least..."
<Glenjamin> and then creates dicts which clearly dont
<vila> jelmer: yes it is, except we don;t have the same definition of redirections following code ;)
<vila> Glenjamin: that's because callers should do that (look at http/__init__ create_auth)
<vila> the redirection code in _urllib2_wrappers don't handle auth correctly (as that bug revealed) instead, callers are supposed to use the do_catching_redirections in transport/__init__
<vila> jelmer: the bug is really that bzr http transport don't provide OPTIONS, don't you think ?
<vila> rotfl
<beuno> vila, thanks for the review,r eplied
<jelmer> vila: yeah, HttpTransport should really have options
<vila> for those not understanding the joke, we had a discussion with jelmer about whether OPTIONS should be supported by bzr even if it's isn't required internally :D
 * vila feels dragged into working on bzr when he should be working on family backups :0)
<Glenjamin> now i remember why i gave up trying to follow this call chain when i first reported this one :D
<vila> beuno: about the README, I'm all for helping people find the relevant bits, but I'm against duplication since it leads to out-of-date info, how about putting the right pointers in the README ? Or separating the concerns and do that in another merge proposal ?
<beuno> vila, sure, I'll drop it from that branch
<vila> Glenjamin: yeah, the design is inherited from the python urllib2, in retrospect, it was a bad idea, but it helped building the actual implementation and all the related feaures: connection sharing, proxy support, various auth schemes, all of which weren't supported by urllib2 :-/
<vila> eeerk low batteries for keyboard, priority interrupt
<mathrick> jelmer: I ran into some crashes: http://pastebin.com/m5b10d31d
<jelmer> mathrick, please file a bug
<mathrick> ok
<sjamaan> Is there a way to get bzr diff to output files which don't include the entire path?
<sjamaan> ie, I do bzr diff under foo/bar/qux and it generates a diff for file foo/bar/qux/mooh.c, instead of just mooh.c
<eelik> will colocated branches aka fasces be supported soon?
<lifeless> eelik: they aren't the same thing, and no one knows :)
<eelik> How they are different?
<lifeless> fasces is a fullermd term to describe something he would like to see
<lifeless> colocated branches is a jelmer created term to describe something he would like to see
<eelik> but basically both describe the "git-style branches" where one working tree is shared by many branches in one directory?
<eelik> That's a feature I'd like to see...
<eelik> So there's actually no schedule for implementing either?
#bzr 2009-11-29
<lifeless> eelik: there is no schedule for either. But you can just use a tree-less repository and a single working tree which you run 'bzr switch' to switch between.
<eelik> I know, but it's clumsy
<eelik> can't compete with git
<lifeless> eelik: true; you're welcome to work on reducing the clumsiness
<lifeless> (or on those other proposals)
<mathrick> jelmer: poke?
<mathrick> jelmer: bzr st on git branches seems wonky, it doesn't report modified files that haven't been added to the index
<jelmer> mathrick, hi
<jelmer> mathrick, you need to "git add" them again to see the changes
<mathrick> yeah, I know, but I was expecting bzr st to tell me about the changes
<jelmer> mathrick, you probably just want a bzr working tree in that case
<lifeless> jelmer: It would be nice if 'bzr st' behaved as bzr does here.
<lifeless> jelmer: that is, to refresh the index
<mathrick> jelmer: possible, I use bzr-git as more bearable git for working on code with git upstream; what's the least painful setup in this case?
<jelmer> lifeless: sure, but somebody would have to code that up
<jelmer> lifeless: it's nontrivial since we can't really trust the index
<jelmer> lifeless, but we also would like to avoid writing to the index on read operations
<lifeless> jelmer: the index is ~= dirstate, and we write to the dirstate on read operations.
<jelmer> lifeless: but that's just the stat cache though, isn't it?
<jelmer> lifeless, modifying the actual contents of the index seems more dubious to me
<lifeless> jelmer: we don't version or unversion things
<lifeless> jelmer: but I'm not suggesting we do that here either.
<jelmer> lifeless: not versioning/unversioning a particular file, but versioning a particular revision of a fil
<jelmer> "git status" would give different output when run after "bzr status"
<lifeless> jelmer: yes, it would match whats on disk more ;)
<jelmer> lifeless: :-)
<lifeless> jelmer:  you will get complaints either way ;)
<jelmer> lifeless: Yes, and it is the way it is because it doesn't require any effort on my part ;-)
<jelmer> *extra
<mathrick> jelmer: the other way is more useful for the bzr-git user though
<mathrick> I think it's fairly safe to assume that people who use bzr-git are expecting more bzr-like behaviour
<mathrick> jelmer: anyway, how hard will it be to push/send patches upstream if I switch to a bzr tree instead of operating on the git tree directly?
<jelmer> mathrick: it wouldn't be any harder/less hard than using a git repository locally I think
<jelmer> mathrick: The index won't ever be a 1-to-1 match with a bzr working tree
<jelmer> I think the best solution would be to keep a separate sha1-cache independent of the git index
<jelmer> and use that for bzr-git
<lifeless> spiv:
<lifeless> https://code.edge.launchpad.net/~spiv/testtools/test-parameterisation - might want to finish, or delete.
<lifeless> \o/ bzr selftest selftest working with testtools test runner
<Peng> An autopack gave me an "inconsistent details in skipped record" message. "bzr pack" did not. What does that mean, exactly?
<Peng> inconsistent details in skipped record: ('monty@askmonty.org-20091125073628-7fekfnr2hmkbjos1',) ('660427 67263 0 319', StaticTuple(StaticTuple(StaticTuple('monty@mysql.com-20091116153408-azpb6hq1zfp1kpvv',), StaticTuple('monty@askmonty.org-20091107103419-28zpi3oyre6kaf2l',)),)) ('1545757 266 0 319', ([('monty@mysql.com-20091116153408-azpb6hq1zfp1kpvv',), ('monty@askmonty.org-20091107103419-28zpi3oyre6kaf2l',)],))
<christoph3141> hi, howcome there is no Arch Linux here: http://bazaar-vcs.org/Download ?
<christoph3141> How do I best install qbzr and bzr-explorer in arch linux?
<christoph3141> hm, bzr seems very ubuntu-centric
<bob2> not really
 * fullermd looks at all the computers around him with bzr installed, and notes that none of them run ubuntu   :p
<bob2> just install them from source
<bob2> or you could be the lucky arch user who packages them first :)
<christoph3141> well, they are packaged in the aur, but the seem to be out-of-date
<christoph3141> Hi, I just downloaded qbzr (I want to install bzr-explorer and it said to install qbzr first). What do I do with the extracted tarball? It doesn't have any INSTALL, and the README.txt doesn't say anything about installing :(
<Glenjamin> christoph3141: python setup.py install
<christoph3141> Glenjamin: thanks!
<christoph3141> I followed the instructions at http://doc.bazaar-vcs.org/explorer/en/install-linux.html, but running "bzr explorer" says "bzr: ERROR: unknown command "explorer""
<christoph3141> What do I do?
<christoph3141> oh, it works now, I was in the wrong directory while running the command
<jfroy> lol
<jfroy> bzr thinks my Mac OS X box is a weird windows hybrid!
<jfroy> Bazaar (bzr) 2.1.0b3
<jfroy>   Python interpreter: /usr/bin/python26.dll 2.6.1
<Noldorin> hi. would anyone have an idea how to get started setting up loggerhead for IIS7?
<Noldorin> python is installed and running fine, but i'm lost from there on
<blueyed> I have a branch derived from a tailor-generated branch. I know want to move it over to a branch created via Launchpad's vcs-import. How would I do that? There's no common ancestor.
<blueyed> hum.. does not seem to be possible (easily).. https://bugs.launchpad.net/bzr/+bug/318620
<ubottu> Launchpad bug 318620 in bzr "When merging two branches without common ancestry, Bazaar provides no means to map file IDs" [Undecided,Confirmed]
<blueyed> I guess I'll do a merge with "-r", manually compare the directories and then commit..
<lifeless> moin
<meoblast001> hi
<meoblast001> where can i get the special SSH for Bazaar?
<lifeless> what special SSH?
<awilkins> meoblast001, AFAIK all the packages now install or cause to be installed sufficient SSH for it to work.
<meoblast001> ?
<meoblast001> lifeless: the one that lets 2 people work on the same project
<meoblast001> without being in the same UNIX group
<lifeless> meoblast001: do you mean the launchpad ssh server?
<meoblast001> yup
<lifeless> meoblast001: because that requires the same UNIX group, by having /everyone/ be in the same unix group and doing its own checking first.
<lifeless> meoblast001: in the launchpad source code.
<meoblast001> i tried downloading launchpad and it tried to screw with my system
<lifeless> meoblast001: yes, it will be a lot of work to reuse that code.
<meoblast001> :/
<meoblast001> does every version control system have this problem :/
<lifeless> yes.
<meoblast001> are there any other SSH servers that can fix my problem?
<lifeless> you haven't described your problem.
<lifeless> so I can't answer that question.
<meoblast001> i have someone who wants to help me on a project i'm doing, this is a personal project so i'm using my Bazaar server
<meoblast001> but i don't want to put him in the same group as me on my server
<meoblast001> well, i don't want him to ahve access to everything i have access to
<lifeless> make a new group?
<meoblast001> but then he can't access my code for this project
<lifeless> chown the project to that new group ?
<meoblast001> then i can't access it
<lifeless> put yourselfin the group too
<meoblast001> then he can access all my projects
<lifeless> how?
<lifeless> they are in a different group
<meoblast001> wait, can a user be in more than 1 group?
<lifeless> of course
<meoblast001> *gasp*
<meoblast001> learn something new everday i guess
<meoblast001> so i just have a group for each project then?
<lifeless> something like that, yes.
<lifeless> you may want to do some reason on this under general unix sysadmin knowledge.
<meoblast001> do you know of any better solutions?
<meoblast001> i don't like to put my personal projects on launchpad because they're really not official, generally just things i make when i'm bored
<gutworth> there's always +junk
<meoblast001> +junk?
<gutworth> you can push stuff to ~yourid/+junk/
<gutworth> like this https://code.launchpad.net/~gutworth/+junk/mod2format
<meoblast001> what if i want it on my server though >.<
<meoblast001> anyways, i'm a hacker, i enjoy experimenting ;)
<Noldorin> hi. does anyone have any suggestions how to use Loggerhead on IIS7?
<lifeless> apparently theres some isapi thing
<lifeless> if you mail the like awilkins, who does that, may see.
<lifeless> he may have blogged about it already in fact.
<lifeless> oh hmm, awilkins does the smart server on windows... but I wouldn't be surprised if he has loggerhead too
<Noldorin> lifeless: ah right, i see
<Noldorin> any chance of getting it on a shared server you think?
<Noldorin> (virtual server i guess)
<lifeless> I don't know what you mean
<Noldorin> lifeless: well my point is that i don't have access to IIS7 directly
<Noldorin> only a control panel - so i can't install arbitrary modules
<lifeless> oh. well I've got no idea there sorry.
<Noldorin> no worries
<Noldorin> lifeless: loggerhead isn't purely web-based, right?
<Noldorin> so it's going to require some hackery
<lifeless> Noldorin: its a python wsgi web server
<lifeless> you should be able to run it up, with some glue code, in any wsgi container
<lifeless> or proxy to it from any proxy capable webserver (such as apache)
<elli222> bzr-gtk makes nautilus crash in debian sid. anyone know a fix?
<Noldorin> lifeless: i see. i'm not really a python coder (as you may remember), so that's probably asking for trouble
<Noldorin> would be cool if someone else has already done it though
<Noldorin> i guess if there's some sort of python web app equivalent to loggerhead, that would be ideal
<lifeless> loggerhead is a python web app
<Noldorin> lifeless: hrrm. probably just showing my ignorance here. i'm an ASP.NET guy mainly.
<Noldorin> and python is installed on my server as well, but i guess i'm not sure exactly what that means
<lifeless> http://www.python.org/dev/peps/pep-0333/
<lifeless> http://code.google.com/p/isapi-wsgi/
<lifeless> (just quickly googled for wsgi python and wsgi python isapi)
<Noldorin> lifeless: yeah, guess i'll just have to ask my web admin then
<Noldorin> thanks anyway
<Noldorin> lifeless: oh, in case you're curious...if you remember those problems i was having with bzr via ftp on my iis server. seems upgrading to iis 7 solved it :P
<lifeless> Noldorin: the crazy file system stuff?
<lifeless> Noldorin: I'm curious if there were any other system changes made at the same time
<Noldorin> lifeless: that's right. where we concluded the ftp server wasn't conforming to the rfc and such
<Noldorin> so am i...
<Noldorin> there was an upgrade to win server 2008 too
<Noldorin> but i wouldn't know anything more
 * lifeless guesses at the OS change being it.
<Noldorin> lifeless: you think? more likely than the version of iis?
<Noldorin> meh. once either gets completely phased out, your problem is solved anyway :P
<lifeless> only another 10 years :)
<lifeless> Noldorin: yeah, much more likely to be OS level - DFS stuff - than IIS
<Noldorin> mm, makes sense i guess.
<Noldorin> lifeless: probably not quite that long, but yeah :P
<Noldorin> at least the problem is rare enough anyway
<elli222> bzr-gtk makes nautilus crash in debian sid. anyone know a fix?
<jelmer> elli222: Did this start recently? I was using nautilus with bzr-gtk installed for quite a while without problems
<elli222> nope its happened whenever i've installed it
<elli222> (in debian sid)
<jelmer> elli222, in that case, no idea - sorry
<elli222> well, what was your idea anyway? it might work regardless
<jelmer> in that case it wouldn't be caused  by e.g. a new version of nautilus being introduced that's incompatible with bzr-gtk
<elli222> it only crashes when trying to go into a directory containing SVN controlled folders. i don't have any native bzr ones.
<jelmer> you should be able to disable the bzr-gtk integration in nautilus, that should at least allow you to use the other bits of nautilus
<jelmer> elli222, does using bzr manually in those folders work?
<elli222> hmm, i'll check
<elli222> i assume bzr pull would be the same as svn up?
<elli222> OK~ thats wrong
<jelmer> no, bzr up
<elli222> that appeared to work
<elli222> yep, it worked
<jelmer> can you try accessing a native bzr branch with nautilus?
<jelmer> you should be able to create one with 'bzr init'
<elli222> that also appeared to work
<elli222> yep, seems like nautilus dosen't like bzr-gtk and bzr-svn
<elli222> looks like bzr-gtk has a spasm with SVN aswell
<jelmer> and what about e.g. "bzr log" in a svn working copy?
<elli222> that works fine
<jelmer> hmm, that's odd
<jelmer> do you have any something likme nautilus-svn installed as well perhaps?
<elli222> nope
<pace_t_zulu_> hey i've got a bzr problem that i can't solve on my own
<lifeless> perhaps you should describe it and ask a question :)
<jelmer> elli222, not quite sure what's happening then
<jelmer> elli222: please file a bug report
<jelmer> elli222, you should be able to work around the problem by uninstalling either nautilus-bzr or bzr-svn if you are not using either of them
<jelmer> *one
<pace_t_zulu_> http://pastebin.com/d42185bf3
<pace_t_zulu_> lifeless, ^
<pace_t_zulu_> when i try to commit i get that error message
<spiv> pace_t_zulu_: run bzr break-lock lp:~jhaitas/gnome-panel/panel-layout
<pace_t_zulu_> spiv, ty
<pace_t_zulu_> later
 * igc out for a few hours -bbl
#bzr 2010-11-29
<vila> hello all !
<poolie> hello vila
<vila> poolie: hi there !
<vila> poolie, spiv: Regarding the doc-new-config mp, thanks for the feedback !
<poolie> hi there
<poolie> thanks for posting it; sorry for the delay
<vila> I don't think it's ready to land in trunk, devnotes sounds more like it, but even there, I think more work is needed before landing, so I will reply to the points raised and put it in wip
<poolie> well, i think you should merge it to devnotes then
<poolie> there doesn't have to be any guarantee that files in that tree are finished or agreed-upon
<poolie> and it makes them visible and shareable
<poolie> (more so than being in just a random wip branch)
<vila> good point, I'll do that then
<MTecknology> So... somebody just asked me "How do I do bzr?"
<MTecknology> any link?
<vila> MTecknology: http://doc.bazaar.canonical.com/en/ ?
<vila> MTecknology: http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/index.html ?
<MTecknology> thanks :)
<poolie> vila, so on the sru
<vila> poolie: So, as maxb raised, on step forward two steps backwards for the Mricro Release Exception, we need testtools included in the main archive to be able to run the tests as part of the build
<vila> poolie: as you pointed out in your reply, this means running the tests externally
<vila> poolie: and making sure testtools is part of main for natty
<vila> poolie: jml said he doesn't care whether python-testtools is part of main or universe, I've started looking at what is needed to get it in main (hopefully not much)
<vila> https://wiki.ubuntu.com/MainInclusionProcess is the relevant page AIUI
<poolie> ok
<vila>  From https://wiki.ubuntu.com/UbuntuMainInclusionRequirements, I think this shouldn't cause any problems
<poolie> meant to do it today; didn't
<vila> ?
<vila> *I* meant to do it Friday but couldn't finish ;)
<vila> well, I didn't get farer than reading the above pages really
<lifeless> vila: farther
<vila> lifeless: haaaa, but of course !
<poolie> *further*
<poolie> or not?
<vila> meh
<poolie> apparently yes, but only barely: http://englishplus.com/grammar/00000213.htm
<vila> I meant: I've started, there is more to do, but I lacked time to continue
<poolie> right, that's what i understood :)
<vila> so literally I think it's farther, but the English usage is probably further, thanks to both of you anyway ;)
<spm> "farer" that's perfect! it even makes sense following the insane rules of english.
<poolie> i think i'll just send a brief note to tb and see what they say
<vila> poolie: ok, can you CC me ?
<poolie> i will
<lifeless> poolie: heh, whoops.
<lifeless> poolie: I've finally logged into netbank and wired you that stuff
<poolie> thanks
<poolie> vila, maxb: just so i don't embarrass myself, it is correct that the test suite is now clean both during a build and from the installed package
<poolie> in 2.2.2
<vila> I haven't checked recently, but that's my understanding
<vila> If that's not the case, it should be fixed
<poolie> vila: sent; we'll see
<vila> ok
<vila> poolie: maverick slave upgraded to 2.2.2, running the test suite there to confirm
<poolie> ok, good night vila
<vila> hehe, good night to you ;)
<lifeless> poolie: http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html
<poolie> nice
<poolie> "Google.... decided the best way to make forward progress was to just turn it on and see whether the internet actually melts down or not"
<poolie> :)
<fullermd> Which do they consider success?   :p
<vila> jelmer: ping
<jelmer> vila: hey
<vila> jelmer: I tried to upgrade lp:~bzr-core/bzr/devnotes which is still in format knitpack6 (bzr 1.9) but it failed because it's still stacked on the old trunk
<vila> there is now a backup.bzr.~1~ there with the previous content
<vila> jelmer: is there a way for me to either restore that and re-stack on the new trunk and upgrade or do I need someone powerful hand behind the scenes ?
<jelmer> vila: It should be possible to use hitchhiker to move the old backup directory and manually fix the stacked-on branch using hitchhiker as well
<vila> jelmer: ha right, made a typo with lftp
<vila> and got a misleading Access failed: Permission denied: "Cannot create '.bzr-broken'. Only Bazaar branches are allowed.
<jelmer> there are particular file names that are allowed
<jelmer> I think backup.bzr* is allowed
<jelmer> as well as .bzr
<vila> yeah, the typo was backup.bzr~2~ instead of backup.bzr.~2~ after .bzr-broken was refused
<vila> so the last period is mandatory
<vila> jelmer: I had to upload a locally patched branch.conf to update the stacked-on repo :-/ After the upgrade failed successfully 8-/
<jelmer> vila: \o/
<jelmer> vila: This is too hard for somebody not familiar with the internals though :-/
<vila> jelmer: yeah, filing a bug asking for --stacked-on parameter for upgrade
<vila> jelmer: exactly my point
<jam> morning vila and jelmer
<vila> hey jam 1
<vila> how was the turkey ?
<jam> pretty good
<jelmer> hey John
<jam> fun to be around my family
<maxb> jelmer: hey. Got a moment to talk about how to run tests on a buildd and the 2.2.2 SRU?
<jelmer> maxb: sure
<maxb> The thing is, the 2.2.2 SRU as is doesn't pass the tests
<maxb> The problem is the tests in 2.2 fail if they are run in a directory containing setup.py and run as root
<jelmer> maxb: I don't think we should be introducing the change to run the tests in a SRU
<vila> maxb: which ones ?
<jelmer> maxb: I fixed the setup.py test a week or two ago in bzr.dev.
<maxb> The one which tests 'setup.py install', and tries to write to /usr/share/apport/
<maxb> This is not a problem in bzr.dev because I ripped out the apport installation from setup.py there with poolie's blessing
<jelmer> maxb: Why did you remove the apport installation?
<maxb> I can dig up the MP, but the summary is "This is never the right thing to do - configuring apport is something for distros to do."
<vila> maxb: I think this test should be skipped if run by root, sounds far too dangerous anyway
<maxb> https://code.launchpad.net/~maxb/bzr/no-install-apport/+merge/38463
<jelmer> maxb: Ah, ok. That's a reasonable approach (though it'd mean we'd have to patch bzr in Ubuntu)
<maxb> vila: To be honest, I'm rather confused why this test is considered valuable at all
<jelmer> maxb: Making sure that "setup.py install" works seems like a nice thing, it's broken in the past.
<vila> maxb: catching up regressions
<maxb> jelmer: The interesting fact to note is that the old apport installation code does *not* install the apport hooks in the bzr ubuntu package :-)
<jelmer> maxb: https://code.launchpad.net/~jelmer/bzr/setup.py-root/+merge/40067
<maxb> Oh, I get it now, you want to catch setup.py install failures in PQM
<vila> maxb: which is why eager tests are bad :(
<jelmer> maxb: But I guess that's been obsoleted by your change.
<vila> maxb: I ran http://babune.ladeuil.net:24842/job/selftest-maverick/ this morning, but not as root, is it the only test failing ?
<maxb> --root is more technically correct anyway
<maxb> vila: checking for my ppa build log...
<vila> meh, wrong url, the correct one is: http://babune.ladeuil.net:24842/job/selftest-maverick-proposed/
<maxb> https://code.launchpad.net/~maxb/+archive/ppa/+build/2064150
<vila> maxb: so I used the bzr from the bzr/proposed ppa
<maxb> That buildlog shows just the one failure
<maxb> Oh, you are testing the run-tests-when-installed part of the puzzle, I am focussing on the run-tests-on-buildd part of the puzzle
<vila> maxb: yes
<vila> maxb: my understanding was that we couldn't use python-testtools during the build so I reverted to the manual check
<vila> oh, so you activate the tests in your private ppa (was wondering where I got my bzr-2.2.2 suddenly ;)
<maxb> vila: I'm testing in ~maxb because ~bzr has a newer testtools than the primary archive, so wouldn't be a realistic test
<maxb> Also, I am running the tests in ~bzr, but with some tweaks to how they are invoked in debian/rules, which I haven't managed to convince jelmer of the rightness of for Debian&Ubuntu yet.
<bzr> Hi--I'm having some trouble with pushing from bzr explorer.  Is this the right place to be?
<bzr> Is anyone here?
<jelmer> bzr: hi
<bzr> Hi!
<jelmer> bzr: I'm afraid I don't really have much experience with bzr-explorer. What's the problem?
<bzr> I seem to have set my username wrong--I'm George from that tricky bzr push bug.
<bzr> When I try to push, I get:
<bzr> Run command: bzr push
<bzr> Using saved push location: https://george@nanotech.com@pl3.projectlocker.com/nano/www/svn
<bzr> bzr: ERROR: Please upgrade your Subversion client libraries to 1.5 or higher to be able to commit with Subversion mapping v4 (current version is (1, 4, 4, ''))
<bzr> (The bug was https://bugs.launchpad.net/bzr/+bug/681285?comments=all)
<ubot5> Launchpad bug 681285 in Bazaar "Can't push my changes in Bazaar (affected: 1, heat: 6)" [Undecided,Incomplete]
<jelmer> bzr: you're using bzr-svn trunk?
<bzr> I think so.
<bzr> Is that:
<bzr> svn 1.0.3
<jelmer> your copy of subvertpy was linked against an old version of libsvn
<bzr>    Support for Subversion branches
<bzr>    /Library/Python/2.5/site-packages/bzrlib/plugins/svn
<bzr> How do I fix that?
<bzr> I tried rebuilding bzr using MacPorts, but that didn't work at all...
<jelmer> bzr: you can either recompile subvertpy against a newer libsvn or install bzr from another source
<bzr> Can I recompile just subvertpy using MacPorts?  Or is there another way to do that?
<bzr> What other sources can I use to install bzr?
<jelmer> bzr: I'm not sure (I've never really used a Mac)
<bzr> Hm.
<jelmer> bzr: I think the other alternative is the installer on the bzr site
<Tak> macports is a quick path to brokenness
<dash> nah
<bzr> I used the installer from the bzr site.
<bzr> This one:
<bzr> http://edge.launchpad.net/bzr/2.2/2.2.1/+download/Bazaar-2.2.1-OSX-10.5-1.dmg
<bzr> Right?
<dash> yeah you can't use the installer if you want to use macports stuff
<bzr> I've also tried: http://launchpad.net/bzr/2.2/2.2.0/+download/Bazaar-2.2.0-OSX-10.5-1.dmg
<bzr> Shouldn't those have a more up-to-date svn version?
<bzr> Do I want to try: http://launchpad.net/bzr/2.3/2.3b3/+download/Bazaar-2.3b3-OSX-10.5-1.dmg
<bzr> ?
<jelmer> I've been using 2.3 for quite some time without problems
<bzr> Okay, I guess I'll try that then...
<bzr> Is it possibly that I'm on OS X 10.5?
<bzr> Same error on bzr 2.3b3.
<poolie> hi all
<poolie> hm, that's confusing :)
<bzr> Run command: bzr push
<bzr> bzr: ERROR: Please upgrade your Subversion client libraries to 1.5 or higher to be able to commit with Subversion mapping v4 (current version is (1, 4, 4, ''))
<jelmer> 'morning poolie
<bzr> Hi poolie.
<bzr> I just tried downloading and installing the py26-subvertpy via MacPorts.  Same error.
<jelmer> bzr: I'm not sure what's going on there. It could be that you end up using the system svn libraries or something like that
<bzr> My system svn claims to be 1.6.9.
<maxb> bzr: Perhaps you could first confirm where this Subversion 1.4.4 installation is - the system one? Something else?
<bzr> (from svn help)
<bzr> It's not the system one.
<bzr> I really don't know where it is.
<bzr> Is there any way to get bzr to tell me where it's getting its svn?
<poolie> bzr set 'BZR_PDB=1' in the environment
<poolie> then when it/if it crashes, type 'pp sys.modules()'
<bzr> Where do I type pp sys.modules()?  And will it work if bzr doesn't crash?
<bzr> It just fails with:
<bzr> Run command: bzr push
<bzr> Using saved push location: https://george@nanotech.com@pl3.projectlocker.com/nano/www/svn
<bzr> bzr: ERROR: Please upgrade your Subversion client libraries to 1.5 or higher to be able to commit with Subversion mapping v4 (current version is (1, 4, 4, ''))
<maxb> If it does not crash, you will not get the prompt at which you would type the pp command
<bzr> Hm.
<bzr> Is there a way to get it to crash?
<maxb> bzr: OK, so I have checked the bzr-svn source code, and the 1.4.4 being reported is the version of Subversion that the subvertpy python extension was compiled against
<bzr> Thanks.
<bzr> So...I need to upgrade subvertpy?
<bzr> Shouldn't updating subvertpy via MacPorts have worked?
<maxb> I have zero Mac knowledge
<maxb> But certainly, you do need to rebuild subvertpy against a newer subversion
<bzr> Who would know how to do that?
<maxb> I have to go now, sorry.
<bzr> I have to go too.  More anon.  Thanks!
<rootart> hello to all
<rootart> I have a question about the bzr hooks and signals, how we can check on server side that new branch is created?
<rootart> I found this hook post_branch_init but I'm not very familar with API so, can someone suggest how to work with this ?
<spiv> rootart: have you seen http://doc.bazaar.canonical.com/development/en/user-guide/hooks.html ?
<spiv> rootart: the object passed to the hook is http://people.canonical.com/~mwh/bzrlibapi/bzrlib.branch.BranchInitHookParams.html
<rootart> spiv: yes, I saw that, for now I think I can get the action, but now I have over one, I have a repository 'repo', I want create a branch 'b1', I am getting the new one branch object, but how can I know what repository this branch is a copy of ?
<rootart> spiv: thanks again, that is done I think
<rootart> spiv: now have only this last one question
<spiv> rootart: if you have a branch object, the repository is 'your_branch.repository'
<poolie> hi maxb, spiv, jelmer
<dOxxx> evening
<mgz> ...if I try and delete the bug watch from bug 682600 I get OOPS-1794O2309
<ubot5> Launchpad bug 682600 in Bazaar "Fix RandomPool Depreciation Warning from pycrypto (affected: 2, heat: 262)" [High,Confirmed] https://launchpad.net/bugs/682600
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1794O2309
#bzr 2010-11-30
<spiv> mgz: ooh: IntegrityError: update or delete on table "bugwatch" violates foreign key constraint "bugwatchactivity_bug_watch_fkey" on table "bugwatchactivity"
<mgz> spiv: does that need a bug filing against something or is there one already?
<mgz> https://bugs.launchpad.net/malone/+bugs?field.searchtext=IntegrityError
<mgz> nothing similar looking there.
<spiv> I *think* the malone team will take care of that for you, I'm pretty sure the OOPS reports are routinely analysed and turned into bugs.
<spiv> But there's no harm in filing a bug with the OOPS ID
<spiv> It might even speed the process.
<poolie> hi mgz
<mgz> hey poolie.
<mgz> hm, some dupe finder on file does something useful for once and turns up bug 575911
<ubot5> Launchpad bug 575911 in Launchpad Bugs "Trying to delete a bug watch results in a non-OOPSing IntegrityError (affected: 2, heat: 6)" [Medium,Fix released] https://launchpad.net/bugs/575911
<mgz> I'm guessing the fix wasn't intended to make it an OOPSing IntegrityError
<poolie> haha
<poolie> hi spiv, how are you?
<spiv> poolie: pretty good.  About to submit a merge proposal for bug 309682, then I was thinking of starting on the HPSS request jam's shallow branch mail talked about.
<ubot5> Launchpad bug 309682 in Bazaar "tags are copied but their revisions may not be (affected: 0, heat: 8)" [Low,In progress] https://launchpad.net/bugs/309682
<spiv> poolie: so, doing better than the Australian cricket team :)
<poolie> hahaha
<poolie> spiv that sounds good to fix
<poolie> i'm a bit tired and struggling through my mail and todo list
<poolie> i might stop it and try some easy bugs soon
<spiv> Hmm, as usual, reviewing my diff before I'm about to submit it I think âI could add more tests...â
<poolie> heh, i didn't think about spiv and cricket until just now :)
<abentley> spiv: Since you're patch pilot and you like incremental diffs: https://code.launchpad.net/~abentley/bzr/is_executable/+merge/42197
<spiv> heh
<spiv> actually that was last week, vila needs to update /topic I guess...
<spiv> But sure, I can take a look.
<spiv> I wonder a little about changing the behaviour in a stable branch
<spiv> Even if it better behaviour.
<abentley> spiv: Well, that's fair.
<abentley> spiv: But it's buggy behaviour, too.
<abentley> spiv: It causes iter_changes to report bogus data.
<abentley> spiv: We can resumit it for lp:bzr if you think that's best.
<poolie> thanks for proposing that, abentley
<spiv> Buggy behaviour that was codified in tests... so buggy in a way that perhaps isn't immediately obvious, so it does seem pretty plausible some plugin might be depending on it, even accidentally.
<poolie> spiv, who is pp now?
<poolie> and i wonder if you should send a brief report?
<spiv> I'm really unsure how large the risk is here.
<spiv> It's an "unknown unknown", I guess ;)
<spiv> poolie: vila I think, and good point...
<abentley> poolie: np.
<spiv> abentley: if landing in lp:bzr is good enough for Launchpad to benefit from the fix, then my inclination is to do that, just to be conservative with our stable releases.
<abentley> spiv: Okay, I'll retarget it to lp:bzr, and then we'll spin a bzr-2.2.2-launchpad-1 for ourselves.
<abentley> spiv: It's not, but we can diverge until we get on the 2.3 series.
<spiv> *nod*, well, it at least helps a bit to have an approved patch to backport to your diverged 2.2.
<abentley> spiv: true.
<poolie> the general plan was to have lp run bzr 2.2 releases, until we get to 2.3rc or the last beta
<poolie> i'll read it too
<abentley> spiv, poolie: resubmitted as https://code.launchpad.net/~abentley/bzr/is_executable/+merge/42203
<poolie> i'd really rather not have lp run its own branch if we can avoid it
<abentley> spiv, poolie: And resubmitted once more, because 2.2 has unmerged revisions: https://code.launchpad.net/~abentley/bzr/is_executable/+merge/42204
<poolie> abentley, i'm so glad you added resubmit&retarget
<abentley> poolie: Cool.
<abentley> poolie, spiv: I can do a more conservative fix to 2.2 if I adjust the is_executable callsite.  Then it would only affect PreviewTree._comparison_data.
* 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: jam | 2.2.2 has is out <http://bit.ly/bzr222rn> (rm vila)
<poolie> spiv did you want to tweak anything in https://code.launchpad.net/~eric97/bzr/fix-merge-docs/+merge/40671
<spiv> poolie: no, it looked good to go except for the contributor agreement
<dmuir> is branching supposed to be fairly immediate?
<dmuir> or am I missing something in my setup?
<bob2> is that an LP question? or are you branching locally?
<dmuir> I've got a shared repo, with a svn mirror in a branch called mainline
<dmuir> branching locally
<dmuir> when I do `bzr branch mainline new-feature`, it seems to sit there for several seconds
<dmuir> Yes, a few seconds isn't killing me... but this is for repos with fewer than 1000 revs
<dmuir> hmm, maybe it's just a caching issue
<dmuir> when I make multiple branches, it goes pretty quick
<poolie> dmuir: it could be a disk cache thing?
<poolie> do you get a progress bar?
<dmuir> yeah, with a counter of some sort x/y with x increasing until it reaches y
<poolie> and what text?
<dmuir> build phase: adding file contents
<spiv> Ah, that's possibly related to #607298
<spiv> bug 607298
<ubot5> Launchpad bug 607298 in Bazaar "Slow branch creation with cold disk cache (affected: 1, heat: 3)" [Medium,Fix released] https://launchpad.net/bugs/607298
<spiv> Which is fixed in the 2.3 branch, but wasn't in 2.2
<dmuir> ah, cool
<dmuir> something weird though. when I branched bzr.dev, it was immediate, even though I hadn't made a branch in that repo in over a month
<dmuir> oh, never mind
<dmuir> the branch I had for bzr was a no-trees branch
<dmuir> when's 2.3 due?
<dmuir> trying to remember what the release cylce was...
<dmuir> oh, I think I found it
<dmuir> http://doc.bazaar.canonical.com/developers/cycle.html
<poolie> dmuir: roughly february
<dmuir> cool, looking forward to it :-)
<lifeless> poolie: spiv: testtools now has some list/load-test functionality, you may be able to delete some more code from bzr
<poolie> great
<mkanat> poolie: Hey.
<dmuir> eol rules are still only global right?
<dmuir> I've got a situation where when I make changes to a file checked out from an svn repo, the whole file gets marked as modified, even though I've only changed one line. I'm assuming that an EOL conversion is to blame
<dmuir> does bazaar apply any automatic conversions or is "exact" the default?
<dmuir> spoke too soon. manual says exact is the default
<dmuir> so maybe it's my ide that's done the conversion...
<fullermd> It's not unheard of for editors to do line ending conversions.  IDE's are probably another step more likely than plain-old-editors.
<dmuir> ah, I think I've found the culprit
<dmuir> I think it's from doing a conflict resolution with meld
<vila> hi all
<spm> hey vila!
<vila> ha ! New kernel, reboots all over the place incoming
<vila> spm: hey !
<dmuir> I'm full of questions today.... what's the quickest way to revert files matching a pattern?
<dmuir> `bzr revert */_notes` does work
<dmuir> d'oh, I mean *doesn't* work
<mkanat> dmuir: ls -d1 */_notes | xargs bzr revert   ?
<mkanat> dmuir: That's just off the top of my head.
<dmuir> mkanat: I'm getting: ls: cannot access */_notes: No such file or directory
<mkanat> dmuir: Then you have no such file or directory?
<dmuir> ah, good point :-)
<mkanat> :-)
<dmuir> they're files that have been deleted
<mkanat> Ahh. I dunnow, then.
<dmuir> I guess I need to use bzr ls
<dmuir> wohoo!
<dmuir> bzr status | grep _notes | xargs bzr revert
<mkanat> Ah, cool. :-)
<mkanat> Good idea.
<dmuir> thanks for pointing out xargs, didn't know about that one
<mkanat> dmuir: Welcome. :-)
<Tiriel> Hi!
<Tiriel> I'm new to bazaar, and I read on the website that it has some limitations with XML and binary files
<Tiriel> How bad is this? because these are mainly the kind of files I'll be working with
<mkanat> Tiriel: Where on the website does it say that?
<mkanat> Tiriel: The only limitations that I can think of are that working with enormous binary files can be slow and use a lot of RAM.
<Tiriel> well, let me check
<Tiriel> I'm pretty sure I just read it, but I can't remember where
<Tiriel> Ah! here http://wiki.bazaar.canonical.com/TheBigPicture
<Tiriel> " It is less effective with tree-structured data (e.g. XML), and is most limited in dealing with opaque binary files (e.g. Microsoft Word documents)."
<spiv> Tiriel: well, the builtin merge is designed to work well with text files
<spiv> Tiriel: that's what that's referring to
<spiv> Tiriel: e.g. if you use "bzr merge" and the two branches have both changed the same MS Word document, bzr will only be able to say "there are conflicting changes, here are the different versions of the file, it's up to you to resolve that"
<Tiriel> Oh! is that it?, I don't think that will be much of a problem then
<Tiriel> see, the plan is to do some translation work, so I don't think there will be a lot of merging
<spiv> (and bzr allows plugins to extend its merge capabilities, so if you have tools that can help with automatic merging you can quite likely hook them into bzr with a plugin)
<Tiriel> that's also good to know
<Tiriel> I was fearing this issue would be a major stopper
<peitschie_> Tiriel: sorry to butt in (i only just joined)... are you wondering about bzr merge capabilities on xml docs?
<Tiriel> Well, it boiled down to it, I was asking about the broader limitations of bzr when dealing with XML and binaries
<Tiriel> all insight is appreciated
<peitschie_> sounds good :)
<peitschie_> just wanted to chip in that most xml merges I've done seem to be going well
<spiv> Tiriel: I suggest just trying it out: it's very quick and easy to make a branch of some files, commit a few revisions, etc.
<Tiriel> Well, I'm on the research stage atm, I haven't deployed anything just yet
<Tiriel> I'm trying to figure out which tool suits best, and bazaar looks very good, but I was concerned about this since XML will take most of the work
<peitschie_> tiriel: r u expecting to do merging on the binaries at all?
<Tiriel> not really
<Tiriel> in fact I'm not expecting to do much merging at all
<Tiriel> but you never know...
<peitschie_> tiriel: cool.  with the xml things, does everyone use a tool when editing it btw?  i.e., the format will b consistent across edits?
<Tiriel> yes, I plan to stablish a standard slang
<Tiriel> as I said this is all in the planning stage, nothing is sure just yet
<peitschie_> tiriel: that will serve well :).  As I mentioned earlier, we've been running an 18month old project on bzr (migrated onto bzr about 8months ago) and so far have found xml merging quite nice... once we established everyone using tabs!
<Tiriel> nice, that leaves me at ease.
<Tiriel> On a totally different matter, is it possible to have some HTML code or something to pull the latest version of a file in bazaar and display it on a webpage
<Tiriel> I don't really need the details, I just want to know if it's possible
<peitschie_> bzr upload plugin?
<mkanat> Tiriel: Depending on what you need, you could just use loggerhead.
<peitschie_> that is helpful to push via ftp or similar
<Tiriel> I really don't know what I need right now :(
<Tiriel> I was thinking that I may want a website where the contents are grabbed from whatever is in bazaar
<Tiriel> i.e. looking for the files in bazaar instead of /htdocs or whatever
<Tiriel> maybe it is as easy as serving bazaar through apache and have the website look in there?
<peitschie_> i'd b looking t bzr upload + cron job 4 that personally :)
<Tiriel> as in pushing the head of bazaar's repo to the website with cron?
<peitschie_> yup
<Tiriel> Why would pushing from bazaar be better than pulling from the website?
<Tiriel> not saying that pulling is better, just trying to understand your approach
<peitschie_> brb :)
<mkanat> Tiriel: Pushing wouldn't require a lot of work from bzr on every web hit.
<mkanat> Tiriel: If you're talking about grabbing a file from a repo on every hit, that is.
<Tiriel> Very good point, I hadn't thought of that
<Tiriel> Also, by pushing we can control wich versions get published on the site!
<Tiriel> and it is less coupled. WTF was I thinking!
<Tiriel> Ok, I'm going to get some fresh air and settle the ideas, thanks to all
<peitschie_> tiriel: pretty much my reasons match mkanat... less work to push it every once in a while than pull every web hit
<Tiriel> yup, pushing does look like a much better idea, I hadn't thought it through
<mkanat> Heyyy folks. :-) I need a review for this loggerhead merge: https://code.launchpad.net/~mkanat/loggerhead/view-default/+merge/42222
<vila> maxb: qbzr and bzr-explorer needs to be upgraded in bzr/proposed right ?
<maxb> ideally, yes
<maxb> mkanat: Hi. The NEWS file on loggerhead trunk is incorrect, the top entry is under th 1.18 heading, but it actually only happened on trunk
<mkanat> maxb: Oh yeah? Lemme go look.
<mkanat> maxb: Ohhhh, you're right.
<mkanat> maxb: Fix Committed.
<maxb> thanks :-)
<mkanat> NEWS also needs some serious updates for dev.
<vila> ghaaa, is there a way to explore the ubuntu package branches ?
<jml> code.launchpad.net/ubuntu?
<vila> bzr info goes into a 'Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored' dance when tried against a non-existing one :-/
 * vila kisses jml
<vila> ...almost : https://code.launchpad.net/ubuntu/hardy/qbzr
<jml> vila: https://code.launchpad.net/ubuntu/+source/qbzr
<vila> jml: haaaaa :)
<vila> thanks :D
<vila> https://code.launchpad.net/ubuntu/+source/qbzr/+branches is the one I was after, pfew
<vila> makes sense
<johnf> Tricky questions around merges. I've been asked to compile some stats on the lines of code changed every day for a code base.
<johnf> The metric I've chosen at the moment is just using a diff -c on each commit and pushing that through diffstat
<johnf> this tree is semi complex with lots of feature branches etc.
<johnf> which diverge and then remerge
<johnf> so for standard commits I think this is fine. But what about a commit that is a merge. Am I going to end up double counting changes?
<vila> johnf: a commit including a merge will produce a diff against its left parent, so it will summarize all the diffs in the right parent(s) *and* whatever modifications made to resolve the conflicts
<vila> it really depends on how you want to interpret the resulting stats and whether you drill down into the merges...
<johnf> vila: yeah not the simplest task I've ever been given.
<vila> johnf: if you don't use append_revions_only then it becomes even more.... interesting
<johnf> At the moment I'm tempted to ignore the merge revisions in my stats and assume that conflict changes were small
<vila> one could argue that a merge commit is more work than a regular one though...
<johnf> vila: Yeah agree but I don't see any easy way to avoid the double counting
<vila> may be you shouldn't avoid it
<vila> that's why I said it depends on what you want to interpret, I'm not sure the raw numbers are meaningful, but how they evolve over time may be more meaningful
<vila> maxb, jelmer: qbzr and bzr-explorer should be upgraded in debian first or can we update the bzr/proposed ppa directly ?
<vila> both debian and the ppas are at qbzr-0.19.2-1 and we want 0.19.3 and for bzr-explorer that's 1.1.0 /1.1.2
<jelmer> vila: hi
<vila> jelmer: hey :)
<jelmer> vila: it'd be nice to upgrade debian first, but it's not necessary
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | 2.2.2 is out <http://bit.ly/bzr222rn> (rm vila)
<vila> maxb: so, should we start the SRU with bug #659590 or do you still have pending changes regarding running the tests during build (or not) ?
<ubot5> Launchpad bug 659590 in bzr (Ubuntu) "dput sftp upload hangs after all files successfully uploaded (affected: 1, heat: 72)" [Undecided,New] https://launchpad.net/bugs/659590
<maxb> vila: I have pending changes
<maxb> Hmm
<maxb> Except
<vila> maxb: ok, so we shouldn't copy the package from proposed to stable either right ?
<vila> maxb: no pressure, just trying to know where we are
<maxb> If we are now decided to *not* run the testsuite on the official buildd, the unresolved discussion between me and jelmer on how to run it does not matter.
<maxb> Thus, I should back out the "run testsuite during build" changes from the sru branch
<maxb> On the matter of the bzr/proposed package, I regard that as OK to promote
<vila> maxb: that's how I read the reply from pitti regarding MRE/SRU: run the tests after installation
<maxb> The indecision remains only on the manner of how to run tests during build
<vila> maxb: ok, so I just copy the bzr one and qbzr and bzr-explorer will be upgraded later
<maxb> works for me
<vila> maxb: where is that defined ? (running the tests)
<vila> maxb: I've branch'ed all the relevant ones (hopefully)
<maxb> On the SRU: We still have an issue that to technically comply with the SRU procedure we need 2.3b4 in natty first. (You aren't supposed to fix things in maverick until you've fixed them in natty)
<vila> grrr, I will get this right on day, I willl !
<vila> ok, so that's postponed until 2.3b4, I'll add a bug task there...meh how ?
<vila> ha, right, the other url
<maxb> lp:~maxb/ubuntu/maverick/bzr/sru is now updated to remove the "run tests during build" changes, rendering it a straight merge of the new upstream version only
<maxb> <vila> maxb, jelmer: qbzr and bzr-explorer should be upgraded in debian first or can we update the bzr/proposed ppa directly ?
<maxb> Whoops, missed that
<vila> maxb: so this sru branch should now be merged into the maverick package branch and from there in the others ?
<maxb> What do you mean by maverick package branch?
<vila> lp:ubuntu/maverick/bzr/bzr-ppa
<jelmer> vila: it'd be nice to upgrade debian first, but it's not necessary
<maxb> vila: There is no need, I have already merged 2.2.2 there.
<vila> jelmer: but *how* should I do that ? (If I even can)
<maxb> jelmer|vila: Updating Debian first is convenient for those packages without a PPA packaging branch - I have a script (which I really need to publish somewhere) for one-line PPAizing and uploading of the debian.dsc
 * vila 's head spins
<vila> maxb: so this sru branch will only be needed when we want to create the bzr package in maverick-proposed ?
<maxb> It does not help that we are currently having two interleaved conversations :-)
<vila> :)
<maxb> OK, so my sru branch is where I have been preparing the source that I eventually want uploaded to maverick-proposed
<maxb> To further confound matters, it does NOT share ancestry with lp:ubuntu/maverick/bzr
<vila> yeah, I'm mixing that with the ppas, hence my confusion
<vila> ha, branching it right now
<maxb> This is because the Debian packaging branch is sane and manually maintained, and based on bzr.dev, but the "official" ubuntu packaging branches are a parallel import by the automated UDD importer
<maxb> So, my recommendation is to ignore the existence of the UDD imported branches for bzr, for now
<vila> ...or use them to fix the parallel imports bugs
 * vila ducks
<jam> morning all
<vila> jam: hey !
<mgz> hm, stopped snowing again.
<jam> vila: can you wait 10s and then say my name again, my audio pings don't seem to be working.
<mgz> jam: you got any insight on bug 680935?
<ubot5> Launchpad bug 680935 in Bazaar "repository on flash bzr pack error (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/680935
<jam> well, that worked
<vila> jam: say what ?
<vila> :D
<jam> mgz: my line numbers are slightly off, but that looks to be a line like:
<jam>                     self._content = zlib.decompress(z_content)
<jam> I don't see how we can use the zlib interface any differently than that.
<jam> looking at the faq, it would hint that a buffer is too small or too large.
<mgz> yeah, also my thought, would be a python bug.
<vila> mgz: hello !
<jam> For example, 'z_content' could be empty
<jam> or it may decompress to something larger than the default buffer size
<mgz> or just corruption of some interesting sort.
<vila> maxb: so the parallel import is about .bzrignore and the debian dir but the others ?
<jam> mgz: zlib.decompress('') does, indeed, give that error, though.
<jam> not that I would specifically understand why we would get '' here
<mgz> hey vila!
<vila> jam,mgz: lifeless remotely diagnosed a *memory* hardware issue with beuno a couple of.. weeks ago, I'm not sure the message was exactly the same though, may be they remember better than me
<jam> vila: IIRC, that was different data corruption, but the data on disk seemed fine. There were 3 bit errors in memory from what poolie said, which would be an indication of how ECC mem would fail to find it.
<mgz> we generally get zlib errors from on-disk corruption, but normally not this one.
<jam> (ecc can often fix 1, find 2, but would fail >=3)
<weigon> if I have a workingdir instance, how can I find out what shared repo it is from ?
<weigon> ... using bzrlib
<jam> weigon: bzr info? tree.branch.repository?
<jam> tree.branch.repository.base ?
<mgz> anyway, what would we need to progress on that bug? a copy of the repo?
<maxb> vila: Um, no the parallel import is about the entire upstream source being imported as historyless tarballs, not derived from bzr.dev
<weigon> jam: yep, thanks
<vila> maxb: I don't get it. If I do 'bzr log --show-ids -v -l1 bzr' in both branches (sru and bzr-ppa), I have the same file-ids
<maxb> vila: Correct
<maxb> Now do it in lp:ubuntu/maverick/bzr and see the difference
<vila> parallel import is about having different file-ids for the same paths AIUI
<maxb> Yes
<vila> oh
<vila> ouch
<vila> maxb: ok, I won't look at that today then :-/
<maxb> vila: Sorry, what?
<maxb> AFAIK the next job is making 2.3b4 land in natty
<maxb> not anything to do with the branches
<vila> maxb: right, I was referring to the parallel import bugs :)
<vila> maxb: 2.3b4 is next Thursday
<maxb> ok, that's not too bad
<abentley> jam, do you still feel you need info on https://code.launchpad.net/~abentley/bzr/is_executable/+merge/42197?  Do you want me to make a more conservative change?
<RenatoSilva> does the last part of revid (like xirl6fr0zipbof4h) is a unique identifier?
<RenatoSilva> I want to add binaries to the branch with namestelling what exact revision they match
<maxb> That was quite impatient
<vila> :)
<jam> abentley: there are a couple of bits. I mostly was hoping to get discussion from others about what is "stable api". But also, I'm not sure whether None isn't more accurate a term for executable on symlinks and directories
<jam> from what I can see, WT and RT both return None
<jam> and PreviewTree returns what is in the basis tree
<jam> MemoryTree is the only one that always returns IE.executable, which defaults to Falso
<jam> False
<abentley> jam, no, it's only RT according to the per-tree tests I introduced.
<jam> abentley: your branch also changed WT
<jam> at least, WT_4
<abentley> jam, My branch also changed DirStateRevisionTree.
<jam> ah
<abentley> jam, None is also inconsistent with our other APIs.
<jam> right, WT.is_executable returns bool(<is_file> and S_IEXEC)
<jam> abentley: the fact that most directories have the X bit set, but are "False" for executable seemed odd to me
<abentley> jam, RT._comparison_data says False, not None for RT.
<abentley> jam, On directories, that bit means they can be searched.  It doesn't mean that they're executable.
<abentley> jam, IMO, directories and symlinks are never, themselves, executable, because they're not files, and you can't execute things that aren't files.
<vila> abentley, jam: I'm very tempted to say that if dirs and symlinks are never executable, then executable should not even been *defined* for them, we don't define symlink target for files or directories either. But since that would be far more invasive to get there, I think None is more precise than False to convey "never"
<vila> s/been/be/ ?
<jam> vila: that was sort of my feeling as well. that said, False does seem a bit more consistent with the current implementations.
<jam> the fact that IE.executable is defaulted do False, etc
<abentley> vila: I don't see value in having a tri-value where a boolean will do.  There is only one answer to the question "can this be executed"?  And there's no value I can see to a programmer, expecially since None is not clearly distinct from False.
<vila> there is a value is using None to mean: this make no sense
<vila> using False implies True is valid
<abentley> vila: What is the value?  How will this aid my bzrlib programming?  And does the value offset the cost of having to deal with a third potential return value, and the inability to treat the value as a boolean?
<vila> I don't see the value in having a boolean where none is needed either, at least 'None' carries this
<vila> It helps to see None more than to see False as you could then realize that is_executable shouldn't be defined for a dir or a symlink whereas a newcomer may wonder: 'Wait, it's False, when will it be True ?'
<vila> And *that* AIUI is why executability changes were wrongly triggered
<abentley> vila: I am saying boolean values are easier for calling code to deal with.  They can be used in conditionals directly.  They can be serialized using standard machinery.
<abentley> When were executability changes wrongly triggered?  do you mean in the incremental diffs?
<vila> wow, wow, what are you talking about here ? All the code exist to handle this *today* no ?
<vila> isn't it what the bug you're fixing about ?
<abentley> vila: No, I think a lot of the code that exists today treats it as a boolean, and mostly gets away with it.
<abentley> vila: The PreviewTree code treated it as a boolean, and that's the cause of the incremental diff problems.
<vila> so all is left to decide is whether None is better than False because we won't un-implement is_executable for dirs and symlinks
<vila> then why not teach this code that is_executable can be None ?
<abentley> vila: Because a) it's the wrong value b) implementing that decision everywhere would be a lot of code and API changes.
<vila> I can understand that it's *easier* to fix it the way you did, but saying that False == None is a bit... different
<abentley> vila: who's saying False == None?
<vila> you
<vila> executable is never defined for dirs/symlinks, you implement it as False
<abentley> vila: Most assuredly not.  If I tell you that a directory is executable, is that a true statement or a false statement?
<vila> MU :D
<abentley> vila: No, it's not MU.  Even if you argue that the state of a directory's executability is undefined, my statement is false.
<vila> well, if you agree that your statement is false, then all is well :)
<abentley> vila: Indeed, because that means that directories are not executable, and the answer to the question "is this directory executable" is "false".
<abentley> vila: It's not a question of "has the executability of this directory been  toggled to the False state", it's a question of "can this directory be executed".
<abentley> vila: In any case, I hold that a two-value system is less complicated than a three-value system, and therefore in the absence of clear evidence that a three-value system provides a superior API, I believe we should opt for a two-value system.
<vila> ha ! That's more convincing, between a zero values (no implementation for dirs/symlinks), 2 or 3 values, then yes, the 2 values being less expensive than the 0 one, let's do that !
<abentley> vila: yay!
<sqwishy> In bazaar, is there a nice way to destroy the history of a file without making your branch messed up and incompatible?
<dash> sqwishy: first, build a time machine
<sqwishy> dash: Do you know which channel I could go to to get help with that?
<dash> sqwishy: there was a time traveler convention at MIT, 7 May 2005
<dash> sqwishy: you might try there/then
<dash> sqwishy: anyway no, you can't change history
<dash> (unless you do it the hard way)
<jelmer> well, technically bazaar supports having a file without history
<jelmer> in other words, the history would still exist.. the repository just would just forget about it
<jelmer> (note that this is different from changing history, which is not possible)
<poolie> hi all
<poolie> hi jam?
<jam> hi poolie
<poolie> hi there
<poolie> vila is just talking to me, then we could talk if you like
<jam> vila: go to bed :)
<vila> jam: hehe, soon soon
<poolie> vila, so shall we do 2.3b4 this week?
<vila> given that we need to do that to comply with the SRU policy that will allow us to release 2.2.2 into maverick-proposed, yes :D
<vila> also, 'rmadison bzr' says that natty only got 2.3b2 so there is something to be done there too
<poolie> work out where it's stalling
<vila> jam: by the way, did you see bug #683307, I wonder if there is an lp bug there (I haven't checked but it's weird to have another mx recursion depth )
<ubot5> Launchpad bug 683307 in Bazaar "Bazaar crashes on push (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/683307
<jam> vila: that is stacking-on-self-causes infinite recursion
<poolie> i thought so
<jam> I've seen 3 of those in the last couple of days, not sure why
<vila> jam: that's my point, especially since for the previous two ones you found an almost empty branch.conf on lp
<vila> jam: if the third has the same file...
<jam> vila: there isn't really a reason to have anything else there.
<jam> I don't know if people are renaming
<jam> or creating the dev focus first
<jam> or we have a regression with the "don't stack on self if self is the default target"
<poolie> that's possible
<poolie> we should trap this and give a sensible warning
<vila> poolie: regarding bug #583667, I think we're not on the same page, I mentioned BZR_LP_XMLRPC_URL only for xmlrpc usages,
<ubot5> Launchpad bug 583667 in Bazaar 2.3 "bzr talks to edge API servers to propose merges (but not for lp: url lookups) (affected: 1, heat: 10)" [High,Confirmed] https://launchpad.net/bugs/583667
<vila> I should clarify that it doesn't apply to launchpadlib for which there is no env var
<vila> poolie: would this address your concerns ?
<poolie> if setting that variable will fix older clients (including older lplib) then that's fine
<poolie> hm, scratch that
<poolie> i think putting this in the bzr news is the wrong place
<poolie> perhaps we should put a post on blog.l.n, or append to that post
<jam> vila: interesting, tart-sleepymate is correct, but the branch it is stacked on is broken
<jam> http://bazaar.launchpad.net/~sleepynate/tart/tart-sleepynate/.bzr/branch/branch.conf
<jam> http://bazaar.launchpad.net/~andreesie/tart/vanilla/.bzr/branch/branch.conf
<poolie> saying, for bzr, you need to either upgrade to 2.0.8, 2.1.x, etc
<jam> vila: I wonder if the +branch/ change to bzr+ssh is confusing us
<poolie> or, set BZR_LP_XMLRPC_URL
<jam> so that we see the stacking location as +branch/tart at one point, but end up setting it to ~/andreesie/tart/vanilla at another point
<poolie> and we need to check whether setting that will fix all interactions with lp, or only lp: urls
<jam> thumper: ^^ some questions about your changes to the lp: resolution stuff
<poolie> lifeless: ^^
<lifeless> hmm?
<jam> lifeless: I think poolie is pointing you to the BZR_LP_XMLRPC_URL stuff
<lifeless> whats that for?
<lifeless> users have no use case for controlling the end point; only launchpad developers testing new XMLRPC releases need to do that.
<poolie> lifeless: vila's proposal had a description of how to reconfigure old bzr releases assuming you won't or can't upgrade
<poolie> even to a bugfix release from the same series
<poolie> which is a bit of an edge case
<lifeless> we're not going to remove edge until it has no users
<lifeless> the goal is to drive the userbase to zero as quickly as possible.
<poolie> right
<vila> poolie: right, either they upgrade and they don't care or they don't and they can't read the NEWS
<lifeless> s/no/very very few/
<poolie> vila, that's my point
<vila> poolie: re-phrasing to make sure I got it ;)
<poolie> if there are folks who won't upgrade, we'll keep supporting them until their hardware dies or whatever
<vila> who's 'we' here ?
<vila> edge.lp.net
<poolie> yes
<poolie> we=Robert :)
<vila> if edge disappears they'll come to us (bzr), we say them: upgrade, they say: we can't, we say: try BZR_LP_XMLRPC_URL, they say: doesn't work, we: upgrade, you're dooned
<vila> doomed
<vila> So there is still a slight chance that they try to read the NEWS for the bzr they can't upgrade to and find the the warning there
<vila> which was my original intent when putting it there
<vila> but that's not satisfying
<AdamDV> How can I see the previous versions of a file from the CLI?
<poolie> AdamDV: `bzr cat -r -1 FILE`, etc
<vila> bzr cat <file> -r-1
<AdamDV> alright
<vila> poolie: shouldn't we just wait for lplib and lp.net to come up with a solution ? That's where people will fail after all
<poolie> vila, let's just not document what people using older clients should do in the news file
<vila> wfm
<poolie> if lp isn't going to pull the plug it's not urgent
<poolie> jam, so how are things with you?
<jam> poolie: moving along pretty well here.
<spiv> jam: good morning
<jam> one very odd thing I just discovered. peak memory during "bzr pack" if you already have an optimal pack is much higher than peak memory when you don't. I wonder if we are reading in the entire old pack file to compute the md5sum...
<jam> hi spiv
<jam> spiv: I wanted to ask you about https://code.launchpad.net/~spiv/bzr/fetch-spec-everything-not-in-other/+merge/42078
<spiv> jam: Today I'm planning to work on the hpss request you suggested in your shallow branching mail.
<jam> it says you changed the description, but it doesn't show a delta
<jam> I was wondering what the different was
<spiv> I typoed the bug number
<jam> bbiab, my son is asking for me
<spiv> So, nothing significant :)
<poolie> hi there spiv
<CardinalFang> Hi.  Is anyone else running Natty right now?  I'd like an independent test of something.
<CardinalFang> Namely, I want to know if there's a problem with plugin "bzr-builddeb".
<CardinalFang> $ bzr branch lp:debian/python-couchdb 0.8-0u1; cd 0.8-0u1; bzr import-upstream 0.8 http://pypi.python.org/packages/source/C/CouchDB/CouchDB-0.8.tar.gz
<CardinalFang> At crash location, there's a comment mentioning spiv's tags-copied-but-no-revisions bug, but I think it's not related.
<maxb> CardinalFang: Not running natty. Will maverick + tip of bzr-builddeb do?
<spiv> CardinalFang: pastebin the crash maybe?
<CardinalFang> maxb, I don't know.  If you get AttributeError ^, you'd know.
<CardinalFang> spiv, I shouldn't have woken you.  I've decided your bug isn't related at all.
<spiv> CardinalFang: also, see if "bzr tags" in that branch reports ? rather than revnos
<spiv> (in the local branch)
<maxb> bzr: ERROR: [Errno 2] No such file or directory: u'http://pypi.python.org/packages/source/C/CouchDB/CouchDB-0.8.tar.gz'
<maxb> for me
<spiv> CardinalFang: well, even if it isn't that bug, seeing the traceback will help us figure out what the bug is :)
<maxb> CardinalFang: No AttributeError here when I download the file locally. However, this sounds vaguely like a bug recently fixed in trunk
<CardinalFang> stack trace:  http://pastebin.ubuntu.com/538464/
<CardinalFang> spiv, all tags have revnos.
<spiv> Ok, that rules out the tag bug.
<CardinalFang> bzr = 2.3.0~beta2-1;  brz-builddeb = 2.6ubuntu1
<spiv> CardinalFang: I'm guessing it's because bzr-builddeb is looking for an upstream branch, but doesn't know of one...
<spiv> It's worth filing a bug on bzr-builddeb, I think.
<maxb> No, it's fixed in trunk r485
<spiv> maxb: ah!
<spiv> maxb: heh, my local copy of trunk was at 484 :)
 * CardinalFang looks for bzr nightlies.
<maxb> bzr branch lp:bzr-builddeb :-)
<spiv> There's also https://launchpad.net/~bzr-nightly-ppa/+archive
<spiv> Oh, actually, that's not the PPA I was thinking of..
<spiv> https://launchpad.net/~jelmer/+archive/bzr-dailies is the one I was thinking of.
<CardinalFang> Rock.
<maxb> no, that's obsolete too
<maxb> You want https://launchpad.net/~bzr/+archive/daily
<maxb> (spiv, CardinalFang)
<spiv> maxb: heh
<CardinalFang> maxb, spiv, thank you very much.  I owe you a beer.
<spiv> maxb: Hmm, I guess the link to bzr-nightly-ppa on https://launchpad.net/bzr should be replaced with that, then?
<peitschie> mornin all :)
<poolie> hi there
<abentley> poolie: I discussed the branch with jam, but things got derailed into a discussion over what the philosophically-correct return value is when calling is_executable on a directory.
<poolie> oh, ok
<poolie> False vs None vs error?
<abentley> poolie: False vs None.
<abentley> poolie: I think False is correct, but I think consistency is the most important consideration.
<abentley> poolie: And False is also consistent with other Tree types and other RevisionTree APIs.  Changing it all to None would be a big change.
<maxb> spiv: Based on the utter deadness of where it currently points, I've just gone ahead and updated it right now
<james_w> thanks maxb
<spiv> maxb: thanks :)
<poolie> abentley: so is it stuck? would you like another review?
<abentley> poolie: So landing in 2.2 is stuck.  Another review would be helpful.
<abentley> poolie: https://code.launchpad.net/~abentley/bzr/is_executable/+merge/42197
<poolie> that one, or the one that supersedes it?
<abentley> poolie: That one.  The one that supsersedes it is for trunk.
<poolie> thanks for the incremental diffs btw
<abentley> poolie: You're welcome.
<jelmer> hi James, Poolie, Spiv, Aaron, Max
<jelmer> spiv: My daily builds are mostly living under ~bzr now
<jelmer> nevermind, I see Max already mentioned that
<poolie> :)
<james_w> hi jelmer
<abentley> jelmer: Hi.
<poolie> abentley: what was the old behaviour?
<poolie> oh, None?
<abentley> poolie: yes.
<poolie> fairly obviously
<mkanat> Hey hey. Anybody available to do a review on a loggerhead merge proposal?
<mkanat> https://code.launchpad.net/~mkanat/loggerhead/view-default/+merge/42222
<mkanat> thumper: Would you be the person to talk to about that, now? :-)
<maxb> jelmer: Hi, a question. Why are the bzr daily recipes using version numbers like 1.4.0~bzr{revno}~ppa{revno:packaging}+{revno:debian} ? The ordering of {revno:packaging} and {revno:debian} is inverted to what feels natural to me?
<poolie> hi mkanat
<mkanat> Hey poolie! :-)
<poolie> maxb: i agree
<poolie> abentley: i replied; on the whole it seems like a good change but some testing wbn
<poolie> perhaps we should do that within hudson
<poolie> or just manually
<abentley> poolie: What kind of testing do you have in mind?
<thumper> mkanat: hmm
<thumper> mkanat: I'm not entirely sure
<thumper> mkanat: poke poolie :)
<mkanat> thumper: Hahaha, okay. :-)
<mkanat> poolie: So, any thoughts on who can do my loggerhead review there?
<mkanat> poolie: Or do you just want me to check it in w/o review? (Not sure how comfortable I am about that, although I have tested it.)
<poolie> i probably could
<abentley> poolie: In the cover letter I said "This branch fixes RevisionTree.is_executable to treat directories and symlinks the same way as other Tree implementations-- to return False rather than None."  Was that not a clear enough statement?
<poolie> sorry, you did
<poolie> perhaps it is worth mentioning in news though
<poolie> is this going to systematically change what's returned by iter_changes in non-test cases?
<poolie> mkanat: shall we discuss it in #launchpad-dev?
<mkanat> poolie: Sure, I'm there now.
<abentley> poolie: I believe only PreviewTree, because only PreviewTree can use RevisionTree.is_executable in its  it only changes iter_changes when it involves PreviewTree, because only PreviewTree uses is_executable to implement Tree._comparison_data.
<abentley> poolie: I believe only PreviewTree, because only PreviewTree can use RevisionTree.is_executable in its _comparison_data implementation.
<abentley> So only iter_changes on PreviewTrees should be affected.
<poolie> so i'd comfortably +1 it now if you could run the tests of the relevant plugins
<poolie> that might be a bit annoying if the test suites are not obviously clean to start with though
#bzr 2010-12-01
<abentley> poolie: by "relevant plugins" do you mean ones that do iter_changes on PreviewTrees, or ones that might do RevisionTree.is_executable, or...?
<poolie> im' not sure if it will be easy to identify which ones could be affected
<poolie> we could guess based on the apis
<poolie> or just test the ones that are packaged
<abentley> poolie: I don't think it will be easy.
<abentley> poolie: Okay, I'll go find out what's packaged and make sure I've got it all installed, and then run the plugin tests.
<poolie> do you think this is too laborious and we should just land it?
<poolie> i think it would be worth at least just running them
<poolie> if it turns out they're too noisy, then we could decide what to do
<abentley> poolie: I think I can run them and delta the test failures against vanila 2.2.
<poolie> that sounds good to me if that works for you
<poolie> so to keep this under control as a contract
<poolie> i think i should mark out what we want in each particular future release
<poolie> would that work for youL
<poolie> mkanat: actually just generally, feel free to request review from me, jam, spiv, or all of ~bzr
<mkanat> poolie: Okay.
<mkanat> mwhudson: If I make the change about the None, do you want me to re-request review or just go ahead and merge it after doing it?
<mwhudson> mkanat: if you're confident in your change, just merge it
<mkanat> mwhudson: Okay.
<mkanat> mwhudson: I'm also wondering if there might be an off-by-one error in the contents array, so that it has an extra line that it shouldn't have.
<mwhudson> seems a bit unlikely somehow
<mkanat> mwhudson: Well, I think that annotate_iter may not consider a final "\n" to be adding an extra line.
<mwhudson> oh right maybe
<mkanat> So I suppose I could just have the generator create an infinite number of empty containers at the end.
<mkanat> Since we iterate over the contents array now instead.
<mwhudson> that works i guess
<mkanat> I think it'd be the simplest solution, code-wise.
<mkanat> Well, launchpad outage stops me from doing any more development or merging. :-(
<jdobrien> is there an issue with launchpad right now?
<mwhudson> jdobrien: one of the data centres is offline
<jdobrien> mwhudson, aha! that would answer it
<jdobrien> mwhudson, I hope it was planned :o
<AfC> mkanat: why would the lack of availability of a centralized web resource have anything to do with you being able to get work done with a distributed revision control system like Bazaar?
<abentley> poolie: I've run all plugin tests, and none fail with is_executable that pass with 2.2.  Actually, an extra fails with 2.2, so I assume it's a flaky test.
<mkanat> AfC: Because my code exists only on LP right now, I reverted my patch locally.
<poolie> abentley: nice
<abentley> poolie: shall I go ahead and land it on 2.2, then?
<poolie> please do
<abentley> poolie: btw, I looked up who committed this code that's causing me grief.  It was me.
<poolie> haha :)
<poolie> thanks for persisting with fixing it
<abentley> poolie: no worries.
<poolie> mkanat: reading your patch now
<mkanat> poolie: Okay.
<poolie> done!
<poolie> good to go
<mkanat> poolie: Thanks! Good timing by me. :-)
<mkanat> poolie: BTW, I'm on the launchpad-devel mailing list still, so I do get the messages even if they're not CC'ed to me. (I usually just watch for subjects about loggerhead or codebrowse.)
<mkanat> poolie: There is a test framework in place, BTW.
<poolie> k
<poolie> ... but it's hard to use for this?
<mkanat> poolie: No, not that hard, I could do it. But I think it mostly already covers this, since annotate is already tested...I believe.
<mkanat> Yeah, annotate is already tested.
<poolie> it seems like if you're changing the default view
<poolie> and the tests don't fail
<poolie> there must be a gap in coverage?
<mkanat> poolie: I haven't run the tests, because they're failing anyway. :-)
<poolie> really, just generally? :/
<mkanat> poolie: Well, they were last time I ran them.
<poolie> to the extent that it's not worth adding a new one?
<mkanat> poolie: Ah, no, it could be worth adding a new one. Let me get the tests running on my new system (I just upgraded my OS and am missing some packages) and I'll see how much work it would be.
<poolie> well, it could be worth a try
<mkanat> I'm not quite figuring out why the tests won't run on my machine. Maybe it's some python 2.7 thing.
<poolie> what os do you use?
<spiv> mkanat: hmm, IIRC bzr's tests are fine on 2.7 now.
<mkanat> poolie: Fedora
<mkanat> spiv: Yeah, but these are loggerhead's tests.
<mkanat> I seem to recall just being able to "nosetests" on python 2.6 and things would be fine.
<mkanat> jam, mwhudson: Do you know what it takes to get the loggerhead tests to run right?
<jam> mkanat: at one point I tried to integrate it with "bzr selftest -s bp.loggerhead"
<mkanat> jam: Ohh, right. Since then, I think the tests have been broken with nosetests.
<mkanat> jam: So I have to have it symlinked in as a plugin to do that, right?
<jam> something like that, yes
<mkanat> AttributeError: 'module' object has no attribute '_WritelnDecorator'
<mkanat> Are bzr's tests only working with python 2.7 on trunk?
<mkanat> I have 2.2.1 installed.
<poolie> mkanat: probably yes
<mkanat> Okay.
<poolie> there's no py26 in fedora 14(?)
<mkanat> poolie: Right.
<spiv> I run bzr trunk's tests with 2.6 all the time.
<spiv> Perhaps you need a newer testtools or something like that?
<mkanat> spiv: No, I just easy_install'ed it.
<mkanat> This is the traceback: http://pastie.org/1337546
<mkanat> It's pretty apparent that it's just related to the unittest changes in 2.7.
<poolie> mm
<poolie> you might be able to cherrypick-back the changes from 2.3 to fix it?
<poolie> or perhaps testing it against bzr 2.3 is still useful
<mkanat> Ah, well, I don't imagine LP runs 2.3.
<mkanat> I'll have to figure out how to make these tests work with nosetests again.
<mkanat> Wow, how is this SO FAST? Probably because of crazy custom Hg implementation. http://code.google.com/p/python-nose/source/list
<poolie> that's what we should aim for
<mkanat> Yeah.
<poolie> might need more than little slices of time though :/
<mkanat> I think we'd have to actually cache the rendered HTML to get that fast.
<mkanat> But maybe not.
<poolie> perhaps an intermediate representation is cached
<poolie> they're probably not touching a magnetic disk to have it consistently that fast
<lifeless> that sort of speed is what cassandra is aimed at
<lifeless> - its a bigtable backend for hg
<mkanat> poolie: Well, if it's anything like their Svn implementation, it's a mapreduce thing with, yeah, bigtable.
<mkanat> First off we'd have to figure out what and how to cache things.
<mkanat> Although if you had a cassandra backend for bzr, we may not even have to cache them, I don't know for sure.
<lifeless> you'd denormalise things like revnos
<lifeless> in a sense such a thing is a cache
<mkanat> Right, we already have a revno cache in loggerhead.
<lifeless> if we can finish the 'does not need vfs for regular use' work, we could seriously consider a cassandra impl
<lifeless> failing that we could push (thus limiting the operations that take place) into a ro cassandra mirror
<poolie> using hpss to talk to a process that talks to cassandra?
<poolie> oh nm, yes
<lifeless> yes, exactly.
<mkanat> jam: Do you know why your changes would have caused this (when trying to run the loggerhead tests via nosetests)? http://pastie.org/1337584
<jam> mkanat: not specifically, but I know that loggerhead doesn't know whether it is a plugin or a main script, and does some ugly hacks with the python import path to try and work both ways
<mkanat> jam: Ah, yeah.
<mkanat> poolie: It's probably going to take me quite some time to get the test suite working again, just as far as figuring out what's wrong and making things work right again. Do you still want me to add a test for the new controller?
<spiv> mkanat: I'm not poolie, but I think investing in the test suite will pay off
<mkanat> spiv: I fully and completely agree with you; this is more of a "how does Canonical want me to spend my hours" sort of a deal. :-)
<poolie> mkanat: let's not block this merge on that, but i do think it would be worth spending some canonical time on it
<mkanat> poolie: Okay.
<mkanat> Sounds good.
<poolie> it seems like it will help do other work in future
<mkanat> poolie: Okay, agreed.
<lifeless> it would be good to switch it to using testtools.run rather than nosetests
<lifeless> which will give it easy hudson integration via subunit.run
<mkanat> lifeless: It can already run under bzr selftest, I just can't run bzr selftest using my version of bzr and my version of Python.
<lifeless> mkanat: why not? actually scratch that question. Different one: perhaps fixing that is more important.
<mkanat> lifeless: Supposedly that's been fixed on trunk, just not in 2.2.x.
<mkanat> lifeless: (This is with python 2.7.)
<mkanat> So, TAL is not a very good template language. :-(
<bob2> the chameleon implementation is nicer
<bob2> gives you $foo for when you're feeling lazy
<mkanat> Yeah, it's not so much the convenience of not of the language, as much as it is that it's just very difficult to work out how to do certain things.
<mkanat> Particularly if you can't wrap an element in another element, or don't want to.
<mkanat> I really liked Mako last time I used it, that's probably what I'd prefer, although I have no idea if there are any serious problems with it in production (or if it's still actively maintained).
<vila> hello all !
<vila> full red babune
<vila> I upgraded to testtools trunk yesterday, direct link, url: http://babune.ladeuil.net:24842/job/selftest-maverick/lastFailedBuild/
<vila> Nice tests as only reading their names strongly suggests a shallow problem
<mkanat> I could do template inheritance with my patch that I'm working on right now, too, if I was using Mako instead. :-/
<vila> lifeless, jml: bug #683505 rings a bell regarding a recent change in testtools ?
<ubot5> Launchpad bug 683505 in Bazaar "bzrlib.tests.test_selftest.TestSubunitLogDetails failures with testtools trunk (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/683505
<vila> mgz: may also be related to a too aggressive cleanup of the test details ? ^
<vila> jml, lifeless: ping
<vila> testtools introduced a change in revno 142 (regarding the return value of running a test suite with failing or erroring test),
<vila> I'd like to guard against that by testing the testtools version
<vila> I can use 0.9.8 for that except if you expect to change the behavior again before releasing 0.9.8
<vila> jml, lifeless: when do you expect to release 0.9.8 ?
<lifeless> vila: its going to be backed out, see the bug
<vila> lifeless: rats, too bad I missed that one, this sounded like a nice change though
<lifeless> only part of the patch is buggy
<lifeless> only that bit will be backed out
<lifeless> it breaks subunit too
<vila> Ok, I'll subscribe to the bug to see how it goes then
<vila> meh, lp already subscribed me :)
<vila> I'll revert my babune testtools in the mean time
<vila> dOxxx: Hey !
<dOxxx> vila: hey :)
<dOxxx> vila: everything go okay with the release?
<vila> dOxxx: Thanks for the reviews and merges ! I haven't looked at the s/update/pull/ bit you mentioned, do you plan to: 1) fix it, 2) revert to use checkouts 3) something else ?
<dOxxx> vila: fixed it when I merged your changes.
<vila> dOxxx: AFAIK, yes, there are a couple of people having troubles with svn on OSX for reasons unclear to me, I was wondering if you knew more about that (they used 2.2.1 if that's relevant)
<vila> dOxxx: Cool!
<dOxxx> vila: Which version of OSX?
<dOxxx> were there bugs filed?
<vila> wow, that was ambigous, re-try: yes, the 2.2.2 release seems okay. Then some people with 2.2.1/10.5 have reported svn related problems
<dOxxx> ok
<vila> dOxxx: I think there were bugs, but linked to/from answers
<vila> dOxxx: at least one of them has installed macports and had related problems but didn't confirm that uninstalling macports addressed them
<vila> dOxxx: the other(s?) didn't mention macports
<dOxxx> if you could point me to the bug reports, I'll take a look
<vila> ok, let me find them
<vila> but... just wondering, was it for 2.3bn that svn/subertpy tip was needed ?
<dOxxx> checking
<dOxxx> No, I think it was for all branches
<dOxxx> But it's a compilation problem not a runtime thing
<dOxxx> I needed r2219+ to actually get subvertpy to compile on 10.5
<jelmer> dOxxx: oh?
<vila> bug #681285
<ubot5> Launchpad bug 681285 in Bazaar "Can't push my changes in Bazaar" [Undecided,Incomplete] https://launchpad.net/bugs/681285
<vila> jelmer: ^ you may know better from the error message in the last comment
<dOxxx> jelmer: yep, as I recall you made the changes for me
<vila> well, the *2* error messages even
<jelmer> dOxxx: can you fetch without problems from that location?
<dOxxx> sorry still reading bug
<jelmer> dOxxx: ahh, ok. That was a while ago though.
<dOxxx> jelmer: yeah, so I don't think that's the problem here.
<vila> dOxxx: right, the other is harder to find back: bug #682904 and https://answers.launchpad.net/bzr/+question/135989, read the question before the bug may be
<ubot5> Launchpad bug 682904 in Bazaar "Can't push my changes in Bazaar--need to update libsvn?" [Undecided,Invalid] https://launchpad.net/bugs/682904
<dOxxx> vila: could you check what version of svn you have on your 10.5 build machine?
<vila> how ?
<vila> I *have* svn ??
<dOxxx> of course, how do you think the installers build? :)
<dOxxx> OS X comes with svn stock
<vila> no idea, I've just pushing buttons ;)
<vila> s/I've/I'm/
<dOxxx> hah
<jelmer> dOxxx: Ahh, you're Gordon!
<dOxxx> jelmer: yers ;)
<vila> jelmer: meet dOxxx aka Gordon
<dOxxx> sorry, shoulda introduced myself :)
<vila> dOxxx: meet Jelmer :)
<vila> svn --version reports: 1.4.4 (r25188)
<jelmer> dOxxx: np, I know who you are.. but I hadn't connected you with your nick name :-)
<dOxxx> hmm....
<vila> dOxxx: is this as bad as I think ? :-/
<dOxxx> jelmer: would compiling subvertpy against libsvn 1.4 cause a problem like described in these questions?
<jelmer> dOxxx: yeah
<vila> i.e. is bzr-svn compatible with svn 1.4.4 ?
<jelmer> it is compatible but certain functionality won't be available
<jelmer> and performance will be impacted
<dOxxx> I don't want to include new svn libraries with the OSX bzr installer
<jelmer> dOxxx: why not?
<dOxxx> jelmer: 1) I'm not sure how to do it correctly, 2) that's touching system files, which is kinda icky
<vila> jelmer: I don't think the OSX installer can use private binaries/libraries easily so they are installed sys... what he said :)
<jelmer> vila: urgh :-(
<jelmer> I guess it makes to use whatever the system is providing
<vila> it is !
<dOxxx> the OSX installer puts all the bzr stuff into the system python's site-packages and stuff like the Qt framework in the system location too
<vila> but the fix here may be to just tell people to upgrade their svn if needed
<dOxxx> so it's already potentially overwriting Qt libraries
<vila> but that's different than pushing a newer one
<dOxxx> but those aren't installed stock with OSX so I didn't feel so bad about that
<dOxxx> but even if they upgrade their system svn, it seems that since subvertpy is compiled against 1.4, it will still cause problems?
<jelmer> yes
<vila> oh my
<dOxxx> right, so we'd need to compile subvertpy against svn 1.5 at least and tell users that they must install svn 1.5 first
<vila> no, wait, I don't get it
<dOxxx> vila: subvertpy build against svn 1.4 on our build machine will make it behave like a svn 1.4 client even if there are newer svn  libraries installed on the user's machine
<vila> are you both implying that 2.2.0 was ok, but 2.2.1 is not anymore because of subvertpy ?
<dOxxx> vila: I don't think this is related to the bzr version
<vila> I was referring to the installer version
<vila> so the set of whatever we package there, including bzr, plugins and their dependencies
<dOxxx> urgh
<vila> if we can't provide an all-in-one installer including bzr-svn, it means (IMHO) that we should have specific packages for svn-1.4, 1.5 and/or whatever other versions are available and install only the relevant ones ?
<vila> s/ones/one/
<vila> but back to my question: bzr-svn was working with the 2.2.0 installer right ?
<dOxxx> like I said, I don't think this is a problem that was introduced in a particular version of the installer, it may have always existed
<vila> dOxxx: or did you use a 10.5 host with an upgrade svn to 1.5 ?
<vila> ha, ok :-/ So these are the first reports that bzr-svn doesn't work on OSX ?
<dOxxx> vila: honestly, I can't remember what version of svn it had installed. I know that it was a fresh install of OS X 10.5, so I'm assuming that it was svn 1.4 like yours
<vila> jelmer: did you get feedback from osx 10.5 users ?
<dOxxx> vila: as far as I know, I don't seem to get emails for bug reports on bzr-svn
<vila> dOxxx: honest ignorance is better than silence :D
<jelmer> vila: please note that these bug reports are not an indication that bzr-svn doesn
<jelmer> 't work at all, it's just certain kinds of pushes
<vila> oh
<vila> right :)
<vila> I was shaking the tree to see which fruits will fall :)
<vila> Wasn't meant to be negative
<vila> meh, especially when the report starts with: "For a while, Bazaar was working fine, but now when I push, I get"
<vila> dOxxx, jelmer : how does one check which svn and which subvertpy is used by bzr (or is subvertpy the only relevant part) ?
<jelmer> vila: newer versions of bzr-svn will mutter that information to .bzr.log
<vila> Said otherwise: how can one install an upgraded svn/subvertpy to make bzr happy ?
<vila> hmm, or may be s/how can one/is it possible to/
<maxb> If you just install svn 1.5.x and reinstall subvertpy, things should be happy
<dOxxx> jelmer: the bzr 2.2.2 OSX installer uses r2219 of subvertpy, has there been an official release since then?
<dOxxx> looks like 0.7.4 and 0.7.5?
<jelmer> dOxxx: yep
<dOxxx> ok, I should update the installer configs to use 0.7.5 then I think
<dOxxx> vila: do you think we should rebuild the OSX installers for 2.2.2 to use a newer subvertpy?
<dOxxx> the version its currently using is from July and about 2 releases out of date
<vila> hmm
<dOxxx> I don't know if it will solve George's problem but it seems like a generally good idea
<dOxxx> since it looks like there have been some svn 1.4 compatiblity fixes
<vila> 2.2 is stable, if we broke it we should fix it, but upgrading too many things may break it even more
<jelmer> dOxxx: yeah, it wouldn't solve George's problem
<dOxxx> jelmer: would subvertpy 0.7.5 still be compatible with bzr-svn 1.0.3 or should we use a newer version of that?
<jelmer> dOxxx: there's no need for a newer bzr-svn
<dOxxx> ok thanks
<vila> so, testing 2.2.1, 2.2.2, 2.3b3 locally with 'bzr info http://svn.apache.org/repos/asf/subversion/trunk' succeeds
<vila> does it mean I need another svn server to test against ?
<vila> to reproduce George's problem ?
<dOxxx> vila: have you tried the URL George is using?
<vila> not yet, I though it required some auth, let me try
<maxb> jelmer: Did you deliberately turn the bzr-pqm-daily recipe on again for karmic?
 * maxb turns it off again
<vila> dOxxx: indeed, it asks for a suer/password and when I enter none, fails with a 500 server error
<dOxxx> darn
<dOxxx> what I don't understand is why, if George upgraded his svn to 1.6.9 and subvertpy to 0.7.4, why is still not working? It gives a different error though.
<jelmer> dOxxx: did he recompile his subvertpy against svn 1.6 ?
<dOxxx> he doesn't say.
<jelmer> maxb: I didn't realize it was intentionally disabled. I enabled the natty builds yesterday evening.
<maxb> The recipe description field could do with being more prominant, and supporting line-breaks
<dOxxx> vila, jelmer: I've updated https://answers.launchpad.net/bzr/+question/135989, asking George for specifics on how he upgraded svn and subvertpy
<dOxxx> I need to go do my actual day job now unfortunately. :P
<vila> jelmer: he says (in bug #682904) : "Note that I am running svn 1.6.9 and subvertpy 0.7.4."
<maxb> jelmer:  Oh, whilst I think about the recipes, I had a question: Why are the bzr daily recipes using version numbers like 1.4.0~bzr{revno}~ppa{revno:packaging}+{revno:debian} ? The ordering of {revno:packaging} and {revno:debian} is inverted to what feels natural to me?
<ubot5> Launchpad bug 682904 in Bazaar "Can't push my changes in Bazaar--need to update libsvn?" [Undecided,Invalid] https://launchpad.net/bugs/682904
<vila> dOxxx: no worries, thanks for the help !
<vila> jelmer: he didn't say *where* he installed them though
<jelmer> vila: but that doesn't say against which version of the libsvn API his subvertpy was compiled against though
<dOxxx> yeah that's what I'm wondering
<dOxxx> considering he was using MacPorts before
<vila> dOxxx: not sure that's the same guy
<dOxxx> they seem to be the same George
<vila> ha, good, well done to file different bugs then :-/
<dOxxx> yeah and two Questions with the same content :)
<vila> ha, now we need duplicates for questions too...
<jelmer> vila, dOxx: If he has svn 1.6.9 installed but compiled his subvertpy against svn 1.4 then it still won't work.
<vila> ha no, poolie turned the bug into a question, oh my
<jelmer> maxb: Something can be said for either
<dOxxx> dammit, I'm not getting notified of bugs filed on bzr-mac-installers
<vila> jelmer: /me nods
<maxb> jelmer: ok :-) I'd like to understand what can be said for this way?
<dOxxx> ok... set myself as the bug supervisor maybe that will do it
<mgz> vila: I don't understand the testtools from the log or Robert's bug entry
<mgz> +issue
<vila> mgz: just a sec, let me push my wip branch, that should be clearer there
<mgz> the three failing tests look wrong to me, but why were two of them passing before?
<vila> three/two ?
<vila> Three were passing three are now failing
<mgz> we don't seem to use a custom wasSuccessful method, and the default one should return False if there's a failure
<mgz> unexpected success flipped, but the other two should be the same
<vila> mgz: in a nutshell, the bug I filed is a duplicate, more fixes should be done in testtools
<mgz> I'm guessing from the bug entry Robert knows what's going on, I just can't divine what the fix should be from what he's written
<vila> hmm, he said the change doesn't take into account decorated was_successful or something, including subunit
<mgz> ah, maybe it's a subunit only thing.
<smoser> i'm not sure this is bzr or launchpad question.
<vila> mgz: now, I don't understand the specifics, I've only been looking at making the tests more precise about whether running a test suite should succeed or not depending on which tests were provided
<dOxxx> argh
<smoser> but this used to work:  bzr branch lp:~ubuntu-on-ec2/vmbuilder/automated-ec2-builds
<smoser> but now gives bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~ubuntu-virt/vmbuilder/0.12/".
<dOxxx> vila: looks like we need to do a new 2.2.2 installer build anyway to update bzr-svn to 1.0.4
<dOxxx> bug 621446
<ubot5> Launchpad bug 621446 in Bazaar Mac Installers "AttributeError: paths when trying to svn-import" [Undecided,New] https://launchpad.net/bugs/621446
<jelmer> smoser: that's a #launchpad question really. You have a branch stacked on another branch that no longer exists.
<smoser> https://code.launchpad.net/~ubuntu-virt shows no 0.12 branch there anymore.  I'm guessing someone deleted that, and my branch shared data
<smoser> jelmer, yeah.
<smoser> jelmer, thanks.
<jelmer> smoser: Soren had the same issue the other day.
<vila> dOxxx: unless this is already fixed in 2.3b3 (or b4 which will be released tomorrow)
<dOxxx> vila: no it's an installer issue. the installer is configured to use bzr-svn 1.0.3.
<smoser> jelmer, funny, soren is probably who deleted my branch :)
<jelmer> maxb: if somebody fixes something in the packaging branch then that change should sort before any fixes in the debian branch.
<dOxxx> nothing to do with bzr version per se
<soren> smoser: I didn't delete your branch. I moved mine to ~ubuntu-virt.
<dOxxx> just that 2.2 is current stable branch so I should make sure it works ;)
<vila> dOxxx: if 1.0.4 is not specifically targeted at bzr-2.2, we shouldn't include it in 2.2.[23]
<smoser> well, one its gone from where it was, so move or delete, ... potAto potato
<jelmer> maxb: ~bzr has write access to the packaging branch but not the debian branch so the packaging branch can always merge in the debian branch if necessary, never the other way around.
<vila> dOxxx: otherwise we end up packaging the same thing in 2.3 and 2.2 and this will break the stability guarantee
<smoser> soren, do you happen to know, then what i need to do to make that function again ?
<vila> dOxxx: that's the rule,  does it apply in this case ?
<dOxxx> vila: not sure I understand your previous comment
<vila> mgz: lp:~vila/bzr/683505-test-no-log, wip, doesn't work yet
<maxb> jelmer: but, every build will always take the latest revno of the debian branch anyway, so I'm not seeing where this ordering issue would arise
<vila> dOxxx: let me look at the bug
<jelmer> maxb: Imagine somebody made a commit in the debian branch
<jelmer> maxb: or, in fact, did a merge in the debian branch (changing the revno's)
<maxb> but... that would be a silly thing to do! :-)
<mgz> thanks vila.
<vila> dOxxx: dang ! Same here, I never got gplyph answer !
<mgz> so, I think the conditions are backwards in those three tests, but it's subunit being funny.
<mgz> so again, probably wants something changing in all three projects.
<soren> smoser: I'd talk to mvo. I think he sorted it out.
<dOxxx> okay really going to work now
<dOxxx> seeya
<vila> mgz: since babune was very update, I've reverted to testtools-0.9.7 waiting for a consensus to emerge :)
<vila> mgz: what is backwards ?
<vila> mgz: that subunit says all is well even when running a single failing test ?
<vila> dOxxx: argh, no one more second !
<dOxxx> ?
<vila> dOxxx: my comment was: if bzr-svn doesn't say: this release is compatible with bzr-2.2 and 2.2 users are expected to upgrade, we should include it in 2.2.2, otherwise we should not
<vila> dOxxx: i.e.: the plugin authors should be explicit, like qbzr maintaining a specific series target at 2.2 and another targeted at 2.3
<dOxxx> that would be nice
<vila> jelmer can confirm that bzr-svn is targeted at 2.2 and 2.3, so in this case, yes, we should rebuild the 2.2.2 installers
<dOxxx> bzr-svn 1.0.4
<vila> meh, bzr-svn-1.0.4 yeah, thanks :D
<dOxxx> argh
<jelmer> dOxxx, vila: The supported versions for a bzr-svn branch should be available in info.py
<dOxxx> George says he "replaced the system-installed svn with the new version using MacPorts"
<vila> jelmer: by the way, the 1.1 and 2.0 series for bzr-svn are not that clear to me ;D
<dOxxx>  /facepalm
<vila> dOxxx: be sure to check the dates ?
<dOxxx> this is a new comment on the question
<dOxxx> posted 15 min ago
<dOxxx> https://answers.launchpad.net/bzr/+question/135989
<dOxxx> as far as I know MacPorts installs into /opt so it wouldn't replace the system svn
<jelmer> vila: Yeah, I haven't really gotten to those. I have Plans, though :-)
<vila> jelmer: hehe great !
<vila> so, bzr-svn 1.0.5 is targeted at 2.x for x in [0,1,2,3] :)
<vila> bzr-svn 1.0.3 is targeted at 2.x for x in [0,1,2]
<vila> and of course I don't have bzr-svn-1.0.4 available here ;D
<dOxxx> anyway so I think his svn is not properly upgraded and his subvertpy not compiled against the right version.
<dOxxx> and now I really must go to work, already 30 min late.
<vila> dOxxx: right, happy work day ! Thanks again !
<dOxxx> bye!
<vila> jelmer: one more thing: bzr-svn is aimed at being compatible with svn-1.[456] right ? (relying on subvertpy compiled against the right library ?)
<jelmer> vila: yep, and 1.7
<vila> hmm, so the issue with OSX installers is to be able to build various subvertpy packages on a host with the right(s) svn installed :-/
<vila> and provide some way to select the right one :-(
<mgz> vila: yes, that's my understanding of the subunit aspect.
<vila> . o O (Oh my god, what does he mean with this 'yes'....)
<vila> :D
<mgz> <vila> mgz: what is backwards ?
<mgz> <vila> mgz: that subunit says all is well even when running a single failing test ?
<mgz> :P
<vila> ha, ok
<vila> I wonder if he does this manually in order to carry some subliminal messages
<mgz> the lunch? or lifeless quitting? :D
<vila> mgz: not you ;D
<vila> This has occurred several times these last weeks with an astonishing synchronicity :)
<vila> mgz: random thought: about 'lost connection during...' errors, could that be explained by 'time' events going backwards in time ?
<mgz> nope, they should be pure decoration.
<vila> I hate them
<mgz> it's not a very helpful starting point for debugging I agree.
<mgz> could perhaps file a bug against subunit to make it provide more information in those circumstances
<mgz> it's from falling off the end of a read-from-stream loop, printing state information about the subprocess where available might be helpful
<mgz> breaks through the abstraction a bit, but otherwise you don't have any clue what caused the eof.
<vila> mgz: is there a way to save these streams ?
<mgz> tee?
<vila> where ?
<mgz> hm, point.
<vila> :D
<mgz> inside fork_for_tests I guess.
<vila> yeah, I was afraid you'll say that ;)
<ccxCZ> is there way to make bzr non-interactive when working on bzr+ssh branches, so it won't ask for password?
<mgz> http://babune.ladeuil.net:24842/job/selftest-windows/237/ <- are you aware of this regression vila?
<mgz> bt.test_msgeditor.MsgEditorTest.test_deleted_commit_message has been consistently failing since then, though it passes locally for me.
<vila> ccxCZ: like... using an ssh key and an ssh agent ?
<mgz> it's something of a hacky test, perhaps tripping over something with del.
<vila> mgz: shudder, I noticed and forgot and bialix also mentioned something related and I was waiting for his feedback
<vila> ccxCZ: so the answer is yes, it would drive me crazy otherwise to type my passphrase hundreds of time each day
<vila> mgz: 'since then' is related to bug #676637 ?
<ubot5> Launchpad bug 676637 in GStreamer "Wrong aspect ratio with DV AVI files in PiTiVi" [Low,New] https://launchpad.net/bugs/676637
<vila> probably not
<vila> mgz: 'since then' is related to bug #673637 ?
<ubot5> Launchpad bug 673637 in Bazaar ""bzr commit" fails when BZR_EDITOR is emacsclient" [Medium,Fix released] https://launchpad.net/bugs/673637
<vila> more like it
<mgz> since that set of revisions, but I'm guessing bug, yeah, that one
<vila> damn, I should fix this asap then
<vila> the bug report was for a windows user, too bad he didn't test it, lack of installer I presume
<ccxCZ> vila: of course I know about ssh keys, but in case they're not loaded (eg. cronjob) I want bzr fail instead of hang
<ccxCZ> bzr to fail*
<mgz> the problem is bzr delegates to your ssh client
<mgz> how would you prevent that from promting?
<ccxCZ> which is paramikoI presume?
<mgz> well, depends on what you have installed.
<vila> the use case is valid though a bit weird
<ccxCZ> you can stop openssh by options and maybe by env
<mgz> vila, I'm not sure the fix for the bug is broken, just that test (and not always, as it seems to pass here)
<vila> ccxCZ: you can force the ssh implementation via...
<vila> BZR_SSH ?
<vila> yeah, see 'bzr help env-variables'
<mgz> yeah, making a sh script with ssh --some-no-prompt-option then setting BZR_SSH to that script would work
<mgz> if you have an ssh client that supports something like that.
<vila> ccxCZ: so you have a cronjob that pass where you have given access to some key via your agent and you want it to fail otherwise ?
<vila> s/where/when/
<vila> ccxCZ: I use password-less keys for unattended jobs, so I'm curious about your use case here
<vila> ccxCZ: also there have been discussions about a true non-interactive mode but I'm not sure the related changes have landed
<vila> ccxCZ: better file a bug with your precise use case, I'm sure I will forget otherwise :(
<ccxCZ> actually I want automate checking whether there are changes on remote server, probably by changing prompt on the shell that is cd'ed in a dir with .bzr in it
<ccxCZ> what should I put in BZR_SSH? would "/usr/bin/ssh -o BatchMode=yes" work?
<vila> I'm afraid we don't accept arguments in this variable, IIRC, it's either a pre-defined value or a path
<vila> mgz: hmm, this may be babune specific...
<mgz> yup.
<lifeless> ccxCZ: you can put BatchMode=yes into a ~/.ssh/config stanza
<ccxCZ> yes, but that would disable it for *every* ssh instance, which I don't want, since I might ssh into a server where I don't have a key
<lifeless> no
<lifeless> put it in a host stanza
<lifeless> only affects that host
<ccxCZ> that's not really what I want, it has several shortcomings
<ccxCZ> needing to remember to add host when I branch from new one for example
<ccxCZ> interesting thin is this still manages to ask for password:
<ccxCZ> TTY="" ssh -p 2222 localhost </dev/null &>/dev/null
<ccxCZ> thing*
<jam> echo -e '#!/bin/sh\nexec ssh -o BatchMode=yes "$*"\n' > ~/bin/my_ssh; chmod ~/bin/my_ssh; export BZR_SSH=~/bin/my_ssh
<jam> ccxCZ: openssh knows how to do direct-to-tty communication, not via stdin/stdout
<jam> so that you can't get your password intercepted, etc
<vila> jam: hello  :)
<jam> hi vila
<jam> vila: I just found # cypthon: profile=True which seems very powerful. Of course, it just changed my runtime from 3min to >1hr so far...
<jam> but you can also selectively disable it for specific functions
<vila> :) :-/
<jam> i thought the 2x overhead from profiling regular python code was bad, 100x for compiled functions?
<vila> may it's more precise :D
<vila> it runs everything 100 times to avoid noise ;)
<vila> jam: what BZR_SSH setting are you using on windows when running from a cygwin shell ?
<jam> vila: BZR_SSH=paramiko
<vila> doesn't work for me:
<vila> err, not the same failure :(
<jam> from cygwin shell, you'd still need "export BZR_SSH=paramiko", and you'd also want to make sure you actually have paramiko installed
<ccxCZ> jam: yeah, I've done just that
<ccxCZ> thanks everyone
<vila> jam: hmm, will that be able to use a forwarded agent ?
<jam> vila: paramiko doesn't talk to forwarded agents, AFAIK
<jam> I'm not sure if "BZR_SSH=openssh" would be able to (if you have openssh installed on that machine)
<jam> actually, AFAIK, you can't forward agents to windows, but I don't know the cygwin ssh server all that well
<jam> I've never tried to use it in anger
<vila> 'ssh-add -l' gives me the expected result
<vila> ha,right, that's where I got the error: 4 [main] ssh 3980 C:\cygwin\bin\ssh.exe: *** fatal error - couldn't initialize fd 2 for /dev/tty0
<vila> I can connect "manually" but not via bzr+ssh :-/
<ccxCZ> /msg *status detach #bzr
<ccxCZ> oops
<vila> ccxCZ: bye ;)
<jam> vila: probably something about TTY hiding/subprocess spawning
<jam> vila: I would guess the problem is that your "bzr" is a win32 native process
<jam> interposing itself from your cygwin shell that you sshed into, and the ssh you are going out of
<jam> you could try running cygwin bzr
<vila> which one is that ? ;D
 * mgz uses plink
<mgz> mixing cygwin ssh and native bazaar could certainly cause oddness
<vila> mgz: and you can ssh *to* a windows host *and* get bzr+ssh to say lp, working ?
<mgz> why would I want to ssh to a windows host?
<vila> mgz: to help me ssh to a windows host and have a babune setup working ;D
<jam> vila: why not use pageant with a decent key and paramiko?
<mgz> (In other words, I've never tried to run an ssh server on windows and probably can't help)
<vila> jam: the windows host is started on demand, there is nobody logged there
<mgz> I'd stick with screen sharing, even though that's not as nice for you as pretending it's another nix box.
<jam> vila: well, *somebody* gets logged in...
<vila> yes, via ssh, but how will pageant be started there ?
<vila> no display
<vila> mgz: screen sharing is good for interactive use, running the test suite doesn't care about a screen :)
<mgz> hudson needs ssh access to work?
<vila> hudson itself, no, but I don't want to duplicate everything just for windows, anyway, EOD for me, dinner is ready ;) I'll try plink tomorrow
<jam> vila: I don't think plink knows how to talk to openssh agents
<mgz> yeah, I'm not sure I'm solving your problem with that.
<jam> the other option is paramiko without pageant, and just use password-less keys
<vila> if this means having one dedicated ssh key for windows, I can leave with that
<vila> or two (one for babune, one for lp)
<jam> I believe paramiko will look in ~/.ssh/* which is C:/Documents and Settings/user on older windows and C:/Users/user on newer
<vila> jam: ha ! excellent, that's certainly the missing bit, as <user> is *not* set correctly so far
 * vila shouts: yeah, I'm coming darling, I'm coming
<Ddorda> âhey guys. how do i push on the last commit?
<dash> which one is the last one? :)
<dash> or do you mean "on every commit"
<Ddorda> âdash: commit that overwrite the last commit
<dash> Ddorda: commits don't "overwrite" stuff
<Ddorda> âdash: i mean revisions (woops)
<dash> right, those don't either
<Ddorda> âto push overwriting the last rev.
<Ddorda> âso?
<Ddorda> âi want to remove the last rev. and make a new one instead
<beuno> Ddorda, "bzr uncommit"
<Ddorda> âbeuno: does it remove the changes?
<beuno> Ddorda, it removes the commit, and leaves the changes uncommited
<Ddorda> âbeuno: thank you :)
<beuno> np
<maxb> vila: Your lucid bzr-landing-dependencies has a version number less than the hardy one. This is bad, if there's ever an attempt to upgrade from one to the other
<vila> maxb: thanks for the tip, I'll fix it, 1.0.2~lucid1ubuntu1 will do >
<vila> ?
<maxb> vila: Well, it's a pet peeve of mine - why include "ubuntu" when it's not a Debian derived package modified in ubuntu?
<vila> maxb: no idea, monkey see monkey do, no thinking there :) I'm all ears
<maxb> If it's a lucidified version of 1.0.0, I'd call it 1.0.0lucid1
<vila> maxb: oooh, that's the '~' that makes it smaller ?
<maxb> Yes, the ~ is the magic that is smaller than nothing at all
<maxb> Unfortunately, the rise of PPAs has taught people to use it as a generic separator
<vila> maxb: because PPAs are supposed to provide preview versions right ?
<maxb> Because they are often used that way
<jam> vila: right, you usually want ppas to be overwritten by real releases
<jam> I've seen similar tricks with nightly builds. So you have bzr-2.3b4~r5536
<vila> maxb: done and dput'ed
<maxb> and mark-uploaded and pushed? :-)
<vila> jam: yeah, as maxb said, I thought it was just a separator
<jam> vila: there is a whole lot of voodoo magic that goes into debian versions :)
<jam> - means something, as does ~, and everything else
<vila> maxb: what ? Hmm, more tricks coming :)
<vila> maxb: I just do a debchange/debcommit/debuild -S/dput dance
<maxb> but don't you have this in a bzr branch?
<vila> maxb: I do
<maxb> "bzr mark-uploaded" is "bzr tag <figure it out from the changelog>"
<vila> hmm, done
<maxb> yay :-)
<vila> pushed
<vila> so the branch lacks a proper tag for the previous version, but we can forget about that right ?
<vila> I should do the same in the hardy branch though
<vila> or should I create 1.0.0hardy1 first to catch up ?
<vila> OMG that's why ubuntu version follow the alphabet ?
<jam> sometimes I wonder what the Unicode people are smoking: http://www.fileformat.info/info/unicode/char/1f63c/index.htm
<jam> "Unicode Character 'CAT FACE WITH WRY SMILE'"
<vila> maxb: ^ ?
<maxb> Yes that is one of the reasons for ubuntu versions following the alphabet :-)
<vila> maxb: cool :) And about creating a 1.0.0hardy1 version ?
<maxb> There is no particular need to do 1.0.0hardy1, I would call the hardy branch the 'trunk' and let it use plain version numbers
<vila> ok
<radix> jam: FINALLY I've been wanting that codepoint for *ages*
<maxb>   File "/home/maxb/wc/bzr/qbzr/ppa/karmic/lib/tests/modeltest.py", line 69, in nonDestructiveBasicTest
<maxb>     assert(self.model.columnCount(QtCore.QModelIndex()) >= 0)
<maxb> TypeError: QAbstractItemModel.columnCount() is abstract and cannot be called as an unbound method
<maxb> Anyone qbzr-involved around who can interpret that?
<maxb> The current qbzr packaging turns on the tests on the buildds, and it fails like that for karmic
<maxb> I am now wondering if anyone actually uses qbzr from the ppa on karmic
<maxb> or jaunty even
<vila> gary gary where are you ??? garyvdm (hoping to trigger a curl/grep daemon)
<vila> maxb: this smells like a qt dependency, filing  a bug on qbzr may be your best bet
<vila> mgz, jam: What will happend if bzr selftest has to access to the TEMP dir ?
<vila> d for devil
<vila> mgz, jam: in windows that is
<jam> vila: if it has to, then it will access it...
<jam> I don't quite understand your question
<jam> are you wondering *where* temp is?
<vila> it turns out babune has no write access (nor read even) to TEMP (c:\WINDOWS\TEMP)
<vila> yet most of the tests pass... So I wonder how :D
<jam> are you sure $TEMP isn't C:\Documents and Settings\<user>\Application Data\Local\Temp ?
<jam> check what
<jam> tempfile.mkstemp() returns
<vila> nothing :-DF
<vila> ha, no typo of course
<vila> c:\\windows\\temp\\tpmxxxx
<jam> or tempfile.NamedTemporaryFile().name
<vila> blink
<jam> vila: are you *sure* it doesn't have access :)
<jam> I'm not sure the protection model for winxp, but it may be impossible to block the standard temp dir, or something
<vila> that's weird, if I set TEMP to  a dir I create myself the offending test pass
<vila> jam: right, it has access, but... something goes wrong just for this test...
<jam> we use $TEMP for the whole test suite, so I would be surprised if that was the specific failure
<jam> maybe the path depth is getting too long?
<vila> no, simple file name
<jam> (more than 260 chars?)
<vila> and my test dir is longer than windows/temp
<vila> right, and from a cygwin shell TEMP is set as you said and the test pass
<vila> so definitely some weird user setup, I fixed some, but more is needed, but enough for tonight, probably the ssh server fail to setuid properly, I may have to tweak the service definition and reboot or something-ish :)
<poolie> hi jam, spiv
<jam> hi poolie
<poolie> jam, join #ubuntu-meeting?
<dOxxx> I return!
<jelmer> \o/
<dOxxx> so the eventual decision was that the installer for bzr 2.2.2 should include subvertpy 0.7.5 and bzr-svn 1.0.5?
<jelmer> dOxxx: I don't remember releasing 1.0.5 :-)
<jelmer> dOxxx: but other than that, yes.
<dOxxx> (09:34:48) vila: so, bzr-svn 1.0.5 is targeted at 2.x for x in [0,1,2,3] :)
<dOxxx> did he mean 1.0.4?
<jelmer> dOxxx: no, 1.0.5 is in development at the moment
<dOxxx> ah
<dOxxx> um
<dOxxx> jelmer: So, just to be sure, bzr-svn 1.0.4 should be bzr 2.2 compatible, right?
<maxb> jelmer: speaking of which, when are you going to release 1.0.5 :-)
<maxb> Would be nice to get those kde code imports that are currently being imported by my desktop on to launchpad proper
<poolie> jam, hi, still around?
<jelmer> maxb: I don't have any immediate plans, would like to get those ghost issues resolved first.
<jelmer> maxb: It should be possible to cherrypick the new release for launchpad though, new bzr-svn releases have to be cherrypicked anyway.
<maxb> jelmer: cherrypick as in merge just the relevant fixes into the ~launchpad-pqm branch?
<jam> poolie: yeah, I'm still here
<jelmer> maxb: No, sorry - I used the wrong word. I meant to say new bzr-svn releases have to be merged manually for lp anyway.
<poolie> sorry otp at the moment
<maxb> yes... but that is dependent on there being a new upstream release first :-)
<jam> np, you were looking for me :)
<jelmer> maxb: not really, we've merged snapshots in the past.
<maxb> So I should review whether there's a comfortable point on lp:bzr-svn/1.0 which we can be happy about using
<jelmer> maxb: Yes; hopefully that will be trip.
<jelmer> *tip
<vila> dOxxx: if 1.0.5 is not released, it's ok to put it in 2.3, hoping for jelmer to release it before 2.3 is final, for 2.2, we should stau with officially released versions, so 1.04, sory for the confusion, I was looking at the source in bzr-mac-installer/2.3/src/bzr-svn
<vila> s/stau/stay/
 * vila off to bed ;)
<peitschie> nite vila
<peitschie> (mornin jelmer, poolie, jam, maxb, dOxxx... woah.. busy today!)
<poolie> bye vila
<maxb> Does anyone know what the graph.sh in hydrazine is intended to be used with?
<maxb> Because the data collection part of the puzzle appears to be missing
<maxb> I am wondering if we should delete graph.sh from hydrazine
<maxb> (poolie perhaps?)
<_habnabit> Is there a thing anyone knows of that visualizes branching and merging?
<dash> _habnabit: 'bzr qlog'
<dash> or 'bzr vis'
<_habnabit> Aha.
<dash> depending on if you have the qt or gtk plugins installed
<_habnabit> Apparently I have neither.
<maxb> I recommend qlog. Even though I am a GNOME user.
<maxb> qlog is just too shiny not to use, even if I have to install all of Qt to do it
<_habnabit> Is there something that can spit out a dot file, maybe?
<poolie> maxb, it's pretty old, i think we should delete it
<poolie> if the collection code is checked in at all, it will be there
<poolie> it never got to a super useful state though
<poolie> i thought there was a count-bugs.py or something?
<maxb> There is, but it emits human-readable text, not rrd anything
<spiv> _habnabit: there is somewhere
<spiv> _habnabit: the graph-ancestry command from bzrtools
<_habnabit> Aha.
#bzr 2010-12-02
<spiv> _habnabit: qlog/vis are nicer than the dot output, I think :)
<_habnabit> It's still churning away at making the dot output.
<spiv> _habnabit: churning away in the graph-ancestry command, or in dot?
<spiv> I wouldn't expect graph-ancestry to need much time, but I would expect dot could be challenged by a large graph.
<_habnabit> dot was being slow.
<_habnabit> I'm also building python at the same time.
<poolie> \o spiv
<_habnabit> Also this dot output is pretty sweet
<_habnabit> It really just shows merges, which is what I wanted
<_habnabit> I don't care about individual revisions
<poolie> maxb: you legend
<maxb> I'm not sure I deserve that just for deleting some cruft :-)
<maxb> Hmm, we need to define an actual policy for when to promote things to the stable ppa
<maxb> but for now, I think I shall just go ahead and promote bzr 2.2.2 since I've just noticed we haven't ye
<maxb> t
<poolie> wfm
<spiv> poolie: heh
<spiv> poolie: o/
<maxb> poolie: You did review=approve on my hydrazine mp - I take it you also mean merge=approve?
<poolie> yes
<spiv> Hooray, tests passing again.  Now all I need to do is split up the new work into the appropriate prerequisite branches...
<poolie> yay
 * spiv idly wonders how many tests he's run today... hundreds of thousands I suppose.
<lifeless> \o/
<lifeless> parallel much?
<spiv> lifeless: always
<spiv> Well, mostly :)
<spiv> bzr alias pselftest='selftest --parallel=fork'
<lifeless> spiv: nice
<lifeless> I'm glad its getting loved :)
<vila> hello all !
<vila> maxb: I was waiting for bzr-explorer to be upgraded to 1.1.2 before promoting
<vila> maxb: but that could come later anyway
<Tiriel> Hi!
<Tiriel> what are some good tools to model the structure of a VCS?
<Glenjamin> hi guys, i'm getting an error trying to access a branch over https from a location served with loggerhead - the error i get is bzr: ERROR: Server sent an unexpected error: ('error', "'NoneType' object has no attribute 'endswith'")
<Glenjamin> but I can't seem to see anything in log files on the server end to get a trace
<vila> Glenjamin: wow, this is even more obscure for me :) Are you using the most recent version of bzr/loggerhead on the server ?
<Glenjamin> i think i'm using the apt version
<Glenjamin> one sec
<Glenjamin> 1.17
<vila> Glenjamin: Also, IIRC loggerhead can be configured in various ways, including having some sort of private apache instance or something, did you check the apache logs too ? (Or is it a case where logs are lost when used with some web server app framework..)
<Glenjamin> in this case i'm proxying through to serve-branches
<vila> I think you want to retry later with mkanat (he doesn't appear to be online right now)
<Glenjamin> there appears to be a stable 1.18, any idea if there's a PPA?
<vila> hmm, they may be several even... let me check
<vila> Glenjamin: running lucid or maverick ?
<Glenjamin> lucid
<vila> stable bzr ppa carries only 1.17
<vila> same for proposed :-/
<vila> and beta
<vila> Glenjamin: and the loggerhead project on lp mentions only the source tarball, that's all I know about it, sorry
<Glenjamin> no probs, thanks for looking at it
<vila> Tiriel: what structure are you referring too ? bzr internals ? history of a given branch ? relationships between branches ?
<Glenjamin> I could get it to work by proxying smart server requests to bazaar on wsgi instead of loggerhead, but its not that important on that server - was just going to try and get simple http reading for when we dont have ssh
<Tiriel> relationships between branches, and maybe branch history as well
<vila> Tiriel: try 'bzr qlog branch1' and 'bzr qlog branch1 branch2 ... branchn' from the qbzr plugin
<Glenjamin> the branch-ancestry command does something like that from bzrtools iirc
<Glenjamin> branch-history
<Tiriel> Yeah, well, I was lookin for something more like UML modeling for version control systems
<Tiriel> I don't have a deployed system at the moment
<Glenjamin> there's graph-ancestry - that outputs something in dot
<pfarrell> hi, I have a quick question: when I check out an svn repository with bzr-svn, it starts building a cache in ~/.cache/bazaar/svn. I don't want it to put it in $HOME, as that's on the network and really slow. Can I tell bzr-svn to put it somewhere else?
<jelmer> pfarrell: you should be able to make that directory a symlink to somewhere else
<pfarrell> true, yep
<pfarrell> thanks for the suggestion
<alf_> Hi, I am trying to merge a branch containing only one revision and then throw away the changes and replace them with my own. However, when I bzr revert after "bzr merge . -r:tag" the merge is forgotten too.
<alf_> I thought I had to use "--forget-merges" to make bzr bzr forget the pending merge.
<alf_> is this the expected behaviour?
<maxb> alf_: The way it works is as follows:
<maxb> 'bzr revert' reverts tree content and pending merge tips
<maxb> 'bzr revert <paths>' reverts the tree content specified
<maxb> 'bzr revert --forget-merges' reverts only pending merge tips
<alf_> maxb: yes, that makes sense, thanks!
<vila> maxb: regarding ppa promotion, I was waiting for bzr-explorer-1.1.2 before using lp-promote-ppa for the first time ! (You broke my toy :-)
<vila> maxb: not a problem anyway, it's good to have 2.2.2 deployed
<UnhappyVssUser> Hello! We use VSS here with more or less success. Well, now our team gets bigger and the VSS data-file errors more. I want to go to a DVCS. Well, I checked their features and ma happy with them. But!!!! No shared files?? can it be possible? We have all over the place shared files. I think that because I read it in the VSS2Git documentation. So I hope Bazaar can do that.
<piranha> hi all. Is there any examples of how can I do a merge programmatically from Python? I found bzrlib.merge.merge_inner(), but it does seem to only add changes and not revisions. Should I just something like what is done in bzrlib.builtins.cmd_merge?
<vila> piranha: builtins is the best source of knowledge when it comes to bzrlib uses. 'merge' in particular does a lot there
<jelmer> UnhappyVssUser: Hi
<piranha> vila: yeah, it seems so... Ok, thank you, will continue to dig.
<jelmer> UnhappyVssUser: What do you mean by shared files?
<vila> jam: hello !
<jam> morning vila
<vila> jam: I'm freezing 2.3b4, what can you tell me about bug #602614 and bug #680763, should I just remove the milestone ?
<ubot5> Launchpad bug 602614 in Bazaar "Out of memory error on auto repacking" [High,Confirmed] https://launchpad.net/bugs/602614
<ubot5> Launchpad bug 680763 in Launchpad Bazaar Integration "bzr to launchpad is slower than to devpad" [Medium,Triaged] https://launchpad.net/bugs/680763
<jam> vila: can you just retarget it? poolie asked me to keep them on milestones so we see them easily as work items
<vila> hmm, so I'll retarget them to 2.3.0 then
<vila> jam: done
<vila> amazing... I manage to make a typo ending in a line containing 'torturer'... caught by make check-dist-tarball...
* vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: jam | 2.3b4 is frozen, installers build time ! (rm vila)
<cody-somerville> If I have a checkout, what is the shorthand to reference it (ie. parent is to :parent as checkout is to....)?
<cody-somerville> like the remote branch, not the local one
<guilhembi> Hello. If some branch has stopped mirroring from our internal host to launchpad (for some unknown reason), who should I contact?
<guilhembi> any lp admin here?
<guilhembi> jam: hello! do you know? ^
<cody-somerville> guilhembi, #launchpad would be the better place to ask
<cody-somerville> guilhembi, whats the branch?
<guilhembi> cody-somerville: ok, I'll go ask there
<guilhembi> the branch is
<guilhembi> https://code.launchpad.net/~mysql/mysql-server/mysql-trunk
<maxb> cody-somerville: It might be :bound
<guilhembi> "next mirror: disabled".
<jam> cody-somerville: "bzr help location-alias"
<maxb> cody-somerville: bzr help location-alias
<jam> :bound
<Peng> Ooh, I didn't know about that help page! I was just digging in the source code.
<cody-somerville> thanks
 * guilhembi goes to #launchpad
<cody-somerville> guilhembi, Yea. It looks like you'll need to ask a launchpad admin for help.
<servilio> hi all! I am trying to install setuptools_bzr in a Python 2.4 environment, but it fails with "AttributeError: 'KnitPackRepository' object has no attribute 'get_revision_inventory'"
<servilio> already tried with bzr 2.2 and 2.3b4
<servilio> any ideas why this is happening?
<Peng> servilio: Repository.get_revision_inventory() was deprecated and then removed in 2.2.
<Peng> servilio: FWIW you should use Repository.get_inventory() AFAIK, though this doesn't help you too much if the problem is in setuptools_bzr.
<servilio> Peng: thanks! I suspected something like was happening, but I haven't kept track of the bzr internals
<servilio> I tried to install bzr 2.1, but there is no downloadable tarball in pypi looks like
<peitschie> mornin everybody :)
<thumper> morning
<jelmer_> 'morning peitschie, thumper
<thumper> jelmer_: hey
<thumper> jelmer_: I'd love some comment on my email to the bzr list :)
<peitschie> mornin jelmer_
<peitschie> mornin thumper :)
<poolie> hi all
<peitschie> mornin poolie
<spiv> Morning poolie, peitschie.
<spiv> (plus plenty other people...)
<poolie> hi there
<peitschie> hiya spiv
#bzr 2010-12-03
<achiang> hello, can someone explain what i'm doing wrong here? http://pastebin.ubuntu.com/539211/
<achiang> trying to make it so that my streamflow project uses my personal email, not my work email
<achiang> according to the help i found on google, that syntax i used should work...
<mwhudson> achiang: what file is that top section from?
<mwhudson> i think it needs to be ~/.bazaar/locations.conf, not ~/.bazaar/bazaar.conf
<achiang> mwhudson: ~/.bazaar/bazaar.conf
<achiang> mwhudson: hm, interesting
<achiang> i will try again
<achiang> mwhudson: yes, that was it, thank you
<mwhudson> achiang: np
<achiang> mwhudson: the problem was entirely mine. i read this page too fast -- http://wiki.bazaar.canonical.com/ConfiguringBzr
<poolie> hi mwh, achiang
<achiang> the documentation clearly says locations.conf, and i misread it
<achiang> so your documentation is good, i am just dumb. :)
<achiang> poolie: hi
<maxb> $ bzr resolve --take-this .bzrignore
<maxb> 0 conflict(s) resolved, 1 remaining
<maxb> erm, what?
<maxb> (yes, .bzrignore is conflicted)
<maxb> text conflicted, that is
<spiv> maxb: :(
<lifeless> maxb: bzr resolve --take-this .bzrignore.THIS ?
<poolie> maxb, iirc what vila said, it does not mark it as resolved
<poolie> it should
<poolie> we should distinguish "do this to the file" from "mark the conflict as solved"
<thumper> hey
<thumper> how do I set append only for an existing branch on LP?
<spiv> thumper: by editing the branch.conf file, I think :(
<thumper> what?
<thumper> that's a bit primitive
<spiv> thumper: I expect vila's config work will provide UI for this fairly soon
<thumper> spiv: what do I need to add?
<thumper> I'm sure hitchhiker can work wonders
<spiv> append_revisions_only = True
<spiv> Or open the branch object and call br.set_append_revisions_only(True)
<poolie> thumper: thanks for your mail about apis, i'm replying
<poolie> spiv, maybe we should pair together more
<poolie> i was thinking of buying a desktop rather than headset mike
<mkanat> poolie: Any hope of getting my loggerhead changes pushed to LP?
<mkanat> Or approved, at least.
<poolie> good question!
<poolie> did i review but not mark them approved?
<poolie> or... there are probably more still unreviewed?
<mkanat> poolie: Ah, I merged them into loggerhead, but the LP branch push MP is still waiting a review.
<glyph> Hey, I have a workflow hiccup with bzr that I am wondering if you guys can shed some light on.
<glyph> I frequently encounter diverged branches that I don't really expect
<glyph> this is mainly in my 'personal preferences' repository, which I keep on several machines
<glyph> the sort of pattern is this; I'm on a plane, I make some settings adjustment based on some new tidbit of information (like, a shell helper that I didn't realize was doing a DNS lookup or something like that, that I discover because I'm offline)
<glyph> commit locally
<thumper> poolie: cool
<glyph> then later I make changes to the repository on my desktop, push those changes
<glyph> and then, 30 seconds before I go somewhere, I do a quick 'bzr pull' on my laptop
<glyph> oops!  branches diverged.  but my upstream is kind of crappy, so it takes 45 seconds to actually do the SSH handshake with my server, and I'm leaving for a meeting or something, so I just leave without my changes.
<mkanat> glyph: Ah, you have to do a "bzr merge" in that situation instead.
<glyph> mkanat: Oh, I know *that*.  But 'bzr merge' needs to do the SSH handshake again and deal with RTT again and it's slow.
<glyph> More importantly, I have to do something interactive
<maxb> glyph: Perhaps you would be interested in 'bzr merge --pull' (pull if you can, otherwise merge)
<glyph> maxb: Hmm, maybe that is what I want
<glyph> although
<maxb> Of course, you still need to commit and push
<glyph> what I _really_ want is 'pull if you can, otherwise, put the diverged branch in some helpful location in the same repository, so you can merge from it later'
<maxb> Well, it's not the greatest of UIs, but that kind of already happens (except for the helpful bit)
<glyph> haha
<glyph> maxb: is that bzr's motto?
<glyph> maxb: 'that already works, except for the helpful bit'
<maxb> The not-actually-pulled head will be stored in the local repository and visible in 'bzr heads --dead'
<maxb> you would be able to merge it by revision-id later
<glyph> woah
<glyph> that's pretty awesome
<glyph> so the network I/O actually _does_ happen?
<maxb> sure, it's not just pretending :-)
<glyph> well, I knew _some_ did
<glyph> I didn't realize it actually pulled all of the revs though
<glyph> so, how about this
<glyph> if I make a no-tree branch in my branch and then only ever pull into it
<glyph> then I can just do 'cd upstream; bzr pull'
<glyph> and then 'cd ..; bzr merge --pull upstream'
<glyph> when I have a moment to sit and merge later, but potentially no network I/O
<glyph> hmm, if I do 'bzr get . upstream', it works, but it doesn't appear to use the working directory as a shared repository
<glyph> the branch in question is ~/something, and I don't want ~ to be a shared repository.  'bzr init-repository .' complains that '.bzr' already exists.
<glyph> do I have any option here?
<maxb> erm, possibly
<maxb> let me test something....
<maxb> It's rather cheating quite a lot, but it seems as if 'touch .bzr/repository/shared-storage' convinces bzr to use an existing branch's repository as a shared repository for contained branches
<glyph> maxb: hmm
<glyph> maxb: maybe I don't need to do that
<glyph> now that I'm looking at the output of heads --dead, I can see that it's basically doing what I want
<glyph> yeah
<glyph> okay this is cool
<glyph> maxb: thanks for the info
<spiv> poolie: it would be interesting to try pairing more
<spiv> poolie: I'd have to have a bit of a think about headsets etc.
<poolie> perhaps we should just meet up and actually pair?
<poolie> i feel a bit buried with stuff i've already started but really there's no reason we couldn't pair on that
<poolie> or or things you have in train
<glyph> so, now I think I know how to phrase my request
<glyph> spiv: there should be a 'bzr merge --last' (or perhaps just the default behavior of 'bzr merge' if there are pulled-but-not-merged revisions)
<glyph> if 'bzr pull' fails
<glyph> or "if the branches have diverged"
<glyph> it looks like 'push' actually fixes the divergent revisions too?  this is really neat!
<glyph> push actually _pulls_ the divergent revisions
<spiv> glyph: how precisely would you define "last"?
<maxb> merge --last is an interesting concept. It's roughly equivalent to .git/FETCH_HEAD
<spiv> glyph: you mean the head most recently added to the repo?
<glyph> spiv: I *think* that's what I mean, but I don't understand those terms perfectly, so, to be explicit:
<glyph> bzr pull; oops, diverged; bzr merge # don't do any network I/O, you already have a diverged merge tip, just merge it
<glyph> I don't really know about .git/FETCH_HEAD, because one of the best things - perhaps _the_ best thing about bzr, is the fact that it prevents me from needing to learn anything at all about git :)
<spiv> glyph: so the trick is finding the right diverged tip
<spiv> glyph: maybe you have other tips from doing "bzr merge; bzr revert", or from "bzr uncommit".
<glyph> spiv: well, this is why I phrased my requirement that way.
<glyph> spiv: You could have 'bzr pull' specifically remember which tip is the right one, when the branches have diverged, and have other things wipe that memory
<glyph> spiv: 'bzr pull; bzr whatever; bzr merge --last' would just say 'Sorry, last command wasn't a pull, I don't know what tip you mean."
<dmuir> kind of a noob question, but how do I go about manually creating patch files? I've got a situation where I've got two trees with no common base, and I just want to copy over some revisions.
<dmuir> is it simply `bzr diff -c revno > filename.patch` ?
<dmuir> and and then `bzr merge filename.patch`?
<dmuir> hmm, that didn't work
<peitschie> dmuir: I think you need to use the gnu "patch" command to apply the batch
<peitschie> it won't handle renames or binary files correctly however
<dmuir> hmm, ok
<peitschie> dmuir: give this a try? http://www.cuberick.com/2009/02/merge-bazaar-repositories-with-no.html
<glyph> dmuir: 'bzr send'
<glyph> peitschie: woah, that is rad.
<dmuir> hmm, if I understand the cuberick trick, I'm basically cherrypicking the tree as a whole?
<dmuir> I'm still getting a bunch of conflicts, but I think they're all fairly straight forward.
<peitschie> dmuir: sounds about right
<peitschie> glyph: I think send wants to provide a bundle, which pretty much requires a common ancestor?
<dmuir> hmm, send crashed on me
<dmuir> bzrtools's patch seems to do the job reasonably well
<spiv> glyph: ok, I'd call that option --last-pull in that case.
<glyph> spiv: really, I just want it to be the default behavior of 'merge' :)
<spiv> glyph: have a local mirror of the source branch, and have that mirror associated as the parent branch, and you'd have that ;)
<glyph> spiv: any better way to do the branch-and-shared-repository thing?
<glyph> it would just be handy to have the local mirror be an empty dir called 'upstream' ;)
<UnhappyVssUser> In VSS (M****** Source Safe) there are shared files. A file is always in a vss "project" (a directory). If you share it (VSS terminology), the same file can appear in multiple projects. Let's say I have a configuration file "OurCommonConfigs.xml". We have this file in all our Visual Studio projects. But we don't want to manually(!) update it in all places where it is used. When I edit it in project X it should be updated in project Y
<UnhappyVssUser> possible with GIT?
<poolie> this isn't the git channel
<UnhappyVssUser> Err, I mean Bazaar. You see I'm evaluating the various Source control
<poolie> you could store it in a bzr branch and reference it from all your projects
<UnhappyVssUser> systems.
<poolie> by a lnk, or some other means
<poolie> bzr won't automatically update every checkout of it
<spiv> glyph: you can do e.g. "bzr init-repo foo --no-trees; cd foo; bzr init .; bzr pull $my_branch; bzr branch $upstream upstream"
<spiv> glyph: although it might be nicer and simpler to use the bzr-colo plugin
<UnhappyVssUser> Thanks, I'll look up branch and link benhaviour
<vila> hi all
<vila> pingeling about https://code.edge.launchpad.net/~vila/bzr/638451-malformed/+merge/41759
<poolie> hi there vila
<vila> poolie: hey !
<poolie> sorry vila, i really wanted to do that today
<poolie> didn't get to it
<poolie> :/
<vila> Should I just land this mp, I summarized in the cover letter that I addressed the points raised, but I'm always a bit hesitant to do that sort of thing
 * poolie looks quickly
<poolie> i have to go soon
<vila> poolie: yeah, no worries, I've seen a couple of interesting mails from you :)
<poolie> does it actually resolve things?
<poolie> i mean, does it mark the conflict resolved?
<vila> oh yes
<poolie> it looks basically ok
<poolie> so, weak +1 if you're confident to merge it
<poolie> now i have to go; have a good day!
<poolie> and weekend
<vila> poolie: you too ! and thanks !
<vila> too slow ;)
<UnhappyVssUser> Regarding shared VSS files: I have read about the "branch" command but didn't found the "lnk" command in documentation. The branch command creates a new repository! Not really what shared files are. But let's assume I make a branch for this file and put it in a shared repository. When I change the file, I change it in this branch. Then there is another branch (smae repository) which contains the class-files of the program. Is it possi
<UnhappyVssUser> class files and the "Shared" file in the same physical directory the developer uses to work with (say: "C:\Product\CurrentDev\ProjectA\class1.cs" and "C:\Product\CurrentDev\ProjectA\Options.xml")? Do you think the Visual Studio plugin will be able to handle this situation?
<vila> UnhappyVssUser: I think poolie meant 'lnk' as in a link to a file that is not part of the branch you're working in but pointing to a file managed in its own branch
<vila> UnhappyVssUser: the point is that bzr handles trees not individual files when it comes to versioning, and I suspect you don't want this file to be part of every revision in all your project branches
<vila> UnhappyVssUser: because if you revert to a previous revision you don't want to revert this file too
<vila> UnhappyVssUser: or not ?
<vila> UnhappyVssUser: by the way, your previous msgs were truncated making them a bit unclear
<UnhappyVssUser> vila: Sorry for the truncated texts. Opera browser makes that (if you meant the two lines).
<vila> UnhappyVssUser: the first one ends with 'It is poss' and the second starts with 'class files and'
<UnhappyVssUser> It seems I havn't understood the philosophy of bazaar full. Let me explain: VSS is very simple (I hear you laughing, don't!). In a project(directory) you check out your file, edit it and check it in. If you want a version, you "label" it, say "v2.3.44". If you want that version you "get" a "label". too be continued...
<vila> I'm not laughing, I feel your pain :)
<UnhappyVssUser> A "shared file" exists in x directories. If you "label" the directory/project and later "get" that "label" the you get also the "shared file"
<vila> right, so that's a fundamental difference
<vila> with bzr you don't version files, you version trees
<UnhappyVssUser> Well, but what do you do if you want to have the same file on multiple places?
<UnhappyVssUser> Don't tell me you edit all of them manually!!!
<vila> the question is whether you want this file to follow the history of its containing tree or not
<vila> UnhappyVssUser: if you revert a tree to a previous revision, do *you* want this file to also revert to this previous revision ?
<UnhappyVssUser> yes, it should also revert to the previous revision ("label")
<UnhappyVssUser> I'm looking up the "tree" and what it represents in VSS....if there is such a thing
<vila> ok, in this case, you're after nested trees, which are not fully implemented (yet) in bzr, but even there, the plan is to nest *trees* not files, so you'll have to put this file in its own directory (AFAIUI)
<vila> UnhappyVssUser: I suspect a tree is really a label: i.e. the set of (file, revision) that happen to carry this label
<vila> .. but may be not, (how would updates of the shared files propagate to other labels ?)
<UnhappyVssUser> I found it in bazaar doc: http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-vss-users.html
<UnhappyVssUser> A "label" seems to be a tag
<vila> UnhappyVssUser: right, this page says that Share is N/A
<vila> UnhappyVssUser: surely the person that wrote it knows VSS (I don't, I *guess* it's closer to CVS than to bzr)
<fullermd> Well, if you're going to insult CVS...
<vila> fullermd: hey !
<vila> I rarely insult tools anymore these days, they tend to just ignore me when I do that
<fullermd> They ignore me too, but it's still very cathartic to scream at them.
<vila> ... another reason is that ISTM, these insults tend to bounce back at me for trusting the tools too much :-D
<UnhappyVssUser> Ok bazaarians, I'm a friendly person too and this Linus guy makes insults even in pulbic speeches. So I'm not very GIT-friendly. I would prefer Bazaar. When can I expect nested trees? It seems I'm the only guy who has the same file at multiple places. It was not my idea, it's Visual Studio.
<vila> UnhappyVssUser: not soon enough :-/ But there are plugins which tries to address the same kind of compositing, bzr-externals and... bialix will hate me for forgetting the other...
<vila> someone help me ?
<vila> scmproj !
<vila> UnhappyVssUser: http://doc.bazaar.canonical.com/plugins/en/
<vila> UnhappyVssUser: both externals and scmproj are actively maintained and part of the devs (if not all) are on windows too, so they should be able to help you better than me
<UnhappyVssUser> vila: Thanks for the link. More to read...
<UnhappyVssUser> vila: I thank you very much. Very helpful. I'll check the plugins...
<vila> UnhappyVssUser: you're welcome
<UnhappyVssUser> have a good day (The boss appeared at my office ...uh)
<UnhappyVssUser> He does not know of his bazaar luck, yet
<vila> UnhappyVssUser: quick ! Bring up your facebook page ! Enough of this productivity-enhancing tools discussions !!
<UnhappyVssUser> lol
<vila> :)
<UnhappyVssUser> But honestly, this is his thinking
<UnhappyVssUser> unfortunately, we must "introduce" changes secretly until they work and present after they are a success. Before: "costs too much", "no effort in this direction"
<vila> fullermd: by the way, just curious, how would you address this 'shared file' issue in CVS ?
<vila> UnhappyVssUser: Yeah, I know the feeling :-/
<vila> fullermd: CVSROOT/modules tinkering ?
<fullermd> I s'pose you could "ln -s /some/other/repo/foo,v ."
<vila> fullermd: naaah, on windows man, no funny symlinks...
<fullermd> Well, you wouldn't be hosting a CVS repo on windows in the first place...
<vila> fullermd: pff, cheater :D
<fullermd> Man, if we're running CVS, cheating is de rigeur   :p
<vila> LOL
<vila> good to know I can use 'de rigueur' with English people ;)
<fullermd> Oh, did French borrow that phrase from English too?   ;>
<vila> something like that certainly ;D
<vila> ha ! window is easy, just one click is enough !
<vila> The trouble is to find which one...
<vila> mgz, jam: For the record, export BZR_SSH=openssh now works for the babune slave *including* using the ssh keys forwarded from the babune master, \o/
<mgz> for the further record, what exactly did you need to change vila?
<vila> hmm
<vila> the ssh server service should be started by the babune user
<vila> starting a service should be allowed from a user with an empty password
<vila> lp key should be registered in the right known_hosts file
<vila> of course none of those admin tweaks could be recorded in a bzr branch :-(
<mgz> but it's what we have irc logs for :)
<vila> one more test including booting the slave
<vila> hehe
<vila> mgz: http://babune.ladeuil.net:24842/job/selftest-subset-windows/23/console
<mgz> it's blue!
<vila> mgz: also note that bzr has stopped complaining about lp-id
<vila> *subset* !
<vila> this address the msgeditor failure
<mgz> yes, but that subset would have been red.
<vila> yup
<vila> but that gave me 1) a simple subset to play with 2) a strong incentive to address the annoying-for-far-too-long issues :D
<mgz> the remaining issues just need the same thing.
<vila> mgz: note that this morning I was about to re-install windows from scratch before a let-s-try-one-more-thing urge :)
<mgz> well, one's a real tough bug, but I'll find the time to finish squishing that.
<vila> the trick was to find the real error behind: 'can't start the service for this user' and from there find where to click to allow a service to be launched by a user with an empty password...
<vila> mgz: by the way, I tried plink too and I was close to make it work there too, but I resign once I understood that pageant can only be a starting point when it comes to forwarding ssh keys...
<vila> which I reckon is because nobody can run a ssh server properly on windows
<vila> The setup I ended up with, really only works for the the babune user, any other one will encounter the same kind of issue
<vila> which basically are: sshd -> bzr -> ssh
<vila> the ssh processes can't communicate reliably because bzr being a native app broke some cygwin assumption about who owns what including one socket/file required to communicate between the two ssh processes
<vila> mgz: re-running a full test suite to see where we are now
<mgz> that all sounds about right
<mgz> I don't even get checkboxes, needed to use ntrights for some perms stuff for my test setup.
<mgz> and manually setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\limitblankpassworduse
<vila> don't mention guessing how this has been translated in French...
<vila> I've already forgot :D
<vila> and  this was less than an hour ago :D
<mgz> well, I'd forgotten the details too, had to go off and find the script where I'd documented what I'd done when you jogged my memory about blank password problems.
<vila> too bad I didn't know about the ability to do this kind of stuff via scripts, I would have been more prone to record my tweaks this way :-/
<mgz> well, that particular script is 50% docstring and 50% after-the-fact test :)
<vila> yup, I love doc strings for this kind of stiff
<vila> stuff
<vila> oops
<mgz> "do these steps, then running this should start working"
<vila> yeah, better than mere: do this stuff again next time if you're lucky enough to remember
<vila> which, as mentioned above, I'm not very good at ;D
<vila> mgz: I had some hope for some vbox fix in the recently release 3.0.12, but the 'lost connection during test' errors are still there :-/
<vila> 3.2.12 even
<mgz> we will need more informaton on that to work out what exactly is going on.
<vila> I painfully know :D
<vila> mgz: wow, have you ever noticed the 'Age' column in the babune failed tests ?
<mgz> yup, that's why I bugged you about the one you just fixed, because it was new-but-not-random
<vila> excellent...
<vila> mgz: surprising new failures in the launchpad plugin
<mgz> those do look odd.
<vila> mgz: surprising + 3 failures *and* surprising +3 tests... very weird
<mgz> possibly related to your lp login change?
<vila> failed in run #253 but not in #252 with only unrelated changes bewteen the 2 ?
<mgz> sorry, as in:
<mgz> <vila> lp key should be registered in the right known_hosts file
<mgz> <vila> mgz: also note that bzr has stopped complaining about lp-id
<vila> ooooh
<mgz> I'd hope the test would be sufficiently isolated, but it may well not me.
<mgz> *be
<vila> bad test isolation then
<vila> :)
<mgz> def get_lp_login(_config=None):
<mgz>     if _config is None:
<mgz>         _config = GlobalConfig()
<mgz>     username = _config.get_user_option('launchpad_username')
<mgz> looks dodgy.
<mgz> wait... should be fine.
<mgz> config is handled by the default setup?
<vila> TestCaseInTempDir, so it should
<vila> eerk, it isn't
<mgz> I thought you told Gordon it was for his mergetools mp...
<vila> no, I mean, TestCaseInTempDir should, but it seems the test manage to escape it
<vila> unless....
<mgz> ah. well, it's a bug to fix, I can't repo it here unfortunately.
<vila> os.environ.get('BZR_HOME') returns None ???
<vila> urgh: tests.TestCase.setUp(self)
<mgz> ha!
<mgz> I'd not noticed that.
<mgz> one line fix to get you three passing tests again.
<vila> sry, that was obscure, it's in a test class based on TestCaseInTempDir
<vila> how creative we can be to defeat our own checks...
<mgz> yeah, I saw it when you pasted.
<mgz> it looks deliberate, so better just check the mp from barry, but seems like it should just be changed.
<vila> and that fixes them all (of course)
<vila> oooh, I can of recall this mp, I may even be the one that proposed the "fix" :D
<mgz> karma!
<vila> s/can/kind/
<vila> hihi
<vila> I don't quite get how it was passing before though...
<vila> raising InvalidURL because it couldn't connect maybe
<mgz> https://code.launchpad.net/~barry/bzr/609186-shortcuts/+merge/37787
<mgz> ^right, that's my guess, not having a lp user was getting an earlier failure
<vila> nice example of an unexpected success...
<vila> mgz: how to call someone evading jail ?
<mgz> escapee? there are better words I'm failing to remember
<vila> dodger will do :D
<fullermd> Fugitive?
<vila> isolation dodger sounds better for the case at hand I think, it's not that it's running away, it's that it cleverly dodge the part we want to enforce :o)
<fullermd> Evade.
<mgz> that's the one. thanks fullermd.
<mgz> was looking for my copy of great expectations.
<fullermd> Eep.  Good thing I happened by  :p
<vila> pfff, Ã©vadÃ© will you ? :-D
<fullermd> Poker?  I hardly know 'er!
<vila> but I won't use accented letters in a branch name, oh no, I've better things to do ;-p
<mgz> fugitive_launchpad_plugin_tests
<fullermd> Ah yes, Bon Jovi telling us how to write tests   :p
<mgz> I thought they were written by the man with one arm.
<vila> they put several arms in servers these days
<vila> fugitif can also means stealth in french
<mgz> right, it's slightly emphasising the sneaking around trying to avoid recapture rather than the gaol break itself.
<fullermd> I'm pretty sure it comes from Latin, so...
<vila> Tempos fugit ?
<fullermd> Same root.
<vila> indeed
<vila> time feels longer in jail, because you're closer to its roots
<vila> https://code.edge.launchpad.net/~vila/bzr/684662-fugitive-launchpad-plugin-tests/+merge/42605
<vila> mgz: meh, for bzrlib.tests.blackbox.test_version.TestVersionUnicodeOutput.test_unicode_bzr_home  we use get_user_encoding() for a path (BZR_HOME) ??
<vila> mgz: is that the right thing to do or a buggy test ?
<mgz> yeah, and the test is a little bogus anyway which is why I've not bothered squishing it yet.
<mgz> as is the actual implementation, anything using 'safe_unicode' is asking for things to blow up randomly.
<vila> in config.py you mean ?
<vila> I wonder if I added this to make this test pass... in anger
<mgz> it was failing for me (in a different way) before that, I think related to depending on the cwd or environment
 * vila tries a full run without this safe_unicode call
<vila> yeah, indeed, this test fails at a totally different place
<vila> and what's the rule about env vars encoding ? It was discussed before no ?
<mgz> they're in user encoding.
<mgz> can't get at unicode environment with python 2 unfortunately.
<vila> ha ! That was it
<vila> right,single test failing
<vila> so the safe_unicode may be necessary but at a different place
<mgz> no. bad vila.
<vila> but then the test itself is valid
<vila> rhaaa, I meant user_decoding the env var :D
<mgz> is never nessersary, it's just sticking a plaster on it.
<mgz> yup.
<vila> but waitaminute, wan't the discussion saying something different between windows and the others there ?
<vila> (about env var encoding)
<vila> s/wan't/wasn't/
<mgz> well, for nix you can shove any old junk in the environment block
<mgz> if you do that on windows, you're liable to crash your process
<vila> so the decoding should happen on windows only ?
<mgz> well, depends on the abstraction, but on nix we need at least to cope with the idea that the bytes may not be in the user's encoding
<vila> hmm, the problem seems so vague it's hard to address it :-/
<mgz> python 3 basically swaps having a problem on windows (with not being able to access the unicode environment) for a problem on nix (not being able to use arbitrary bytes)
<mgz> which they now 'solve' with a combination of two apis for everything, and the god-awful 'surrogate escape' codec
<mgz> also known as, the 'please break my xml' codec
<vila> you're just adding weight to my remark :)
<mgz> clear abstrations help but yeah, some of this stuff is just complex
<mgz> +c
<vila> basically we should start with s/os.environ.get/osutils.get_env/ or something
<vila> I'm sure this will raise some eyebrows...
<vila> 53 matches...
<vila> wrong, 160 matches, there are os.environ[xx] uses
<mgz> or just limit the apis that access the environment, and make them locale-sane depending on what we're trying to get out (a path, a flag, etc)
<vila> yeah, second step :-/
<mgz> we've still got quite a lot of fiddly little bits of platform-specific code scattered around despite the osutils module
<vila> but I would rather not add this if we don't need to, flag and especially 'etc' shouldn't suffer
<vila> yeah :-/
<vila> I know :(
<vila> right, bug #262874
<ubot5> Launchpad bug 262874 in Bazaar "enviroment may not be in get_user_encoding() on Windows" [Medium,Confirmed] https://launchpad.net/bugs/262874
<vila> mgz: so that's not quite user encoding even :-/
 * vila lunch
<mgz> that's a semantics-and-implementation thing
<mgz> have meant to close that bug out for a while.
<vila> I'll defer to you then ?
<mgz> basically, don't worry about that, and assume it's always in the user encoding.
<vila> err, but isn't the "don't worry" attitude that led us there ? :D
<mgz> not in that case :)
<vila> I'll look into bzrlib.tests.test_transform.TestTreeTransform.test_rename_fails  instead (after lunch ;)
<mgz> what get_user_encoding does is poorly defined, and on windows we'd be better off with a raw GetACP, but that's basically what it does
<mgz> which is also what the mbcs codec uses, so will in the decoding case where all bytes are in the codepage (and it doesn't have to replace invalid ones) do the same thing
<mgz> bt.test_transform.TestTreeTransform.test_rename_fails is one I've got fixed vila, though you may want to add your skip_if_root thing to the top as it relies on a permissions failure
<vila> mgz: meh, fixed where ?
<vila> mgz: I thought the problem was to match on the error string instead of the error code those failing on the slave localized in french, but I haven't really dug so far
<ScottK> Is there a way to checkout/branch just part of a bzr repo?  I just need http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/files/head:/scripts/ and the rest of that repository is frickin' huge.
<vila> ScottK: no, you can't (yet)
<ScottK> Sigh.
<ScottK> Can the duration of yet be quantified at all?
<vila> hardly
<vila> or rather, it would be shorter to checkout the whole :-}
<ScottK> Right.  Just wanted to know if I should ask again next week or in 2020.
<ScottK> (this isn't the first time I've missed this feature)
<vila> ScottK: there are several sub parts to address: one being to transfer no more than the last revision. Otherwise getting a subtree once you have part or all of the history is something that 'views' is supposed to address
<vila> ScottK: but I've never played with 'views' myself
 * ScottK nods
<vila> transferring only the last revision may be worked on, I'm not sure, but it's often asked for UDD so it may happen sooner than I think
<jam> vila: so the debuntu stuff was why Windows was failing from the TEMP paths?
<vila> jam: oh ! hi !
<vila> hmm, no, the debuntu stuff revealed itself once I fixed the babune windows slave config
<vila> jam: damn, my history is too short, waitasec
<vila> <vila> mgz, jam: For the record, export BZR_SSH=openssh now works for the babune slave *including* using the ssh keys forwarded from the babune master, \o/
<vila> <mgz> for the further record, what exactly did you need to change vila?
<vila> <vila> hmm
<vila> <vila> the ssh server service should be started by the babune user
<vila> <vila> starting a service should be allowed from a user with an empty password
<vila> <vila> lp key should be registered in the right known_hosts file
<vila> <vila> of course none of those admin tweaks could be recorded in a bzr branch :-(
<vila> jam: so, from there, the windows slave suddenly got a launchpad login which triggered the test isolation bug
<jam> vila: why does it need an lp login?
<mkanat> Is there anything to guess the mime type of a file in the repository, in bzrlib?
<vila> jam: to get rid of some annoying warnings and use the smart server instead of http
<jam> mkanat: I don't believe there is mime awareness inside bzrlib
<mkanat> jam: Okay.
<jam> vila: is that for the test suite itself? or for other stuff
<mkanat> All I really would want was something that would check the first few bytes of a file in the repo and guess its mime type.
<jam> I'm fine w/ other stuff, but I'd like to understand what the *test suite* is trying to do
<jam> mkanat: to get the first few bytes basically gets all of them
<jam> so you may as well get the text and send it to "file"
<mkanat> jam: Fair enough. I'm trying to avoid that, though.
<mkanat> jam: This is for loggerhead, and I want to return a generator that can stream the file, but I also want to have reliably mime-type guessing. I'm going to be doing it based on the file name, but still.
<jam> mkanat: do what you feel is best, just letting you know that we don't extract partial content
<mkanat> jam: Okay.
<jam> extracting content is probably a O(2x size-of-fulltext deal)
<jam> one for the delta buffer, one for the final text
<mkanat> Sure, I just don't want it in memory if I can avoid it, as much as possible.
<jam> (and 0.5 for the compressed content of the delta buffer)
<jam> mkanat: 'as much as possible' would probably mean extracting it, writing it to a temp file, streaming from that
<mkanat> jam: Well, I was just going to return an iter_bytes or whatever it's called.
<jam> mkanat: that just extracts the whole thing, and probably caches all the intermediate stuff until its done
<vila> jam: both, it makes the pulls faster and it gives access from the slave to the master for planned features
<mkanat> jam: Okay. But will that always be the case? I mean, if bzr improves, I'll get the improvement there too.
<jam> mkanat: I would not expect us to change that for a long time
<vila> jam: including: automated updates for dependencies, upload of artifacts from slave to master, etc
<mkanat> jam: Okay, well, what about the big-file work?
<jam> mkanat: there is one proposal which might break up big content into smaller chunks, but that is goingto complicate whatever you try to do anyway
<jam> vila: all not test-suite related, afaict. I think it is great that you have it. My concern is why it affected the *test suite*
<mkanat> jam: But if it's just an iter, it shouldn't complicate anything.
<vila> jam: the test suite doesn't require ssh access, but the slave get its branches from lp (so far). If you look at some old windows runs, you'll notice the lp-related warning
<mkanat> jam: I suppose the problem is that you have to build the revision text before you can stream it?
<jam> mkanat: well iter_bytes *today* is just [content_string]
<jam> it might change in the future, but that is pretty unlikely at this point
<jam> vila: sure. Though you said "I fixed the login stuff, and suddenly the test started failing"
<vila> jam: yes, that's what happened
<jam> vila: hence my concern why external config is affecting the test suite
<vila> jam: you didn't read the fix don't you ?
<vila> jam: the test was getting a launchpad login by accessing the local bazaar.conf in $HOME instead of the empty one we create under TMP
<jam> vila: ah, ok. So the fix should actually remove the dependency. I did read the fix
<vila> which dependency ?
<jam> vila: the existing code accidentally dependend on the users config because it escaped isolation. You noticed the bug because of changing the user config, which prompted you to fix the dependency. Future test runs should be properly isolated from user config. \o/
<vila> but they are as long as they use TestCaseInTempDir and not TestCase
<vila> these ones are a bit special as in this case they were unexpected successes but I felt it wasn't worth the time to guard against that
<vila> I think I mentioned in the cover letter that they were probably succeeding before because InvalidURL was being raised earlier (while attempting to connect without a proper lp login or something)
<mkanat> Is there a way to get the size of the content that iter_file_bytes is going to return, or do I just have to get all the bytes and then do len(content)?
<jam> mkanat: tree.inventory[file_id].text_size
<mkanat> jam: Awesome, thank you. :-)
<hazmat> when using bzr-pipeline, and switching pipes is there a way a hook can be invoked, i often have *.pyc files that end up cluttering directories that are added and removed, which generates spurious conflicts when navigating up/down the pipe
<mkanat> mwhudson: Do you know what the motivation was behind choosing SimpleTAL for loggerhead?
<mgz> vila: that test will start passing when bug 273978 is fixed, which I have a branch for (unproposed as yet, still needs work)
<ubot5> Launchpad bug 273978 in Bazaar "UnicodeDecodeError when strerror is not ascii" [Low,Confirmed] https://launchpad.net/bugs/273978
<vila> mgz: haaa, good :) Oh yeah, I remember now !
<vila> EOD here (and invited by friends so I'll may poke here far later but that's rather unsure ;)
<mgz> it's one of my top things to do before 2.3 now I've sorted the testing unicode stuff, just need a space to bash it in.
<mgz> food for me too.
<mkanat> Wow, bzr really *is* fast, when you use the API right. It's pretty remarkable sometimes.
<mkanat> I'm doing everything needed to get a file out of the system and send it to the client in 0.05 seconds or less.
<jam> mkanat: simpletal was the fastest reasonable engine at the time, and was used elsewhere, IIRC
<mkanat> jam: Ah, okay.
<mkanat> Is that what Launchpad is using also, or is it using something else?
<jam> I think there was a push at one point to use something like Cheetah, which compiles the same syntax into python bytecode
<mkanat> jam: Yeah, I was thinking Mako actually.
<jam> mkanat: IIRC, simpletal is zope's engine pulled out
<jam> and LP is built on zope
<mkanat> jam: Ahh, okay.
<mkanat> So there's also shared expertise.
<jam> right, though using the same syntax with a faster engine would be fine
<mkanat> It's fine, I don't have any problems with SimpleTAL right now. I mean, no major problems. The templates would be cleaner in Mako.
<jam> I think we wanted to avoid a different TAL
<jam> (template language, if that is actually a bad acronym)
<mkanat> Yeah.
<beuno> mkanat, jam, we went with simpletal because it was fast, and used TAL, which is what Launchpad used, so we where familiar with it
<mkanat> Okay. I think TAL has some nice advantages, but I wouldn't be super-excited about designing a large system with it. Although I suppose you guys did with LP. :-)
<mkanat> I like that it forces you to have valid HTML that at least has closing tags and so on.
<mkanat> And I like the convenience of putting stuff in attributes.
<mkanat> But I think that after a while, it becomes very difficult to read, with everything in the attributes.
<mkanat> Although that does encourage you to keep the templates simple.
<mkanat> It's *very* hard to see the logic flow in a large template with a lot of tal:condition.
<jam> beuno, mkanat: sites like this http://nick.zoic.org/2009/07/29/templates-fugit-3/ doen't make me think simpletal is all that fast. :)
<jam> or this: http://nick.zoic.org/2010/04/
<jam> though I think that is the same guy
<mkanat> jam: Yeah, another reason I like Mako. :-)
<mkanat> Besides the fact that it's the best template language I've ever used, possibly tied with the Template Toolkit.
<mkanat> Well, I think I like Mako more in some ways, though.
<beuno> jam, at the time, simpletal was as fast as the other engines we tried out
<beuno> I implemented loggerhead in a few different engines
<beuno> and our benchmarks where more or less the same or worst
<beuno> so we went with that for familiarity
<beuno> but, this was... 3 years ago?
<mkanat> Yeah, I wouldn't imagine that the template language is a primary performance limiter on LP in any case.
<jam> beuno: I can imagine that it would depend a lot on what you were doing with the template
<jam> I do remember the discussions (though not in detail()
<mkanat> Three years ago, I don't think Mako even existed.
<maxb> Does anyone know, did Savannah ever get a helper to help with Loggerhead?
<mkanat> maxb: Not that I know of.
<jam> mkanat, beuno: My email archives show Mako being mentioned back in 2008-07-09 and also another 2008-07-10 proposal to use SimpleTAL
<mkanat> jam: I think at that time Mako would have been brand new.
<jam> with mwhudson saying: If we could get the same perf out of genshi, I would prefer it,
<jam> and that simpletal is the "fastest tree-based engine"
<jam> (from beuno)
<jam> so the "Tree-based" was probably a familiarity factor
<beuno> right, I did test genshi, and it was slower
<beuno> yes, mwhudson really wanted something tree-based
<jam> he seemed pretty happy with genshi, except the perf sucked :)
<jam> mkanat: anyway, I don't think there is a strict requirement for simpletal, but there should be a strong reason to switch
<jam> since it involves re-building all the dependencies, etc.
<mkanat> jam: Okay. Yeah.
<jam> mkanat: (so if you find that a page request is 0.1s bzrlib time, and 10s simpletal time, and mako would make that 0.01s mako time, that would be motivating. If it makes it 9s mako time, not so much, or if it is 10s bzrlib time, and 0.1s simpletal vs 0.00001s mako, etc)
<mkanat> jam: Yeah, for sure.
<mkanat> jam: I think what I would like about Mako would be the development advantages more than the speed advantages.
<jam> well, you are currently the primary dev on it, but you won't always be :)
<jam> Looking at the differences, I  do find TAL to be a bit strange
<jam> the "replace the current <> with this content" is odd to me
 * mkanat nods.
<jam> but then again here: http://www.makotemplates.org/
<jam> having:
<jam>     % for name in row:         <td>${name}</td>\     % endfor
<jam> is also really odd
<mkanat> But much more readable.
<jam> (lines with % are python control, but they output the content of lines that aren't %, etc)
<jam> goes back to why I didn't like PHP
<mkanat> Yeah, but that quality is pretty much extant in all template languages.
<jam> I was never quite sure what got put out the pipe and what didn't
<mkanat> I mean, that's pretty much the definition of a template language.
<jam> never quite sure what was wrong with """%(data)s""" % {'data': 'foo'}
<mkanat> Well, a lot of things.
<mkanat> One of the cool things that Mako has that no other template language has (that I know of) is inheritance.
<lifeless> mkanat: I don't mind if you change the template language but...
<lifeless> mkanat: it will make it harder for lp devs to debug and fix things.
<mkanat> lifeless: Yeah.
<mkanat> lifeless: I have no immediate plans to make any major changes like that.
<jam> mkanat: I do seem to remember that rendering time was pretty long for stuff like the 'changes' page. about 50/50 IIRC
<mkanat> jam: That wouldn't surprise me, I haven't tested that yet.
<mkanat> jam: Sometimes rendering times are long because we are sending a generator from bzr though, too.
<jam> mkanat: possible, though the bits I saw tend to list(bzr_stuff) before passing them over.
<jam> anyway, glad you're working on it rather than me ATM.
<mkanat> jam: :-)
<jam> also, glad to see you working on it, period
<jam> you went quiet for a bit, and I wasn't sure what was going on
<mkanat> jam: I'm really glad you did the history_db stuff, though--I think for the most part that would have been much too high a level of bzr wizardry for me at this point. :-)
<mkanat> jam: Yeah, some of it was getting contract details worked out, and then some of it was scheduling issues.
<jam> mkanat: thanks, just need to actually get it deployed so it doesn't sit there languishing
<mkanat> jam: Yeah, I want to deploy it more or less once we're ready for 2.0.
<mkanat> jam: In any case, now I'm pretty active on loggerhead, and though my actions are somewhat limited, there's still a lot of stuff I'm planning to do.
<achiang> hello, i'm trying to help a non-technical friend (she is a scientist, not a programmer) use bzr. she's created an LP account, downloaded bzr for windows, managed to pull source from LP, made a change, and committed it locally
<achiang> now she is having issues pushing the branch back to LP
<achiang> the error is:
<achiang> Run command: bzr push "bzr push lp:~lindsayvail/streamflow/newheader\n"
<achiang> bzr: ERROR: Unsupported protocol for url "bzr push lp:~lindsayvail/streamflow/newheader
<achiang> "
<achiang> i guess that's coming from the windows gui tool, which i've never used
<achiang> any hints?
<achiang> ah, she reports that the command line is working for her
<achiang> still, i'd like to know what we might be doing wrong in the windows tool.
<jam> achiang: it at least sounds like she didn't install the lp plugin
<achiang> jam: hm, didn't realize that was a required step
<achiang> jam: thanks for the clue
<jam> achiang: it is part of the installer
<jam> it can be disabled, defaults to on
<jam> achiang: if she was able to branch from the begininng from an lp: url, then that probably isn't it
<jam> because it would work both ways
<achiang> jam: interesting. i don't think she would have turned it off
<jam> the other option
<jam> is that she hasn't informed bzr of what account to use on LP
<jam> I don't remember the gui way to do that
<jam> the command line is "bzr launchpad-login <lpusername>"
<achiang> nod
<jam> achiang: I would have thought that would give more "unable to push to http://..." but it could be a secondary error
<svz90> Hi. I had a quick question about bzr's ssh/sftp module. Is it possible to specify a custom ssh identity file (like with ssh -i somefile)?
#bzr 2010-12-04
<maxb> svz90: Easiest thing to do would be to configure it in your OpenSSH .ssh/config file
<svz90> maxb: Thanks.
<pattern> i've just done a "bzr add foo", but before i committed the change i changed my mind and i no longer want to add "foo"
<pattern> how can i tell bzr i don't want to add "foo" anymore?
<bob2> rm
<bob2> --keep or whatever
<renatosilva> english question: in a commit message like "reverted changeset xyz", reverted is past participle, not simple past, right? that is, changeset was reverted, not I reverted it.
<Meths> As a commit message it would make more sense to say "Reverts changeset xyz" as the message should say what that changeset does.  But in the above either works really, not sure which way it would be interpreted by a grammer perfectionist though.
<fullermd> I'd go with "revert changeset" myself.  Imperative FTW.
<renatosilva> can it be read, is it usually read, as past participle?
<renatosilva> is it "undone commit 123.", "commit 123 undone.", or "undid commit 123."?
<Meths> 3rd IMO
<renatosilva> there's one guy saying 1st could be read as "the commit has undone commit 123"
<renatosilva> and other guys saying "commit 123 undone" ("commit 123 has been undone") is ok, even though 3rd one is more usual
<fullermd> vila: Around?
<vila> fullermd: briefly, may I help ?
<fullermd> I wondered if you've ever seen oddities of selftest on your FreeBSD vm with it locking itself up waiting on a semaphore.
<vila> this doesn't ring any bell, FreeBSD (the babune slave) is on of the most stable (if the not *the* most)
<vila> fullermd: is it something you've seen with an explicit output or only a weird behavior
<vila> ?
<fullermd> Well, for instance, http://babune.ladeuil.net:24842/job/selftest-freebsd/lastCompletedBuild/testReport/bzrlib.tests.blackbox.test_branch/TestSmartServerBranching/test_branch_from_trivial_branch_streaming_acceptance/?
<fullermd> That one.
<vila> while being stable it's also quite slow (compared to the others), but I don't have a good explanation for this
<fullermd> If I run it via 'bzr selftest branch_streaming_acceptance', it runs fine.
<fullermd> If I just like 'bzr selftest' hit it, it just stops dead.  python had 'usem' as a wchan in ps/top.  I've let it sit for 4 or 5 minutes, and gets nowhere.
<vila> haaa interesting
<fullermd> (runs in <3 seconds standalone)
<fullermd> I've tried running a full selftest a half dozen times, and I keep finding new places further on that it locks down.
<fullermd> Except last try around, where I foudn another place _early_ on that it started locking.  Gruuh.
<vila> so, IIRC, that's a test which runs both a client and a server in the same process
 * fullermd nods.
<fullermd> All the ones that lock are of that ilk AFAICS.
<vila> I've been suspecting a weird interaction between python and BSDs (including OSX) but other OSes too (but quite differently) but I've never been able to diagnose precisely enough
<vila> weird interaction around sockets
<vila> some double handling of socket state (especially when both sides of the socket are used in the same process)
<vila> but that's only a theory so far... and pretty weak :-/
<fullermd> Mmm.  And you're using --parallel and somehow don't it it?
<fullermd> (hit it)
<vila> I do use --parallel yes
<vila> well babune that is
<fullermd> Annoyingly it seems like sometimes it sneaks past it fine.  Weird timing stuff; always works when it's part of a short list of tests being run.
<vila> ha, that rings a bell
<fullermd> Would make it easy enough to work around by running a couple times, if it didn't happen 5 or 10 minutes into a freakin' test run...
 * fullermd is now trying `./bzr selftest -x branch_streaming_acceptance -x test_create_clone_on_transport_use_existing_dir -x RemoteBranch -x RemoteBzr`.  Furrfu.
<vila> my suspicion began when there was a bunch of sockets waiting to die which seem to slow the overall run
<vila> which led me to suspect some select() call
<vila> a bit like if python was relying on the OS to sort things out while.... somehow checking until it was happy with sleeps() intermixed... as you can see nothing very concrete
 * vila baktracks
<vila> fullermd: you encounter hangs ?
<fullermd> Except for me, python ends up waiting on a semaphore of some sort, so it never checks again.
<fullermd> Well...  halting problem.  It COULD just be being very very slow, for 4 or 5 minutes, using no CPU and never waking up.
<fullermd> But it sure smells like...  oh, look.
 * fullermd tries a-fscking-gain...
 * vila holds his breath...
<vila> look what ?
<vila> :D
<fullermd> Oh, it locked itself again a thousand or so tests in.
<vila> what's the flag... -Dthreads -Ethreads ?
<vila> -Ethreads
<vila> It was quite useful when debugging the leaks, but I think it was a but too intrusive and led to some failures (changing the output that some tests are checking), so be careful while encountering failures
<fullermd> Well, we're 1600-some in to this attempt...
<fullermd> Aaaand, it does.
<vila> oh yes, lsof !
<vila> lsof was also useful combined with -Ethreads whose output gives the socket references by tests
<vila> both client and server side
<fullermd> % fstat -p59868 | grep -c tcp
<fullermd> 212
<fullermd> That's a couple TCP sockets open...
<vila> that's bad
<vila> so, the other factor here is paramiko which leaves pending sockets
<fullermd> Not a factor here.  I've had paramiko uninstalled for, like, a year and a half.
<vila> but they can't be easily collected as they are internal to pa...
<vila> damn
<vila> one more theory dead
 * fullermd , slayer of theories!
<fullermd> When you say -Ethreads, does that mean some sort of python internal threads, or does it use OS-level threads?
<vila> python threads
<vila> -Ethreads outputs debug statements at various "interesting" points
<fullermd> There are 3 threads in the hung process.  One seems to be sitting in the 'accept' wchan, which I WAG may mean it's sitting in accept(2)...
 * vila hates vbox a bit more every day especially when killing one VM sometimes kill *all* the running VMs
<vila> WAG ?
<fullermd> Wild-Add Guess
<vila> :)
<vila> one thread for the accept(), one thread for the serving, one thread for the client (usually the main one)
<vila> and by the way, the selftest in running with BZR_CONCURRENCY=4 and the VM has 2 processors configured
<vila> s/in/is/
<fullermd> Well, I'm not doing any --parallel'ing.
<vila> I got that, just mentioning
 * fullermd nods.
<vila> I'm running a straight selftest right now
<fullermd> Oh, hey, it locked up only 197 in this time.
<vila> with -Ethreads ?
<fullermd> Only 16 TCP sockets open this time.
<fullermd> Trying that out now.
<vila> this... is surprising, I was pretty sure we collect almost all sockets now, except for the paramiko ones (which aren't relevant here)
<vila> you're running bzr.dev there right ?
<fullermd> Well, locked up, but I guess I should use -v too so's to have some idea where it is...
<fullermd> Well, technically, this is bzr.dev+someotherchanges.  But nothing that would mess with network.
<fullermd> Well, it dumps a pile of information, but I don't see how it's much useful...
<vila> 2700 tests and running and fstat reports only 'internet stream tcp' lines, that's sockets right ?
<fullermd> Yah.
<fullermd> 'sockstat | grep python' should tell you what they are (well, unless you've got a lot of other stuff python running; then grep for the pid)
<vila> it helps making sure the sockets are for past tests not the current ones and it also helps in finding which tests are leaking
 * fullermd frowns.
<fullermd> Hm.
<fullermd> I'm trying t selftest --no-plugins now.  That seems to clean up after itself pretty fast; I'm in the 500's now and nothing hanging around...
<vila> right, ~4000 here and still no socket leaks (only 3 displayed)
<fullermd> Oh, well, that was a good theory while it lasted.  Locked up.
<vila> out of curiosity, what changes do you keep there ? Are you sure they aren't some gems worth proposing ? ;D
<fullermd> Well, I WANT to propose them.  That's why I want selftest to run   :p
<fullermd> Here's an interesting thing:
<fullermd> USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
<vila> ha great :)
<fullermd> fullermd python     60430 4  tcp4   127.0.0.1:39758       *:*
<fullermd> fullermd python     60430 5  tcp4   127.0.0.1:39758       127.0.0.1:16483
<fullermd> That's presumably the socket of the current test.  One of the threads is waiting in accept.  The socket is listening.  But there's also a connection made to it.
<fullermd> That's on a test_pull_smart_stacked_[something]
<vila> yes, could be the client and the accept() or the serving one, -Ethreads should help there no ?
<vila> also, you should certainly see the mirrored one most of the time but if you happened to list while they are killed ?
<fullermd> OK...
<fullermd> ...nching.test_branch_from_trivial_branch_streaming_acceptanceServer thread ('127.0.0.1', 31415) started
<fullermd> Client thread ('127.0.0.1', 10740) -> ('127.0.0.1', 31415) started
<fullermd> fullermd python     60607 4  tcp4   127.0.0.1:31415       *:*
<fullermd> fullermd python     60607 5  tcp4   127.0.0.1:31415       127.0.0.1:10740
<fullermd> fullermd python     60607 6  tcp4   127.0.0.1:10740       127.0.0.1:31415
<vila> 7000 and fstat is still clean as a baby, your 212 number above is still very weird
<fullermd> Only tcp sockets open for the process.
<fullermd> So it's got both sides of the connection open.  But one thread is still sitting in accept.
<vila> sounds fine
<fullermd> And it's dead there.
<vila> there is one thread waiting in the accept, spawning a thread for serving each connection and accept'ing again
<vila> dead and staying dead right now ?
<vila> keep it alive !!!!
<fullermd> Well, it's been a couple minutes...
<vila> seriously,
<vila> this is the dirty bit when shutting down a test server
<vila> what's the test name ?
<fullermd> ...nching.test_branch_from_trivial_branch_streaming_acceptance
<vila> let me see
<fullermd> In this case.  I don't think it matters though; it's semi-random.
 * fullermd just fired off a selftest in a virgin bzr.dev, just for kicks.
<vila> could be, but I want to look at what kind of test server is involved and show you the relevant code so you may have your own take on it
<vila> (not asking to debug it, but look at the code in a context where it seem to be failing )
<fullermd> Man, the relevant code is python.  My take will be "Hey, I can just rewrite that in perl..."   :p
<vila> hehe, no I mean as socket code, whatever the language, we're almost doing C there :)
<fullermd> Remember, any test it's halted on yet, it works just peachy if I run it alone.
<vila> ok, so that's a TestCaseWithTransport so it should be an http server
<fullermd> Or in a small group.  It's only when I run a big enough group (e.g., a full selftest) that it semi-arbitrarily picks a time to lock itself up.
<vila> I've seen very very very weird failures when chasing the leaks
<vila> exactly
<fullermd> Oh, there went virgin bzr.dev.
<fullermd> | [1516/24890 in 3m27s, 1 failed] per_branch.test_branch.TestBranch.test_comm..
<vila> bah, showing you the code is a bad idea, too many classes involved
 * fullermd has no class.
<vila> ha, no, have a look at bt.test_server.TestingTCPServerInAThread.stop_server
<vila> the dirty bit I was referring to is defined there: the server is blocked in an accept call, so we 1) tell him to stop acception connections (after getting out of it's current call), 2) give him a dummy connection
<vila> there is also a if debug_threads():... call that you could copy/adapt/add in various points
<vila> I suspect the case you encounter should be in this area but exhibit an unexpected behavior
<vila> 14000 test and still clean
<vila> hmm, IPV6 ?
<fullermd> All those connections are over 127.0.0.1
<vila> naah, you're running py2.6 right and anyway, I'm pretty sure I've used a variation of the right python code
<vila> we've seen weird things even when using only ipv4 for us, as long as the host is configured for ipv6, (paramiko at least as a bug for this kind of config)
<vila> most of the time we force ipv4 by using 127.0.0.1 but some tests may still use localhost and went unnoticed
<vila> we have some fugitives like that here and there ;D
<fullermd> Just switch it to force ipv6 by using ::1 instead.  If their system doesn't support v6 yet, set it in fire; better for everyone that way   :p
<vila> hehe
<vila> 18000 and still clean, babune:~ :) $ fstat -p1004 |wc -l
<vila>       12
<vila> but if you encounter the problem with bzr.dev and --no-plugins that should rule your proposal out :)
<vila> 20000 and raising briefly at ~40 (paramiko), back at 12
<fullermd> It doesn't seem to [generally] do any notable accumulation of stuff over time.  Most of the locks have no sockets except the current ones.
<vila> but when it blocks it's on a socket right ?
<vila> and one in the accept() state ? (with no foreign address ?)
<fullermd> Yah.
<vila> or are you unsure about that ?
<fullermd> Well, I'm not _sure_ insofar as I've dug into the stack.  But that's what everything looks like.
<vila> so, I encounter weird things when trying the kill-the-socket-with-shutdown approach IIRC
<vila> I tried various ways with mixed results until I ended up giving it a dummy connection and even there I think I tried various tricks before settling on a simple close()
<vila> that's why I suggested adding some sys.stderr.write in this area but if you're blocked on a case where there is no foreign address...
<vila> it kind of means that this last_conn didn't succeed ?
<vila> or did you even not reach reach the point where 'Server thread %s will be joined' ? Or is this message not flushed ? <shudder>
<fullermd> I don't recall ever seeing joins on the locks.
<vila> oook
<fullermd> See the one I pasted ~half hour ago.  The "Client thread started" is the last thing that shows up.
<fullermd> As if the server thread sat in accept() waiting for the client thread (which the OS sees as connected), and never got out of accept().
<vila> that part is expected, the server thread has spawned another thread
<vila> what isn't expected is that this spawned thread can't finish (or its related client thread)
 * fullermd sighs.
<vila> the client thread being the main thread
<fullermd> It sucks trying to figure out why changes were made when you can't ask the maker   :|
<vila> so, this kind of hang is the hardest
<vila> which changes ?
<fullermd> The ones I'm working on cleaning up, which led me to trying selftest in the first place.
<vila> which changes ? :D
<fullermd> upgrade enhancements.
<vila> ha :-/
<vila> err, may I misinterpreted here, you mean in upgrade.py ?
<fullermd> Yah.
<vila> qblame mentions only living people, so you should be able to reach them no ?
<fullermd> Yes, that would be for the existing merged code, not the outstanding unmerged.
<fullermd> Which is igc   :(
<vila> ha, I didn't misinterpreted :-/
<vila> you're digging an old mp ?
<fullermd> https://code.launchpad.net/~bzr/bzr/smooth-upgrades/+merge/8921
 * vila reading
<vila> by the way, the selftest succeeded here with only: bzrlib.tests.test_smart_transport.TestServerHooks.test_server_started_hook_memory is leaking threads among 2 leaking tests.
<vila> 1 non-main threads were left active in the end.
<vila> hmm, lots of stuff there ;-/ Nice to see you working on it, I should leave now, but I'll be pp next week and will look at anything you'll submit, so feel free to begin with high level questions or even re-start the discussion on the ML
<vila> --pack should be useless, --cleanup I think has been implemented elsewhere, so it's worth having a look at that while it still makes sense to propose it there (I went with a bunch of upgrades lately and could have used it)
<fullermd> You're thinking of pack --clean-obsolete-packs I think.
<jelmer> fullermd: that's an interesting mp
<fullermd> Yeah, it should be a real nice addition to 2.0.0   :|
<jelmer> :-P
<fullermd> 's one of the things whose continued absense pisses me off.  I don't really have time or inclination to work on it, but I have even less of both to keep not having it.  Sigh.
<fullermd> vila: Just dropped what I could do on it.  Enjoy your piloting   :)
<nonix4> if revision x in branch a adds file c, and revision y in branch b adds file d, where d is actually descendant of c... is there a simple way to tell that to bzr after both commits have been made? (both mentioned revisions containing other unrelated changes as well)
<fullermd> I'm not sure what you mean by "descendant".  But the answer will be "no".  Once you've made a revision in the current World Order, it's too late to go back and tell bzr more about it.
<nonix4> except for uncommit?
<fullermd> Well, semantics.  Even uncommit doesn't change a revision, it just pops things off the top of the history and throws them away.
<fullermd> There is occasional discussion about ways to _annotate_ information after the fact (specifically to this case, things like equivalences between separate files).  But it's all speculative and far-future, which doesn't help anything now.
<nonix4> well... how about cherry-picking creation of one file from a distant branch?
<fullermd> You could do that.  Being a cherry-pick, it wouldn't record any of the revision info.  But it would use the same file-id.
<mgz> ah, was going to ask about the 'local oddities' fullermd ran into with the test suite, but I see it's in the history so I'll just read up.
<mgz> I'd be interested if lp:~gz/bzr/cleanup_testcases_by_collection_613247 helped though, I recall freebsd has som lower default resource limits than other nixes so leaks could hurt
<lifeless> hi mgz
<lifeless> mgz: if you're interested in testrepository, I would love to know if trunk still works on win32
<mgz> hm, looks more like 's just theclient-server tests being dodgy still from the log
<mgz> lifeless: I'll pull and test.
<lifeless> thanks!
<lifeless> mgz: its specifically 'testr run' I'm hacking on
<lifeless> mgz: I've added a SIGPIPE fixup for unix
<lifeless> but that may bork win32 subprocess invocations
<mgz> hm, some kind of import issue
<mgz> I wish the framework didn't hide that stuff
<lifeless> ?
<mgz> ...  File "C:\Python24\lib\unittest.py", line 532, in loadTestsFromName
<mgz>     parent, obj = obj, getattr(obj, part)
<mgz> AttributeError: 'module' object has no attribute 'tests'
<mgz> not useful.
<lifeless> ah yes
<lifeless> I filed a bug on python
<lifeless> and there is one on testtools too
<lifeless> workaround
<lifeless> python
<lifeless> import testrepository
<mgz> yup.
<lifeless> import testrepository.tests
<lifeless> ...
 * lifeless wags on testrepository.ui.cli
<mgz> what are the dependencies explictly?
<mgz> I'm failing to find them documented anywhere.
<lifeless> cat INSTALL.txt
<mgz> doh.
<mgz> okay, I'll fix up my python path and go again.
<lifeless> the autotools have kindof devalued that file
<lifeless> which is a bit sad
<mgz> ...
<mgz>   File "C:\bzr\testscenarios\lib\testscenarios\scenarios.py", line 26, in ?
<mgz>     from itertools import (
<mgz> ImportError: cannot import name product
<mgz> will fix that and see what else I hit.
<mgz> so, your sigpipe fixup also wasn't valid 2.4 syntax, but that and a few other things look like easy fixes.
<mgz> 17 failures, a bunch look quoting related.
<lifeless> heh
<mgz> some rename-over-existing-file ones.
<lifeless> feel like filing bugs?
<mgz> only if I can't fix 'em.
<lifeless> cool
<lifeless> well I'm mid rewrite of run to do parallel test invocation
<mgz> hm, so, could either fix the quoting in commands.run, or make it use a subprocess pipe rather than a shell pipe. you got any strong feelings there?
<lifeless> thats one of the things I'm mid rewrite on
<mgz> okay, will leave that one for the mo.
<mgz> a test with a tempdir that needs quoting in would be worth adding though.
<lifeless> the shell=True is for shell expansion
<lifeless> mgz: please do
<fullermd> mgz: Yeah, it's not a resource limit.  More something squirrel with the sockets.  Race or sumfin'.
<mgz> wow python-dev has had a lot of long pointless threads of late.
<lifeless> yeah
<lifeless> win
<mgz> lifeless: I hate DocTestMatches, it's awful. Down to six failures though, four of which are quoting related.
<lifeless> mgz: :(
<lifeless> mgz: I'd welcome a more powerful full text matcher
<mgz> fullermd: I'd be interested if you give that branch a run anyway, though it probably won't help. I'll do yours in turn to check you've not regresses anything.
<mgz> lifeless:
<mgz> FAIL: testrepository.tests.test_testr.TestExecuted.test_runs_and_returns_run_argv_no_args
<mgz> AssertionError: Match failed. Matchee: "True True True
<mgz> ['b:\\temp\\tmprbtwer\\testr']
<mgz> "
<mgz> Matcher: DocTestMatches('True True True\n[...]\n', flags=8)
<mgz> Difference: Expected:
<mgz> I don't see why that's a mismatch, and the output sucks.
<mgz> it possibly has an extra newline off the end? who knows.
<mgz> the test_bdist was even worse because it prints pages of text every time.
<mgz> I don't think the Matcher scheme works well with more than one line of text, the top thingy needs to know about every leaf object to not spam you.
<lifeless> mgz: it should have printed a difflike thing
<mgz> but the matchee is always printed anyway.
<mgz> `assertThat(some_giant_thing, WhateverMatcher)` brings pain.
<lifeless> mgz: that can be changed
<lifeless> mgz: OTOH its good to be able to see definitional errors
<mgz> it's good to be able to see more than the tail of the last failing test's output.
#bzr 2010-12-05
<mtaylor> jelmer: awake? you grok git, right?
<ryan_scott> I've got two branches/repos cloned from the same SVN.  I want to merge the latest changes from one into the other.  I can generate a patch file and apply that, but it seemed like merge could facilitate this.
<ryan_scott> However it's not working and I can't quite tell why.  It seems to be mis-identifying files (like using the wrong -p# would)
<ryan_scott> I tried using --verbose to maybe get some hints, but that's not helping me in this case.
<ryan_scott> Anyone have any pointers?
<ryan_scott> Found out my issue was this: https://bugs.launchpad.net/bzr/+bug/318620
<ubot5> Ubuntu bug 318620 in Bazaar "When merging two branches without common ancestry, Bazaar provides no means to map file IDs" [Medium,Confirmed]
<Kamping_Kaiser> jeees, bzr just ate all my resources o.0
<Kamping_Kaiser> oh, only 40% for bzr, vim has 10%. i take it back *g*
<ryan_scott> Is there a way I can do a merge and ignore conflicts by using the version in the branch?
<Ddorda> âhey guys, i commited and pushed a first rev, now i wish to remove it and to push a fixed commit. is that possible? i tried using uncommit + push, but it says "No new revisions to push." - any ideas?
<Kamping_Kaiser> Ddorda: you may be able to --force it, or just sacrifice commit #2
<Ddorda> âKamping_Kaiser: bzr: ERROR: no such option: --force
<Kamping_Kaiser> Ddorda: --overwrite is what i was thinking of, but hang around, you may get a better one
<Ddorda> âKamping_Kaiser: --overwrite doesn't work either
<Ddorda> âKamping_Kaiser: No new revisions to push.
<vila> Ddorda: this sounds like you're using a checkout (or a bound branch) and in this case you don't have to push as commit already put the new revision there
<fullermd> mgz: Doesn't change anything; still deadlocks itself with your 613247 branch.
 * fullermd waves at vila.
<Ddorda> âvila: and when i use branch and not checkout only after push it really pushes it, right?
<vila> _o/
<vila> Ddorda: yup
<Ddorda> âvila: thanks
<Ddorda> â:)
<vila> Ddorda: 'bzr info' is the best way to understand which branches are involved
<Ddorda> âyea, that what i did
<Ddorda> âthanks
<lifeless> mgz: hey
<mgz> hey lifeless.
<lifeless> when do you think 2.4 will die?
<mgz> probably soonish.
<lifeless> thanks for your branch/bug
<mgz> all systems will ship something newer these days, so it's just a question of how many old machines there are.
<mgz> for most python packages, assuming 2.6 or 2.7 is reasonable.
<mgz> but likewise, not many actually *depend* on any particular new feature, just get written to the modern syntax and style
<lifeless> right
<lifeless> testtools explicitly supports 2.4
<lifeless> so deps for it (fixtures, scenarios) need to support 2.4, until we decide to raise the minimum
<poolie> hi lifeless, mgz, spiv
<poolie> i'm going to work offline for a while this morning
<peitschie> mornin all :)
#bzr 2011-11-28
<lifeless> jelmer: poolie: fwiw dealing with tarmac failures is ~ the same opaqueness as pqm, from my observations of nontrivial projects that have migrated :)
<poolie> :/
<poolie> don't know what you're smiling about
<poolie> ;)
<lifeless> habit
<lifeless> or something
<thumper> what does conflicting tags mean on 'bzr pull' ?
<spiv> thumper: both sides have a tag named 'FOO', but they disagree on which revid FOO refers to.
<thumper> spiv: so how can I say 'pull and use their tags' ?
<spiv> --overwrite
<thumper> hmm...
<thumper> ok
<jelmer> there is also bug 681792
<ubot5> Launchpad bug 681792 in Bazaar "wishlist: bzr pull --overwrite-tags" [Medium,In progress] https://launchpad.net/bugs/681792
<spiv> (Or delete the offending tag(s) locally and pull again)
<thumper> jelmer: thanks
<thumper> jelmer: do you understand the package recipes? robert_ancell was asking me about them
<robert_ancell> I'm trying again to get the logs of what goes wrong...
<robert_ancell> simple question: does http://paste.ubuntu.com/752089/ look correct and are the branches in the correct format?
<robert_ancell> I tried to use lp:ubuntu/simple-scan as a packaging branch initially but I don't think it has the correct relationship to lp:simple-scan to work (it had merge conflicts)
<jelmer> robert_ancell: yes, though I don't think that version of bzr-builder can be entered on launchpad yet
<robert_ancell> jelmer, yes, I subscribed to that bug
<jelmer> robert_ancell: the version looks a bit odd, though with {date} as the debian revision
<robert_ancell> Now it is failing with 'dpkg-buildpackage: error: version number does not start with digit' because it pulls out the wrong version number (I was using simple-scan-VERSION tags but I'm now using just VERSION).  Any way to delete the old tags on the server?
<jelmer> robert_ancell: it's fine if the branches aren't related, so long as they don't have overlapping files
<jelmer> robert_ancell: bzr tag -d lp:simple-scan --delete TAGNAME
<robert_ancell> jelmer, yes, been playing around with the version number, needs some work
<robert_ancell> jelmer, I have to build with --allow-fallback-to-native - will that work on the server?
<jelmer> robert_ancell: yes, launchpad has --allow-fallback-to-native enabled by default
<jelmer> robert_ancell: alternatively, you could tag the upstream version with 'upstream-X.Y', and it would create an orig tarball for you
<jelmer> or change the package to be native
<robert_ancell> ok
<robert_ancell> jelmer, any idea when 0.4 will work?  Or is there another method of getting the version number in 0.3 I can use?
<jelmer> robert_ancell: {debupstream-base} might do what you need to
<jelmer> *too
<robert_ancell> jelmer, the issue is that requires me to update debian/changelog right?
<jelmer> robert_ancell: yes, but only for upstream releases
<jelmer> robert_ancell: in bzr we e.g. use {debupstream-base}bzr{revno}~daily{revno:packaging} for most packages
<robert_ancell> right.  For most of the packages I want to do I am upstream and I want to set it up and then forget about it
<jelmer> robert_ancell: that works for us too, because we end up updating the debian/changelog version when we do a release
<jelmer> robert_ancell: and then do a matching upload to debian/ubuntu
<robert_ancell> jelmer, I know I'll forget to do it :)
<jelmer> robert_ancell: you're not uploading to ubuntu ? :-)
<jelmer> (we use the same branch for ubuntu packaging as for the daily PPA)
<robert_ancell> jelmer, no, these are daily builds to a PPA for upstream testers
<robert_ancell> the Ubuntu packaging has some patches, merges from Debian and may not be running the latest version
<jelmer> robert_ancell: in that case you'd probably indeed want to wait for the 0.4 support
<robert_ancell> jelmer, thanks for the help
<poolie> so apparently if you call accept from one thread and connect from another, python can sometimes deadlock in futex()
<poolie> nice
<lifeless> on different sockets?
<poolie> on the two sides of the same socketpair
<poolie> simulating a server in process
<lifeless> interesting
<poolie> ie this fixes it http://bazaar.launchpad.net/~mbp/bzr/2.5-client-reconnect-819604/revision/6209#bzrlib/tests/test_bundle.py
<poolie> "fixes"
<poolie> the loop doesn't fix it, only changing to a nonblocking select
<lifeless> possibly accept isn't giving up the GIL ?
<poolie> seems likely
<poolie> i guess i should see if i can reproduce it and file a bug
<poolie> it's kind of a stupid thing to do imo
<spiv> It pretty clearly releases the GIL in 2.7.2: http://hg.python.org/cpython/file/8527427914a2/Modules/socketmodule.c#l1656
<poolie> hm
<spiv> In the past all our sockets+threads deadlocks have turned out to be bugs in our logic, not cpython
<poolie> :)
<poolie> that does seem likely
<poolie> but, strace shows one side in accept and one in futex
<poolie> ...
<spiv> (Although arguably perhaps because the APIs offered aren't as convenient/safe as one might hope?)
<poolie> the futex not being released by getting eintr from accept
<poolie> when i say it's stupid i mean i think running the server inprocess is a bit likely to fail
<poolie> anyhwo
<spiv> Well, that shows that one side is in accept, and the other side is stuck in a lock â quite possibly a lock owned by pure Python code (e.g. a threading.Mutex in a Queue.Queue)
<poolie> that is possible
<spiv> It would be extremely helpful if strace could magically distinguish between "Python VM internal lock" and "Lock exposed to Python application code"
<lifeless> pytrace is pretty good at that
<lifeless> (gdb + py* macros I mean)
<poolie> i was excited for a second there
<poolie> i'll try to hit it again and use gdb
<poolie> it's inside lock_PyThread_acquire_lock
<poolie> ah inside threading.join?
<spiv> poolie: doesn't sound like a vm bug :P
<poolie> :)
<poolie> ah :)
<poolie> apparently closing a socket does not interrupt threads that are accepting on that socket
<poolie> so that explains why alternating selecting and accepting avoids the problem
<spiv> That sounds familiar.
<poolie> yeah
<poolie> spiv, so basically the patch is reasonable but the explanation is wrong
<vila> hi all !
<poolie> hi there vila
<vila> poolie: hmm, what patch and explanation are you talking about ?
<poolie> i think i understand why that was hanging
<vila> great ! I'm all ears :)
<poolie> https://code.launchpad.net/~mbp/bzr/2.5-client-reconnect-819604
<poolie> oops no mp
<vila> I can review that locally, nw
<poolie> no apparently that's not everything
<vila> poolie: 'accept from one thread and connect from another' leading to hang rings a 'ipv6' bell
<vila> where one side get an ipv4 socket but the other got an ipv6 one
<vila> may not apply but encountered several times
<poolie> pretty sure that's not it here
<vila> also, 'not being released by getting eintr from accept', *only* the main thread get interrupts
<vila> poolie: which test(s) is/are hanging ?
<poolie> test_bundle test_smart_server_connection_reset
<poolie> at least
<vila> poolie: will it help to focus on getting an external smart server running first and only then look at those failures ?
<poolie> mm
<poolie> i think no, really
<poolie> although i'm down on running the server in process, in this case the bug could have happened the same way externally
 * vila get a weird 'table turned' feeling
<vila> genuine surprise, no smiley there
<vila> poolie: I only get one failure with your branch and it looks genuine: bzrlib.tests.test_smart_request.TestSmartRequest.test_all_registered_requests_are_safety_qualified
<poolie> we seem to have a regression that selftest does not exit 1 on failure
<poolie> that might be a known bug
<poolie> vila, right that seems genuinely out of date with jelmer's changes
<poolie> vila, you ran everything and that was the only one?
<vila> yes
<vila> twice
<vila> ha, spoke too soon, the second is hanging at 26507 in 4m50s, 1 failed (hanging test unknown though)
<poolie> i wonder if we couldn't have a test fixture that sets an alarm
<poolie> which one?
<vila> ok, got it by lurking below /tmp: bzrlib.tests.test_bundle.TestReadMergeableFromUrl.test_smart_server_connection_reset
<poolie> that's the one i'm fixing
<poolie> that's the one i'm fixing
<poolie> vila, i'm adding a config option for a timeout
<vila> for the select ?
<poolie> globally
<poolie> :/
<poolie> how do i actually get a value from the command line?
<vila> for the test ?
<poolie> nm
<vila> poolie: from a config stack ? conf.get('mytimeout') but remember those are reset for tests, we may want something like -E (used for debug flags) but for test options
<poolie> i think a regular option is ok as long as it's read early enough
<poolie> possibly we need a way inside tests to get the real config stack
<vila> if you get the option before the test is started, you're fine
<vila> s/started/create/
<vila> d
<poolie> yep, it's ok now
<poolie> i wonder if there should be a timeout by default
<poolie> perhapsonly from make check
<poolie> vila does babune run make check or just selftest directly?
<vila> selftest directly
<vila> why does the test name mentions smart server when no smart server is involved there ? (Or do I misread the test?)
<vila> ha, silly, bzr:
<poolie> i wonder if there should be a timeout by default
<vila> a timeout for what ? All socket based requests from the clients ?
<poolie> for tests
<poolie> well https://code.launchpad.net/~mbp/bzr/test-timeout/+merge/83559
<vila> hmm, lp downtime
<wgrant> Nearly back.
<vila> back
<wgrant> Nope.
<vila> err, weird
<sagaci> heh
<wgrant> There we are.
<vila> the importer said: down, down... back.. down, down... back
<wgrant> vila: Ah, yeah.
<wgrant> It went down for 35 seconds, came back because it failed, then we retried.
<vila> ooh, thanks
<wgrant> But it was down for the second time when you mentioned it here.
<vila> yeah, I lag :)
<vila> but the importer did cope well, not fallout failures
<vila> poolie: reviewed, BB:tweak
<poolie> thanks
<poolie> got to go
<poolie> back later maybe
<mgz> morning all
<vila> mgz: _o/
 * jelmer waves
<mgz> hey jelmer
<m1sc> what's the right way to delete a branch?
<mgz> m1sc: delete the directory. there's also `bzr rmbranch`
<m1sc> mgz: ok. it's a shared repo - the data is garbage collected automatically?
<mgz> nope, but it's generally insignificant. if not... I don't think we have a better way than making a new shared repo, mirroring all the branches you care about, then replacing the old repo.
<m1sc> mgz: bzr rmbranch <mybranch> gives me "Not a branch.." oO special syntax required?
<mgz> when `bzr info` on the same path tells you it's a branch?
 * mgz just deletes the directories, with shared repos there's not much that can go wrong there.
<m1sc> mgz: nope, it doesn't. must be my fault, works for other branches.. thank you.
<jelmer> hmm, it seems that the hpss-call-count test for 'bzr verify-signatures' is spuriously failing
<mgz> as in, some runs gives a different value and some runs doesn't?
<mgz> rather than just the value being wrong, which wouldn't need much comment :)
<vila> jelmer: yup, was about to mention it, could it be that some variations happens because readv groups differently depending on the compression results ?
<vila> jelmer: in other words: if both 22 and 21 can occur, you may just relax the assertion there to accept both
<jelmer> vila: yeah, indeed
<vila> indeed as in related to readv grouping ?
<jelmer> yes, and also indeed: we should just be accepting both
<vila> hehe, double indeed then ;)
<vila> jelmer: yup, spurious, I got 2 failures out of 3 runs locally
<jelmer> vil: https://code.launchpad.net/~jelmer/bzr/verify-signatures-spurious-hpss-call-counts/+merge/83583
<spiv> jelmer: yes, that sort of thing is another reason to remove VFS calls: to make the call counts more deterministic :)
<deni> hello everyone
<deni> am i mistaken (doing something very wrong) or does bzr ignore *.o files by default?
<jelmer> hi deni
<deni> and is there a way to disable that behavior?
<jelmer> deni: it does, see ~/.bazaar/ignore
<jelmer> spiv: :)
<deni> jelmer: oh ok, tnx...didn't realize it
<mgz> deni: versioning build artefacts is a very bad idea, what's the reason behind wanting to commit a .o file?
<vila> jelmer: approved
<jelmer> vila: thanks!
<jelmer> vila: are you going to post a followup branch to 2.5-client-reconnect-819604 ?
 * jelmer bumps his branch back to needs-review
<vila> dunno :-/ I see your vote *after* posting my 2 comments and refreshing the page
<jelmer> vila: I posted that vote before you commented
<vila> yup, I realizeD that
<jelmer> vila: so, with your comments in mind, I think it would be nice to improve the branch
<vila> ok, I'll submit one then
<deni> mgz: i know i know....it's a whole tree of bad ideas that lead to this. :D anyway, deployment reasons
<vila> jelmer: your branch still fails test_smart_request.TestSmartRequest.test_all_registered_requests_are_safety_qualified
<vila> jelmer: with AssertionError: These requests were not categorized as safe/unsafe to retry: ['Repository.get_stream_1.19', 'Repository.insert_stream_1.19']
<vila> jelmer: which is weird as there were more of them earlier this morning (but I haven't precisely tracked which version I used vs what you fixed since then)
<jelmer> vila: r6124 ?
<jelmer> vila: err, r6214 ?
<vila> 6215
<vila> but the last one is mine
<jelmer> test_smart_request.TestSmartRequest.test_all_registered_requests_are_safety_qualified passes here
<jelmer> and get_stream_1.19/insert_stream_1.19 do indeed have a categorizatin
<vila> urgh, it just passed 8-/
<vila> trying again, that was woth --parallel=fork
<vila> (the failure was for a full run with --parallel that is)
<vila> jelmer: hmm, I've pushed my fix on lp:~vila/bzr/819604-fix-test-bundle
<vila> it may be easier for all involved if you just merge it into your proposal rather than me using yours as a pre-requisite
<vila> safety_qualified failed again
<vila> isolation ?
<vila> lazy loading ?
<knielsen> I want the result of `bzr branch -rA t t_A; bzr branch -rB t t_B; cd t_A; bzr missing --include-merges ../t_B`. A is a parent of B. Can I do it without needing to create the two branches t_A and t_B?
<knielsen> `bzr log -n0 -rA..B` does not work when A is not the primary (main-line) parent of B
<knielsen> `bzr missing` has --my-revision and --revision arguments, but again it seems not to work for non-mainline parents (the docs seem unhelpful for this)
<vila> knielsen: doesn't 'bzr log -n0 -rA..B --exclude-common-ancestry' work ?
<jelmer> vila: with the same requests?
<vila> jelmer: yes
 * knielsen checking
<jelmer> vila: pulled into lp:~bzr/bzr/2.5-client-reconnect-819604
<knielsen> vila: no, it doesn't work. `bzr log -n0 -rA..B` is missing a changeset that `bzr missing` shows (and --exclude-common-ancestry does not help with this)
 * vila curses complicated log implementation
<vila> knielsen: you know branch accepts a --no-tree parameter ? Branches are way cheaper to create this way if you have a big working tree
<knielsen> the obvious answer would be `bzr missing --include-merges --my-revision=A --revision=B .`, but I could not get this to work, in fact I could not get --my-revision to do anything for some reason...
<knielsen> vila: yes, probably will need to go with explicit branches and --no-tree
<knielsen> should be ok, though I need to do this for a couple of 1000 revisions
<vila> if '--revision A --revision B' is accepted, it should translate to '-rA..B' or nothing is really wrong
<fullermd> knielsen: Don't overlook that you don't need to keep creating new branches for all those thousand.  You can just create A and B branches once, and use 'pull' in 'em to reset their revs for each run.
<knielsen> fullermd: right, interesting idea, might help
<fullermd> (and with them in a shared repo with your source branch, all those resets will be cheap, since no data needs to be transferred)
<vila> knielsen: 1.000 revisions... I can't imagine what you're trying to achieve...
<knielsen> hehe. I'm trying to get an overview of a very complicated merge. I have a list of commits that were merged and pushed into a tree in sequence, and I want to for each one know how many revisions were merged in that push
<knielsen> and I just wanted to try understand how `bzr log` worked with non-mainline revision ranges. But `bzr branch --no-tree` branches several trees per second, so I think that will be plenty sufficient for my needs
<knielsen> tnx for the help
<vila> knielsen: did you give 'bzr qlog' a shot ? It's pretty good at showing which revisions were merged into each mainline revision
 * knielsen will try qlog also ...
<vila> It may be slow to start (for big & complex histories), but you'll start it only once
<knielsen> vila: the main thing is that the mainline revisions do not correspond to the pushes into the tree, as there has been no discipline about in which order to merge before pushing
<vila> You can also give several branches and it gives a pretty good view of what has been merged
<vila> knielsen: argh, yeah, makes it hard to understand what is shared :-/
<knielsen> so I re-constructed a list of the commits that existed in the main tree during time. Many of these commits are not mainline revision, and many main-line revisions are not on the list
<vila> knielsen: append_revisions_only is your friend to converge to such a workflow
<knielsen> vila: yep :)
<jelmer> vila: do you have any plugins loaded when running the testsuite?
<vila> jelmer: I ran with BZR_PLUGIN_PATH=-site
<jelmer> vila: found it - we override verbs in the testsuite, but don't cope with info=
<vila> jelmer: where ?
<jelmer> vila: override_verb() and disable_verb()
<vila> ha, right, bad cleanup, I see
<jelmer> vila: can you try again with my last commit to ~bzr/bzr/2.5-client-reconnect-819604 ?
<vila> revno 6217
<vila> running
<vila> jelmer: right fix, confirming isolation issue, note that the proper (and usual way) to do that is to overiddeAttr(request.request_handler) and populate it with a copy (out of scope for your branch)
<vila> jelmer: run succeeded, the fix is good
<vila> I got one spurious failure though:
<vila> bzrlib.tests.per_interrepository.test_fetch.TestInterRepository.test_fetch_parent_inventories_at_stacking_boundary_smart_old(InterDifferingSerializer,RepositoryFormatKnitPack6RichRoot,RepositoryFormat2a)
<vila> with a slightly different error for the client: ConnectionReset: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<vila> so reconnecting doesn't help there (despite the hopes)
<jelmer> yeah, me too
<vila> jelmer: reliably ?
<jelmer> vila: no, it seems to be spurious
<vila> right, would have been too nice
<mgz> ugh, the reconnection branch changes the way our current random failures fail?
 * fullermd . o O ( If they're really random, you can't tell   :p   )
<mgz> they have a limit axis of randomness fullermd :)
<mgz> they either pass, or fail in a specific way.
<mgz> they don't turn into elephants.
<fullermd> Well, that sucks.  No wonder nobody runs the test suite.
<fullermd> Without a good payoff like that, it's so not worth it.
<jelmer> mgz: ugh indeed
 * jelmer thinks the value of elephants is widely overestimated
<fullermd> How else could we get revision info into pachyderm files?
<jelmer> fullermd: zlib?
<mgz> jelmer: are you nearly done passing all your hpss branches? :)
 * mgz doesn't want to merge trunk for news till he's sure of getting a free slot
<jelmer> mgz: it's all in the queue now
<mgz> cool
<jelmer> mgz, vila: so, I wonder what we should do about the ~bzr/bzr/2.5-client-reconnect-819604 branch
<mgz> cry?
<jelmer> is the remaining spurious failure worse than what we have at the moment?
<vila> the only way to know is to land it
<vila> why should it be worse ?
<jelmer> vila: for me, it *seems* to occur more often than the ones currently present, which I can't reproduce at all
<jelmer> of course that's all totally unscientific, and I don't think we should hold that against it
<jelmer> vila: but yeah, perhaps we should JFDI and rather than let it sit there for a couple more weeks
<vila> as an experiment I'm running for i in {1..10000} ; do echo $i ; ./bzr selftest -s bzrlib.tests.per_interrepository.test_fetch.TestInterRepository.test_fetch_parent_inventories_at_stacking_boundary_smart_old -v InterDifferingSerializer  -Ethreads ; done for bzr.dev revno 6311
<vila> I had 58 failures for 1837 runs so far
<jelmer> vila: ah, interesting
<vila> more failures when babune run jobs
<vila> but at least it means there is a way to reproduce, slow, painful but reproducing nevertheless ;)
 * jelmer does another merge of lp:bzr
<jelmer> vila, mgz: can either of you have another look at it again too?
<jelmer> hmm
<jelmer> vila: "merg hokk", is that Swedish for merge hook ? :P
<vila> sry was afk (cooking), oook ? In the COVER or in the code ?
<fullermd> Well, we wouldn't want to interrupt your cokking...
<jelmer> vila: in the cover, so not really something that requires fixing
<vila> arf, in the cover letter ;) Right, tyop, I thought hhtp was too last century ;)
<jelmer> fullermd: vila is the Swedish chef?
<fullermd> Dunno.  Do you actually cook Swedes?  I thought they were better just smoked...
<vila> tagliatelles a la carbonara, more likely to be Italian
<jelmer> vila: nice work on the po merge hook! submitted a review
<jelmer> I wish writing these was easier..
 * jelmer calls it a day
<croepha> im making some build scripts, and I was wondering if there was a way to get a revison number for just a file or a directory and the files under it? or maybe just a way to tell if thoese files have changed since a specified revision?
<lamalex> hey bzr, im trying to do bzr lp-propose-merge but it seems to be coughing since im using pipes and colo
<lamalex> bzr: ERROR: file:///home/alex/Code/unity/.bzr/branches/rip-out-ap/trunk/ is not registered on Launchpad
<lamalex> any ideas?
<lamalex> do i just need to push my first pipe (which is just a clone of trunk) to lp?
<Noldorin> hi poolie, jelmer
<Noldorin> has Markdown support landed on LP yet?
<jelmer> hi lamalex
<jelmer> hi Noldorin
<jelmer> Noldorin: this isn't really the right channel for that question
<lamalex> hola jelmer
<jelmer> noldorin: the lp folks are working on markdown support?
<Noldorin> jelmer, true, but it's not that inappropiate either ;-)
<Noldorin> jelmer, they are indeed. poolie for one
<Noldorin> jelmer, how are you coming along on bzr-git anyway? i'm looking forward to the repo fix i want as a christmas present :-)
<jelmer> Noldorin: sorry, lots of other more important stuff to fix first..
<Noldorin> :( :-(
<Noldorin> jelmer, what's so much more important, i want to know?
<Noldorin> this seems like a MAJOR bug...it prevents the most basic functionality of bzr git on some repositories
<Noldorin> and not even very special repositories
<Noldorin> for me, this would be #1 priority... i struggle to think of a more important one
<Noldorin> sorry, i just find it hard to believe :-S
<jelmer> Noldorin: push support in bzr-git is still experimental, the focus is on importing from git into bzr at the moment
<Noldorin> jelmer, oh is that right?
<jelmer> Noldorin: in addition, you're hitting a particular corner case
<Noldorin> jelmer, sorry didn't know
<Noldorin> jelmer, i'd dispute calling it a "corner case" (seems fairly simple), but i can accept that git -> bzr importing is more important :-)
<jelmer> Noldorin: I use dpush on a regular basis and I've never hit that particular issue.
<Noldorin> jelmer, oh well. maybe i'm jsut strange ;P
<jelmer> Noldorin: I'm not trying to say the bug doesn't matter, but there's more things that deserve attention. This is just one.
<Noldorin> jelmer, no no, i concede that. now that you've stated that git to bzr importing is your main goal
<Noldorin> jelmer, i'm going to hope, but not expect, for new year :-P
<fullermd> Noldorin: There's a good chance there'll be one in a month or so  ;p
<Noldorin> fullermd, oh yes? that's good to know :-P
<Noldorin> fullermd, you work on bzr-git too huh?
<fullermd> Never touched it.
<Noldorin> oh
<Noldorin> how do you knwo good chance ina month or so then? :-P
<fullermd> 15:40 <Noldorin> i'm going to hope [...] for new year
<fullermd> 'cuz I can read a calendar   ;p
<Noldorin> fullermd, yeah but that's making the bold assumption that my hope is a liklihood :-P
<fullermd> Well, unless the world ends, it's going to be hard to NOT wind up with a new year in about 5 weeks.
<fullermd> (I don't rule that out, to be sure.  I just hope there's enough warning to make popcorn.)
<Noldorin> fullermd, oh dear. you were making a cheesy joke by taking my sentence out of context. i just saw :-P
<Noldorin> fullermd, makes sense now at least.
<fullermd> It does?  That should worry you...
<Noldorin> heh
<Noldorin> perhaps
<Noldorin> but not too much
<poolie> hi all
<Noldorin> hi poolie
<GRiD> hello
<poolie> jelmer, the reconnect thing still has some  logical conflicts with your new hpss verbs
<poolie> i'll try to fix them up and send it
<jelmer> 'evening poolie, GRiD
<jelmer> poolie: the ~bzr -owned version? That merges lp:bzr fine here
<lifeless> jelmer: logical, not textural
<lifeless> texual
<lifeless> bah
<lifeless> textual.
<jelmer> lifeless: oh, right.. logical and logical conflicts...
<poolie> specifically some tests fail because your new verbs do not specify whether they can be safely retried
<poolie> anyhow i will finish it today
<jelmer> poolie: are you sure you have the last revision? vila and I had it pass the full testsuite today, including the HPSS stuff
<poolie> jelmer, no i probably don't
<poolie> i was just talking about my last result yesterday
<poolie> if you guys fixed that, do land it
<poolie> or perhaps you already did
<jelmer> ah, cool
<jelmer> poolie: actually, vila had some follow-up to your blocking-accept fixes, and I did some conflict resolution
<jelmer> poolie: it should be ready to land, but if you'd like to have another look at the recent changes, that'd be great
<poolie> ok i will
#bzr 2011-11-29
<poolie> ok back to memory usage
<poolie> so much state to pick up
<vila> hi all, hey poolie
<poolie> hi there vila
<poolie> hi jam :)
 * jelmer waves
<mgz> morning all
<jelmer> hey mgz
<mgz> poolie, vila: standup?
<poolie> oh hi
<poolie> was having so much fun
<poolie> good idea
<vila> mgz, jelmer, poolie: I found the pad for last week standup, will post it (thought I did...) as well as the one for this week
<poolie> ok thanks
<mgz> so... I guess for the installer work I need access to the ec2 instance and urk, probably something other than just ssh
<poolie>  probably you do
<poolie> do you have an AWS account?
<mgz> nope.
<mgz> standard signup okay?
<jelmer> vila: I've got a pending MP for bzr-upload from October, I was wondering if you'd seen it: https://code.launchpad.net/~jelmer/bzr-upload/only-strip-slash/+merge/80111
<vila> err, yeah I saw it, I thought I merged it 8-/ Let me check
<vila> hmm, obviously I didn't...
<poolie> mgz, hm, i might need to send you credentials
<poolie> i don't think you actually have to sign up
<poolie> jam1, hi?
<mgz> poolie: that might be better, otherwise they want card etc from me
<mgz> I may have trouble till PSU gets delivered, as I lack windowsy things currently
<jam> poolie: hi
<poolie> jam, could you help mgz get the windows ami going so he can build an installer etc?
<jam> poolie: sure, mgz, you around?
<poolie> urk
<poolie> that's enough
<poolie> jam if you want you could read https://code.launchpad.net/~mbp/bzr/890085-add-bytes/+merge/83735
<poolie> it doesn't directly improve anything though
<poolie> was kinda hoping it would
<poolie> perhaps will leave it on the shelf until it's more clearly useful
<mgz> jam: I'm around but what will I need this end? A spider did for my windows machine.
<poolie> rdesktop will do
<jam> mgz: yeah, its on an ec2 instance
<jam> poolie: did you want to make add-bytes have a prereq of BigString so that the review is simpler?
<jam> or you want them together
<poolie> it's actually independent
<poolie> i rebased it out
<poolie> ..
<poolie> perhaps lp needs to be told
<poolie> jam, should be better now
<jam> the web page looks good
<jam> the email didn't
<poolie> i think it doesn't always email updates
<poolie> not sure of the logic
<jam> poolie: so we actually need to change the Pack code to take a [chunks] parameter instead of a 'bytes' one.
<poolie> i know
<poolie> i'd really better go
<poolie> i know this isn't sufficient by itself
<poolie> i hoped it would show an incremental improvement but apparently not
<jam> I'll comment on why it isn't sufficient, have a good night.
<poolie> i'm a bit surprised there is nothing though
<poolie> i do understand other stuff is joining up the strings
<jam> poolie: well, we have to ''.join() the zlib chunks to pass it to the pack parameter
<jam> and then we delete the chunks
<jam> so there is one peak
<jam> then the pack code does it *again*
<jam> and we have the second peak
<jam> we have to get rid of both
<poolie> yep
<poolie> got that
<poolie> so mostly for this review i'm hoping for "not wrong" and "in the right direction"
<vila> jelmer: sorry, in parallel with your review, I realized I missed the points you re-raised, was about to say so in the proposal ;)
<pitti> hello
<pitti> who is responsible for http://bazaar.launchpad.net?
<pitti> today's Xubuntu CDs failed to build because http://bazaar.launchpad.net/~xubuntu-dev/ubuntu-seeds/platform.precise/ ceased to exist
<pitti> but https://code.launchpad.net/~xubuntu-dev/ubuntu-seeds/xubuntu.precise exists, and bzr pull works fine, etc.
<Peng> pitti: #launchpad in general
<pitti> Peng: ok, will try there, thanks
<jam> pitti: I have a feeling a $platform forgot to be expanded.
<jam> $platform vs platform, etc.
<Peng> Ooh, good catch
<Peng> http://bazaar.launchpad.net/~xubuntu-dev/ubuntu-seeds/xubuntu.precise/ works
<Peng> And https://code.launchpad.net/~xubuntu-dev/ubuntu-seeds/platform.precise does not exist.
<jam> yeah, you can go to: https://code.launchpad.net/~xubuntu-dev/ubuntu-seeds to see what branches exist underneath it.
<pitti> oh, I see
<Peng> pitti: Sorry for the hopping back and forth.
<pitti> sorry, missed that
<pitti> I'll go back to poking the cdimage folks then :)
<pitti> actually, it seems it's meant to be like that, it just had trouble reading http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.precise
<pitti> but that works, so maybe it was just a glitch; I'll retry the build
<jam> pitti: ~ubuntu-core-dev/.../platform.precise is not the same as ~xubuntu-dev/.../platform.precise
<jam> "(10:42:12 AM) pitti: today's Xubuntu CDs failed to build because http://bazaar.launchpad.net/~xubuntu-dev/ubuntu-seeds/platform.precise/ ceased to exist"
<pitti> jam: right, as I said I just misunderstood the logs
<jam> ah, ok
<jam> the names are pretty similar
<pitti> it apparently tries to pull the "platform" seed for both the derivative and ubuntu
<jelmer> vila: np, I figured you just missed it
<pitti> and both failed, I just looked at the wrong one
<vila> jelmer: ping, po_merge options registrations,
<vila> good catch (my god, what was I thinking !), but lazy won't gain us anything here
<vila> it's useful only it it helps *not* loading additional stuff from the plugin but nothing is required here
<vila> importing config is required but it is also required to register the options anyway
<jelmer> vila: it prevents running the constructor of the option objects, not sure how heavy that is
<jelmer> and potentially having to import whatever method is used for from_unicode
<vila> Option() constructor should be << import config time, if a specific from_unicode method is needed, yes, lazy should be used to get access to it
<vila> overall, I should use lazy to set a good example :) Will fix
<mgz> ahh, a windows machine, it's been so long...
<mgz> (well... since thursday)
<mgz> ...a java update is available, okay, novelty has worn off
<vila> mgz: probably a TZ update :-}
<vila> jelmer: are bug #894461, bug #368717 and bug #608640 fix released or not ? tool/check-newsbug.py is confused :)
<ubot5> Launchpad bug 894461 in Bazaar "HPSS call for Repository.pack" [Medium,In progress] https://launchpad.net/bugs/894461
<ubot5> Launchpad bug 762330 in Bazaar "duplicate for #368717 lightweight checkout over hpss is slow, many roundtrips" [Medium,Fix released] https://launchpad.net/bugs/762330
<ubot5> Launchpad bug 608640 in Bazaar "bzr export from remote branches downloads way more data than it should" [Medium,In progress] https://launchpad.net/bugs/608640
<vila> the duplicate is weird in itself but what about the others ?
<jelmer> vila: I've marked #894461 fixreleased
<jelmer> vila: it's debatable whether the other two are fixreleased yet
<jelmer> the HPSS branch for Repositor.iter_files_bytes is the first part of it, I consider the HPSS call for Repository.iter_inventories also necessary for it
 * vila nods
<zyga> hi
<jelmer> hi zyga
<zyga> is there any way to speed up accessing bzrlib.branch.Branch().nick on a checkout?
<zyga> it takes veery long, much longer than revno() which is the other thing I'm intereted in
<jelmer> zyga: there has been some talk on making branch.Brnach().nick only access the local branch, and synchronising it on "bzr up"
<jelmer> zyga: in the mean time, you can use:
<jelmer> bzrlib.branch.Branch._get_nick(local=True)
<zyga> oh!
<zyga> excellent
<zyga> how will that differ from the other method?
<zyga> will it raise exceptions or return out-of-date data?
<jelmer> it only accesses the local branch nick, not the remote one
<jelmer> so you'll also have to explicitly set the local branch nick
 * zyga checks what it does on his branches
<hrw> hi
<jelmer> hi hrw
<hrw> I have question (again). probably one of stupid ones. I have lp:~hrw/ubuntu/precise/gcc-4.6/cross-fixes branch and want to generate diff against lp:ubuntu/precise/gcc-4.6 branch. is there other way then fetch both and then diff directories?
<jelmer> hrw: in theory you could do the diff without downloading the branches. with the current smart server deployed on Launchpad, that will probably be about as slow as actually pulling down the branches.
<hrw> jelmer: first branch I already have on disk
<hrw> s/have/had
<hrw> I fetched second one and diffed dirs
<hrw> have to experiment with bzr-colo later
<hrw> as with git I would have both in one .git
<hrw> bb in ~20 minutes
<zyga> hrw: yes
<zyga> hrw: bzr diff --old one-branch --new other-branch
<zyga> hrw: you can skip either argument if you are in a branch already
<jelmer> hrw: you can fetch into a shared repository without trees, that should have the same behaviour as bzr-colo or a single .git directory
<jelmer> bzr init-repo --no-trees gcc; bzr branch lp:~hrw/ubuntu/precise/gcc-4.6/cross-fixes gcc/cross-fixes; bzr branch lp:ubuntu/precise/gcc-4.6 gcc/4.6
<zyga> jelmer: I think hrw already has a shared repo for gcc
<zyga> so he has 99% of the data locally already
<zyga> also, with 'bzr diff' you don't need trees
<jelmer> zyga: in that case, I don't understand why bzr-colo / .git would are better
<zyga>  jelmer they are not
<zyga> they are identical
<hrw> jelmer: I have a feeling that when I ask about bzr and branches I will always see 'bzr init-repo --no-trees' ;)
<hrw> zyga: lp:linaro-gcc != lp:ubuntu/gcc-4.6
<zyga> hrw: sure but they may share ancestry
<hrw> zyga: they have one thing in common: 3 letters in branch name ;D
<hrw> jelmer: will try your stuff
<vila> hrw: '3 letters in branch name' seriously ? Not a single revision is shared ? parallel imports ?
<hrw> vila: lp:linaro-gcc is copy of gcc source code. lp:ubuntu/gcc-4.6 is debian/ubuntu packaging for gcc-4.6
<hrw> like you would compare linux kernel and qt5 repos
<mgz> jelmer: is there actually a dulwich 0.8.1 release? I didn't see a tag for it.
<vila> oh, upstream and packaging-only branches ? sry, missed that detail
<mgz> ..there is... I just don't have the tag
<jelmer> mgz: ah, you're trying to build the windows installers?
<mgz> yes and it's all your fault >_<
<mgz> ...I have one that now works with `bzr info git://...`
<jelmer> mgz: what about "bzr clone git://
<jelmer>  ?
<jelmer> I'm not sure much network activity bzr info generates
<vila> jelmer: bug #897690 filed for ObjectNotLocked on jubany
<ubot5> Launchpad bug 897690 in bzr-builddeb "bzrlib.errors.ObjectNotLocked raised when calling _mark_native_config" [High,Confirmed] https://launchpad.net/bugs/897690
<vila> jelmer: I think I have a fix (testing)
<vila> yup, seems to work, proposing
<mgz> also works, but tells me 'clone' is deprecated :)
<jelmer> vila: ah
<vila> jelmer: https://code.launchpad.net/~vila/bzr-builddeb/897690-object-not-locked/+merge/83790
<vila> with hopefully enough explanations
<jelmer> vila: looking
<jelmer> vila: I think you're missing one of the return paths in _default_config_for_tree
<jelmer> vila: (still returns 2 elements in the tuple rather than 3)
<vila> crap, you're right
<jelmer> vila: other than that, it looks good to me
<vila> jelmer: including the debian/changelog ? Not sure if I got this right
<vila> missed return path fixed
<jelmer> though it is slightly odd that path2id doesn't require a read lock..
<vila> it does
<vila> it has a @needs_read_lock decoratr
<vila> tor
<jelmer> vila: right, but's slightly surprising imo
<vila> yeah, was about to guess a rationale but ended up with a poor one :)
<jelmer> vila: not sure if this needs mention in the changelog btw, the regression isn't in any releases
<vila> but anyway, digging this route won't address the current issue so I punted
<vila> ha, so I just remove that and merge to lp:bzr-builddeb ?
<jelmer> vila: right - +1ed
<vila> ECANTPARSE :)
<jelmer> vila: yep
<vila> ha
<jelmer> vila: approved :)
<vila> done, deploying on jubany (including a newer bzr.dev as you've fixed set_root_id(not None) which needs to be deployed too)
<vila> bah, of course, chromium-browser is running... shudder
<vila> s/running/imported/
<vila> hmm, tiplog fall in the infamous 'access self.branch.control_transport on a smart branch' trap :-/
<jelmer> vila: it seems tiplog has no choice but to fallback to VFS anyway though
<jelmer> when it's pushing stuff, etc
<vila> yeah, was thinking along the same lines, I never realized it was pushing a file to lp though which is... surprising,
<vila> I thought lp was strict about which files were allowed...is *anything* allowed below .bzr ?
<vila> scary
<jelmer> vila: yes
<jelmer> vila: but don't dare creating a file outside of .bzr
<vila> I haven't looked closely, but the trap is really that even if it doesn't *need* the control_transport later, ensure_real has fired anyway
<jelmer> vila: the scanner will without warning delete your branch
<vila> ha good
<mgz> uploading windows installers now.
<jelmer> vila: did you run the testsuite before landing?
<jelmer> vila: https://launchpadlibrarian.net/86194438/buildlog_ubuntu-oneiric-i386.bzr-builddeb_2.7.9%2Bbzr649~oneiric1_FAILEDTOBUILD.txt.gz
<vila> nope, I only tested on my case :-/
<vila> fixing
<vila> fixed
<vila> jelmer: pushed, really sorry about that :-/
<jelmer> vila: no worries, thanks for fixing the other bug
<jelmer> which was a regression in *my* code :)
<vila> what I don't quite get is why it didn't trigger earlier but I suppose there are more code paths
<vila> than the one used on the importer
<mgz> I say that, was wondering why it prompted for password, and after uploading everything now it says there was an auth problem
<vila> mgz: enable js ;-p
<vila> (just kidding)
<mgz> I don't really see how curl is meant to be doing auth here, presumably via the single sign on somehow?
<vila> curl ? Is that the recommended way ? Isn't there a script that will use lp API ?
<mgz> the script uses curl, I'm guessing there's no lp api for uploading files
<vila> note that I don't know what I'm talking about here...
<mgz> lp:bzr-windows-installers ./upload_to_launchpad.py
<vila> ok, I reverse my advice: Are you sure this script is used ? :0p
<mgz> jam manages it!
<mgz> so it must work somehow.
<jam> mgz: --user USERNAME:password
<mgz> okay, that worked, need to manually enter lp email address and pa... each time
<jam> but yes, Launchpad lets you post your entire document before it tells you your password is wrong
<mgz> or not, like that
<jam> it is because uploading the file is a POST
<jam> which doesn't validate the info until the post has finished streaming the body.
<mgz> or three whole documents, in the last case, because the curl output wasn't flushed :)
<mgz> hm, I didn't add '-1' in the filenames
<mgz> do I really want 20 minutes more upload time to fix that...
<jelmer> is it really that much?
<vila> nope, you have an allowance of 3 bad uploads across 2 releases as the new maintainer :)
<vila> ghaaaa Alarm clock
<mgz> time to wake up vila!
<vila> hehe, I wasn't sleeping, I was thinking !
<vila> while debugging a test and the new test timeout triggered losing my context ;)
<vila> I'm probably not the last to fall into this trap ;)
<mgz> ehehe
<mgz> yeah, need to cancel out on pdb break in I guess
<vila> mgz: yup, my thought exactly (but invading pdb.break is hard, TestCase.debug on the other hand...)
<mgz> not sure what to do about my last git related issue from earlier
<mgz> I guess I could put up the patch I used ripping setuptools out of dulwich, on moral grounds
<mgz> but looks like losing the `./setup.py test` thing might upset some people
<mgz> and I didn't record the exact failure but just hacked around it as it was clearly setuptools sucking as usual
<mgz> jelmer: if you have any thoughts^
<mgz> basically dulwich didn't work with buildout till I made it believe setuptools didn't exist as it was installing to a path it objected to for whatever reason
<mgz> there's probably a buildout level fix but I didn't try and find it.
<vila> bingo, 13 failures less on jubany (if only new ones could stop appearing ... ;)
<jelmer> mgz: hmm
<jelmer> mgz: dulwich' setup should work without setuptools, can't you remove it on your local system?
<mgz> the build bot needs it for other things, I can possibly kill it at the correct level next time
<jelmer> \o/ 'bzr checkout' and 'bzr checkout --lightweight' are now VFS-free
<supton> what's the best practice for merging a feature branch to a mainline while preserving history of each changeset in the feature branch, without rebasing?  I rebased a mainline on a project last night, and now I feel a bit icky.
<mgz> ...just merge it?
<supton> mgz: right, tried merging, resolving conflicts, then committing, but I want to preserve the diffs per-changeset on the feature branch on my mainline.  If I push my merge to launchpad, and I view history, IIRC, I don't see this.
<jelmer> supton: that history is still there, you can view it with e.g. "bzr qlog" or "bzr log -n0"
<supton> so I uncommitted a merge and had the mixed luck of thinking, I'm the only one using the mainline, why not just rebase it from my dev/feature branch.
<supton> jelmer: cool.
 * supton needs to figure out what plugin qlog is in
<mgz> it's part of qbzr.
<supton> now, I need to figure out how to undo my rebased branch pushed to lp, so I can do this right
<supton> mgz: thanks
<mgz> but just for the history of the last merged change, try `bzr log -c-1 -n0 BRANCH`
<supton> I wonder if I can rebase back to a common revision, then merge properly?
<supton> I shouldn't have pushed this, but for lack of sleep, I did
<mgz> `bzr uncommit lp:PROJECT` works, you just want to be quick enough that no one pulled yet :D
<mgz> (otherwise, it's not the end of the world, and you can just leave the merge proper in next time)
<mgz> sometimes with very messy branches you're better off flattening them, like `bzr merge ../FEATURE && bzr revert --forget-merges && bzr commit --author contrib@example.com -m"...description of change..."`
<vila> mgz: sounds like a plugin...
<supton> mgz: good idea, thanks.
<mgz> I despair of ever getting this guy to set up a http smart server correctly.
<tkamppeter> hi
<jelmer> hi tkamppeter
<tkamppeter> I have cleaned a file from UTF-8 characters to make it pure ASCII and then committed it to bzr+ssh://till-guest@bzr.debian.org/bzr/pkg-cups/cups/debian-trunk.
<tkamppeter> Then the bzr client crashes with a traceback:
<tkamppeter> bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 349: ordinal not in range(128)
<tkamppeter> Traceback (most recent call last):
<tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 946, in exception_to_return_code
<tkamppeter>     return the_callable(*args, **kwargs)
<tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 1150, in run_bzr
<tkamppeter>     ret = run(*run_argv)
<tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 699, in run_argv_aliases
<tkamppeter>     return self.run(**all_cmd_args)
<tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 721, in run
<tkamppeter>     return self._operation.run_simple(*args, **kwargs)
<tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 135, in run_simple
<tkamppeter>     self.cleanups, self.func, *args, **kwargs)
<tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 165, in _do_with_cleanups
<tkamppeter>     result = func(*args, **kwargs)
<tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/builtins.py", line 3316, in run
<tkamppeter>     lossy=lossy)
<tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/decorators.py", line 217, in write_locked
<tkamppeter>     result = unbound(self, *args, **kwargs)
<tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/workingtree_4.py", line 209, in commit
<tkamppeter>     result = WorkingTree.commit(self, message, revprops, *args, **kwargs)
<tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/decorators.py", line 217, in write_locked
<tkamppeter>     result = unbound(self, *args, **kwargs)
<tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/mutabletree.py", line 210, in commit
<tkamppeter>     *args, **kwargs)
<tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/commit.py", line 289, in commit
<tkamppeter>     lossy=lossy)
<tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 131, in run
<tkamppeter>     self.cleanups, self.func, self, *args, **kwargs)
<tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 165, in _do_with_cleanups
<tkamppeter>     result = func(*args, **kwargs)
<tkamppeter>   File "/usr/lib/python2.7/dist-packages/bzrlib/commit.py", line 440, in _commit
<tkamppeter>     self.rev_id = self.builder.commit(self.message
<tkamppeter> How can I commit this file? Problem is probably that the diff between the old file and the new file contains non-ASCII characters.
<mgz> amusingly despite all that, I don't see the bit of the traceback I need
<mgz> !pastebin
<ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<mgz> for future reference tkamppeter
<tkamppeter> mgz, http://paste.ubuntu.com/753917/, with calling command.
<tkamppeter> Bazaar (bzr) 2.4.2 on Oneiric with Python 2.7.2.
<mgz> how did you supply the commit message? are you using bzr-builddeb or did you manually enter it with an editor?
<mgz> retrying with `bzr commit -m "A message that's really just ascii"` will probably work,
<tkamppeter> mgz, seems that bzr-builddeb is in use and already pre-configured, as "bzr commit" does not open an editor if I commit in that repository.
<mgz> okay, what bzr-builddeb version?
<tkamppeter> "bzr diff" output is on http://paste.ubuntu.com/753921/.
<tkamppeter> I will try the -m metyhod now ...
<mgz> nope, don't.
<mgz> you probably just need to update bzr-builddeb
<mgz> the file is a red herring, it's 'Martin-Ãric' causing the problem (which is fixed in the latest bzr-builddeb version)
<mgz> bug 853664
<ubot5> Launchpad bug 853664 in bzr-builddeb "tries to decode debian/changelog as ascii, and fails when it's not" [Medium,Fix released] https://launchpad.net/bugs/853664
<tkamppeter> mgz, thank you. Used the "-m" to not need to wait for the update.
<jelmer> hmm, I don't think that's actually released yet
<mgz> ...you marked it as such though!
<jelmer> ah, it's in 2.7.9
<mgz> jelmer: that's where the version markers in launchpad are useful :)
<jelmer> mgz: unfortunately it's not possible to assign a closed milestone to a bug
<jelmer> mgz: which is often useful after the release has happened
<mgz> there's a (slow, manual) trick to that
<mgz> re-activate the milestone, set the bug to it, re-de-activate the milestone
<poolie> hi all
<mgz> hey poolie
<poolie> hi there
<GRiD> hey guys.
<poolie> hi grid
<GRiD> jelmer, bug 806904 says you committed a fix. is this likely be working on launchpad soon then? if there's something left you do and you can point me in the right direction, i can take a look.
<ubot5> Launchpad bug 806904 in Launchpad itself "Mercurial import fails from Google code" [High,Triaged] https://launchpad.net/bugs/806904
<GRiD> i realize now that i'm getting a different error than the one in this bug. but it is a failing google code import.
<GRiD> http://launchpadlibrarian.net/85941722/weyrick-crack-lang-trunk.log
<GRiD> "something left to do", rather. i'm not sure how much of this is bzr vs. launchpad code. i suppose a first step is trying a local import with the latest bzr-hg.
<poolie> that's generally useful
<poolie> actually that would be highly useful to see if you can reproduce it locally
<poolie> then we can update it in lp
<GRiD> yep ok i'll give it a shot in bit here.
<jelmer> GRiD: the hg import is still very much beta at this point, so I wouldn't be surprised if there are multiple issues affecting one import
<AuroraBorealis> question: on mac...does bzr know about resource forks?
<GRiD> jelmer, ok. well i'll see what happens when i try locally. does it work well enough to rightly be offered as on option on launchpad at this point, then?
<poolie> nup
<jelmer> GRiD: bug #889530
<ubot5> Launchpad bug 889530 in Launchpad itself "mercurial imports should be marked 'beta'" [High,In progress] https://launchpad.net/bugs/889530
<mgz> AuroraBorealis: no
<GRiD> jelmer, ah ok :)
#bzr 2011-11-30
<vila> hi all !
 * fullermd waves at vila.
<mgz> morning all
<vila> mgz: morning
<mgz> vila: what are you up to today?
<vila> udd stuff mainly
<vila> on a related note I'm also up to 48 ;)
<mgz> surely not!
<vila> since 17 minutes to be precise
<vila> grr
<vila> 18
<vila> clocks are conspiring to make me tyop now ?
<vila> I'll probably lose my internet access today, hopefully no longer than 1/2 hour, I may even be able to warn here first
<vila> mgz: ha, *asking* if there was a problem was needed to trigger the reconnect :)
<mgz> only 15 minutes downtime though :)
<vila> yeah, no I need to restore wireless and phone though
<vila> now
<vila> hmm, got the phone but still no wifi, lunch break, will obviously work better after that ;)
<fullermd> Hm, I've got no wifi either.  Maybe that means I should eat..
<chromaticwt> What advantages does bzr have over git?
<smoser> hey all. i'm wondering if i could get a little help doing a merge.
<smoser> i'm trying to 'bzr merge-upstream' with lp:ubuntu/python-boto
<vila> smoser: hi, you're welcome
<smoser> python-boto exhibits bug 883207
<ubot5> Launchpad bug 883207 in bzr (Ubuntu) "bzr reports huge differences compared to 'diff'" [Medium,Triaged] https://launchpad.net/bugs/883207
<smoser> and the merge reports a bunch of conflicts that are just silly.
<smoser> vila, thank you ;)
<vila> ha, hmm, sounds like a parallel import again, right ?
<smoser> maybe..
<vila> can you pastebin the output of 'bzr conflicts' ?
<smoser> i'm perfectly willing to just say "bzr merge-upstream" and take upstreams' version of any file.
<vila> in this case, 'bzr resolve --take-other' should get you pretty close to what you're after
<smoser> vila, i can... but you can very easily see the same thing as me. (bzr branch lp:ubuntu/python-boto && cd python-boto && bzr merge-upstream )
<Wellark> hmm.. am I doing something wrong or is this a real bug: https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/898179
<ubot5> Error: ubuntu bug 898179 not found
<Wellark> argh.. it's private atm..
<smoser> http://paste.ubuntu.com/754921/
<vila> smoser: branching...
<Wellark> ok, public now
<Wellark> https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/898179
<ubot5> Ubuntu bug 898179 in bzr (Ubuntu) "bzr crashed with UnicodeDecodeError when using dailydeb command" [Undecided,New]
<vila> smoser: merge-upstream'ed, looking
<smoser> so --take-other is probably pretty close to what i want. i can go forward with that.
<smoser> however, it has the issue on some files as reported in 883207.  it thinks some files have been deleted and replaced with the same content.
<smoser> and i would really like to fix this branch so it doesn't do that any more.
<jelmer> Wellark: I think that's a dupe of a bug mgz fixed earlier
<smoser> as its really annoying.
<jelmer> Wellark: what version of bzr-builder are you running?
<vila> smoser: so, the root issue is that to track renames, bzr assign a file-id when a file is first added
<vila> smoser: when it happens for the same file in two separate branches, we call it a 'parallel import'
<smoser> yeah, i'm not sure what got it into this situation, and quite likely the source of the problem is typing this sentance.
<vila> smoser: when these two branches are merged, bzr (so far) fail to realize that these two files are really the same
<smoser> but i'd like to get it fixed, and am willing to do some hacks now to get there.
<vila> 'bzr resolve --take-other' removes the file-id present in the branch and takes the other one
<vila> so if you keep merging from the same branch, you shouldn't encounter the same issue
<smoser> well that is good enough for me.
<vila> the long term fix is to allow both file histories to be merged
<vila> smoser: let me know how it goes for the *next* merge-upstream
<vila> smoser: and if you're subscribed to the udd mailing list, there is a thread about collecting such issues/recipes
<vila> smoser: called 'UDD: categorising and working around common issues'
<smoser> vila, thanks.
<smoser> one other thing as punishment for your helpfulness
<smoser> i just did merge-upstream... resolve --take-other...
<smoser> then 'bzr commit'
<smoser> and it did not ask me to add a message
<smoser> it did the same thing as debcommit would have
<smoser> which is not what i wanted (non-interactively taking the debian changelog entry)
<vila> jelmer: is that ^ Riddell patch striking ?
<jelmer> vila, smoser: yes, that's fixed in bzr-builddeb trunk
<jelmer> in other words, trunk now has it disabled by default and you have to explicitly enable it
<vila> pfew, lucky me ;)
<jelmer> in older versions of bzr-builddeb the option defaults to True, but you can disable it
<smoser> jelmer, ok. i'm bzr-builddeb 2.7.9ubuntu1
<smoser> but, thanks.
<smoser> is there a way to explicitly request edit ?
<smoser> i guess i can just type a message and use --file
<jelmer> smoser: set "commit-message-from-changelog = False" in bzr-builddeb's config, e.g. ~/.bazaar/builddeb.conf
<smoser> thanks to everyone.  i have to say, that i find #bzr to be probably the most immediately helpful channel that i frequent, followed closely by #launchpad.
<Wellark> jelmer: the one which comes from oneiri repositories
<Wellark> lemmecheck
<Wellark> jelmer: 0.7.1-0ubuntu1
<jelmer> Wellark: It's fixed in 0.7.2, which is in oneiric. I've just marked your bug as a dupe.
<mgz> hm, bzr-builder doesn't have an exposted version number?
<jelmer> mgz: it does in 0.7.2 :-)
<mgz> and hey, you're talking about exactly the same bug I was just reading mail on
<Wellark> 0.7.2 is probably still in proposed
<mgz> bug 837741 is the one.
<ubot5> Launchpad bug 837741 in bzr-builder (Ubuntu) "bzr-builder has to call .decode on get_maintainer() output" [High,Fix released] https://launchpad.net/bugs/837741
<Wellark> I'll grap it there
<Wellark> jelmer: I see 0.7.2 for precise, but not for oneiric
<jelmer> Wellark: sorry, my bad. I meant to say precise
<Wellark> I'll just grab the trunk directly
<Wellark> np
<jelmer> Wellark: 0.7.2 is indeed not in oneiric. You should be able to grab it from the bzr daily build PPA or install it in ~/.bazaar/plugins manually.
<Wellark> yeah, I go manual
<Wellark> or not.. apparently I have to upgrade bzrlib, too
<Wellark> daily PPA, here I come :)
<jelmer> Wellark: it's ppa:bzr/daily
<jelmer> Wellark: I'm surprised you would need a newer bzrlib though, did you get an error of sorts?
<mgz> hey, on the ubuntu bugs index page for a package it tells you what versions are in what series, hadn't noticed that before
<smoser> vila, i just realized that 'take-other' didn't get me my bin.moved directory
<smoser> so i'm missing a bunch of bin/ files.
<smoser> suggestions on thta ?
<vila> bin.moved was put out of the way and 'bzr rm'ed' , so either you move the files you want back into your branch and add them again (suboptimal)
<vila> or you come back to the state after 'bzr resolve' to cancel the removal of the files you want to keep
<vila> ghaa, this sounds horribly complicated :-/
<vila> smoser: did the above make sense or should I explain more ?
<smoser> i can easily reproduce the prior-to-resolve state.
<jelmer> vila: yeah, we really should address parallel imports at some point..
<vila> ok
<smoser> so how would i 'cancel the removal' ?
<vila> smoser: justasec, trying locally
<vila> right,
<vila> so, you 'bzr mv bin.moved/* bin' to say : I want to keep those
<smoser> i didn't do that, but i can.
<vila> it will fail for s3put, leave it for now, do 'bzr mv bin.moved/*admin bin' to get the missing ones
<smoser> and there was one file i think that existed in both.
<smoser> right.
<vila> *now*, if you do 'bzr resolve --take-other' you'll notice that it says: deleted bin.moved/s3put (and deleted bin.moved)
<vila> so the original bin and bin/s3put are the only ones deleted
<vila> you may want to do the same for ec2/*.moved/*
<vila> s/may/probably/
<smoser> ok.. so what do i do about the conflicts ?
<smoser> what i've done before, which probably got us into this situation was 'bzr rm, bzr add'
<vila> EEEEEERK !
<vila> :)
<vila> never ever do that :)
<smoser> well bzr rm seemed like the only way to get the original outof the way.
<vila> That's exactly the cause indeed, not a parallel import but a remove/add pair breaking the rename tracking :)
<smoser> as 'bzr mv --force' isnt a thing.
<vila> when do you need to get the original out of the way ?
<smoser> because its different than the right version
<smoser> and 'bzr mv' wouldn't do it.
<vila> the content ?
<smoser> yeah
<vila> so you got .THIS .OTHER .BASE ?
<vila> and conflict markers in the file /
<vila> s!/!?!
<smoser> bzr diff ./boto/ec2/autoscale.moved/group.py ./boto/ec2/autoscale/group.py
<smoser> as an example.
<vila> if .moved appears somewhere, there was a conflict on the name (abusively called content conflict)
<vila> resolve --take-other should do the right thing
<vila> oh
<vila> resolve --take-other  boto/ec2/autoscale/group.py
<vila> in this case
<vila> either path can be used, which one you use doesn't change the result
<smoser> ok.
<smoser> i understand the 'rm and add' are bad, but from other rcs (ie git) the result is still sane.
<vila> yup
<vila> because renames are not tracked
<vila> it's the other side of the same coin
<vila> and breaks badly for bzr which is why we need to address it
<smoser> vila, so does this seem sane:
<smoser> $ for d in $(find . -name "*.moved"); do for e in "$d/"* ; do o=${e//.moved/}; if [ -e "$o" ]; then echo bzr resolve --take-other $o; else echo bzr mv $e ${e//.moved/} ; fi; done; done
<smoser> bzr resolve --take-other ./bin/s3put
<smoser> bzr resolve --take-other ./boto/ec2/autoscale/group.py
<smoser> bzr resolve --take-other ./boto/ec2/autoscale/__init__.py
<smoser> bzr mv ./boto/ec2/autoscale.moved/instance.py ./boto/ec2/autoscale/instance.py
<smoser> bzr resolve --take-other ./boto/ec2/autoscale/launchconfig.py
<smoser> bzr mv ./boto/ec2/autoscale.moved/policy.py ./boto/ec2/autoscale/policy.py
<smoser> bzr mv ./boto/ec2/autoscale.moved/request.py ./boto/ec2/autoscale/request.py
<smoser> bzr mv ./boto/ec2/autoscale.moved/scheduled.py ./boto/ec2/autoscale/scheduled.py
<smoser> bzr mv ./boto/ec2/elb.moved/healthcheck.py ./boto/ec2/elb/healthcheck.py
<smoser> bzr resolve --take-other ./boto/ec2/elb/__init__.py
<smoser> bzr mv ./boto/ec2/elb.moved/instancestate.py ./boto/ec2/elb/instancestate.py
<smoser> bzr mv ./boto/ec2/elb.moved/listelement.py ./boto/ec2/elb/listelement.py
<smoser> bzr mv ./boto/ec2/elb.moved/listener.py ./boto/ec2/elb/listener.py
<smoser> bzr mv ./boto/ec2/elb.moved/loadbalancer.py ./boto/ec2/elb/loadbalancer.py
<vila> !pastebin :)
<smoser> bzr mv ./boto/ec2/elb.moved/policies.py ./boto/ec2/elb/policies.py
<smoser> bzr mv ./boto/ec2/elb.moved/securitygroup.py ./boto/ec2/elb/securitygroup.py
<smoser> bzr mv ./boto/ec2/cloudwatch.moved/alarm.py ./boto/ec2/cloudwatch/alarm.py
<smoser> bzr mv ./boto/ec2/cloudwatch.moved/datapoint.py ./boto/ec2/cloudwatch/datapoint.py
<smoser> bzr resolve --take-other ./boto/ec2/cloudwatch/__init__.py
<smoser> bzr mv ./boto/ec2/cloudwatch.moved/listelement.py ./boto/ec2/cloudwatch/listelement.py
<smoser> bzr resolve --take-other ./boto/ec2/cloudwatch/metric.py
<smoser> crap!
<smoser> sorry
<smoser> http://paste.ubuntu.com/755002/
<smoser> thats what i meant to paste.
<vila> lol, nw
<vila> yup, looks sane, does the resulting diff looks sane ?
<smoser> vila, boto/ec2/elb/__init__.py is not conflicted
<vila> smoser: no, you did: 'bzr resolve --take-other ./boto/ec2/elb/__init__.py'
<vila> so you took the other content
<smoser> ok. so that output was expected, and did what i wanted. thats fine.
<smoser> now do a blanket resolve ?
<vila> what does 'bzr conflicts' says ?
<vila> testing locally, there is a problem
<vila> my 'either path can be used' was misleading, it applies only when .moved is the only difference between the two paths
<smoser> conflicts still lists all the original conflicts.
<vila> right, 'bzr st' is clearer here (and also list the conflicts)
<vila> is the 'tests' hierarchy deletion deliberate ?
<smoser> it moved. i think. have to check, though
<smoser> no. tests removal was not deliberate. upstream has it.
<smoser> oh wait. it *was* deliberate :-(
<smoser> the upstream tarball apparently does not have tests/ in it although revision control does.
<vila> testing locally, 'bzr resolve --take-other' output seems fine
<smoser> so that sucks for a different reason.
<vila> 'bzr revert tests' will restore it
<smoser> yeah, but dont you think its probably best to leave it gone ?
<vila> I have no idea
<smoser> yea.. i was hoping you'd have a better feel for that.
<vila> Only a personal preference for not deleting tests (especially all of them ;)
<smoser> it does suck that upstream's tarball and revision control tag aren't equal.
<smoser> well, the only issue is that my tests/ directory would then be that of 2.0.2, not 2.1.1 and potentially not even work, *and* its different than upstream tests/
<smoser> i'll mail upstream about lack of that in tarball as a long term fix.
<vila> yeah, exploring with 'bzr qlog', 'tests' was added in 2.0.0-ubuntu1 which get them from upstream-2.0
<vila> which ironically outlines why getting the parallel import fixed is important as here if upstream add the tests again, we really want to reconcile the histories
<Wellark> jelmer: running bzr daily ppa version of dailydeb fixed the problem as you guessed
<Wellark> now. Is there a way to trigger rebuild on dailyppa after uploading new branches?
<Wellark> is there any way to see what is the current rebuild period?
<jelmer> Wellark: there is a "Build now" link that is shown whenever one of the branches has unbuilt revisions
<Wellark> let's see
<jelmer> otherwise the branches with changes get rebuilt within a 24-hour window
<jelmer> there is no ETA on when in the 24-hour window that is (but an open lp bug about showing that)
<Wellark> hmm.. odd.. I can't find the recipe on any of the branches
<Wellark> there has to be one as the daily ppa sends me build error emails
<Wellark> the build uses these branches: https://code.launchpad.net/~indicator-network-developers/ofono/trunk, https://code.launchpad.net/~indicator-network-developers/ofono/trunk.packaging
<Wellark> but both of those branches say: No recipes using this branch.
<Wellark> I'm a bit puzzled now
<jelmer> Wellark: how did you create the recipe?
<Wellark> no, somebody created it before
<Wellark> now, I'm suppose to continue development and maintenance of those packages and I'm trying to figure out all the pieces of the puzzle
<Wellark> s/no/no, I didn't create it my self/
<Wellark> jelmer: do you have some powertool to list the recipes which land stuff to this PPA: https://launchpad.net/~indicator-network-developers/+archive/daily-ppa ?
<jelmer> Wellark: usually I just look for recipes owned by the same user that owns the PPA
<jelmer> Wellark: based on the versions of the packages in that PPA, it seems like those packages weren't created by a recipe
<jelmer> Wellark: it's probably just somebody (a bot?) doing daily source package uploads
<Wellark> sigh...
<vila> jelmer, mgz: I'm looking at some import failure and I encounter a weird case you may help me to understand, get the branches for debootstrap -rtag:1.0.36 for oneiric, sid and wheezy, launch qlog on them  and tell me it's not as bad as I fear :-/
<jelmer> vila: hmm, it seems like the debian and ubuntu branches have parallel imports?
<jelmer> vila: seems like it was caused by the fact that ubuntu diverged for a bit, then discarded its changes
<mgz> hm.
<jelmer> vila: it diverged in 1.0.29ubuntu1, and then discarded that
<vila> but the tags '1.0.xx' should be for upstream no ?
<vila> they seem to exist with different revids in debian and ubuntu
<jelmer> vila: there is no upstream in this case
<jelmer> vila: it is a native package
<vila> surely the same tag can't be used for different revs ?
<vila> even for native packages
<vila> and the picture is even more fun when you add the precise branch :-/
<jelmer> vila: different branches can have different tags
<vila> right, that's the theory, but does it make sense here ?
<jelmer> vila: in this case bzr-builddeb doesn't pull from the Debian branch anymore because it sees the Ubuntu and the Debian branch have diverged
<vila> precise merged them
<mgz> this branch is a little large for my connection, it's not finished yet.
<mgz> there we go.
<vila> mgz: oh, sorry :-( ~133MB
<jelmer> vila: please file a bug against bzr-builddeb
<vila> jelmer: so, debian and ubuntu, for native packages, having the same tag used for different versions is expected ?
<vila> jelmer: I'm trying to understand first, I'm not sure builddeb is at fault here, the failure is udd so far and it seems it assumes a tag cannot point to different revs there
<vila> s/udd/in udd/
<vila> jelmer: so, debian and ubuntu, for native packages, having the same tag used for different versions is expected ?
<jelmer> vila: no, that's not expected
<vila> what tags should they use then ?
<vila> x.y.zdebianN and x.y.z.ubuntuN ?
<mgz> okay, I see the pretty picture.
<jelmer> vila: the tag names aren't the issue
<jelmer> vila: it's the fact that bzr-builddeb doesn't pull from the debian branch to import those revisions, and then reimports them itself.
<jelmer> vila: and when it reimports htem itself, they end up with new revision ids and tags
<vila> ha
<vila> so the ubuntu ones are wrong is what you're saying ?
<jelmer> vila: when 1.0.30 was synced from debian to ubuntu, that discarded 1.0.29ubuntu1
<jelmer> vila: yes
<jelmer> it would be interesting to see if you can reproduce this issue by taking the ubuntu branch at 1.0.29ubuntu1 and then trying to import the 1.0.30 package
<vila> but the parents of the ubuntu 1.0.30 are 1.0.29ubuntu1 *and* debian 1.0.30
<jelmer> vila: the parents of ubuntu 1.0.30 should be 1.0.29 only
<jelmer> vila: it should be the same revision as debian 1.0.30
<jelmer> vila: what happened is basically the equivalent of "bzr push --overwrite"
<vila> meh, 1.0.29ubuntu1 cannot be part of debian right ? Oh, you mean 1.0.29ubuntu1 shouldn't be there *at all* anymore ?
<jelmer> vila: right, it shouldn't be there anymore at all
<jelmer> vila: if you look at the current changelog.gz, you'll also see it's not there
<vila> which the 1.0.30 merge shows in its associated diff yes
<vila> I suspect the package importer have no idea this can occur
<vila> so both may need to be fixed (importer and buildeb)
<vila> no, wait, something is wrong here
<vila> say 1.0.29 was for lucid and then 1.0.30 for maverick, I still want 1.0.29 to be there so I can make other dot releases for lucid, as long as the content for 1.0.30, the prior history shouldn't need to be altered
<vila> s/as the content/& is correct/
<jelmer> vila: I'm not sure I follow?
<vila> you said 'right, it shouldn't be there anymore at all' , that sounds excessive
<jelmer> in the revision graph for the oneiric branch, 1.0.29ubuntu1 shouldn't be present at all
<vila> the tags was a red herring as you explain, knowing they are legit, the branches don't look that weird now
<jelmer> 1.0.29, 1.0.30, etc should be present in the oneiric branch
<vila> 1.0.29ubuntu1 commit says: 'Cherry-pick from trunk:' so it has been released right  (in natty) ?
<vila> why should it disappear from the history in this case ?
<vila> it seem the branches converge again at 1.0.30 if they can have different revs for the same tag, what's the issue ?
<jelmer> vila: it's like bzr release series
<vila> endless superfluous merges ?
<jelmer> vila: it's possible to cherry-pick a change from trunk onto 2.1 but it will become a different revision, and that different revision isn't in lp:bzr
<vila> right, but it's still part of the 2.1 history and becomes part of bzr.dev history when merged up
<jelmer> vila: there was no up-merging from ubuntu into debian here though
<jelmer> vila: which is why that revision shouldn't be part of the oneiric history
<vila> right and they will never be because ubuntu is downstream and has a larger history
<jelmer> vila: ubuntu oneiric has the exact same history as debian sid at the moment
<jelmer> vila: they're both shipping 1.0.38
<vila> but their branches are different, same content because ubuntu merges debian but still different histories
<jelmer> vila: the ubuntu natty branch *should* have 1.0.29ubuntu1
<jelmer> vila: their branches should be the same, like for any package where ubuntu doesn't have a delta
<vila> we seem to agree about the branch content but disagree about the branch history
<jelmer> vila: about what should be in the branch history you mean?
<vila> the oneiric history should be a subset of the natty history so 1.0.29ubuntu1 should also be part of oneiric
<vila> yes
<vila> grr
<vila> s/subset/superset/ of course
<vila> or not ?
<jelmer> vila: I don't think it should be a superset, it doesn't reflect what has actually happened
<vila> are you saying the history can somehow be restarted when a new ubuntu release is started ?
<vila> so the natty branch and the oneiric one can really diverge and never be reconciled ?
<vila> my understanding was that launchpad was always creating the new release branches from the previous release...
<jelmer> vila: sure - the same thing happens e.g. with SRUs
<jelmer> james_w: around?
<vila> right, but SRU happen *after* the branches have been bootstrapped
<vila> miss an s, here are some ssss
<jelmer> vila: the bootstrapping and old branches don't really matter I think
<jelmer> vila: the point is that when ubuntu discards its changes for a package, we should reflect that in the history
 * vila blinks
<vila> by removing a revision ?
<jelmer> vila: effectively, what ubuntu is doing is:
<jelmer> taking a debian, making some local changes to it
<jelmer> taking a debian package (1.0.29), making some local changes to it and uploading that (1.0.29ubuntu1)
<vila> recording that in the branh history
<jelmer> then later, when e.g. the fixes in 1.0.29ubuntu1 have been applied upstream too, they discard their version of it
<jelmer> "bzr pull --overwrite debianlp:debootstrap"
<jelmer> so they again have the same history as debian
<vila> wow
<vila> and no trace that 1.0.29ubuntu1 ever existed ?
<jelmer> right - see debian/changelog in e.g. 1.0.37, no sign that 1.0.29ubuntu1 was ever there
<vila> hehe, touche
<vila> hmm
<vila> right, so I see your point
<vila> I don't think it is what is implemented yet though,
<vila> but I can imagine that the failures are related
<vila> I'll big further tomorrow, thanks for the explanations and the discussion
<vila> s/big.... ???/dig/
<jelmer> :) see you tomorrow
<vila> hmm, and the tag should be deleted too, everywhere :) ...
<jelmer> vila: not everywhere, just those ubuntu releases that no longer have the version..
<vila> ha ! Who is making things harder now ! :0D
<jelmer> vila: I don't think that's making things harder - it's just one of the things we should do when we do the "bzr pull --overwrite" from debian
<vila> yeah, was mostly kidding.
<vila> --overwrite may have a lot of unforeseen fallouts is what I meant, people having mirrors and so on
<vila> or pending proposals
<Wellark> hmm.. I'm trying to write a recipe
<Wellark> my .recipe file contains:
<jelmer> vila: I don't think we necessarily handle that very well at the moment, as we record the parent but don't actually have the changes from 1.0.29ubuntu1
<vila> anyway, food for thougt, first of all, fixing the imports ;) EOD, have fun !
<Wellark> # bzr-builder format 0.4 deb-version {debupstream}-0ubuntu1+bzr{revno}+bzr{revno:packaging}
<jelmer> vila: g'night & g'appetite :)
<Wellark> but running $bzr dailydeb gives me an error
<Wellark> bzr: ERROR: Invalid deb-version: {debupstream}-0ubuntu1+bzr5947+bzr2792: Invalid version string '{debupstream}-0ubuntu1+bzr5947+bzr2792'
<Wellark> so it seems that {depupstream} doesn't get substituted
<jelmer> Wellark: what's the full recipe?
<Wellark> jelmer: $ cat ofono.recipe
<Wellark> # bzr-builder format 0.4 deb-version {debupstream}-0ubuntu1+bzr{revno}+bzr{revno:packaging}
<Wellark> ofono.trunk
<Wellark> arg,,
<Wellark> argh.
<Wellark> jelmer: http://pastebin.ubuntu.com/755157/
<jelmer> Wellark: does ofono.trunk have a debian/ directory? If not, you probably want {debupstream:packaging}
<Wellark> ah, ok
<Wellark> jelmer: ok, now it works!
<Wellark> jelmer: then there's a documentation bug
<Wellark> bzr help dailydeb says
<Wellark> "{debupstream} will be replaced by the upstream portion of the version number taken from debian/changelog in the final tree."
<Wellark> bzr help builder, I mean
<jelmer> Wellark: "bzr help dailydeb" doesn
<jelmer> t mention {debupstream} here
<jelmer> Wellark: never mind, found it in "bzr help builder"
<Wellark> jelmer: 20:00:11 < Wellark> bzr help builder, I mean
<Wellark> :)
<Wellark> jelmer: do you want a bug report or will you handle this on your own?
<jelmer> Wellark: submitting a fix now
<jelmer> Wellark: thanks for reporting that, btw
<Wellark> jelmer: no problem
<Wellark> thank you for fixing it so quickly! :)
<smoser> vila, i can't seem to get rid of all the add/remove pairs
<smoser> http://paste.ubuntu.com/755216/
<mgz> jelmer: reviewed bzr-builddeb mp
<jelmer> mgz: merci
<jelmer> mgz: updated
<smoser> vila, i'm sure you're sleeping or afk, but it seems to me that this ended up doing what i wanted
<smoser> http://paste.ubuntu.com/755287/
<smoser> i would appreciate your input (or others) as to if this will then get me into a sane state for merges from debian and/or upstream in the future.
<mgz> ah, so I don't get bzr-builddeb bug mail...
<jelmer> smoser: I'm not entirely sure if that revert command will do the right thing. I would personally use "bzr resolve --take-other $d"
<mgz> I probably need to join bzr-builddeb-hackers
<jelmer> mgz: you should be able to be subscribed without being in the team that owns bzr-builddeb
<jelmer> mgz: that said, you probably should join bzr-builddeb-hackers >-)
<jelmer> smoser: the diff output seems reasonable enough though
<mgz> hey, that's a fun regression
<mgz> too many yaks, too many yaks
<jelmer> mgz: hmm?
<poolie> hi all
<mgz> something in 2.5 broke the error you get when trying to commit an unversioned file, with non-ascii filenames
<mgz> it was kinda bust before but now it's good ol' "Unprintable exception"
<mgz> which... as I was trying to test a different fix against that was very confusing
<poolie> hm
<poolie> mgz, i would like to change the tests from using hardcoded file names to getting the names from some kind of factory object
<mgz> picking well known problem values isn't bad.
<poolie> so that more of them can be unicode
<poolie> right they could just start with a list like that
<poolie> we may need to adjust it for non unicode filesystems
<poolie> though, actually, there really are none of them
<poolie> so perhaps we just need to make sure the tests always run with the right fsenc
<mgz> there is a problem at the moment where testing of filenames is ad hoc where people have reported bugs rather than systematic
<mgz> but...
<poolie> right
<james_w> jelmer, I am now
<jelmer> hi james_w
<james_w> hi
<james_w> how are you?
<jelmer> I'm well, how are you ?
<jelmer> james_w: vila and I were looking at an interesting importer issue this afternoon
<jelmer> james_w: basically, the importer wasn't dealing well with revisions with ubuntu-specific changes that were discarded
<jelmer> james_w: shouldn't those just be discarded from the branch history in Ubuntu as well so that the ubuntu branch has the same contents as the debian branch ?
<james_w> jelmer, IIRC it should make the trees the same, but leave the revisions in place
<jelmer> james_w: and then do a merge for every subsequent revision?
<jelmer> james_w: IOW, once there has been a ubuntu-specific revision, the revision graphs will never ever converge again?
<james_w> jelmer, yeah
<james_w> that seemed to more accurately reflect the upload history to Ubuntu
<jelmer> james_w: ah, so it's about the upload history rather than the actual package history I guess
<james_w> yeah
<jelmer> vila: ^
<mgz> heh
<mgz> bisected regression... comes out at r6124 ;_;
<mgz> guess it's a gettext change then.
 * mgz does the hidden 16 former mainline revs as well
<mgz> 6123.1.10 indeed.
#bzr 2011-12-01
<vila> hello bazaristas !
<poolie> vila, hi
<nigelb> bazaristas is a bizzare word ;)
<poolie> vila i want to go soon but i would like to write some config developer docs
<poolie> first
<poolie> is there anything more up to date than configuration.txt?
<vila> I was thinking about that too while discussing with jelmer the other day,
<vila> he mentioned that devnotes/configuration.txt should go in bzr.dev (can't remember where exactly but there is a place we talk about our plans)
<vila> but back to the dev subject itself,
<poolie> ah
<poolie> yes i think it should go there
<vila> I happily review/complete whatever you want to wrote
<poolie> devnotes was interesting but just putting it in trunk is better
<poolie> we land things faster now
<vila> ok
<poolie> we do need to garden out stuff that gets old
<vila> crap, I have local revisions to push to devnotes
<vila> pushing^H^H^^Hed
<vila> I will review/submit that
<vila> targeting at trunk that is
<poolie> so reading that document
<poolie> it's fine
<poolie> but it starts with a kind of longwinded explanation of current problems
<poolie> 1- these will eventually be fixed
<poolie> 2- i just want to look up an option!
<vila> 1) if we keep track of it yes
<vila> 2) right, user guide vs reference guide
<poolie> so what we have in the tree should perhaps be structured as
<poolie> brief overview
<poolie> how to use the common cases
<poolie> more details
<vila> so, will a rewrite on the document follows ... hehe
<poolie> then, the kind of changes we want to make
<vila> 1) how to use 2) reference guide 3) pending issues
<vila> hehe
<vila> wfm
<vila> poolie: any related bug you can think of or should I just go from our discussion here ?
<poolie> ah for what?
<poolie> documentation of configuration?
<poolie> i think
<vila> clarifying the config , yeah
<poolie> i'll just put up an mp answering my questions
<poolie> you can tell me if the answers are right :)
<vila> hehe, k, no bug then. Can you use a lp:~bzr branch so I can push there too ?
<vila> poolie: in other news, I requeue a bunch of imports yesterday,
<poolie> great
<poolie> good idea about a team branch
<vila> ~20 now succeeds, ~50 moved from one kind of failure to another, I started digging the find_unimported_versions:check (74 failures) ones which led to an interesting discussion with jelmer
<poolie> nice work
<vila> the 74 failures may also be related to the other 43 ones from find_unimported_versions (no :check)
<poolie> speaking of which, i wasn't sure if you heard the other day i made your terrine
<poolie> vaguely speaking of which
<vila> really ?? Great ! So ?
<poolie> it was good
<vila> :)
<poolie> your corrections were on point - it would have been too salty otherwise etc
<poolie> :)
<vila> I'm glad you enjoyed it :) Will tell my friend his recipe went around the world ;)
<vila> poolie: and did you manage with the advices about how ti find if it's cooked or not ?
<vila> s/ti/to/
<poolie> i did
<poolie> i used a thermometer too
<vila> cheater :)
<poolie> i think it could have done with a little less time
<poolie> anyhow i thought it might please or amuse you to know
<vila> oooh, that reminds me that I cheat too (yeah, thanks, pleased and amused indeed):
<vila> I made several terrine in various sizes so the smaller ones are finished first and help get the biggest one right
<poolie> ok https://code.launchpad.net/~bzr/bzr/doc/+merge/84069
<vila> and also allow the chief to taste before serving ;)
<poolie> :)
<poolie> ok
<poolie> i've pushed my stuff
<poolie> i think i'll log off soon
<vila> waiting for lp to refresh
<vila> enjoy your evening (and week-end right ?)
<poolie> this was leading up to changing to append_revisions_only
<poolie> thanks, yes
<vila> yeah, I've seen your bug comment,
<vila> the last experience we did was on the importer but I need to refresh my memory about why we reverted it and whether or not it should block making it the default (I strongly hope not)
<vila> and yes, -Oappend_revisions_only should work (and if not, should be fixed)
<vila> and yes, -Oappend_revisions_only=False should work (and if not, should be fixed)
<mgz> morning!
<vila> mgz: hey !
<poolie> vila so was my patch actually correct?
<poolie> :/
<vila> which one ?
<vila> I haven't see a patch for a_r_o yet, but I agree (strongly) with the intent
<poolie> the doc thing
<poolie> anyhow
<poolie> not a big deal
<poolie> i'm not going to finish a_r_o this week, i think
<vila> yup, doc thing sounds good, perfect for driving my answers
<vila> there is one important thing missing though: which stack you chose for a given option defines where it can be defined and where the modifications will be made
<vila> i.e. GlobalStack or BranchStack for example
<vila> weird, nexuiz-data is at it again, consuming 4GB without any obvious output... (but 100% CPU)
<vila> for hours it seems
<fullermd> Maybe they borrowed some developers from firefox.
<vila> DuplicateKey: Key new-362 is already present in map, yeah 362 ! will be so fun to debug :-}
<mgz> vila: do you remember the trick to get localised strerror? I did it on a box at home but now can't get it working here.
<mgz> what I've done is `dpkg-reconfigure locales` to get some non-english ones, and then set LAND and LC_ALL and use locale.setlocale
<mgz> but... that seems to not be enough
<vila> mgz: LANG but yeah should do
<mgz> yeah, that was just an IRC tyop.
<vila> mgz: on the other hand, I'm definitely the one to ask for that: I switch to C decades ago and never looked bac k;)
<vila> this is supposed to Just Work, with additional tweaks via LANG
<mgz> okay, fail at that, dug up another bug by accident instead
<mgz> worked it out at second try, also have LANGUAGE env var that breaks things
<vila> OS ?
<mgz> ehem.
<vila> we do weird stuff about locales in the bzr script itself too
<vila> oh, That one ;)
<mgz> no, not windows, it's easy on windows :)
<vila> debian ?
<mgz> yup.
<mgz> okay, it's working.
<mgz> now tempted to see if I can close a long standing bug without even having the change any code...
<mgz> should be able to run a full selftest even on this machine now the test suite cleans itself up better
<vila> yak shaving *is* useful ;)
<vila> jelmer: no wonder doc/developers/plans.txt fell of my radar, it's not part of the online site... something weird happened years ago
<vila> ha, no, it's part of the sphinx generated docs not the regular ones
<mgz> still a little memory constrained, errors on fork
<mgz> trying again with X gone should do it though.
<jelmer> vila: did you see mydiscusion with james yesterday here on IRC?
<vila> jelmer: yup, was waiting for you to summarize,
<vila> so, we keep the upload history,
<vila> yet, I found your idea interesting too, so longer term we may want to investigate, it sounds like a useful optimization
<vila> overall, there is more than one history ;)
<jelmer> yeah, there is some tension here between convenience for packagers and keeping all history
 * vila nods
<mgz> two failures, I think both were known random ones
<vila> what's the difference between random and spurious in English ?
<vila> (in the context of test failures I mean, not in general)
<mgz> spurious implies the failure isn't meaningful, but may always happen
<mgz> random implies the failure may or may not happen, but might be meaningful
<vila> thks
<mgz> some of our issues may be both spurious and random (the test test server ones), but some of the races are random but not spurious
<mgz> (they could in theory be hit in general usage)
<mgz> are views documented anywhere? does anything currently use them?
<mgz> bt.test_sftp_transport.test_bad_connection_ssh fails if paramiko is not installed
<vila> are your two last messages related ?
<vila> views are used by some people AIUI
<vila> bt...bad_connection should use requireFeature, we *have* a paramiko one right >
<vila> yup, features.paramiko
<mgz> unrelated, just doing other things while tests run
<mgz> hm, and the test does use that require
<mgz> wonder what's going on (apart from general bogosity of using run_bzr outside blackbox)
<mgz> ...ah, actuallyrun_bzr_subprocess so probably a path issue
<vila> more MalformedTransform bugs on jubany. Joy ;)
<mgz> your favourite :)
<vila> hehe, looks like I'm making progress at using tree transform ;)
<mgz> so two bugs, one is that run_bzr_subprocess doesn't get my path right, the other is that this test sucks.
<vila> LOL
<vila> and trying the version proposed in the comment ?
<vila> even hardy uses python-paramiko-1.6.4 so that may be worth a try
<vila> yesterday results of poking jubany: http://webnumbr.com/ubuntu-package-import-failures.from%282011-11-01%29
<vila> back to where we were 3 weeks ago :)
<mgz> it looks like the commented version may be a happier route indeed, if the only flaw was some ssh kipple
<jelmer> mgz: we do seem to be playing whack-a-mole with unicode bugs, rather than actively trying to find and squash them :(
<jelmer> I do wonder if python3 (and an attempt to port to it) would be helpful in that regard.
<jelmer> or to phrase it differently - being explicit about what is encoded and what are bytes would both help our existing python2 version of bzr, and porting to python3
<mgz> I'm still tempted by the idea of objectizing paths, but that's not clearly a win
<mgz> the current state of bytes input, get unicode paths, change to utf-8 for dirstate, maybe change back to unicode for reporting error... is not ideal
<jelmer> mgz: being forced to use non-bytestring paths on Linux is frustrating
<mgz> the transcoding could be avoided, what we really want is validation though
<mgz> which you can't easily do in python except by .decode(...)
<vila> but you proposed (in that mail ;) some escaping scheme that could be used. With objectized (sp?) paths, this will at least be done in a single place. Obj... paths would also provide a simpler API
<vila> ideally we'll still accept <whatever> in the current API and start throwing deprecation warnings
<vila> since neither approach (whack-a-mole / all paths as objects) can be done in one go, starting both would at least make the goal clearer
<vila> The alternative name of 'safe_utf8' is 'break_things_randomly' :-D
<jelmer> vila: its name is kindof ironic
<vila> just found that in mgz's review, burst out laughing because I was expecting an explanation so the joke really took me off-guard :)
<vila> the most scary is that I'm pretty sure I used it in the past, with confidence, and I can't remember where :-}
<jelmer> mgz: can we deprecate it?
<vila> not a lot of uses left according to grep, good surprise
<chromaticwt> is there a way to push a bzr repo to github?
<mgz> jelmer, vila: there are lots of things in osutils that would ideally be deprecated
<mgz> it's a bit too tempting to just dump stuff in there.
<mgz> chromaticwt: it's possible to push to github with bzr, but you'd need a (git) branch registered via the site already to target
<vila> mgz: yup, lots of things to clean up there
<mgz> okay, bug half one worked out and fixed.
<mgz> test machinery sets $HOME which then breaks the site module's path addition if run_user_subprocess is run
<vila> huh ? Why would tests use site modules ?
<vila> talk about isolation...
<mgz> 'site' is the (ugly) module that runs at python startup and does things like filling in bits of the sys module
<mgz> one part of that is adding things to sys.path
<vila> ha, sorry
<vila> but what kind of $HOME can break that ?
<vila> isn't it a case where TestCase is used where TestCaseInTempDir should /
<vila> ?
<mgz> if HOME is set to a tempdir, when the site module tries to add my user specific python packages in ~/.local it's looking relative to that tempdir
<mgz> hence, self.requireFeature(features.paramiko) passes, but the spawned subprocess says there's no paramiko
<mgz> I have a fix.
<vila> there is no .local dir there, so should be fine or is it that '~' needs to be expanded ?
 * vila blinks and wait to see the fix :)
<mgz> ~/.local expands to /home/martin/.local in the selftest process, but for the subprocess the test spawns it expands to /tmp/bzr/....
<vila> and you installed paramiko in ~/.local
<mgz> right.
<vila> I'm stil surprised requireFeature() works...
<vila> does it means it is first called when $HOME is valid ?
<mgz> paramiko works from bzr - I run bzr as me.
<mgz> site does it's path lookup once at python startup
<vila> argh
<mgz> so bzr gets the right module paths... unless spawned from within a testcase where we set $HOME
<vila> so what ? We need to force a PYTHONPATH ?
<vila> this vaguely rings a bell
<fullermd> Nono, just copy everything in it into the tempdir!
<vila> didn't run_bzr_subprocess already tweak the env ?
<mgz> nearly - there's actually a more targetted envvar we can use instead
<mgz> PYTHONUSERBASE
<vila> jelmer: looks like import_upstream blows up if a symlink is turned into a dir (probably a packaging mistake) this leads to http://package-import.ubuntu.com/status/rserve.html#2011-12-01%2011:18:38.327140
<vila> reproduced locally when importing 0.5-3 where clients is now an exact copy of src/client instead of clients -> src/client
<mgz> that sounds similar to an error that the path name encoding branch fix exposed as well
<vila> jelmer: does that ring a bell ?
<mgz> I think the logic is just old and incorrect.
<vila> mgz: more context ?
<mgz> ikiwiki
<mgz> slightly different place, but I think the problem is similar.
<vila> in my case, the code involved try to handle renames but this is a kind change (symlink -> dir)
<mgz> basically the custom transform in bzrtools_import is complicated, a little buggy, and not maintained
<vila> ha
<mgz> we've done fixes for this symlink stuff in bzr itself (poolie tackled a bunch of bugs), but this is different code doing the same kind of thing
<mgz> so, we don't benefit from that.
<mgz> I said to jelmer when I last looked at this that ideally the bzrtools_ copied modules would ideally just be ripped out and replaced
<vila> ha
<mgz> most of the logic isn't used, just the core transform, which should live elsewhere
<mgz> (and then it would get its bugs and corner cases fixed more easily)
<vila> just a matter of refactoring under the associated tests umbrella right ?
<mgz> right.
<mgz> there are six or so testcases for it
<vila> better than I thought :-P
<mgz> probably some more need writing or things would break, but the job is basically to work out what the code is trying to do and then make it use other mechanisms :)
<mgz> at worst, it would highlight gaps in the bzrlib api that need plugging, and could then share testing but not implementation yet
<mgz> ^good mgz classic double 'ideally' up there
<mgz> vila: so, it was on my list for when I wanted to get to know transform code better, if you have a bunch of similar failures now it might be worth tackling before then
<vila> I think I will file a bug and punt, I've got a good enough explanation for the failure and more important ones to address first :-/
<mgz> :)
<vila> I agree with the feeling that this code is duplicating features that should be implemented elsewhere but it's more a gut feeling that a real understanding
<mgz> hm... transport.get_transport(something_bogus) doesn't raise these days?
<mgz> connection doesn't happen till later?
<vila> yup, always have
<mgz> okay, ensure_base() should do, the commented out test just needs fixing
<vila> even .has('not-exist') should be enough (and is already used as an idiom working for read-only transports too)
<vila> bug #800270
<ubot5> Launchpad bug 800270 in BzrTools "import-tar incorrectly handles symlinks turned into directories" [Medium,Triaged] https://launchpad.net/bugs/800270
<vila> mgz: by the way, since you reviewed the 2.4 variant, https://code.launchpad.net/~vila/bzr/test-server-races/+merge/84096 should be easy to review ;)
<mgz> I have a tab in my browser for that :)
<vila> You'll even find the comments you were asking for at the time but weren't committed when I submitted :-}
<mgz> okay, fixed test works, just need to make a less hacky varient
<vila> i.e. have a look at the revisions dates ;)
<CaMason> quick Q... how can I get my working tree to be at a particular revision?
<mgz> `bzr update -r N`
<mgz> using revert works as well, and may be what you want depending on the circumstance
<CaMason> ok thanks
<mgz> what I sometimes do as well, if I want to jump between revisions and maybe base other work of them
<mgz> is create a new (treeless) branch with `bzr branch -r N dev rN` and then switch my checkout to and from it
<CaMason> I'm getting a bunch of conflict messages. Taking a bak
<mgz> if there's a lot of divergence, just having a new tree is sometimes easiest.
<CaMason> I know what the problem is - some non-versioned files that would otherwise be deleted (folder changed)
<CaMason> new branch fixed it
<mgz> ah, yeah, that one is always annoying, the dreaded pyc problem.
<CaMason> thanks for the assistance
<mgz> `bzr clean-tree --force --ignored -q && bzr update -r N` is also possible, but annoying to spell
<vila> mgz: that run_bzr_subprocess diff presented by lp is one of the less informative yourcan get :) It's in tests/__init__.py, ok, but where ? :D
<vila> .pyc problem is supposed to be addressed with bbzr.transform.orphan_policy=move
<vila> until we have a way to split precious/junk files, that's the best work around
<vila> gha tyop
<vila> bzr.transform.orphan_policy=move in bazaar.conf
<vila> CaMason, mgz: ^
<vila> (yes, there is at least one hook in tree transform ;)
 * vila EOD, doctor said I still work too much ;)
<mgz> EOD happily vila.
<mgz> if lp let me specify --diff-options=-U20 I'd use it :)
<timrc> why does pushing a bzr branch a couple times seem to "sort out" this issue? https://pastebin.canonical.com/56636/
<timrc> (apologies for the canonical pastebin, I can re-paste to ubuntu if necessary)
<wgz> win box lives, and I can still just about manage to get over my aversion to hardware
<kiko> hey there
<kiko> I'm still running into https://bugs.launchpad.net/bzr/+bug/855155
<ubot5> Ubuntu bug 855155 in Bazaar "InconsistentDelta error when using bzr update" [High,Confirmed]
<kiko> is there somebody who can give me a hand into recovery?
<wgz> kiko: you should just be able to branch into a fresh directory to recover
<wgz> it's a problem with the dirstate, which is just used for tracking the local tree, so the core repo is fine
<kiko> wgz, the problem is that the "fresh directory" is /etc
<kiko> :-/
<wgz> do you have any local changes pending?
<kiko> lots
<kiko> that's the problem
<wgz> ...are any renames or executable bit changes that you wouldn't be able to redo?
<wgz> if not, run `bzr repair-workingtree`
#bzr 2011-12-02
<crtxc> hi.  Internet where I am is very very unreliable and slow.  Is there a way to resume a branch that has been cut off?  I am trying to branch emacs and it keeps stopping, then I have to start the whole thing over.  I can't find anything via search.
<vila> crtxc: you probably want to pull by batches, so:
<vila> bzr init-repo emacs ; cd emacs ; bzr init trunk ; cd trunk ; bzr pull <trunk url> -r100
<vila> then 'bzr pull -r200' until you get to the tip
<vila> use any increment that your connection can support 1.000 10.000 100.000
<vila> once you get the full history, things should be more reliable as you'll need to download only the new ones
<vila> discussions about allowing more robust branching by automating the above occur from time to time but I don't remember anybody going ahead and implement it
<mgz> morning all
<crtxc> vila, oh, ok.  I never came across -r200, that sounds much better for lower the probability of line failure.  Ty very much.
<vila> mgz: _o/
<crtxc> vila, is -r revision ARG?  I am trying to find it in the man.
<vila> yup
<crtxc> vila, hats off to ya, that is a very clever solution. :)
<crtxc> ty
<vila> yeah, I learned a few tricks by lurking in this channel so these kudos are really for more than me (/me blushing)
<crtxc> if you have a web site or a blog you might want to make a small post and get some traffic with that.  I see a few people had trouble with that.  :)  Then kudos to all who have good brains. :)
<crtxc> :)
 * fullermd is willing to accept any and all credit.
<crtxc> :)
<vila> ha, right, yeah, that's all fullermd fault, now that you mention it :)
<vila> 's ?
<crtxc> fullermd has been so kind for hidding the i an n between the m and d.  If fullermd weren't so shy it would be fullermind for all to see.  :)
<fullermd> Here now.  *I* handle the bad puns around here.  You're on my turf, sparky!
<crtxc> :)
<jelmer> hah, finally figured out what the trouble was with those multiple upstream tarballs
<vila> jelmer: \o/ ?
<vila> planets should be well aligned, my wifi problem just... resolved itself (using canal 6 instead of 13 *cannot* be related right ? Not when the only laptop that was hanging trying to connect is mine, right ?)
<mgz> wifi goes by water in france :)
<quicksilver> antenna in your laptop is damaged and finds some channels easier to tune than others?
<quicksilver> the breed of chicken you sacrificed was not holy enough to use channel 13?
<vila> goats, I always use goats... But now that you mentioned it I may have to audit my provider...
<fullermd> I guaranteed the goats for SCSI.  I didn't say nuffin' about 802.11.
<soren> vila: Not all wifi adapters can go up to channel 13.
<soren> vila: I've had a few that only went up to 11.
<mgz> I thought fullermd said he was in charge of the bad jokes...
<vila> soren: good point, but the router upgrade triggered the issue while the previous was already using channel 13
<fullermd> Why don't you just raise the frequency of 10 a little, and have 10 as the top channel?
<soren> vila: Oh.
<soren> fullermd: lol
<vila> soren: still,  thanks for pointing that
<vila> SCSI ? Come on ! I still have cables and even scsi drives... in my attic ! But I was clear enough when we engage on this goat deal that they won't be used outside of sabbat where virgin (and not goats) are used anyway
<vila> (the scsi stuff I mean, not the goats)
<vila> jelmer: what's your feeling about your reconcile proposal and bug #897487 ?
<ubot5> Launchpad bug 897487 in Bazaar "progress indication for Repository packing and reconciliation over HPSS" [Medium,Confirmed] https://launchpad.net/bugs/897487
<vila> jelmer: should the bug be a pre-requisite ? Do you think you can fix it soon ? Should we just land and see ?
<vila> 4) should we raise the importance to high ?
<vila> writing help thinking, so: I bumped to high and approved ;)
<jelmer> vila: I wonder what the best way is to provide progress reports
<jelmer> vila: if it's sufficient to just stream some data, then we can easily do that, even if it's not very useful data
<vila> jelmer: I don't know the code well enough to say if multiplexing data and progress is easy or not, so if there is data you can stream, good enough
<jelmer> vila: btw, on another note
<jelmer> vila: if we're looking at fixing the import code in bzr-builddeb, I wonder if we could stream directly from the tarball into commit builder
<jelmer> vila: I've been wondering about that previously as well, because currently we have to check out the base parent on disk, etc
<jelmer> so it would improve performance, but it would also help my current work
<vila> my understanding is that import is not simply a commit, there could be renames and kind changes
<vila> and deletions, and so on
<vila> what I don't understand though, is why we can reuse more of our existing stuff. Are renames and the like really the issue again here ?
<jelmer> vila: deletions and so on shouldn't be a problem,
<vila> as in: some operations cannot be automatically deduced
<jelmer> vila: ? I don't see how that matters, the only difference is that we're reading the contents for the commit from a tarball rather than off disk.
<vila> ha, let's sync
<vila> I was referring to the actual implementation that seems to use a transform tree to better handle renames and file-id reuses
<vila> you're talking about using a different source for commit, which indeed sounds like a good plan (gmta ;), but what about file-id reuse and renames ?
<vila> are the existing tests good enough to cover that ? (obviously nothing covers bug 800270)
<ubot5> Launchpad bug 800270 in bzr-builddeb "import-tar incorrectly handles symlinks turned into directories" [High,Triaged] https://launchpad.net/bugs/800270
<vila> jelmer: still there ?
<mgz> I think being able to do certain transforms without having a tree on disk is something we need.
<jelmer> vila: sorry, back now
<jelmer> vila: I'm pretty sure there are some tests for preserving file ids
<vila> and renames ?
<vila> mgz: wow, you're raising the bar now ;)
<vila> bah, pqm not using news_merge is now really going on my nerves
<vila> hmm, could it be that pqm is using a too old bzr version...
<vila> ... and we don't want to upgrade until that subunit/testools compat bug is fixed, I've lost track :-/
<jelmer> vila: I think the plan also was to look at tarmac
<vila> hehe, reading mgz proposals on the active review page is... funny: fix-bzr-subprocess followed by don-use-bzr-subprocess-after-all :)
<vila> jelmer: yeah, better
<vila> wwooooow, lunch time
<mgz> hey, I said it was a bug in two halves, I just fixed both of them :)
<crtxc> hi.  I cloned emacs.  I am not a developer.  I only want to make a copy, build emacs, then use the original to update any changes on the parent repo.  Did I do this right?  http://codepad.org/et7ETDzS
<mgz> crtxc: you don't really need any of that except `bzr branch` for your use
<mgz> all I'd suggest is using the launchpad mirror rather than savannah may still be faster
<crtxc> oh.  So I just do bzr branch everytime I update?
<mgz> no, you branch once, then you just `bzr pull` to update
<crtxc> oh.  I overcomplicated it.
<mgz> right, but the extra bits you did aren't harmful
<crtxc> ok :)
<mgz> they're just for emacs developers' funny work flows.
<crtxc> ok.  I never did this before I only use bzr to track my text files.
<crtxc> oops.  I just tried to bzr and I got an error.  http://codepad.org/0qXcOk71
<crtxc> tried to bzr pull^
<fullermd> unbind it
<crtxc> ok.  ty.  unbind.
<crtxc> well.  Ty very, very much for your insights all.
<crtxc> ok.  That is it.  I should do some reading on shell scripting and c++ but my eyes are burning so ty very much
<fullermd> A little C++ will fix that right up.
<fullermd> There's no burning left after you gouge them out.
<crtxc> :)
<crtxc> I am trying to learn shell scripting, python, and c++.
<mgz> lunchtime, prize if anyone can guess where I'm going with these mps
<vila> lol, I was reading it and was about to ask :)
<vila> ha, I read only one
<jml> what's the udd mailing list?
<jml> for lp:udd in particular, I mean.
<vila> ubuntu-distributed-devel@lists.ubuntu.com
<vila> mgz: getting encoding right in more contexts ?
<fullermd> mgz: To lunch.  What do I win?
<vila> mgz: rats, lunch of course
<chromaticwt> why learn c++ before lisp?
<vila> mgz: I'm still holding my breath
<wgz> it will be very exciting... maybe
<vila> hehe
<fullermd> I dunno, I think holding your breath that long is probably pretty boring.
<fullermd> Maybe not for your heirs, I guess.
<vila> she looks worried indeed
<lamalex> jml, is there a convenient way to call testtools.run from python on all of my test_ modules?
<jml> lamalex: 'testtools.run discover [package]' iirc
<jml> lamalex: http://testtools.readthedocs.org/en/latest/for-test-authors.html#running-your-tests will get it righter than me :)
<lamalex> jml, thats from a shell though
<jml> lamalex: what are you trying to do?
<jml> lamalex: or, is testtools.run.main() not convenient enough for you?
<lamalex> jml, nevermind that discover thing was exactly what i needed
<lamalex> jml, setUp runs for every test_ method, is there a TestCase wide set up?
<jml> lamalex: no.
<jml> lamalex: having such a thing is a bad idea
<lamalex> why's that
<jml> lamalex: because it makes test isolation very hard
<jml> lamalex: which in turn makes it very easy to write tests where a failure or mistake in one corrupts the results of others
<lamalex> jml, yah but we're not writing traditional unit tests
<jml> lamalex: are you not interested in the results of these tests?
<vila> wgz: encoding guessing... to cope with people using wrong fs encodings or not setting any ?
<vila> (I had to breath .... ;)
<wgz> not quite yet, but that one is on the list :)
<vila> oooh, at least properly reporting the full string on unicode exceptions ?
<wgz> yup, and full unicode output for all errors.
 * vila whistles
 * vila hugs mgz too
<fullermd> Pah.  7 bits should be enough for anyone.
<vila> now, given that nexuiz-data needs more than 24h and that we kill imports that exceed their 24h quota... we need a finer-grained configuration ;)
<vila> jelmer: pretty cute failure: http://babune.ladeuil.net:24842/job/selftest-chroot-precise/lastFailedBuild/testReport/junit/bzrlib.tests.blackbox.test_checkout/TestSmartServerCheckout/test_lightweight_checkout/
<vila> jelmer: looks like you did even better than you thought ;-D
<jelmer> vila: argh
<jelmer> vila: we'll have to change the lower limit to 34 I guess
<vila> jelmer: yup, not a problem
<jelmer> vila: there's a lot of variation in a single "bzr co --lightweight" command
<vila> which is not ideal for a test but meh
<vila> the point is to not go up
<vila> do you really need the 9 commits ?
<jelmer> vila: this is before I worked my magic btw ;-) the hpss-get-inventories branch brings it down to 15
<vila> woohoo
<vila> jelmer, mgz : would you mind clearing the active reviews page guys, you have 7 approved reviews ready to land there :)
<wgz> I'm trying to get everything ready all at once :D
<vila> hehe, beware of conflicts when landing... the more you land before hand the less conflicts you bump into ;)
<vila> on top of that you have one for 2.4 that will need to be merged up ;-p
<jelmer> hmm
<jelmer> vila: I wonder if that RevisionNotPresent issue we've been hitting with the importer is related to the repository not clearing it's caching of negative revids in the parent map cache
<jelmer> vila: it looks like the "PoMerger created" message made it into bzr.dev, btw
<kirkland> okay, a couple of bzr fast-import questions, from git
<kirkland> I've done the fast-export from git, and then fast-import into bzr
<kirkland> I now have a directory of a bunch of branches/tags, I think
<kirkland> I guess I'm trying to figure out what/how to do with those
<jelmer> hi Dustin
<jelmer> kirkland: You should be able to just use those branches like you normally would
<jelmer> kirkland: if they don't have a working tree yet, you can use "bzr co" to create one
<kirkland> jelmer: oh, hmm, okay
<kirkland> jelmer: let me try those
<kirkland> jelmer: all of them looked "empty" except for .bzr
<kirkland> jelmer: i guess i just needed to co them
<jelmer> kirkland: we should have bzr-fastimport hint that the branches created are tree-less, just like most other bzr import tools do
<jelmer> kirkland: this is done for space reasons, btw - you don't want to end up with 20 copies of the kernel if you're fastimporting a kernel repo with 20 branches
<vila> jelmer: I left it there on purpose, I still have doubts about whether it's created only once and it's the cheapest way to gather data. Once I get this feedback, I'll address the issue one way or the other (remove the message or fix the duplicated creation)
<vila> jelmer: hence my reply to your review: "It's not useless noise" ;)
<jelmer> vila: it should at least be hidden behind a debug flag in that case I think
<jelmer> vila: it's showing up for every revision processed by the udd importer
<vila> it's one line per merge and will be useless if hidden behind a debug flag...
<Noldorin> what's the easiest way to run Bzr server as a Windows Service?
<jelmer> vila: that's the case for lots of things
<jelmer> vila: doesn't mean we have them enabled by default :_)
<vila> then consider that I put a debug flag active by default and that this will be revisited
<jelmer> vila: sure, I'll file a bug
<vila> if you're really searching to reduce the size of the import logs, there are far bigger targets though
<jelmer> vila: sure, I'm just saying it's noise unless you're actually trying to debug something related to pomerge
<vila> I *am* :)
<vila> I mentioned that I've seen at least one case where the message where there twice for the same merge
<vila> but to avoid chasing ghosts for too long I submitted without digging further (nothing in my proposal should trigger such a behavior)
<vila> and there is one spurious merge in this sentence
<vila> ghaa, where not merge
<vila> way past EOD ;)
<jelmer> vila: I still don't think that's a good reason, by that reasoning we might as well enable a whole bunch of things because they will help with debugging - like -Dhpss and -Devil
<jelmer> vila: if there was a -Dpo_merge flag, *you* could enable it
<jelmer> anyway, it is indeed well past EOD :-)
#bzr 2011-12-03
<pcpratts> any ideas why my system can't find bzr-gtk?
<pcpratts> I installed from the ppa, sudo apt-get install bzr-gtk
<pcpratts> pcpratts@helloworld:~$ bzr-gtk
<pcpratts> bzr-gtk: command not found
<pcpratts> are there any tests I can do?
<jelmer> pcpratts: bzr-gtk is a plugin for bzr, which provides extra subcommands to bzr
<jelmer> e.g. "bzr viz"
<pcpratts> jelmer: okay thanks!
<pcpratts> I have used git and hg
<pcpratts> learning to use bzr so I can push a .deb package to a ppa
<pcpratts> have to do something fun on a friday night
<pcpratts> jelmer: do you know of somewhere I can find the available bzr-gtk commands?
<pcpratts> ah, I found it.  bzr help gtk
#bzr 2011-12-04
<Noldorin_> any windows guys around here?
<jelmer> hi Noldorin_
<fullermd> I hope so.  I haven't laughed a good schadenfrudes laugh all day.
<Noldorin_> hi jelmer
<Noldorin_> fullermd, hmm? i think you mean masochists. schadenfreude is enjoying others' pain ;-)
<Noldorin_> which you may be :-)
<Noldorin_> heh
<fullermd> If they're running windows and I'm not, I am   ;p
<Noldorin_> fullermd, yeah, but you said laughed at schadenfrudes... which doesn't quite make sense. unless you're laughing at people laughing at windows users ;-)
<Noldorin_> though i like your poetic license with the word schadenfrude anyway :-P
<fullermd> Well, it was rather flowery phrasing maybe.  But it's like "laughed a good laugh"; doesn't mean you're laughing AT a good laugh, just laughing in a good way.
<fullermd> Thus, I'd be laughing in a scadenfreudorific fashion.
<Noldorin_> fullermd, oh right, i slightly misread your original message
<Noldorin_> yeah.,
<Noldorin_> fair enough
<Noldorin_> fullermd, still, lol @ "schadenfrude"
<fullermd> (yes, language _is_ my plaything, why do you ask?  ;)
<Noldorin_> i don't ask ;-)
<Noldorin_> but i do admire the rare software developer who has a good grasp of natural language in addition to those of the programming variety.
<fullermd> Well, I'm a perl guy, not a python nut.  Twisting things into valid but bizarrely hideous constructs is second nature.
<fullermd> Maybe first and a halfth nature.
<Noldorin_> heh
<Noldorin_> thou speaketh not with forked tongue.
<fullermd> Depends on what I'm working on.  Sometimes, my language _does_ get pretty forked.
<Noldorin_> fullermd, especially if it's process-related bash ;-)
<fullermd> Oh, I'd be all KINDS of forked off if my processes started showing up under bash...
 * fullermd hugs his precious %
<Noldorin_> meh, powershell is what the cool kids use these days.
<fullermd> I...   you...   it doesn't...   the world...   I...
 * fullermd huddles up in the corner whimpering.
 * Noldorin_ ticks off the 100'th unix fan he's made sob
<Noldorin_> you got to admit, windows users are harder to troll :-D
<fullermd> Do you get a new badge for that, or is it just an endorsement?
<Noldorin_> personal gratification
<Noldorin_> everyone has their own way :-)
<fullermd> Well, yeah.  But it's uncouth to even try.
<fullermd> It's unsporting to engage in a battle of wits with an unarmed man.
<Noldorin_> oh trust me, if i wanted to face an unarmed man, i'd pick on Apple users.
<Noldorin_> i daresay there's 100s of delightfully trollable users online Freenode right now!
<Noldorin_> *sits here typing this on his MacBook Pro*
<fullermd> If you unsuccessfully troll yourself, is that victory or defeat?
<Noldorin_> it's some strange superposition of the two
<Noldorin_> Schrodinger called it win-lose.
<Noldorin_> it has adverse affects on the fabric of quantum space-time.
<fullermd> Ah yes, Quantum Trollodynamics.  Much harder to evaluate than the old Substandard Model.
<Noldorin_> i can't decide whether that's the study of the motion of tiny trolls, or the study of the effects of a little bit of trolling
<fullermd> Well, it means when you get into sufficiently small quantities of trolling, it becomes impossible to tell which side is being trolled.  Only on the macro-level do things settle down.
<Noldorin_> yeah. it's what makes uber-trolls so deterministic.
<Noldorin_> predictable, that is.
<Noldorin_> i'm still waiting for the 10^-50 chance some uber-troll spontaneously trolls himself.
<fullermd> These sort of things have a built in uncertainty principle, too.  It's impossible to discuss them at all without driving any real physicists in the audience into a seething rage over pop-cultural interpretations of their field...
<Noldorin_> it's the only reason i'm on IRC, you now
<Noldorin_> know*
<Noldorin_> research into QTD.
<lifeless> quantum troll displacement?
<Noldorin_> quantum trollodynamics
<Noldorin_> but indeed, displacement is an interesting phenomenon too
<Noldorin_> i hear there's a net out-flux from EFnet these days
<fullermd> That's just Cherangstkov radiation.
<Noldorin_> fullermd, funnily enough, i am a "physicist", and as such can vouch that our humour is pretty much confined to this level
<Noldorin_> in the same way the quark-gluon palsma is confined to the atomic nucleus.
<fullermd> Only until we turn up the Electron Pump.
<Noldorin_> don't meddle with such things
<Noldorin_> the results are unknowable!
<fullermd> Oh sure, _that_ advice always has the desired effect   :p
<fullermd> You say "meddle", I say "hold my beer and watch this!"
<Noldorin_> irony is interpreted literally by physicists, alas
<fullermd> So I Fe.
<Noldorin_> you iron?
<Noldorin_> ppft.
<fullermd> Sometimes iron, sometimes youron.
<fullermd> I don't know.  Third base.
<Noldorin_> hah.
<Noldorin_> well, i dare not pollute this channel any more. :-P
<Noldorin_> 'twas a jolly good banter.
<fullermd> If you flip it upside down, it makes a good turban   :>
<Noldorin_> even better
<Noldorin_> i shall don the turban (turban?) and depart.
<Noldorin_> adieu
<fullermd> No, aeiou
<richardus> is there a way to get bzr to print the actual diffs of a range of commits as a patch?  something like git format patch or git log -p.
<richardus> i've got a few commits in my repo but there's lots of unadded/changed files and bzr diff -r keeps sticking those in the output
<Kamping_Kaiser> not sure i follow, 'actual diffs' as opposed to changes?
<richardus> actual diffs as in the diffs that went into the change.  the output you would see from git log -p
<Kamping_Kaiser> including the commit message? bzr log --show-diff might be what oure after
<richardus> hmm, that's close!  it's still showing files with unadded modifications though
<Kamping_Kaiser> don't think i can help you past that - i'm not deep into such things. hopefully someone else will appear soon and give you a solution
<richardus> thanks for offering
<Kamping_Kaiser> np,gl
<richardus> (i tried a dummy commit after my good commits but it still shows unadded files, wtf)
<jelmer> richardus: bzr log -p
<wgz> always amusing when go to retarget a bug I just got mail for and see jelmer did it five minutes ago
<vila> ...passing around doing the same, and see gz commented on it 12 minutes later but still 5 minutes ago ;-p
<wgz> ehehe
<jelmer> wgz: clearly you should install a faster MDA :-P
<Noldorin> hey folks
<Noldorin> any bzr windows devs around?
 * fullermd has the weirdest feeling of deja vu.
<jelmer> hi Noldorin, fullermd
<Noldorin> fullermd, who knows why
<Noldorin> hi jelmer
<fullermd> The Shadow knows!
<Noldorin> tau neutrinos must have broken the speed limit again!
<Noldorin> tut tut
<Noldorin> wgz, you're not a windows dev are you? "_
<wgz> on the basis of this evening, no
<wgz> Noldorin: if you have a question, it's generally best to just ask it
<wgz> if I don't know the answer, someone else in the channel may.
<Noldorin> heh okay, i suppose
<Noldorin> does anyone know how to set up bzr as a Windows service?
<Noldorin> server, of course
<wgz> you generally don't, because you need an authentication layer
<wgz> so, I have apache running as a service, and mod_wsgi imports bzrlib
<wgz> or you could have an ssh server, or something else, which would then invoke bzr
<wgz> so, what are you trying to do exactly? just share stuff over the local network, or expose bzr to the internet?
<Noldorin> wgz, both intranet and internet
<Noldorin> wgz, surely smart server is the way to do it?
<wgz> sure, but it has no authentication, so you can't use `bzr serve`
<Noldorin> how do you mean?
<wgz> if you let the internet access a plain bzr tcp protocol, you're letting the entire world do whatever they like to your disk
<Noldorin> oh sure. of course
<wgz> hence the use of bzr+http or bzr+ssh rather than just bzr
<Noldorin> but smart serv uses ssh no?
<wgz> in which case, you're not running bzr as a service, you're running httpd or sshd as a service
<wgz> no.
<Noldorin> except i'm on windows
<Noldorin> heh
<Noldorin> but fair enough
#bzr 2012-11-26
<Logan_> Can any UDDers please perform this? $ requeue_package.py --full initramfs-tools
<bob2> don't you want #launchpad instead?
<Logan_> Someone recommended that I go here for this request.
<Logan_> jam, maybe?
<Logan_> Or lifeless?
<jam> Logan_: lifeless is no longer @canonical, but I'll look into it. One moment.
<Logan_> Alright, thanks. :)
<Logan_> I'm requesting it based on http://package-import.ubuntu.com/status/ and the linked https://bugs.launchpad.net/udd/+bug/714622 , which recommends running that command for packages that encounter that bzr failure. It has worked in the past.
<ubot5> Ubuntu bug 714622 in Ubuntu Distributed Development "import fails when lp branch has been push --overwrite'n" [High,Confirmed]
<jam> Logan_: I have requeued your package.
<Logan_> Awesome, thanks jam. :)
<gour> morning
<gour> i've a need to use svn to contribute to some open-source project, so wonder how does bzr-svn compare with hg & git's options?
<gour> otoh, it's sad to see bzr development stalled :-(
<lifeless> bzr-svn is pretty good
<mgz> mornin'
<jam> morning mgz
<gour> lifeless: what's going  to happen with bzr?
<mathrick> hiya
<mathrick> so what exactly is the difference between development-colo and bzr-colo, and how am I supposed to use the former?
<jiku> hello All..
<jiku> im pretty new to bazaar and would like to implement it in my workplace..
<jiku> bzr-explorer is good and would like to master it so that i can talk to developers on how to use it and create a workflow.
<jiku> 1 issue im facing is..
<jiku> i have a revision in the server with name, think-blog..
<jiku> i checkout in a client (win7) machine with bzr-explorer installed.
<jiku> it asks for sftp password when doing checkout which is normal.
<jiku> once i download, if im not wrong, the revision with its history is saved in the client..
<jiku> but here whenever i open bazaar explorer and open that working tree, it asks for passwords.. when i do a diff, it asks for passwrods..
<jiku> why is it still dependent on the server which actually should be doing everything from the local perspective ?
<jiku> any ideas ?
<jiku> or is it that im doing it wrong ?
<jiku> hi,.. anybody ?
<mgz> jiku: you don't want a lightweight checkout, you want to make a proper branch
<jiku> mgz, oh.. ok...
<jiku> i was doing that by default..
<jiku> let me try again.
<mgz> you then also may want to put the passwords in your authentications.conf file, see `bzr help authentication`
<jiku> ok..
<jiku> let me try this..
<mgz> or, use an agent so you don't type the password each time but use a public key instea
<mgz> d
<mgz> mathrick: you don't want to use development-colo, but you can use the builtin colo support in 2.6, it's just a little less polished than the bzr-colo plugin
<jiku> mgz, hmm..
<jiku> looks like, whenever i do a checkout using explorer, it does  with --lightweight enabled.
<mgz> you don't want to do checkout
<mgz> you want a branch
<mgz> (I suspect)
<mgz> if you have options over workflows, you really don't want to emulate the centralised server thing of svn etc
<jiku> mgz, true.. yes..
<jiku> mgz, was confused with git (never used but just read).. there you checkout and branch.. (if im not wrong)
<mgz> depends what you think you can get everyone else to use, but having a full branch locally, and working with trunk+merge is how to get the main benefit of dvcs
<jiku> yes.. right.. this is what we need actually.. there shouldn't be a centralized locking..
<mgz> in git, saying 'checkout' means get me all the history, and branch just... prints the branch name or something
<mathrick> mgz: right, but still, how do I use it? I don't see much explaining how to do it
<mgz> mathrick: basically, you just create a new standalone branch, do `bzr switch -b trunk` or whatever to name the default branch
<mathrick> ah
<mgz> then you can do `bzr switch -b feature` to create a feature branch
<mgz> `bzr switch trunk` to go back to trunk
<mathrick> and what about cloning, will it carry over all branches?
<mgz> the main missing thing is a nice addressing scheme for colocated branches outside of a few commands
<mathrick> I see an open bug about it, so I guess not?
<mgz> right, it doesn't, though there's a workaround of some kind I think
<mathrick> what'd that be?
<mgz> not sure, but it's reasonably trivial to iterate over local branches and push them all up, there's a plugin that does something like that for shared repos
<mathrick> this was what I hoped most for, along with fixing the fact that bzr-colo refers to branches with absolute paths, which breaks alternative approaches of just sharing the same workspace dir amongst many machines
<mathrick> mgz: well, yes, but it needs thinking on my part and remembering to do it. As much as I think git's model is stupid, the fact that fetch carries over everything is a boon
<mathrick> not just my part, but everyone I talk to
<mathrick> which is a bigger problem really
<mathrick> mgz: does 2.6 need anything in the way of the branch format to support colocated branches?
<mgz> nope, that's all done
<mathrick> so just 2a?
<mgz> it's just making it all pretty to use that's unfinished
<mathrick> mhm
<mgz> I'm using it for one project currently as an experiment
<mgz> apart from some confusion setting up, and needing to know to type file:,branch=FEATURE in a few circumstances, I've not had any issues
<mgz> that said, I've not wanted to push all branches, push has been specifically for updating remote trunk after feature branch merge
<Logan_> jam: Can you please do < requeue_package.py --full iscsitarget > when you get the chance? Thanks so much!
<Logan_> (Or any other UDDer, for that matter.)
<mgz> warum?
<mgz> I can do this... well, I could look at the package log as well, but would prefer to not take 15 minutes looking at it first.
<nDuff> Is shelve expected to work with bzr-svn? I'm getting "NotImplementedError: <bound method SvnBasisTree.path_content_summary of <SvnBasisTree for '<SvnWorkingTree of /home/cduffy/VC/boundsetter>'>>"
<jelmer> nDuff: no, I don't think it works with bzr-svn
#bzr 2012-11-27
<lduros> Hi there, what's the proper way to resolve a content conflict when you have a directory and you have a directory from the tree you're merging but you really don't want that directory to be there? I tried bzr rm [directory], but then when I do bzr resolve, it doesn't seem to list it as resolved
<lduros> I guess after rm -rf the directory, if I do bzr resolve --all. it takes care of it
<didrocks> hey
<didrocks> I have a branch which is in split mode (well, I guess seeing my change to .bzr-builddeb/default.conf)
<didrocks> but when I bzr bd, I see: Building package in native mode
<didrocks> and then:
<didrocks> This package has a Debian revision number but there does not seem to be
<didrocks> an appropriate original tar file or .orig directory in the parent directory;
<didrocks> â¦
<didrocks> any idea what can happen? Forcing split mode with --split in bzr bd, it works fine
<jelmer> didrocks: debian/source/format perhaps?
<didrocks> jelmer: it's set to 3.0 (quilt), does it impact it? it's run before bzr split it?
<didrocks> oh
<didrocks> yeah, it's native, not split
<didrocks> thanks jelmer :)
#bzr 2012-11-28
<AfC> I just did my first Pull Request on GitHub.
<AfC> I feel dirty.
<fullermd> Did you wear gloves?
<gmarkall> sometimes when i try to rebase, bzr identifies almost an entire file being in conflict when only a small portion has changed - does that sound like I'm doing something wrong?
<AfC> In bzr land, using rebase is doing it wrong, but anyway.
<gmarkall> i've just noted that if i try a merge instead, it seems to pick out the lines that have actually changed
<gmarkall> AfC: can I quote you on that?
<gmarkall> (i'm not a fan of rebasing with bzr at all! :-) )
<AfC> gmarkall: sure
<AfC> gmarkall: Bazaar takes a much stronger view of merging, and doesn't encourage people to throw history away. Some Git communities think that merging (by anyone other than the maintainer) is bad, so rebase.
<AfC> gmarkall: my impression is that GitHub has effectively made it such that people don't have to think about this anymore, but we'll see
<LeoNerd> I hardly ever rebase in bzr
<LeoNerd> The only time I do it is when I accidentally diverged history on a branch, say, between my laptop and my server by not being up-to-date first before committing locally on the laptop
<mgz> I cherrypick specific changes from time to time, which is pretty much the same thing
<mgz> but easier to do safely as you have two branches at all points
<gmarkall> AfC: thanks. when you say "people don't have to think about this anymore", are you referring to the fact that you can just click a button to merge a pull request as long as its rebased on the branch being merged into?
<gmarkall> or do you mean that people are rebasing without thinking?
<AfC> gmarkall: no, that it's provinding better UI around commit selection and selectively viewing history
<AfC> gmarkall: meaning you don't have to rebase
<gmarkall> ah, right
<gmarkall> so anyway, if a project is using bzr and wants clean history (hence the rebasing), it's acceptable to say "you're not using a good strategy, could you please start using merging instead of rebasing?"
<gmarkall> since i'm relatively inexperienced with bzr, i'd be nervous about telling people how to use it without being sure of what i'm saying
<LarstiQ_> gmarkall: hmmm, telling others how to work is perhaps not the way to go
<fullermd> Not?  Well, what's the fun in THAT?
 * LarstiQ_ stresses the perhaps
<gmarkall> it does seem rather brazen
 * LarstiQ_ isn't sure what to suggest
<LarstiQ_> gmarkall: how attached are they to this workflow?
<LarstiQ_> gmarkall: rebasing can be useful, but there are reasons not to do it all the time. Perhaps dig up a post by Linus where he complains about this.
<LarstiQ_> gmarkall: I guess I don't understand this desire for a "clean history" over real history
 * LarstiQ_ back to math
<fullermd> Hey, you eliminate terms in math.  That's just like making a clean history   ;p
<gokr> I know its a bit silly to enter and ask this question but I do have quite a bit of experience of SCMs but can't really find a proper "modern" comparison of bzr and hg. If anyone can share their view on why bzr is preferrable I am interested.
<gokr> I have used git, SVN, CVS, darcs and even hg a bit a few years back. Only dabbled with bzr but now I am contemplating giving it a more serious try.
<wilx> Hi.
<wilx> What does 'bzr rmbranch' do exactly?
<wilx> What if I just do 'rm -rf foo' on the branch checkout and directory inside my shared tree?
<wilx> What is the difference?
<jelmer> wilx: rmbranch removes the branch, not the tree or the control directory
<wilx> Hmm, like in the shared repository's metadata?
<jelmer> wilx: in older style bzr branches it basically removes .bzr/branch
<wilx> Or to put it another way around: Can I safely do 'rm -rf foo work-foo' to remove the temporary foo branch from my shared repo?
<wilx> Ah.
<jelmer> wilx: yes
<wilx> Cool, thank you.
#bzr 2012-11-29
<mgz> morning!
<jelmer> hey mgz!
<mgz> hey!
<vila> hey jelmer, mgz ;)
<jelmer> hi vila
<jlf> hi #bzr, i'm getting the error 'bzr: ERROR: Unable to connect to target of bound branch BzrBranch7(file:///Users/jlf/trunk/) => bzr+ssh://jlf@bzr.savannah.gnu.org/emacs/trunk/: Not a branch: "bzr+ssh://jlf@bzr.savannah.gnu.org/emacs/trunk/".' when i try to do  bzr up  -- this may be due to firewall settings beyond my control.  can i specify an alternate transport method to update my repo?
<LarstiQ_> jlf: that depends on what savannah is providing
<LarstiQ_> jlf: but, maybe that is not the problem
<LarstiQ_> jlf: can you verify some other way /emacs/trunk exists and is a bzr branch?
<LarstiQ_> jlf: hitchhiker might be helpful
<jlf> i've used this in the past without incident, but i suspect the firewall is blocking me from this location
<LarstiQ_> aha, then the error is a bit misleading
<jlf> it wouldn't be the first time :)
<LarstiQ_> jlf: other transports are slower, but you could see if http or sftp works (though if ssh works, sftp probably doesn't either)
<LarstiQ_> jlf: myself I'd maybe try tunneling ssh through somewhere else
<jlf> i'm something of a noob -- how can i check and specify the transport method?  iow i can set up a tunnel but i don't know how to tell bzr to go there instead of savannah:22
<LarstiQ_> jlf: if savannah provides the bzr:// protocol you can also try that
<LarstiQ_> jlf: let's see
<LarstiQ_> jlf: either a Host entry in ~/.ssh/config, since bzr calls out to ssh anyway, or
<LarstiQ_> jlf: bzr+ssh://host:port/path
<jlf> LarstiQ_: thanks.  since i don't see an option to specify transport in  bzr up  , how should i specify it?
<LarstiQ_> jlf: that sounds like you're using a checkout
<jlf> i'm an extremely casual user but i have pushed a few changes into the tree successfully this way
<LarstiQ_> jlf: you can use `bzr bind bzr+ssh://host:port` to bind your checkout to something else
<jlf> great, thank you!
<LarstiQ_> jlf: remember to change it back when the firewall is no longer an obstacle :)
 * jlf nods
<fullermd> Doing manual ssh/sftp-ery is a good way to see if you can't track down where things break.
#bzr 2012-11-30
<delinquentme> someone removed my .rvmrc file from the repo ... once upon a time it was mainted in the repo
<delinquentme> is there a way to restore the version in a given revno?
<mgz> morning
<ccxCZ> is there a tool to visualise the branching of several branches with same root?
<ccxCZ> launchpad has something like that on project pages iirc
<mgz> you can run qlog in a shared repo and get multi-branch history, probably not quite what you want but can be handy
<ccxCZ> that's for only one branch though?
<ccxCZ> how would I go about traversing everything in a shared repository and creating a graphviz diagram for it? http://people.canonical.com/~mwh/bzrlibapi/bzrlib.repository.Repository.html#all_revision_ids returns an iterator over a http://people.canonical.com/~mwh/bzrlibapi/bzrlib.revision.html I assume...
<mgz> ccxCZ: see the bzr branches command for reference, bzrlib/builtins.py cmd_branches
<ccxCZ> hmm, so far it seems simpler to postprocess the output of log --long --with-ids with awk instead of doing it using bzrlib
<LarstiQ> ccxCZ: qlog can do multiple branches, `bzr qlog ~/branch1 ~/branch2` is an example from its help
<ccxCZ> neat, thanks
<lduros> hi, I'm doing bzr export new-folder mybranch and it's a pretty big directory, on which I run ./configure && make -- then when I make change to my branch, is there a way to update the exported folder without rewriting all the files there?
<mgz> lduros: not sure, I'll note that bzr-upload does smarter sync, but if it's just for a local build dir that's probably not what you want
<lduros> hmm, right yeh
<lduros> mgz: I guess the easiest thing to do is to just copy those files manually
<lduros> :-)
<mgz> any particular reason you're not just using a lightweight checkout and using update say?
<lduros> mgz: no, no reason, didn't think about it
<lduros> mgz: i'm still learning bzr really
<lduros> I'm trying to figure out what you mean by a lightweight checkout ;-)
<mgz> well, some things match particular ways of doing stuff better, it's always a bit hard to see without trying and seeing what hurts :)
<lduros> no local branch or repo
<lduros> ok
<lduros> hehe
<nDuff> lduros: *nod* -- lightweight checkouts are more like the traditional svn way of doing things
<mgz> so, `bzr checkout --lightweight mybranch new-folder`
<lduros> mgz: so I just do this: bzr checkout mybranch mylightweightco?
<lduros> ah ok
<lduros> nice :-)
<lduros> alright, that should same me some time on the build :-)
<mgz> as it's a real versioned thing linked to the branch, it can do more, but also possible to get in a bit of a muddle, provided you remember you can just ignore stuff in there if it's a scratch build folder you should be fine
<lduros> right, ok :-)
<lduros> mgz: thanks much for the lesson!
<mgz> what I often do for build-intensive projects where I actually want to use feature branches is have a --no-trees repo with all the branches under it, then a 'tree' lightweight checkout I work in and switch between the branches, and other checkouts on demand
<lduros> hmm, sounds like the way to go!
<lduros> mgz: so once I have made changes to my branch, how do I bring them in my lightweight checkout. if I do bzr merge ../mybranch, it tells me the working tree has uncommitted changes
<lduros> bzr update?
<lduros> yeh looks like it
<lduros> cool!
<lduros> :-)
<mgz> that's the one :)
#bzr 2013-11-25
<amitprakash> Hi, how do I get the code from a directory in a bzr repository? specifically.. how do I get the code here http://bzr.mozilla.org/bmo/4.2/files
<lifeless> amitprakash: bzr branch http://bzr.mozilla.org/bmo/4.2 I imagine
<LeoNerd> So... It turns out that bzr over a 3-hop ProxyCommand sshfs is a liiiitttle bit slow
<LeoNerd> Like... orders of magnitude slower than just filesystem access on the disk
<fullermd> That's 'cuz 3 is a prime number.  Add 1 more hop; perfect squares are way faster.
<KombuchaKip> Avaneya, a libre cerebral sci-fi for GNU under development! https://www.avaneya.com
#bzr 2013-11-26
<vinmassaro> anyone know how to fix this error with the bzr-svn plugin? "No module named subvertpy"
<beuno> vinmassaro, install python-subvertpy maybe?
<abadger1999> abentley: Hey, Yesterday I received a bug report about bzrtools being out of date wrt bzr-2.6 for the Fedora packaging.
<abadger1999> abentley: Any plans to make a new bzrtools release for bzr-2.6?
<abentley> abadger1999: Sorry, I've been slack.
<abadger1999> abentley: no worries.  Just making sure bzrtools is still alive ;-)
 * fullermd tightens abentley a few turns.
<vinmassaro> beuno: ok, just installed subvertpy and now i get "ERROR: exceptions.ImportError: cannot import name CommittedQueue" when running `bzr info`
<abentley> abadger1999: IIRC, there actually are some compatibility problems, so doing it will require some work.
<abadger1999> abentley: <nod>  I saw that you had a compat commt on bzrtools.dev and this branch was pointed out to me: https://code.launchpad.net/~andrewsomething/bzrtools/kill_get_ancestry/+merge/126586
<abadger1999> I don't know the bzr code well enough to know what else might need changing.
<vinmassaro> beuno: FWIW i installed an older version of subvertpy and it works now. thanks!
<beuno> vinmassaro, cool cool
<ovidiu-florin> hello world
<ovidiu-florin> I've downloaded https://code.launchpad.net/~jr/+junk/kubuntu-docs-downloader and made some modifications, I want to uploaded it to my account and then send it to the devveloper to be merged. How do I do that?
#bzr 2013-11-27
<pgnd> Is there a release/branch of BzrTools compatible with Bzr v2.6.0 release?  Checking here http://wiki.bazaar.canonical.com/BzrTools & https://code.launchpad.net/bzrtools , does not appear to be ...
#bzr 2013-11-28
<LeoNerd> Meh.. shelve's Edit manually is all well and good but I've never managed to unshelve it without it leaving two levels of conflict markers in my file... :/
<mightyiam> hi. i moved a whole bzr controlled directory and now when i do 'pull' i get 'error: not a branch'
#bzr 2013-11-29
<Wiz_KeeD> hey guys, i need some help with a merge, my scenario is exactly like this guy: http://stackoverflow.com/questions/6581330/how-to-properly-merge-two-bzr-branches
<Wiz_KeeD> But I would like to see all the differences between the files
<Wiz_KeeD> Can someone tell me how bzr merge works?
#bzr 2013-11-30
<Wiz_KeeD> hey guys!
#bzr 2013-12-01
<Wiz_KeeD> hey guys
<Wiz_KeeD> anyone on?
<Ven-2> hello
<Ven-2> anybody can help me to publicate font on ubuntu?
<Ven-2> https://github.com/texrg/Labiryntowy
<Ven-2> this is freeware
#bzr 2014-11-24
<peetaur> What's the easiest way to split up a big patch into a bunch of smaller ones?
<mgrandi> well, you can either commit only some of the files at a time
<mgrandi> or you can select only certain parts of files to commit, although i believe that requires staging (this is easiest in bzr explorer -> stage)
<mgrandi> err, shelve
<peetaur> is bzr explorer some other tool?
<mgrandi> its a GUI for bazaar, makes certain things eaiser
<mgrandi> easier*
<peetaur> how do I make a local commit? I split one of my patches manually and it won't let me commit, since it seems to want to send to the remote.
<peetaur> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~apparmor-dev/apparmor/master/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
<mgrandi> you append --local when you do bzr commit, although thats weird that its doing that, is it bound to the http version of the branch?
<mgrandi> probably should unbind the branch, 'bzr unbind'
<mgrandi> and rebind it with the correct url, "bzr branch lp:apparmor"
<mgrandi> err "bzr bind lp:apparmor"
<peetaur> and then I can commit locally?
<mgrandi> if you 'bind' a branch, it wants to commit to remote after you commit locally, sort of like svn
<mgrandi> if you only want to commit locally now, just 'bzr unbind'
<peetaur> okay so I did the bind thing and same sort of thing     bzr: ERROR: Cannot lock LockDir(chroot-72202384:///%2Bbranch/apparmor/.bzr/branch/lock): Transport operation not possible: readonly transport
<peetaur> so I have to unbind every time I want to commit locally?
<peetaur> no way to add multiple remotes like with git, and choose when and where to push?
<mgrandi> what is chroot-72202384?
<peetaur> no idea :D
<mgrandi> Bind is just a convince, to make it act like SVN, its not really like a git remote
<mgrandi> jelmer: do you have any idea what his problem is?
<mgrandi> you can just leave it 'unbound', and then when you are ready, you commit it, and push it to launchpad, then you can do a merge request there
<peetaur> k, I think that answers an unasked question.. so when I bind, I'm binding to my own personal thing then
<peetaur> can people choose individual commits from my online version?
<peetaur> (without manually editing that is)
<mgrandi> they can set the branch tip to be a certain commit and merge that
<mgrandi> although i'm pretty sure merging one commit is preferable then a bunch of them
<mgrandi> you can have multiple commits, like commit 1: fixed thing, part 1, commit 2: part 2, commit 3: finished feature, and then at commit 3 they merge it
<peetaur> k, well I have a feature, a few fixes, and some typos, and 2 major performance fixes (one or the other or both takes a certain audit.log processing down from unknown >1h to 5 min :))
<peetaur> well actually one of the bugs is 1/2 performance fixes
<mgrandi> well usually in all version controls, a merge request should be 1 thing
<peetaur> so I can just dump that there and they won't scream?
<mgrandi> so 1 merge for a feature, 1 for the bug fixes, etc
<peetaur> can I request one feature merged even if my online thing has a bunch?
<mgrandi> i'd probably ask on wherever apparmor's irc is and see if they have a preference
<peetaur> k, I think they just want email on the list
<peetaur> but the online thing would be an interesting option, like if I could link them to my patches there or something
<mgrandi> that too, you can just generate a patch file
<mgrandi> i would just have it so you have the base that you branched off of
<mgrandi> one patch file that goes from base -> code with feature
<mgrandi> one that is base -> code with bug fixes
<mgrandi> one with base -> log improvements, tec
<mgrandi> etc*
<peetaur> what I was planning was to split my commit into a few, then do like "git diff oldremote commit1" and send, then "git diff commit1 commit2" etc
<peetaur> does that plan make sense with bzr?
<peetaur> so to merge my question and your question...   you say file, but I say commit. Can bzr do diffs between local commits like git can?
<mgrandi> yeah
<mgrandi> "bzr diff -p1" is equivalent to "bzr diff --prefix old/:new/", and
<mgrandi>   produces patches suitable for "patch -p1"
<peetaur> I have been simply using "diff" and patch -p1 seems happy :D
<peetaur> "bzr diff" that is
<peetaur> or maybe I imagined it
<peetaur> https://bugs.launchpad.net/bzr-historycache/+bug/382957  how do I disable plugins?
<ubot5> Launchpad bug 382957 in Bazaar History Cache "bzr: ERROR: Transport operation not possible: readonly transport" [Low,Confirmed]
<mgrandi> so you are using bzr-historycache?
<peetaur> I don't think so https://bpaste.net/show/7281d000cfdc
<peetaur> so is that not my bug?
<mgrandi> can you paste the entire traceback when you are getting the 'transport operation not possible'?
<peetaur> there is no trace, only that line
<peetaur> is this related then? do I need to create a new branch? https://answers.launchpad.net/launchpad/+question/154704
<mgrandi> one sec
<mgrandi> are you sure your branch is unbound?
<mgrandi> bzr info -v
<mgrandi> paste that in pastebin
<peetaur> I am not sure of anything... I don't know bzr at all :D  https://bpaste.net/show/cfc4a9afda09
<peetaur> it is not unbound
<mgrandi> so run bzr unbind just to be sure
<peetaur> because I ran "bzr bind lp:apparmor"
<peetaur> but I wanted to put it on lp to test it
<mgrandi> just run 'bzr unbind', don't need to specify a url
<mgrandi> you need to create a branch on launchpad i believe
<mgrandi> or fork it
<mgrandi> somehow on bzr
<mgrandi> one sec let me find it
<mgrandi> ok
<mgrandi> you branched lp:apparmor
<mgrandi> for something i did a while ago, it says for me (except it was lp:bzr)
<mgrandi> https://gist.github.com/anonymous/6086156f7e6d80caeb81
<mgrandi> so try bzr push lp:~<USERNAME>/bzr/<BRANCH_NAME>
<peetaur> push, or bind?
<mgrandi> push
<mgrandi> that will put your branch on launchpad
<mgrandi> and then you can go to "https://code.launchpad.net/~apparmor-dev/apparmor/master", and click "propose for merging"
<peetaur> how can someone view my branch without a propose for merging?
<peetaur> oh I guess I found it.... clicked "code" tab at the top of my page https://code.launchpad.net/~peter-maloney/bzr/peter
<mgrandi> yeah
<mgrandi> you put that as the "Target Branch" when you are "registering a merge"
<mgrandi> (when you are here: https://code.launchpad.net/~apparmor-dev/apparmor/master/+register-merge)
<peetaur> yes but the apparmor project does it on the mailing list, so I'll play around with the lp pushing, but not do the merge request
<mgrandi> ok
<peetaur> so thanks for all the help
<peetaur> and I decided that copying my bzr repo, using vimdiff one file at a time, then commiting the copied repo works for splitting patches
<mgrandi> ok! let me know if you have any more questions =)
<peetaur> (copying bzr repo, then "bzr revert" that is)
#bzr 2016-11-29
<jelmer> vila: thanks!
#bzr 2016-11-30
<throstur> a coworker committed an uncommited file, then reverted it, what happened to the changes?
<throstur> ah there it is
<throstur> nevermind
#bzr 2017-11-29
<Zectbumo> Is there a command to shelve and then unshelve --keep? It would be nice to have a bzr snapshot command
<LeoNerd> snapshot?
#bzr 2017-11-30
<Zectbumo> yeah maybe snapshot is a dumb approach and I'm really looking for bzr shelve --keep option
<LeoNerd> Why shelve it?
<Zectbumo> let's say I am developing and then I want to try something crazy
<LeoNerd> commit --local
<Zectbumo> I want to shelve, unshelve --keep and then try my crazy idea. It doesn't work then revert and unshelve
<Zectbumo> ah
<Zectbumo> does that work only on checkout mode?
<LeoNerd> that's a commit without push
<LeoNerd> You can also unbind first, which is then equivslent
<Zectbumo> I'm developing unbounded
<LeoNerd> So just commit
<Zectbumo> and then uncommit
<LeoNerd> You could.. or revert back to an earlier point
<Zectbumo> okay I'll try that. not bad idea
<Zectbumo> looks like I was just afraid to commit
<Zectbumo> ;)
<Zectbumo> Do you know how uncommit works internally? Is it an actual uncommit or a simulation by applying a reverse diff?
<Peng_> Actual uncommit. (And it doesn't remove the commit from the repository.)
<Peng_> (It removes it from the branch, but not the repository's underlying storage.)
<Zectbumo> ah, so logs are still present but no diff/undiff
<Zectbumo> or are you saying the repository does diff then undiff and the branch gets stripped?
<Peng_> Neither?
<Zectbumo> like for instance if a password was checked in and then uncommitted. would the password data exist somewhere?
<Peng_> Yes.
<Zectbumo> okay
<Peng_> Yes./32
<Peng_> Oops
<Zectbumo> thx guys
<Zectbumo> btw, bzr is my favorite and I don't want to move from it and it seems to me that it's not gaining popularity and that scares me
<Zectbumo> One sign I found was Trac and Bzr not working as well anymore and it appeared that nobody was interested in fixing the incompatibilities in the tracbzr plugin for quite some time. It works better now but still all basic functionality is not there.
<Zectbumo> I've already decided I'm going to sink with the ship. (If there is any sinking)