#bzr 2008-05-12
<rockstar> I've just done a bzr checkout of an svn repo (using bzr-svn).  Problem is, when I bzr push the checkout to a branch, I get "bzr: ERROR: At lp:~entertainer-releases/entertainer/devel you have a valid .bzr control directory, but not a branch or repository. This is an unsupported configuration. Please move the target directory out of the way and try again."
<rockstar> Is there a way to work around this?
<jelmer> rockstar: can you try pushing to a slightly different location?
<jelmer> It might be that there's an incomplete branch around
<lifeless> rockstar: push --use-existing-dir
<rockstar> lifeless, same error
<Peng> rockstar: You're using a checkout? Like, "bzr checkout"?
<mwhudson> i guess sftp in an rm .bzr should work
<rockstar> Peng, yea, bzr checkout http://<path-to-svn>
<rockstar> mwhudson, ?
<Peng> It's possible to push from a checkout?
<lifeless> mwhudson: I think the sftp server prhobits that
<lifeless> rockstar: bzr init --rich-root-pack URL might work
<rockstar> lifeless, will that kill my bzr log?
<lifeless> rockstar: EPARSE
<rockstar> Well, the thing I'm trying to accomplish is pretty much a conversion from svn to bzr.  I want to keep the versioning.
<lifeless> of course
<rockstar> I was just wondering if a bzr init would blow out the past versioning
<lifeless> no
<lifeless> bzr init prepares a fresh database
<rockstar> And the versions are stored in the database?
<lifeless> uh
<lifeless> we have lots of things that are versioned
<rockstar> s/are/aren't/
<lifeless> can you be more specific ?
<rockstar> Okay, the output of bzr log, along with the actual changesets
<lifeless> I'm saying create a fresh database on lp
<lifeless> that you then push into
<Peng> rockstar: If there was already a branch at the location, "bzr init" would error out.
<spiv> rockstar: init'ing a repo on a remote server isn't going to affect the history you have locally.
<rockstar> Ah, on the destination.
<rockstar> I think this bazaar version is just too old.
<lifeless> what version is it?
<rockstar> 0.90
<rockstar> :)
<lifeless> yes, please run something created this millenium
<rockstar> Yea, I guess this is the default in gutsy
<Peng> It is.
<Peng> You can use bzr's deb repo thingy. https://launchpad.net/bzr/+archive
<Peng> Or upgrade to Hardy, which almost has the newest version of bzr.
<rockstar> Peng, yes, but there's currently no bzr-svn for 1.5
<jelmer> rockstar, https://lists.ubuntu.com/archives/bazaar-announce/2008-May/000149.html
<rockstar> And I tried building my own package, and it doesn't seem to like life
<jelmer> no PPA yet though
<rockstar> jelmer, thanks, I'm on that list
<nysin> Is there documentation somewhere on the intended usage pattern of bzr-gtk? It looks like it only pays attention to the this/other/base files, but then doesn't fold that back to the non-this/other/base files. How is one intended to bridge that?
<rockstar> Er, no bzr svn for 1.4.  1.5 is just barely rc
<jelmer> rockstar: see that link - that's bzr-svn for bzr 1.4
<nysin> gconflicts in particular
<rockstar> Ah, the ppa must be broken.
<rockstar> I saw an email on the list that said "since 1.4 and 1.5 are coming out so close together, there won't be a ppa release of bzr-svn for 1.4" and thought there would be a release.
<jelmer> rockstar: I announced I wouldn't do a release a the same time as bazaar 1.4
<jelmer> The bzr-svn intended to work with 1.5 also happens to work with 1.4
<rockstar> Ah, I see.
<rockstar> Regardless, it's working now.
<Peng> OMG! New bzr-svn! Yay!
<jelmer> (-:
<Peng> Since I always run bzr.dev, it's been a long time since I've had bzr-svn working.
<thumper> rockstar: you should have the ~bzr PPA in your sources.list :-)
<Peng> Huh. bzr co has a -r option, but up does not.
 * Peng uses revert, then.
<rockstar> thumper, I do.  I was working on another system
<thumper> ah
 * rockstar has more than one system...  :)
<Peng> jelmer: BTW, from when I ran pyflakes/pylint, there are quite a lot of unused imports.
<jelmer> Peng: patches are welcome :-)
<Peng> Hmm.
<Peng> I think I actually got all of the imports.
<Peng> I stopped working on it a bit after that and never got back to it.
<bob2> "someone" should add lazy_import support to pyflakes/lint
<Peng> bzr-svn doesn't lazy_import much, so it wasn't a big problem.
<bob2> ah
<Peng> Now, all of the whining about too many methods or too many arguments or too many lines, that was annoying.
<spiv> bob2: there is a pyflakes branch with lazy_immport support
<jelmer> pylint gives a lot of output and a lot of it is not actually fixable in bzr-svn (such as classes having to much methods or functions having too much arguments)
<spiv> bob2: thanks to mwhudson, IIRC.  You can find it on lp.
<jelmer> Peng, yeah, indeed
<bob2> oh, awesome
<spiv> bob2: yeah, it is awesome
<bob2> also awesome is the "notification" plugin
<Peng> jelmer: The thing is, my linted branch has lots of XXX comments strewn about about things I didn't know how to resolve.
<mwhudson> getting pylint to be useful is A Project
<rockstar> mwhudson, yea, I'm dealing with that right now...
<beuno> abentley, BB web interface seems to be hung up  (email works though)
<Peng> bzr: ERROR: You must have a branch nickname set to loomify a branch
<Peng> :(
<abentley> beuno: It auto-restarted a minute ago.  Should be fine now.
<beuno> abentley, ah, thanks.  Is this because of sqlite, or something else?
<Peng> Oh, ok.
<abentley> beuno: It's an unfortunate interaction between TurboGears and SQLite.
<beuno> abentley, ah, because I want to use BB for a project of mine, and I was thinking of porting the backend to mysql (which I know better then postgre)
<beuno> bot sure if that's something you'd like to see done
<beuno> s/bot/but
<Peng> abentley: bzrtools needs its version compatibility thingy updated for bzr.dev.
<jelmer> Does anybody have experience with the redmine bug tracker?
<igc> jelmer: when you get a moment, can you double check my write up re bzr-svn in the User Guide?
<igc> see http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#bzr-svn
<igc> I probably ought to give an explicit svn-import example
<igc> anything else?
<jelmer> igc: Sure, I'll have a look now
<igc> thanks
<jelmer> igc: svn-push is only required when creating a new branch in Subversion, you should be able to just use "bzr push"
<igc> jelmer: ah good
<igc> I was wondering whether there was any other need for using svn-push over push
<igc> sounds like there isn't?
<igc> jelmer: the help did say svn-push would go away one day
<igc> is that some time off still?
<jelmer> igc: renames are supported (pushing into svn and then pulling those changes back in from svn works) but copy tracking isn't imported
<jelmer> igc: yep, that's still the plan but it depends on some changes in bzr itself
<jelmer> bug 121875
<ubottu> Launchpad bug 121875 in bzr "cmd_push() should abstract away transport.mkdir()" [Wishlist,Confirmed] https://launchpad.net/bugs/121875
<igc> jelmer: any magic source for keeping a bzr repo mirror in sync?
<igc> e.g. a std svn hook we suggest?
<jelmer> igc: not really - you can just use "bzr pull" like you would for keeping a mirror of a bzr branch in sync
<jelmer> "bzr svn-import" is incremental and can be used for full repositories
<jelmer> igc: there's also a small typo; s/0.49/0.4.9/ for the version number
<igc> jelmer: any idea how most bzr-svn are keeping mirrors in sync? cron jobs with svn-import or pull mainly?
<jelmer> I think so, yes
<jelmer> I personally just run pull manually whenever I need the mirror
<jelmer> igc: having an example use of svn-import up there may indeed be useful as well
<igc> jelmer: yes I think so too
<jelmer> Verterok: w00t on the DMG :-)
<Verterok> jelmer: Hi :-)
<Verterok> jelmer: right now I'm trying to build the minimal dependencies (svn client + libs + svn-python), but it's not working as expected :(
<jelmer> Verterok: you're building subversion 1.5?
<Verterok> sort of :P, only trying to get the minimal dependencies to run bzr-svn
<Verterok> but the simples solution to make it available for bzr-1.5, is to bundle bzr-svn in OS X dmg, and point to the subversion dmg
<jelmer> That would be a huge improvement over the current situation
<jelmer> including the svn bits in the Bazaar dmg would be nice but may not be worth the effort
<Verterok> that's my conclusion too...after a few hours trying to get it working
<Verterok> jelmer: for the moment I can build the Tiger dmg (no Leopard yet), but I think I achieved building a universal installer (I can easily add bzr-svn to it) for Tiger...now I only need a mac intel with triger to test it :P
<jelmer> Verterok: awesome, thanks ! :-) There's been quite a few people asking about this...
<Verterok> np ;)
 * Verterok looking for a owner of mac intel with Tiger (to help beta test the installer)  
<michalski> hello, problem: typing this in the terminal: ----> bzr push lp:~michalski/+junk/vector-core
<michalski> returns error:   bzr: ERROR: Transport operation not possible: http does not support mkdir()
<Peng> michalski: You're trying to push over http.
<michalski> how do i do so differently
<Peng> michalski: You should run "bzr launchpad-login" to log in to LP, and it'll start pushing over bzr+ssh.
<michalski> ah ok :)
<Peng> michalski: What version of bzr?
<michalski> not 100% sure but im guessing the latest
<michalski> it says: No Launchpad user ID configured.
 * igc lunch
<michalski> how do i do this?
<Peng> michalski: Oh.
<Peng> michalski: "bzr launchpad-login michalski" or whatever your username is, then.
<michalski> success :) thanks
<michalski> peng
<michalski> :)
<Peng> :)
<michalski> goodnight
<Peng> Good night.
<jelmer> igc, is there a particular reason rebase is discussed under "pseudo merging" rather than "brief tour of popular plugins" ?
<jelmer> I personally like how that bit is done better because users will likely not care how certain functionality is provided
<jelmer> (e.g. just having a note for some bits of the user guide saying "this functionality requires plugin X")
<jelmer> anyway, just my â¬0,02
<Verterok> jelmer: running selftest svn (OS X) I get this: http://rafb.net/p/qutRww45.html
<Verterok> any ideas?
<jelmer> ah, ouch
<jelmer> please file a bug about that bit
<jelmer> looks like I broke compatibility with subversion 1.5
<Verterok> ah, it's fresh branch of trunk
<Verterok> ups
<Verterok> ok, I'll fill a bug then. should I add any additional info?
<jelmer> nope, that should be sufficient
<Verterok> ok, thanks
<igc> jelmer: no deep reason. the plugins chapter didn't exist when I wrote the rebase stuff
<igc> jelmer: for the reasons you outline though, I didn't feel compelled to move it
<huyx> ä½ å¥½
<bignose> I love bzr shell. I love ssh-agent.
<bignose> I'm less enamoured of gpg-agent.
<lifeless> I haven't sipped from that fountain yet
<bignose> It only seems to remember my "secret key is unlocked" state for five minutes or so, and I can't find any configuration to turn it off.
<lifeless> I'm still using gnome-gog
<lifeless> *gnome-gpg* I mean
<bignose> which clangs horribly compared to 'ssh-agent', that simply remembers I've unlocked my key for the entire session.
<bignose> well, my sessions last longer than my GNOME session, since I reconnect to my screen session.
 * igc picking up kids - bbiab
<abentley> Peng: I've updated bzrtools' version number on the dev branch.
<bob2> ooh, and it ate 'heads'
<Peng> abentley: Thank you! :)
<Peng> bob2: Wait, what did you mean by "ate"?
<Peng> That's neat that heads is a part of bzrtools now.
<Peng> And I just installed it like last week. :P
<abentley> bob2: Yeah, heads is really useful when you need it, so I wanted to get it broader distribution.
<fullermd> Ooh, nifty.
<abentley> Also I'll be ensuring it's maintained.
<bignose> so what do folks use to ensure their 'bzr shell' in a 'screen' session keeps the GPG key open?
<bignose> if 'gpg-agent', then how did you configure it to stop forgetting the key every few minutes?
<lifeless> I'm done, later all
<Verterok> I just uploaded a universal installer for 10.4 (Tiger), I can't test if it works in i386 arch...beta testers are welcome :)
<i386> Verterok: oh nice - only tested on PPC?
<Verterok> i386: yep, I don't have mac intel...yet
<i386> ahh
<i386> Ill test it if you want
<Verterok> that would be great! :D
<i386> is it on the website?
<Verterok> yes: http://launchpad.net/bzr/1.4/1.4/+download/Bazaar-1.4-OSX10.4-universal-1.dmg
 * Verterok heading to bed...
<Verterok> i386: thanks for testing the installer, if you encounter any trouble with the installer, please contact me IRC or mail (I'll check IRC in the morning)
<igc> jamesh: see the bzr mailing list for a Python string concatenation test program. Can you please check I'm not doing something dumb? :-)
<jamesh> igc: note that there are a few different cases to consider
<jamesh> igc: in the case that was being discussed, we had a list containing all the strings to be concatenated as the starting point
<jamesh> your test program starts with a file descriptor and incrementally reads in the data
<jamesh> so it really depends on what you want to test
<jamesh> as for measuring the memory usage, valgrind's massif tool might be a good way to compare the algorithms
<igc> jamesh: yeah - my test program reflects exactly what happens in bzr-fastimport
<igc> it's actually reading a # of bytes from a stream and tracking line #s as it goes: hence the readline approach
<jamesh> igc: right.  So the optimal code for fastimport might be different to the optimal code for knit.py
<jamesh> igc: unrelated to the concatenation bit, using the file object as an iterator will be faster than repeatedly calling readline()
<jamesh> iirc
<jamesh> it definitely was in older versions (reading the file in larger chunks)
<igc> sure - I actually pass the blob size to readline though so I suspect I need to keep using it
<Peng> I think iterating over the file object buffers more than calling readline().
<jamesh> igc: the size arg to readline() just limits how much data it will return
<jamesh> igc: iter() protocol reads larger blocks from the file then returns successive lines from those blocks
<igc> I know - and I need to do that to follow the git-fastimport spec
<igc> i.e. there's no certainty the blob will be newline terminated
<jamesh> igc: so you just use read(size_of_blob) for the blob, right?
<igc> that won't track the newlines for me though
<igc> perhaps I can scan the blob after the fact though
<jamesh> igc: blob.count('\n') might be what you want then
<jamesh> igc: count() also takes optional start/end arguments in case you want to carve up even larger string blocks
<igc> jamesh: cool - I'll try that
<igc> jamesh: the only issue then is whether \n is good enough for newline detection on Windows
<jamesh> igc: the answer to that will depend on whether fastimport data streams are considered to be text or binary
<jamesh> igc: if they contain binary data inline, then they probably need to be handled as binary
<jamesh> in which case line endings should always be \n
<igc> both :-)
<igc> they contain binary
<igc> but we report reports in turns of text line #s
<igc> s/reports/errors/
<jamesh> igc: so if I have a binary file that happens to contain '\n', would it be represented as '\n' or '\r\n' in the stream?
<jamesh> if the file format depends on switching back and forth between text and binary mode, then it sounds broken :)
<igc> the binary content would be exactly as is
<igc> but it's a line-based format otherwise
<jamesh> it sounds like the file needs to be treated as binary then
<igc> with a size indicator given on the line above where binary content starts
<igc> jamesh: I think count('\n') will be good enough
<jamesh> igc: http://www.kernel.org/pub/software/scm/git/docs/git-fast-import.html seems to indicate a binary file format where newlines are represented by \n
<bignose> so what do folks use to ensure their 'bzr shell' in a 'screen' session keeps their GPG secret key open?
<bignose> if 'gpg-agent', then how did you configure it to stop forgetting the key every few minutes?
<AfC> Ah! bzr 1.4 is available now. Terrific.
<RAOF> bignose: You should be able to pass in --default-cache-time or somesuch; that's what I've done in the past.
<AfC> bignose: put a gpg-agent.conf in your ~/.gnupg directory
<AfC> bignose: the parameters you want are default-cache-ttl and
<AfC> bignose: max-cache-ttl
<AfC> The defaults are to expunge your keys in time frames on the order of minutes, which I find just a little too aggressive.
<AfC> [I mean, shit, day or week is fine; if you're being paranoid then half day or hour or even half hour, but _minutes_?]
<bignose> so how can I make it *never* expire, the way 'ssh-agent' works?
<AfC> [we use heuristics to flush keys anyway if certain actions have occurred, but in practise we find reboots to do the trick]
<bignose> my sessions commonly live for many months.
<AfC> bignose: put a rather large number of seconds in those settings.
<bignose> so a setting of 0 won't do it?
<AfC> bignose: it didn't seem to, but maybe I was being misled.
<jamesh> AfC: so I suppose you're not one of those people who carry half their PGP key around on a USB key?
<AfC> (it might have disabled caching all together)
<AfC> jamesh: uh, no.
<bignose> <URL:http://www.gnupg.org/documentation/manuals/gnupg/Agent-Options.html> doesn't indicate what a value of 0 will do.
<bignose> I guess I'll just have to experiment.
<jamesh> AfC: I do know people who have things set up so they can recover their PGP key with a USB key plus their desktop or laptop, or with just the desktop and laptop together
<jamesh> having just one is not enough
<bob2> using par or something?
<bignose> AfC, RAOF: thanks for the helpful response.
<jamesh> bob2: gfshare
<AfC> jamesh: Oh, I'm a big fan of two factor authentication, but I just never managed to make it work. (eg, there is an SD slot in this damn thing, but I haven't managed to get that to work yet, etc)
 * igc dinner
 * awilkins used to do smartcard developmen and has never bothered with 2-factor auth apart from his work-supplied RSA secureid
<awilkins> My work it are now planning to only allow read-only access to unencrypted USB keys :-(
<awilkins> Very irritating ; I don't deal with any classified data, so it just stops me using a BZR repo on my USB key to work at home.
<AfC> awilkins: (obviously the mechanism for reading encrypted devices is not something you are able to replicate elsewhere. Interesting)
<awilkins> AfC: It's some proprietary piece of crap
<awilkins> "SafeBoot"
<AfC> The vogue at a number of our clients has been to use hardware VPN devices and to only allow people to connect to foreign networks through such devices
<AfC> which leads to the poor shmucks carrying around this heavy module strapped to the back of their laptop's monitor to then go to either ethernet or a PCMCIA wifi card.
<AfC> and, of course, a neato hard-to-use pain-in-the-ass web interface to control the thing.
<AfC> "usability"
<awilkins> Nasty. We have to use Cisco VPN, but with the "Windows Firewall" setting on
<awilkins> So I can't use my router as a VPN bridge with vnpc
<AfC> [like, "if you connect your laptop to a foreign network not through this device, your employment be terminated. Immediately"]
<AfC> awilkins: annoying
<awilkins> Yeah, I usually prefer to shove my laptop under the desk and remote desktop it on my vastly superior monitor / keyboard cluster
<awilkins> Hence me finding BZR so useful - I can just work offline and tote the data in on a USB key
<awilkins> So when they encrypt those keys it will be yet another annoyance.
<awilkins> I'd ask if they could supply a license for my to use it at home, but I don't want it on my machine.
<awilkins> I don't trust any encryption product you can't read the source for (not that I'm skilled enough to vet it myself, but at least I have the comfort of knowing that hundreds of others have)
<AfC> Certainly
<awilkins> IMHO they should have found someone who could provide them with a support contract for TrueCrypt
<awilkins> I understand their need to have someone to blame, and to pay money to assuage their guilt at not being man enough to take the rap themselves
<AfC> awilkins: hah. You should have started a concern to sell such support :)
<awilkins> Likewise for archiver - they must have shelled out 15,000 euro, minimum, for a WinRAR license
<awilkins> They could have donated , say, 8,000 euro to 7-zip and made them very happy russians
<awilkins> The "TrueCrypt support" thing may have legs
<awilkins> I wonder if anyone offers it aready
<awilkins> Verterok: ping?
<quicksilver> Ouch.
<quicksilver> bzr: ERROR: exceptions.AttributeError: 'SSHSubprocess' object has no attribute 'get_name'
<mwhudson> quicksilver: something to do with paramiko versions
<quicksilver> so I was just gathering from google searches.
<quicksilver> careless upgrading is the root of all evil.
<quicksilver> "Andrew Bennetts" apparently fixed it on the 10th of April, in bzr.
<quicksilver> I wonder which bzr version contains the fix.
<mwhudson> 1.4 should
<quicksilver> hmm. I'm using 1.4. I think.
<quicksilver> ah, no, I"m using 1.3
<quicksilver> d'oh.
<quicksilver> erm. I'm in a mess!
<quicksilver> macports thinks I have 1.4 but bzr --version says 1.3
<quicksilver> --->  Activating bzr 1.4_0
<quicksilver> bzr --version
<quicksilver> Bazaar (bzr) 1.3
<quicksilver> makes no sense to me :(
<mwhudson> that seems broken
<quicksilver> I shall force macports to recompile it. If that doesn't work I will go cry on the shoulders of the macports people.
<quicksilver> that fixed it.
<quicksilver> I obviously broke something in some unpleasant way.
<quicksilver> grmargh. Now I broken py25-bz2. Bad python day!
<mwhudson> quicksilver: this is all much easier on ubuntu :-)
 * awilkins just runs the installer for windows
<quicksilver> mwhudson: believe me, I am no stranger to the shortcomings of anything-which-isn't-apt.
<quicksilver> mwhudson: I *really* wanted apple to use dpkg for OSX. They even hired a dpkg developer.
<mwhudson> quicksilver: parallels is only $50 :)
 * mwhudson stops being gratuitously unhelpful
 * quicksilver was even a debian developer once. elmo over there did his security call.
<joh> Is it possible to edit a committed message?
<jamesh> joh: no
<jamesh> although you can create a new revision with a different message
<jamesh> if you want to change the revision you just committed and you haven't done any other work, then try "bzr uncommit; bzr commit"
<bob2> if it was the previous commit, and no one else has merged/pulled it, you can uncommit and re commit
<joh> Aw, I forgot to add --fixes
<joh> Ok
<joh> What if I already pushed the changes to LP?
<jamesh> joh: you can "push --overwrite" to update the branch even if you've diverged
<jamesh> (which uncommit+commit will do)
<joh> jamesh: Great, thanks :-)
<muncul> hi ! How can I simply: log to machine ; bind to repository with configuration; than diff checkin etc,  ; and remove .bzr/
<muncul> 2. is it possible to have working tree in 2 repos ?
<muncul> 1. i mean using /.bzr to version /etc
<bob2> dunno about the rest of your question, but you'll want to use etckeeper or something
<bob2> or else you won't be versioning file permissions
<muncul> i want to have some files from /etc/ in bzr
<muncul> but i do want to have repo on central server
<muncul> and delete /.bzr after work
<muncul> so config history is known only to me
<bob2> you'd need to write a little shell script to do that for you
<bob2> but lightweight checkout .bzr dirs are quite small
<muncul> but when i have repo on server
<muncul> and log to machine
<muncul> how to make this .bzr binded to central repo
<bob2> "bzr bind"
<muncul> i tried: bzr: ERROR: Not a branch
<muncul> as i said after work i deleted /.bzr last time
<bob2> yes, you need to get that back, or not delete it
<muncul> so how after delete
<muncul> simply branch ?
<muncul> and then bind ?
<quicksilver> win 29
<muncul> but i got conflicts
<quicksilver> ! :(
<muncul> branch destroys my current /etc/
<bob2> don't do that
<muncul> bzr is fine but some things seem diffictult to me
<bob2> branch to another dir, mv .bzr to /etc
<muncul> aaaa
<bob2> seriously, not deleting it is a lot less hassle
<muncul> but deleting is for privacy
<muncul> sometimes needed
<muncul> good idea with branching to /tmp/ and moving .bzr
<muncul> thx
<bob2> "bzr co bzr+ssh://whatever/ /etc" will probably work, too
<muncul> checkout doesn't work if i have not .bzr
<bob2> wfm
<muncul> yes works but creates second etc dir
<awilkins> muncul: If you want privacy, would using a lightweight checkout and restricting access to the master branch work for you?
<muncul> awilkins> probably shoud if lighwight .bzr works as link only
<awilkins> Is jam Mr Meinel?
<vila> awilkins: You mean our beloved Mr John Arbash-Meinel ? Then yes ;-)
<awilkins> I was hoping to ask him exactly how one uses his "service" plugin
<awilkins> Coolio, he dabbles in Judy AND DICOM.
<jam> awilkins: hi, yeah that is me
<jam> I'll be afk for a bit, but I can discuss it with you later.
<jam> awilkins: in short summary, you can just run 'bzr service' in a terminal, and then run one of the clients (there is a C program, and a python one)
<jam> there are some caveats, but I can get to those later.
<awilkins> jam: I was enquiring because I wanted to use it with the bzr-eclipse plugin
<awilkins> So would I just replace the call to bzr.bat with a call to the equivalent "bzr-service.bat" ?
<awilkins> (the other approach I'm trying at the moment is binding a "bzr shell" session to a process object and piping things to and from.
<jam> awilkins: well, if someone ran "bzr service" then you can talk to the process via sockets
<jam> The structure is rather trivial
<jam> I might recommend a couple quick fixes
<jam> so that it is a bit more robust/secure
<jam> it worked for what I wanted at the time (proof of concept)
<jam> It shouldn't be too hard to clean up
<beuno> is there a hook for the smart server to run "bzr update" after a user pushes to it?
<beuno> I'm not sure if the post-push hook will do that
<awilkins> post-push uses SSH to run a bzr update local to the server
<beuno> hm, that's no good. I need the server to run the update as a different user
<beuno> I currently have a cron running updating all repos, but that's getting too expensive
<ricardokirkner> hi. I know this might be a little offtopic, but does anyone know what the current status of trac-bzr is? I want to start using it at the company I work, but from what I saw it seems to be little activity right now.
<jam> beuno: not on the server side, afaik
<jam> beuno: you could certainly hook something like that into our new "post_branch_tip_changed" hook
<jam> or whatever it is called
<LeoNerd> Anyone here familiar with the 'mmv' command..? Lets you rename multiple files at once based on some pattern. I wonder if a 'bzr mmv' plugin could be based on it?
<beuno> jam, the post_branch_tip is on the server side then?
<guilhemb> statik: hello! May I phone you for a few minutes, please?
<statik> guilhemb: certainly, privmsg
<guilhemb> statik: I bet you cannot see my replies in the privmsg
<statik> guilhemb: I cannot
<guilhemb> ok, maybe my registration for privmsg didn't work, retrying...
<guilhemb> statik: but I can see your messages; if you pasted me your phone number in the privmsg I would see it.
<statik> guilhemb: ok, will do
<nDuff> just curious -- does anyone have knowledge as to how actively paramiko is maintained? I posted a bug report & patch to the ML and bug tracker there ~a week ago, and haven't seen any activity.
<vadi2> Somehow loggerhead is messing up. If I click on any of the "changes" links on this page (http://bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main/files), it always gives me changes for the whole trunk, not specific to a file like the tooltip says so.
<jam> beuno: post_branch_tip, IIRC, is fired locally and on the server
<beuno> jam, great, I'll give it a try, thanks for the tip
<jam> nDuff: robey is fairly active, but he is only 1 developer, and can get backlogged with other stuff
<jam> nDuff: if it is critical, you could probably ping someone here, as we've worked with him a bit
<nDuff> jam, probably not that critical -- I can patch my tree manually for the time being -- but thank you for the update; given the lack of any ACK, I was worrying that paramiko was under abandonment.
<pickscrape> Are there any plan afoot for some client-side plugin management UI?
<pickscrape> i.e. something that will manage installing/updating/uninstalling plugins.
<pickscrape> Yes, your friendly neighborhood package manager could do that, but few plugins appear to be packaged at all.
<beuno> pickscrape, yeap, I'm working on that
<pickscrape> sweet!
<beuno> it's pretty advanced
<pickscrape> Is any of it public? I'd like to have a nosey at it... :)
<beuno> I'd like to release a preview version of it these next weeks
<pickscrape> Yet another killer feature point to bzr :)
<beuno> pickscrape, I'll upload one today, and email you the URL if you send me a reminder email  (argentina@gmail.com)
<pickscrape> Will do
<beuno> the first step is, it tells you if the command you are running is from a plugin you don't have installed
<beuno> which is finished
<beuno> the installing bit through a checkout is half-way there
<beuno> and I got the core bits I needed into 1.4, so that's why it's been stalled for a while
<pickscrape> I suppose it would make sense for plugins to maintain a 'current release' branch, so it can always update from the same place.
<beuno> that would be the idea  :)
<pickscrape> Email sent
<pickscrape> Tangent, but is anyone aware of any use-case examples of using the loom plugin?
<beuno> pickscrape, great, thanks. I'll upload in a few hours, when I take a while off work
<beuno> pickscrape, packaging mostly
<beuno> where you have to maintain multiple patches
<pickscrape> It seems like one of those fantastic features that could have all sorts of great uses, but I can't imagine any just from the docs.
<beuno> I believe that's what drove it's development, but I could be wrong, and lifeless is very unlikely to be awake already
<pickscrape> 'Oh, lifeless is a person?
<beuno> he's *the* person  :)
<pickscrape> Very unfortunate name to have when it gets written next to branch names on launchpad. :)
<pickscrape> Had me thinking the branch was dead...
<beuno> hahahah
<beuno> I promise, he's a person. I've met him
<pickscrape> :) I believe you. I genuinely did think 'lifeless' meant the branch hadn't been touched for more than X amount of time though.
 * james_w files a bug against lifeless 
<pickscrape> :)
<pickscrape> Maybe I'm the one who needs a bug ticket raising...
<james_w> hi beuno
<beuno> hey james_w!  how are you doing?
<james_w> great thanks. How are you?
<dato> hello beuno, james_w
<james_w> hi dato
<beuno> james_w, good good, trying to start the week properly, but it doesn't seem to be working  :)
<beuno> hey dato!
<james_w> start it on tuesday, that always makes it a little easier.
<beuno> I'd love to, but I have to convince too many people to follow my lead, and it just feels like it might not work as well...
<dato> jelmer: right, bzrtools need one more upload by me. let's see if I can do it tomorrow (together with bzr-gtk, hopefully)
<BasicOSX> Using the email plugin is there an entry you can put into location.conf to prevent email notification just for a specific project?
<jelmer> dato: yup - thanks!
<ricardokirkner> hi. i am trying to access a bzr branch that is exported by apache, but requires authentication and I get the following message: Unable to handle http code 401: expected 200 or 404 for full response
<ricardokirkner> I have googled it, but couldn't find any answer
<ricardokirkner> do you guys have any idea if auth is working when using http?
<beuno> ricardokirkner, 401 seems to me access denied
<beuno> are you sure the user/password is correct?
<ricardokirkner> beuno, bzr never even asks me for use/pass
<beuno> ricardokirkner, it's not interactive
<beuno> you have to add it in the url
<ricardokirkner> oh. wait... i'll try that
<ricardokirkner> :-D
<ricardokirkner> now it WAS interactive... after specifying the username, it asked me for the password
<ricardokirkner> thank you
<beuno> ricardokirkner, yes, it is for passwords
<beuno> you're welcome  :)
<beuno> I wonder if that can be considered a bug...
<beuno> just to annoy vila perhaps
<pickscrape> Does seem to violate the principle of least surprise.
 * beuno looks to see if it's been reported before
<beuno> ricardokirkner, bug #229714
<ubottu> Launchpad bug 229714 in bzr "Accessing a password protected URL through http without username should ask for username" [Undecided,New] https://launchpad.net/bugs/229714
<ricardokirkner> beuno, I might even attempt to fix that bug, thank you :-)
<beuno> ricardokirkner, that would rock  :)
<ricardokirkner> when I get back home from work, I will try
<ricardokirkner> I was just wondering.. I know about repositories, and that they allow to reduce duplicate space, but what happens if I start with just one branch and later on I decide I want to use a repo, because I will have many branches... can I just create the repo and then move my branch into it, or what should I do?
<dato> create the repo
<dato> cd into it
<dato> bzr get your branch
<ricardokirkner> dato, ok, so in order for the data to be stored in the repo I just re-checkout my branch, right? sounds easy enough. thanks
<dato> yep
<ricardokirkner> another newbie question (I am really getting into this :-)). when I have created a repository with branches in it. is there a simple way to checkout the full repository? when I point bzr to the url of the repo, I get a message about it not being a branch (which is quite correct)
<mwhudson> no, not really
<mwhudson> there is a 'multi-pull' command in bzrtools, which is like one tenth of what you're asking for
<beuno> sounds like nested branches
 * beuno stares at LarstiQ 
<dato> beuno: not really, I think
<beuno> dato, well, partially at least
<ricardokirkner> beuno, not really. I just mean the whole repo, but the branches within are just related by belonging to the same project
<beuno> enough to other LarstiQ with it
<beuno> right, it should share some code with nested branches though
<dato> I don't think so...
<beuno> hm, then I'll get back to work  :)
<pickscrape> I just did update on a checkout that contained some commits I'd made using --local, and they've vanished
<pickscrape> I can see the commit using the heads plugin. Any tips on how I can get it back?
<pickscrape> Would the rebase plugin be of use here?
<james_w> pickscrape: are they listed at the end of "bzr status"?
<pickscrape> Oh, yes they are actually.
<pickscrape> As pending merges, and many of the files in the repo are marked as modified too
<james_w> yeah, they get converted in to "pending merges", if you resolve any conflicts and commit you will see them in the output of "bzr log -r -1"
<pickscrape> commit with --local again? (if I don't want to go upstream yet)
<james_w> that will work.
<james_w> (I hope)
<pickscrape> :)
<pickscrape> Yep, that worked, though I now have one revision with the three commits as parents of it. Presumably though this is what would have happened when I wanted these revisions to go upstream anyway, right?
<pickscrape> Useful bit of experience this... Would update be the correct command when you do want to sync your local commits with upstream?
<pickscrape> i.e. update, then commit without --local
<pickscrape> Ah, doing update again I now see the completely clear message it gives at the end about local commits being pending merges.
<pickscrape> I missed that before because I'd done the update through olive (messing about)
<james_w> pickscrape: yes, if both upstream and you were moving forward (committing) then you would need to do a merge at some point to send your work upstream
<pickscrape> Yes. In this case I'm the only one doing any committing.
<james_w> this can either be an explicit merge with "bzr merge", or an implicit one with "bzr update"
<james_w> but upstream are committing on their branch?
<james_w> or are you upstream as well?
<pickscrape> I'm upstream as well. I'm experimenting with the centralised workflow.
<pickscrape> I actually think there's as little room for improvement here. My local checkout was the same as upstream with a few commits extra.
<pickscrape> So I think in that case, update could have left things as they were.
<pickscrape> Instead it's forced me to merge, when I might not have wanted to at this point.
<james_w> ah, my instinct would have been that it would have done exactly that
<pickscrape> merge, or leave alone?
<james_w> leave it alone
<pickscrape> Yes, I'd expected it to be a noop.
<jml> what's the recommended bzr-svn to use.
<james_w> hi jml
<james_w> pickscrape: I see now that it does always merge
<jml> james_w: hi.
<jml> james_w: it's been a while :)
<james_w> jml: I think 0.4.10, or 0.4.9 failing that
<james_w> are you in Prague next week?
<jml> I am.
<james_w> great!
<igc> morning all
<james_w> I've got some questions for you, come prepared :-)
<james_w> hi igc
<jml> james_w: actually, if you ask them now, perhaps via email, I might be even more prepared.
<pickscrape> james_w: Yes, I just tried it with a trivial example
<james_w> jml: that's true, I don't know exactly what they are yet, so I'll write you an email later explaining what I'm working on if that's ok?
<jml> james_w: that'd be great.
<jml> Last week, I made my first working .deb in preparation for UDS :)
<james_w> pickscrape: so, you could say that "update" means, give me upstream's branch with anything I have locally being working tree modifications/pending merges, which gives you this behaviour.
#bzr 2008-05-13
<james_w> pickscrape: however, this gets pretty silly if upstream never commits anything and you just do update && commit --local over and over again
<james_w> which is pretty silly in itself
<james_w> pickscrape: I think this would be a worthy topic for discussion on the mailing list, are you subscribed?
<pickscrape> Yes, you could end up with a really deep nest of what accounts to one merge
<pickscrape> I'm already composing one :)
<james_w> great!
<jelmer> jml: 0.4.10
<jml> jelmer: thank you.
<jml> jelmer: btw, I have tribunal using subunit now.
<jml> (it was you who was asking, right?)
<jelmer> yep
<jelmer> I'll give that a try soon
<jelmer> we're using subunit inside of samba 4 and it would be awesome to be able to use tribunal there
<jelmer> lifeless: is there any news on your subunit patch for check?
<jml> jelmer: it's still... rough
<jml> jelmer: if I get more users than just "me sometimes", I promise I'll take better care of it.
<jelmer> well, we're used to rough :-)
<lifeless> jelmer: they want docbook and other crap written up
<lifeless> jelmer: which is afaict a higher standard than the previous code; I've kind of lost interest
<jelmer> lifeless: ah, ok
<jelmer> lifeless, I may have a look at finishing it then
<lifeless> that would be cool
<mxpxpod> jelmer: ping?
<jelmer> mxpxpod, pong
<mxpxpod> jelmer: I'm getting a strange exception using bzr-svn 0.4.10 and bzr 1.5rc1
<mxpxpod> jelmer: trying to push some changes
<mxpxpod> jelmer: do you want me to file a bug or look at it here?
<jelmer> please file a bug
<mxpxpod> k
<mxpxpod> jelmer: #229775
<jelmer> mxpxpod, thans
<jelmer> lifeless, hmm, upstream appears to be dead
<lifeless> for check?
<lifeless> its definitely dysfunctional IMO
<jelmer> it's the only sane library of this sort for C though
<lifeless> yup
<lifeless> which is why I patched
<Verterok> awilkins: pong (sorry for the delay)
<lifeless> woo
<lifeless> get_record_stream now behaving moderately sanely
<lifeless> although not memory capped yet
<ricardokirkner> hi. I don't know if this is the place to ask, but since it's related I'll just shoot: does anyone know the status of the trac-bzr project? is the dead - stable - or active? I ask because I want to start getting more into bzr and bzr-related development, and the trac-bzr project just scratches one of my itches :-)
<mlh> ricardokirkner: I think it has stalled - people thought that trac wasn't a good git for bzr
<mlh> good FIT
<mlh> but don't take my opinion as anything remotely official
<mlh> there's probably better alternatives (to trac) out there anyway
<ricardokirkner> mlh, and what would that alternative be?
<chandlerc> ricardokirkner: you can always push your bzr repository into a subversion one for the purposes of running trac
<chandlerc> ricardokirkner: i do this for all of my OSS projects (code.google.com rather than trac, but same principle)
<ricardokirkner> chandlerc, not really, since bzr-svn (which I guess you are suggesting) does depend on the subversion 1.5 python bindings which are not readily available on all linux distributions
<chandlerc> yea, thats the price you pay
<ricardokirkner> and my attempt is to make bzr adoption as low impact as possible
<chandlerc> what linux distro?
<ricardokirkner> fedora at work
<chandlerc> ubuntu has patched subversion packages, and i thought fedora did as well
<ricardokirkner> and thats something I cannot change
<chandlerc> gentoo has them
<ricardokirkner> no, fedora lacks behind a lot :-(
<chandlerc> so its not as big of a price as switching to svn 1.5
<chandlerc> you *can* do it by installing the python bits in the users home directory, but yea, kinda ups the ante of moving to bzr
<chandlerc> however, installing subversion python bindings is a *lot* easier than retrofitting vcs/project management tools like Trac, Retrospectiva, Collaboa, googlecode, sf.net, et al to use bzr
<chandlerc> oh, ohloh support comes free as well
<ricardokirkner> chandlerc, you mean I can install the python subversion 1.5 bindings in my home folder, without them interfering with the system subversion installation
<ricardokirkner> and that way using bzr-svn?
<chandlerc> yes
<chandlerc> its not as easy, but it can be done
<ricardokirkner> can you give me some pointers for that?
<chandlerc> just a sec, lemme look through the docs again and refresh myself
<chandlerc> ricardokirkner: https://planning.acm.org/hq/documentation/version-control/installing-bzr-svn does this not work for you?
<chandlerc> eh, reading that, those instructions look moderately suspect
<ricardokirkner> chandlerc, no, I tried that, but it more-or-less breaks the whole distro :-p
<ricardokirkner> I think it is a bit outdated
<chandlerc> k
<chandlerc> can you install things on the system itself, or do you need it installed in the home dir?
<mlh> ricardokirkner: don't know offhand, sorry.  I was thinking of launchpad, but you're probably looking for something to host yourself/internally.
<ricardokirkner> I can, but it is actually a nuisance, since I would have to do that on every developers computer
<ricardokirkner> mlh, exactly, thanks anyway
<mlh> rumours are that canonical will open up launchpad code sometime
<mlh> what features of trac do you particularly want?
<chandlerc> ricardokirkner: would home dir help you with that?
<mlh> issue -> code linking?  code browsing?
<ricardokirkner> the thing is we are already using trac internally for all projects, and since I am trying to convince them to move from svn to bzr, I need to disrupt as little as possible
<chandlerc> yea
<ricardokirkner> oth, trac works well enough: code browsing, diff, wiki, issues
<chandlerc> my recommendation would be to keep trac, and find a way to support bzr-svn... i looked at a lot of alternatives, and it seems the lowest effort way to introduce bzr
<ricardokirkner> chandlerc, maybe, if it could be done in a zc.buildout-like manner, i think it would be quite painless
<chandlerc> ricardokirkner: ok, lets go through this then, but i warn you that i haven't done these exact steps myself, so ymmv
<chandlerc> http://bazaar-vcs.org/BzrForeignBranches/Subversion#id35
<chandlerc> ^^ that is basically what you want to do
<chandlerc> but instead of "./configure" you want to "./configure --prefix=/home/username"
<ricardokirkner> chandlerc, you mean installing subversion 1.5 in the home dirs, and then somehow telling bzr to use that subversion installation?
<chandlerc> yep
<chandlerc> you can do one step less invasive though
<ricardokirkner> is it possible to only install the bindings, without having to install the svn client?
<mlh> or install to /opt if you want others to see it
<chandlerc> i think (but am not 100% certain) if you can match up subversion source code version to the one installed on the system
<chandlerc> you can "make install-swig-py" only
<chandlerc> and then just manipulate the Python environment variables to include the correct /home/username/lib/python... path
<chandlerc> i'm not a python guru, so that part I can't help as much with
<chandlerc> mlh: i think he wants to do something like re-tarball it all up post-installation so that each user can do a one-time untar and magically have it sitting in their home directory
<ricardokirkner> mhhh... I can try that... so if I could manage to install the python bindings locally (say to the home folder), I might even write a zc.buildout recipe that installs bzr (and all its dependencies including bzr-svn) to a developers sandbox
<chandlerc> mlh: /opt would require sudo or su access or the equivalent
<mlh> oh yeah
<chandlerc> ricardokirkner: i dunno anything about zc.buildout
<ricardokirkner> permissions are not an issue
<chandlerc> if permissions aren't an issue, then yea, use --prefix=/opt
<mlh> then /opt/subversion-v.x.z si a better option then
<chandlerc> and hell, you can roll out a full subversion-1.5.x install, and have people just use that version of subversion
<ricardokirkner> and how do I tell bzr to use the /opt subversion?
<mlh> I do that for solaris, and make a symlink /opt/subversion to the current version
<chandlerc> same way for local
<chandlerc> you just have to manipulate the Python search paths to find python libraries within the install tree
<chandlerc> whatever that install tree is
<ricardokirkner> supposing I dont want to modify the default subversion version
<chandlerc> then find the sources for that exact version (including patches if possible) and just build install-swig-py
<chandlerc> er, just "make install-swig-py"
<ricardokirkner> chandlerc, ok, so I just prepend the /opt/ paths before the /usr paths and that should do it, right?
<chandlerc> ricardokirkner: theoretically... i'd follow mlh's suggestion and make it "/opt/subversion-1.4.?-pypatch" or something to distinguish it
<chandlerc> but you can make Python look anywhere you please for its python libraries
<chandlerc> and bzr-svn just uses Python to "import" stuff
<ricardokirkner> chandlerc, ok, great... I will look into it then tomorow at work...
<chandlerc> with the correct Python environment variables, you can have it look first in your custom rolled subversion python bindings directory
<ricardokirkner> thank you both for your suggestions
<chandlerc> what those might be, i can't help much with, being relatively ignorent of python
<chandlerc> but that at least will be well documented
<chandlerc> np, feel free to ping me if you run into issues
<chandlerc> i use bzr-svn heavily for this exact purpose
<chandlerc> (no offense to launchpad, but googlecode is more to my minimalist style)
<ricardokirkner> chandlerc, another question. so when using bzr-svn, you have found out that there are no issues due to the interoperability of bzr and svn? (i mean, nothing breaks)
<ricardokirkner> what version are you using ? (of bzr-svn)
<chandlerc> latest iirc
<chandlerc> i had one terrifying data-loss incident, but that was (i am mostly convinced) due to my own terrible mistakes. i was trying to do something i should not (and could not) do
<chandlerc> it ended up reverting a bzr repo to revision 1
<chandlerc> that was sad
<chandlerc> however, i recovered all the data by pulling back down from subversion... so no real problem with bzr-svn there
<ricardokirkner> that's not good pr :-)
<ricardokirkner> ah, ok
<chandlerc> eh, it just a "feature" of bzr... if you only have one branch around, and do something royally dumb....
<chandlerc> my mistake was the only one branch part
<ricardokirkner> so it commited everything fine, and you could grab latest version from svn
<chandlerc> yep
<ricardokirkner> all through bzr-svn
<chandlerc> yep
<ricardokirkner> that is good pr :-)
<chandlerc> here, take a look at an active repo if you like: http://code.google.com/p/inc/
<pickscrape> Sorry to interject, but why was trac considered to not be a good fit for bzr?
<chandlerc> nfc
<pickscrape> We were hoping to use it ourselves
<chandlerc> the python web app apparently meshes better with non-python vcs than with python vcs... go figure
<chandlerc> i worked on trac briefly... i was not impressed by their internal design. thats where i would look first for reasons why it didn't work out
<pickscrape> By that I presume you mean it also has issues with mercurial?
<ricardokirkner> chandlerc, well, svn already existed long time before svn, so it actually makes sense
<chandlerc> ricardokirkner: oh i know, svn support being better makes sense. git and mercurial support before bzr is a little unusual
<ricardokirkner> I mean trac existed before bzr
<chandlerc> true as well
<bob2> isn't trac from like late 2004
<chandlerc> they really struggled making their system interoperate with other VCSes back when i was working on the project. i dunno if they've gotten all the cruft refactored, but back then it was pretty awful
<bob2> ah, early 2004
<pickscrape> The framework is basically all plugins now from what I know.
<chandlerc> i never looked back. retrospectiva is a much saner web app if that's what you need, and for project hosting i enjoy googlecode
<chandlerc> i'd love to see something like retro done in python on top of turbo gears or django in order to cooperate nicely with all the python bindings for VCSes out there
<ricardokirkner> yeah, might be, but trac make sense for internal application design
<ricardokirkner> where you don't want to host your code outside
<chandlerc> ricardokirkner: retro = trac on ruby on rails
<chandlerc> ricardokirkner: its perfectly well suited to that use case, i was tasked with working on such a design at a previous company
<pickscrape> In Trac 0.10, the VCS backend is entirely a plugin (AIUI), so theoretically you should be able to shove anything in there.
<ricardokirkner> chandlerc, well..... looking at the tickets list, the first one is 'Multiple SCM support' , so apparently they too haven't solved it yet
<chandlerc> ricardokirkner: correct, i've been using svn as a multiple SCM support layer because git, mercurial, and bzr all will speak svn
<chandlerc> pickscrape: the problem is that shoving stuff into trac is notoriously challenging
<chandlerc> pickscrape: but yes, you could build a plugin for trac, and it probably wouldn't be terrible to do
<ricardokirkner> well, thank you guys, I'll be off now... I'll try your suggestions tomorrow
<pickscrape> But the plugin already exists.
<chandlerc> =] goodluck! and keep with the bzr!
<chandlerc> pickscrape: it does?
 * ricardokirkner waves good-night
<pickscrape> Yes, there's a trac bzr plugin
<pickscrape> https://launchpad.net/trac-bzr
<ricardokirkner> yes, that is what I am using
<pickscrape> Last commit was March this year.
<pickscrape> Anyway, I'm off to bed. :)
<poolie> hello
<lifeless> (v1, 'unknown verb')
 * igc picking up kids - bbiab
<gnomefreak> anyone here that can give me a hand with an error when pushing a bzr branch to LP?
<spiv> gnomefreak: sure, what's the error?
<gnomefreak> spiv: 1 sec im getting it and i will pastebin it
 * gnomefreak cant open browser
<gnomefreak> spiv: gnomefreak@Development:~/extensions_build$ bzr push bzr+ssh://gnomefreak@bazaar.launchpad.net/~gnomefreak/firefox-extensions/firegpg.ubuntu
<gnomefreak> Permission denied (publickey).
<gnomefreak> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
<gnomefreak> sorry my browser isnt working
<mwhudson> there's a clue in there
<mwhudson> "Permission denied (publickey)."
<gnomefreak> mwhudson: permissions
<gnomefreak> yes but why
<gnomefreak> my .ssh has wrong permissions?
<spiv> gnomefreak: that's openssh's way of saying it can't authenticate with the server
<spiv> probably because the SSH key you have on your computer doesn't match the public key(s) you have in Launchpad.
<mwhudson> gnomefreak: could be that, or more likely you don't have the correct key in your key agent or something
<mwhudson> gnomefreak: you could try
<mwhudson> ssh -vv gnomefreak@bazaar.launchpad.net
<gnomefreak> permission denied as well
<mwhudson> i can connect to the server ok, so it's /probably/ not some system wide problem
<mwhudson> you should have got a page or two of output first
<gnomefreak> my key shouold be fine since i got it from  usb stick
<gnomefreak> mwhudson: i did
<mwhudson> well, did it should ssh presenting the key you expected to work?
<spiv> mwhudson: s/should/show/
<mwhudson> spiv: thanks
<gnomefreak> mwhudson: ran out of reading it over atm
<gnomefreak> s/ran/reading
<gnomefreak> oh no sorry 2 posts niether complete
<gnomefreak> debug1: Host 'bazaar.launchpad.net' is known and matches the RSA host key.
<gnomefreak> debug1: Found key in /home/gnomefreak/.ssh/known_hosts:1
<gnomefreak> that tells me it works no?
<mwhudson> no
<spiv> No, that's the host key
<gnomefreak> oh
<spiv> That's just SSH checking that the server isn't being spoofed.
<gnomefreak> thats odd shouldnt there be more than one file in ~/.ssh?
<gnomefreak> only one there is known_hosts
<spiv> If you have a keypair, yes, there should be.
<gnomefreak> i might have forgotten to grab dir off usb stick after i reinstalle
<spiv> Typically you'd also have "id_dsa" and "id_dsa.pub", if you have a DSA keypair.
<gnomefreak> d
<gnomefreak> i got password dialog
<gnomefreak> looks like bzr crashed
<gnomefreak> http://pastebin.mozilla.org/429931 is what i get when trying to push
<mwhudson> now _that_ is obscure
<gnomefreak> that is bzr problem not so much LP or me right?
<mwhudson> well, i guess it's a bzr-svn problem
<mwhudson> gnomefreak: can you try again with --no-plugins
<gnomefreak> k
<gnomefreak> that got rid of traceback issue
<gnomefreak> that looked like it worked with --no-plugins and --use-existing-dir
<spiv> gnomefreak: please file a bug on bzr-svn with that traceback, I'm fairly sure that's not meant to happen
<gnomefreak> spiv: will do shortly
<spiv> gnomefreak: thanks!
<gnomefreak> anytime. thanks for the help :)
<dhd> hi - I want to take one repository and import it into a subdirectory of another repository - how do I do this?
<jamesh> dhd: you can use "bzr branch" to move each branch in the first repository to the second
<bob2> multi-pull or repo-push might help automate it
<gnomefreak> spiv: mwhudson the bug is filed its bug 229819 please let me know if more info is needed, thanks again for your help
<ubottu> Launchpad bug 229819 in bzr "bzr-svn gave traceback during push" [Undecided,New] https://launchpad.net/bugs/229819
<nbjayme> hello every one.  i have a branch that i created under a shared repository and I don't need it anymore. Is it okay to just delete it?  or is there a proper way to delete a branch under a shared repo.
<nbjayme> ?
<james_w> nbjayme: just deleting it is fine
<nbjayme> thanks james_w.
<james_w> however the space taken up by its unique revision data will not be freed.
<james_w> there's currently no garbage collection command to do this, if it is going to be significant for you you can do it by hand, creating a new shared repository and branching over all the other braches.
<nbjayme> okay. thanks for that helpful tips.  it'll help me in informing the participants during the Bazaar workshop. :)
<nbjayme> one more thing, supposing i created branchA under a shared repo than later on I renamed it as BranchB will bzr still relate the commits of BranchB to BranchA (it's previous name)?  or will bzr create another repository batch different for BranchB unrelated to previous commit when it was Branch A...?
<nbjayme> i assume bzr doesn't care whatever the name of the branch under the shared repo. as long as it keeps the .bzr folder files intact.  am I right on this?
<nbjayme> yep. it did.  thanks for the info and patience.
<Peng> Augh, I was just about to say that to him.
<Kamping_Kaiser> what if you add something youve already added? does bzr simply ignore you?
<spiv> Kamping_Kaiser: right
<Kamping_Kaiser> spiv, thanks
<gour> hi
<gour> i just read http://www.infoq.com/articles/dvcs-guide and see that it says that "end of line conversions" is planned for bzr-1.6. what it is exactly and any eta for 1.6?
<gour> i.e. does it refer to unix/mac/win stuff or text vs. binary?
<spiv> gour: we release on a monthly schedule, more-or-less.
<spiv> 1.5 is due out at the end of this week, so 1.6 should be about a month after that.
<spiv> It refers to unix/mac/win stuff, if I understand your meaning correctly.
<spiv> i.e. the ability to say "these files are text files, and so please do the Right Thing with their line endings depending on my platform"
<spiv> There's a bunch of recent discussion on the mailing list with the details.
<gour> spiv: very nice. i'm looking for (possible) alternative to darcs (for a haskell project) and see there are some gui tools available for bzr for win32 users ;)
<spiv> Yeah, that's an area of active development.
 * gour is looking at ml
<gour> git is way too complicated to push to my dev-friends
 * spiv nods
<spiv> We try to make bzr a pleasure to use.  It's not perfect, but we're working on that :)
<gour> i was looking at hg as well when wanting to move from darcs, but stayed with darcs; darcs-2 is nice but no gui tool for windoze and future is also not certain
<gour> i anticipate that decentralized workflow with human gatekeeper would be our choice
<gour> rcs should be a tool to help and not spending weeks to master it. one reason i like darcs
<spiv> Exactly.
<spiv> Do let us know if we're doing a good job on that front or not :)
<spiv> Feedback from new users is always good to have.
<gour> sure. will play a bit with it and try gui tools.
<gour> anyone can give brief comparison with darcs?
 * gour is researching how is bzr supported with emacs
<spiv> Someone probably can, but not me I'm afraid.
<spiv> Some of our developers use emacs, so I assume quite well :)
<gour> spiv: ok. thans
<spiv> (I'm a vim user, so again, not much help for you!)
<gour> *thanks
<spiv> I think there's a generic "DVCS" mode or something that apparently supports bzr quite well.
 * gour migrated to emacs some months go
<gour> *ago
<gour> right, that's the one with bad support for darcs - http://download.gna.org/dvc/
<gour> heh, DVC uses bzr
<spiv> :)
<spiv> emacs itself is planning to use bzr as well, I believe.
<gour> yeah, but it's not easy
<gour> eol is huge topic, indeed...
 * gour --> lunch. bbl
<pickscrape> Is there any way to silence the DeprecationWarning messages?
 * gour just installed bzr-gtk on his archlinux machine, but it crashes
<gour> here is the trace - http://rafb.net/p/uqKwzD16.html
<gour> bzr --version ==> 1.3
<jelmer> gour: that's a known issue. for now, you need to have seahors einstalled
<jelmer> *seahorse
<gour> ahh, i recently got rid of xfce running xmonad + xmobar only
<gour> ok, will tolerate it for testing purposes - only 2 extra pkgs
<gour> jelmer: thanks. now it works
<gour> btw, it's nice to see bzr's initial screen with basic commands :-)
<gour> although (now) git presents saner interface as well
<gour> what is the use-case for for bzrtool's rspush command over builtin push?
<bob2> it was a lot faster, back in the day
<gour> heh
 * gour is curios whether to install bzrtools or not
<gour> mostly due to shelve command
<bob2> shelve is handy
<bob2> as is cdiff
<gour> cdiff? not seeing it as part of tools
<gour> by reading several posts today, i got impression that bzr is improving in speed-issues, so i wonder about the issue described here http://dave-programming.blogspot.com/2008/04/switching-to-mercurial.html ?
<james_w> network perforance is known to be the biggest performance weak-spot at the moment, and it is being worked on
<james_w> v3 of the smart server protocol will land soon, and that will provide a base on which to speed up a lot of operations.
<james_w> I don't know all the details though, so if you want to know more about what is in v3 you will have to ask someone more knowledgeable, sorry.
<james_w> in that specific case though I imagine that the server is not performing the diff, and as such all of the data for the file is being downloaded.
<james_w> I might be completely wrong there, but it would probably account for the time it took.
<gour> james_w: thank you for the input
<awilkins> gah. Anyone know about Java streams (not entire non-bzr related)
<awilkins> Dammit, where's Guillermo when you want him
<james_w> awilkins: you mean the new things in 1.5/1.6, or the old InputStream etc.?
<ignas> hi
<awilkins> james_w: Sockets, Input/Output streams, and blocking
<james_w> hi ignas
<james_w> awilkins: sorry, I don't think I can help with that, it's been a while since I did any Java
<ignas> I am working on migration from svn to bzr, and the most difficult part for me is trying to come up with the new workflow and explaining it to other developers on my team
<menace> when a branch from one code-development line is created.. how difficult is it to synchronize it later with this code-development-line (in svn-terms "with the trunk")?
<menace> which actions have to be done?
<Zindar> menace: 1000 times easier then with svn :)
<ignas> i have a stab at documenting it in http://ignas.pov.lt/setting_up_bzr_schooltool_sandbox.html and would be very glad if someone with some actual bzr experience could look at it
<awilkins> I've got Mr A-Ms "service" plugin going as the underlying supplier for this bzr-eclipse thing ; it makes certain operations magnificently nippy
<james_w> ignas: bzr is designed to be partially compatible with svn in command line syntax, so  checkout, status, diff, commit, update should get you quite some way
<Zindar> menance: you simply merge in "trunk" to the development branch
<menace> Zindar: i believe this, but i want to know the difference. i'm comparing several SCMS right now
<Zindar> check that it looks ok
<Zindar> and commit
<Zindar> that's it
<ignas> james_w: yeah, but management of backports of features and bugfixes from trunk to release
<gour> any (ex)darcs user here?
<ignas> james_w: is done quite differently
<james_w> ignas: ah, in that case you want feature branches I expect
<Zindar> gour: used it for tests a few years ago
<awilkins> menace: For comparison with SVN ; I've been doing multi-branch merging in bzr as a project requirement for some months now and it kicks the crap out of SVN.
<menace> ok, only to make sure, that i got it: i have the "main line" 1 and a a line 2 was created from 1. i edited a few things in 2 and then i merge the line 1 into line 2?
<james_w> menace: "bzr merge" should be all it takes in that situation.
<menace> is my suggestions of the workflow right here? :)
<menace> ok
<gour> james_w: anything like darcs-send & darcs-apply here?
<james_w> menace: that will get all of trunk's changes since you branched in to your branch, if you want to get the changes back in to trunk that's one or two more steps.
<awilkins> gour: bzr send and bzr merge
<ignas> james_w: i want them, but as I can't expect everyone on the team to go read bzr documentation and learn the best practices, i have to document at least the simple use scenario for someone who wants to work on new features and deploy them without commiting to trunk
<james_w> gour: take a look at "bzr send", it's not the same as "darcs send", but it's what we came up with to do a similar thing.
<james_w> ignas: sure, I'll take a look at your document in a minute.
<ignas> james_w: thanks
<gour> thank you guys...let me read some docs...
<james_w> gour: "bzr send" was written partly because of someone else saying how much better darcs was than bzr at this, so if there is anything else you miss from the send command let us know, as it might be worthwhile addition.
<gour> james_w: heh, cool...i'll give you feedback...
<gour> so, bundle prepared with bzr send can be merged with bzr merge?
<bob2> yes
<gour> nice
 * gour is reading 'plugins' page
<ricardokirkner> hi. I am trying to use bzr-svn in fedora where the subversion 1.5 python bindings haven't been backported. for that I installed subversion trunk into /opt and after that I installed bzr-svn. after pointing PYTHONPATH to /opt/subversion/lib, I get no warnings when running bzr plugins, but nevertheless I cannot correctly check out a svn branch.
<ricardokirkner> when doing bzr selftest svn I get errors.
<ricardokirkner> how can I make sure the /opt subversion installation is being used?
<ricardokirkner> I just wiped every other subversion installation from my devel machine, so I am sure the only version I have is from svn trunk, and I am getting the following error (bzr selftest svn fails): ython: subversion/libsvn_ra/ra_loader.c:1025: svn_ra_get_log2: Assertion `*path != '/'' failed. any ideas?
<asabil> ricardokirkner: not sure, but you probably also want an LD_LIBRARY_PATH
<ricardokirkner> yeah... sorry, tried that too
<ignas> james_w: did you find anything obvious mistakes in the document?
<james_w> ignas: ah, sorry, distracted by food and secret keys, I'll look now
<ignas> thanks
<dato> heh, secret keys
<james_w> ignas: first thing, "bzr init-repo" takes a directory argument, so you don't need two commands, though making it clear that a directory is being created might be useful.
<ignas> i see
<james_w> is your aim for people to just create the branches, and then you will be the gatekeeper who does the merges?
<ignas> yes, as I am responsible for making releases, so I decide what goes where and when most of the time
<ignas> it used to be that everything was being commited to trunk and i would have to fish out the revisions to backport myself
<ignas> so it kind of transferrs that part of the job to other commiters now ;)
<ignas> as this is the initial step of migration, i am trying to keep it simple, and not explaining how one would go about merging changes + backporting them to releases himself
<james_w> I see you explain feature branches later, cool.
<james_w> I like the title of the last section :-)
<james_w> it looks pretty good though, I can't see any obvious errors, and you've covered the big things.
<ricardokirkner> when using bzr to handle svn branches, is merging done by bzr or by svn?
<ignas> james_w: well - it is a major increase in complexity compared to "we use svn and commit everything to trunk" workflow ...
<james_w> ricardokirkner: bzr
<gour> if i want to provide public mirror of my local repo via bzr push, there is no need for bzr on the server?
<james_w> ignas: yep, but you don't need to convince me of the benefits :-)
<ignas> :)
<james_w> gour: no, but you get increased performance if there is.
<james_w> gour: you can just "bzr push sftp://..." and then if that location is accessible via http people can just do "bzr branch http://..."
<ricardokirkner> james_w, so if I manage my branches with bzr, but have those branches stored in a centralized svn repository, I get all the benefits from bzr (decentralized, good merging, ...) but everything is stored by svn,
<james_w> ricardokirkner: I think it should all work fine from bzr's view
<gour> james_w: does push works over ssh as well?
<ricardokirkner> I am trying to figure this out, because I am trying to push the use of bzr at my work, where everything is svn right now
<james_w> ricardokirkner: however, I don't know what the svn client will think has happened. I imagine it all works fine, but it has no idea the branches have had any interaction.
<ricardokirkner> and unfortunately I am struggling with bzr-svn because fedora (which is what they use here) doesn't have the 1.5 bindings backported yet
<james_w> gour: sftp:// is ssh, you can use bzr+ssh:// if the server has bzr installed.
<james_w> ricardokirkner: yeah, I saw that, that's a shame.
<gour> james_w: but sftp requires some setup on the server, right?
<ricardokirkner> james_w, I just saw in svn that they have 1.5-rc5, do you think it will be long before they release 1.5?
<james_w> gour: I don't think so, I don't know if it's real sftp, or just the name we use for it. I suspect the former, but it required no setup here, and I've never seen anyone ask how to get it to work. Do you have a setup that wouldn't be expected to have this already?
<james_w> ricardokirkner: I have no idea I'm afraid.
<ricardokirkner> ok... thanks anyway
<james_w> ricardokirkner: I know jelmer was also working on avoiding the 1.5 bindings altogether by implementing his own with pyrex, I don't know if that will happen before svn 1.5
<gour> james_w: i'll check it right now
<james_w> gour: it works fine with no setup on a Debian/Ubuntu server at least.
<james_w> ricardokirkner: I'm just going to look if anyone has ever requested fedora backport the bindings.
 * gour is doing bzr push...let's see
<gour> kind a slow...
<gour> ok, the repo is pushed, now lets pull back...
<gour> it works...cool
<jelmer> ricardokirkner: try bzr-svn 0.4.98
<ricardokirkner> what changed?
<jelmer> regression
<ricardokirkner> sorry jelmer , 0.4.98? or 0.4.9 or 0.4.8?
<jelmer> 0.4.9
<ricardokirkner> ok
<jelmer> svn is more picky about input parameters
<ricardokirkner> jelmer, now the tests fail with No default access_method or index any more
<ricardokirkner> and the checkout also fails, but with python: Objects/classobject.c:2281: instancemethod_dealloc: Assertion `g->gc.gc_refs != (-2)' failed.
<jelmer> ah, yes - you'll need bzr < 1.4 for 0.4.9 to work :-(
<ricardokirkner> ouch
<ricardokirkner> ok, i'll try
<ricardokirkner> do you know anything about the checkout error?
<ricardokirkner> the same error was happening before
<menace> did someone already tried ACLs with bazaar?
<james_w> menace: what sort of ACL?
<menace> Privileges of Reading/Writing to certain parts of the sourcecode repository
<ricardokirkner> ok, apparently it is working (using bzr-svn in fedora), albeit only through svn:// and not through http://
<menace> hm :/
<james_w> menace: so that would have to be implemented in bzr?
<james_w> in which case I haven't heard of it being implemented.
<jelmer> ricardokirkner: is subversion built against libneon?
<gnomefreak> is there a way once branch is pushed to remove the source files and leave debian dir. in place? i pushed the source files by mistake
<ricardokirkner> mhh.... it isn't by default, I am guessing right now :-) (i just did ./configure --prefix)
<ricardokirkner> i'll fix it and let you know
<james_w> gnomefreak: the debian dir, do you mean that, or the .bzr dir?
<gnomefreak> james_w: debian
<gnomefreak> the branch should only be the debian dir and .bzr afaik the source files shouldnt be there
<gnomefreak> i have a separate source branch
<james_w> so you have project/.bzr and project/debian/.bzr?
<james_w> and you ran "bzr push" in the "project" directory when you mean to run it in "project/debian/"?
<gnomefreak> james_w: https://code.edge.launchpad.net/~gnomefreak/firefox-extensions/firegpg.ubuntu should only pull debian dir not everything
<gnomefreak> bzr branch lp:~gnomefreak/firefox-extensions/firegpg.ubuntu
<james_w> gnomefreak: ah, so the problem isn't specifically with push, it's that you versioned all the source with bzr when you only wanted to version "debian/"?
<gnomefreak> https://code.edge.launchpad.net/~gnomefreak/firefox-extensions/firegpg.upstream  << should be only branch with these sources
<gnomefreak> james_w: yes
<gnomefreak> but i did bzr add debian
<gnomefreak> and commit than push and it pushed everything
<james_w> because you started with a "bzr branch firegpg.upstream firegpg.ubuntu" presumably?
<gnomefreak> yeah
<james_w> then that's the expected behaviour
<gnomefreak> i guess easiest would be to delete branch and repush correctly
<james_w> and as I understood it, this was the plan for the extension packaging.
<gnomefreak> james_w: yes i know im trying to correct it
<gnomefreak> james_w: there should be an .upstrewam and a .ubuntu ubuntu == debian dir upstream == upstream source fiels
<gnomefreak> files
<james_w> I realise that's not what's done with the firefox packages themselves currently, but I would recommend it for the extensions.
<gnomefreak> upstream and ubuntu together?
<james_w> yep
<gnomefreak> when upstream changes we would rather not start with old upstream sources
<james_w> if you like we can move this to mozillateam, as I think they would be more interested in this discussion than #bzr
<gnomefreak> james_w: ok
<james_w> cool
<ricardokirkner> james_w, I think it is compiled with neon support. nevertheless if it works through svn it is enough for me. I can have all my branches be branches of the main branch which lies in svn (in order to have good trac support), and work with bzr on the child branches
<jelmer> ricardokirkner: if libneon-dev isn't installed it will build without http support
<ricardokirkner> jelmer, no, I have libneon-dev installed
<jelmer> ricardokirkner: and you're using svn+http:// when specifying the URL?
<ricardokirkner> no, just http (i have svn webdav installed in the web server)
<jelmer> you may need to specify svn+http:// when specifying URLs to bzr because of a bazaar bug
<ricardokirkner> no, something isn't working, when trying http:// or svn+http://, I get python: Objects/classobject.c:2281: instancemethod_dealloc: Assertion `g->gc.gc_refs != (-2)' failed.
<jelmer> hmm, that looks like a python-subversion bug
<gour> i'm inspecting emacs' DVC repo..bzr tags gives: Tags not supported by BzrBranch5. anyone can explain?
<fullermd> Well, pretty much what it says   :)
<fullermd> The Branch5 branch format doesn't support tags.  You need Branch6 for that, and apparently the branch in question isn't.
<gour> i mean, how 'new' is that feature?
<fullermd> That came in with 0.15 (April 1 2007).  So not particularly new.
<gour> ohh, it means the repos is quite old
<fullermd> Well, the format still works with newer versions, so it could be being intentionally kept back for known older clients.
 * gour just finished looking at ian's (igc) slides: getting started with bazaar
<gour> nice stuff
<CroX> I have FTP access to a box, but not root. Could I use that for centralized development with Bazaar?
<CroX> Eg, does Bazaar require any "listening software" to handle requests or can it just read the .bzr catalog and use that?
<radix> hmph.
<radix> CroX: You definitely don't need to run any software as root.
<CroX> radix: Yeah, but do I need to run any software at all for the centralized part? I have a web hotel which I want to use to commit to. We all got dynamic IP's, so commiting and merging from eachother doesn't work too well.
<radix> CroX: If all you have is an FTP account, though, you would need to share the account details with everyone who is able to commit
<CroX> That would be a problem. Alright, so reading the folder with the .bzr subfolder is all that's needed. Awesome!
<CroX> *wouldn't
<radix> :)
<schmichael> how bad of an idea is it to use bzr on large binary files?
<schmichael> i'd like to keep all my documents including music and photos synced between computers
<beuno> schmichael, probably pretty bad
<pygi> ++ on that
<beuno> I'd go with rsync for something like that
<beuno> I've tried, it aint pretty
<schmichael> beuno: ha, thanks!  thats kind of what i expected, but i thought i'd check
<beuno> you'll get conflicts, enourmos repos, out of memory errors...
<pickscrape> Can/will that be improved as development continues, or is that likely to always be the case?
<mwhudson> you can end up needing to have about three times the ram of the largest file you're versioning, or something
<pickscrape> I don't particularly need to do that right now, but it's always nice to know about such things. :)
<mwhudson> pickscrape: yeah, this will probably get better over time
<pickscrape> Sweet.
<mwhudson> i wouldn't have thought photos or music would be too terribly bad
<mwhudson> isos, on the other hand :)
 * pickscrape is currently writing a presentation to demo/sell bzr to his colleagues
<beuno> pickscrape, I do, on the other hand, use bzr to version large-ish binary files (50-300mb)
<beuno> we do web development, and everything has to be versioned, so gfx people have their videos que large images in a repo
<beuno> RAM is an issue sometimes, but bzr is getting better pretty fast
<beuno> and, I bought a bigger HD  :)
<pickscrape> Can anyone suggest bullet points for why bzr and not hg/git?
<beuno> pickscrape, igc setup a page of comparisons
<beuno> but I think the failsafe answer is that bzr is mucho more user friendly in general
<nDuff> pickscrape, see the web page. ease-of-use, though, is a massive one -- particular re git
<nDuff> pickscrape, http://bazaar-vcs.org/BzrVsGit, http://bazaar-vcs.org/BzrVsHg
<pickscrape> The annoying thing is I started out looking at git, then hg and finally bzr, but by the time I'd decided that I preferred git I couldn't exactly remember the reasons :)
<pickscrape> Sorry, preferred bzr
<pickscrape> Yeah, the user friendly argument works very well against git, but less so against hg.
<beuno> pickscrape, if it's for an open source project
<beuno> LP is a good argument too
<beuno> super-cool free hosting
<pickscrape> It's not, unfortunately.
<mlh> not super-cool or not free ? :-)
<pickscrape> :)
<pickscrape> Not open-source
<mlh> ah
<pickscrape> Those two pages are an excellent reference, thanks!
<demod> schmichael: on your question about syncing large files: have a look at "unison", it's easier to sync both ways with it than with rsync, imho
<demod> beuno: is LP really such a good argument? i mean there is github (free for small projects iirc), freehg.org, etc.
<beuno> demod, AFAIK, none of those have a pseudo-unlimited size, code view, revision navigation, rights managment, bugs, etc etc etc
<schmichael> demod: i've looked at unison but was scared off because it sounded like its no longer maintained
<demod> beuno: ok, you are probably right ,)
<beuno> I don't think there's anything out there that provides something even close
<pygi> beuno, gitorious will have soon
<pygi> but anyway, no fights :)
<beuno> demod, and, of course, you can use bzr without LP perfectly. I was just throwing ideas at him  :)
<beuno> pygi, well, we'll see what LP has soon  :p
<pygi> beuno, true :)
<demod> schmichael: i believe i installed a new version a week or two ago, but can't really spot any release dates on the unison homepage atm... hm
<demod> beuno: kk ,)
<demod> pickscrape: btw. you really got to read the response from the mercurial team on the BzrVsHg entry imho
<mlh> schmichael: I believe it's maintained; it's just very stable.
 * demod should idle less
<mlh> not that I ever used it much
<schmichael> demod, mlh: thanks, i'll try it out
<beuno> any idea on how to get "the revision previous to X"?
<beuno> by using revid
<mwhudson> beuno: with the api?
<mwhudson> repository.get_revision(revid).parent_ids
<beuno> mwhudson, good old command line  :)
<beuno> maybe I could use --limit and ..revid:X
<mwhudson> bzr revision-info -r $(($(bzr revno -r revid:...) - 1)) ? :)
<beuno> but that gives me the revidX
<beuno> mwhudson, almost!  that gives me the next one (ie. X == revno 3, it gives me back revno 4)
<jam> mwhudson: what is wrong with before: ?
<mwhudson> jam: i didn't know about it :)
<jam> beuno: bzr -r before:revid:XXXX
<mwhudson> beuno: listen to jam :)
<beuno> jam, that's it, thanks  :)
<beuno> mwhudson, ditto  :)
<lifeless> moin
<beuno> mornin' lifeless
<mwhudson> hi lifeless
<beuno> yay!  works!
 * beuno starts preparing to release the php-bzr thingie
<mwhudson> sweet
<beuno> merges are a pain in the *rs if you have to keep bzr's history in sync with a DB
<beuno> vila, ^^^
<jam> beuno: merges are a pain in the stars? or did you mean *rse?
<jam> What do you mean about bzr history versus DB?
<jam> out of curiosity
<beuno> jam, arse  :)
<beuno> jam, well, I have bzr's history in a DB
<beuno> and, when merges happen all around
<beuno> revno 177 suddenly is revno 6, with a whole lot of subrevnos
<jam> beuno: well, you wouldn't have to cache the revnos :)
<jam> beuno: further, a specific revno should never become anything but a dotted revno
<beuno> jam, I do if the interface uses mysql to show 'em
<jam> if that helps
<jam> 'revno' has only 1 possible value if it is a simple integer
<beuno> jam, well, it becomes part of a different revno
<beuno> a merge
<beuno> and I wanted to represent it properly
<beuno> so, what I did up to know, is detect merges
<mwhudson> launchpad has separate revision and branchrevision tables
<beuno> delete the history from the DB, and re-generate
<jam> beuno: if it were me, I would probably use a 2 pass check
<jam> if the revision is a simple decendent from the previous tip
<jam> just do some quick numbering
<jam> if it isn't
<jam> call branch.get_revision_id_to_revno_map() and just rebuild the cache
<beuno> jam, if I could do calls to bzrlib, it would be very easy
<jam> you technically only have to rebuild things that are outside of the common left-hand ancestry
<beuno> but I don't want to use anything besides bzr and php
<beuno> so it's bzr + xmloutput, which PHP writes into the DB
<jam> beuno: write a plugin :)
<jam> you're already using xmloutput
<jam> so you can obviously have custom functions/plugins
<beuno> hmmm
<jam> beuno: if you care, 'bzr revision-info' can take multiple arguments per pass
<beuno> I was hoping XMl would go into the core
<beuno> and eliminate the use of plugins
<jam> bzr revision-info -r -1..-2..-3..-4..-5..-6
<beuno> jam, that sounds interesting...
<jam> It certainly isn't something that comes up often :)
<beuno> I should see if that speeds things up
<jam> beuno: alternatively you don't need the -r
<beuno> anyway, I wanted to have something better than drop the history and reload
<jam> bzr revision-info -- -1 -2 -3 -4 -5
<jam> beuno: if you do
<jam> bzr revision-history OLD
<beuno> so now I just start going back one revision until I get the same revid/revno in DB and in bzr
<jam> bzr revision-history NEW
<jam> if you can find how much of history is the same
<jam> you only need to rebuild ones that are ancestors of the tips
<jam> but it sounds like you might be doing that anyway
<beuno> jam, yes, I should try using revision-info and/ir revision-history and see if makes it faster
<beuno> but, for now, I want to finish cleaning it up and open source it
<beuno> then, start making it better
<beuno> but that definitely sounds faster than using log -r
<beuno> it got tricky when we had to re-generate 1000k revision repos into XML 30 times a day  :)
<jam> 1M revision repos sounds pretty big
#bzr 2008-05-14
<beuno> hm
<beuno> I probably meant 1k
<jam> beuno: internally, bzr log will be traversing the whole list, as will 'bzr revision-info' if it gets a non-mainline commit
<jam> beuno: so calling it 1 time with a lot of revisions
<jam> should be a lot faster than calling it lots of times.
<beuno> jam, I shoulds absolutely go down that path then
<beuno> I wonder how hard it would be to change the current code...
<nDuff> in what contexts is bzr-git intended to be presently usable?
<jam> nDuff: proof of concept, afaik
<jam> bzr fast-import is the recommended way to convert from git
<jam> bzr-git probably has some bitrot, etc.
<bob2> I think it could run 'bzr log' on a git repository
<jam> bob2: I believe that was working as well
<jam> because it could run "bzr viz" at the time
<lifeless> yes, my first fraft at EP2006 did that :P
<rockstar> abentley, ping
<abentley> rockstar: pong
<rockstar> You seem to be close to my timezone, and I'm rather interested in getting into Bazaar hacking, probably outside of Canonical time.  I was wondering if we could arrange a mentoring situation.
<rockstar> I promise to stay out the way as much as possible.
<abentley> rockstar: Sure, I'd be happy to.
<abentley> Did you have a task in mind?
<rockstar> Not really.  I looked at the bug list, and I'm not really sure I know enough to say "That's a good starter bug"
<abentley> There are actually a few that are tagged that way.
 * rockstar looks again
<abentley> Look for the "easy" tag.
<rockstar> Ah, 23 of them.
<abentley> Also "trivial".
<abentley> I can't guarantee that the assessment is right-- some are probably only "easy" until you actually try to fix them... :-)
<rockstar> abentley, yea, that's what I gathered out of some of the trivial bugs.  Didn't see the easy ones
<rockstar> Alright, I'll just take one of these, and start exploring.  Be prepared to be harassed.
<abentley> If you let me know which one you're doing, I can give you some starting points.
<rockstar> I was thinking this one:  https://bugs.edge.launchpad.net/bzr/+bug/200575
<ubottu> Launchpad bug 200575 in bzr ""Address already in use " crashes smart server" [Medium,Triaged]
<abentley> rockstar: It seems there's already a patch attached to that bug.
<rockstar> Ah, bugger
<rockstar> https://bugs.edge.launchpad.net/bzr/+bug/89570
<ubottu> Launchpad bug 89570 in bzr "unknown format exception could be clearer" [Low,Confirmed]
<abentley> rockstar: I'm not sure what more needs to be done there.
<abentley> Newer formats do indicate the minimum Bazaar version in their format strings.
<abentley> But people still get thrown from time to time.
<abentley> Of course, it's impossible for Bazaar to guess what version is required for an unknown format.
<rockstar> Alright.  How 'bout I take an hour or so and find a few of them, and them come back to you.  :)
<abentley> Sure.
<thumper> poolie: ping
<igc> thumper: poolie on an leave today
<igc> s/an/on/
<thumper> igc: thanks
<thumper> igc: are you up for a call?
<igc> I guess so
<thumper> you sound so enthusiastic ;-)
<igc> well - I'd need to know what's its about
 * igc lunch
<abentley> BB is temporarily down while I update the machine.
<igc> out to a medical appointment - bbl
<abentley> BB back.  Failed to install Hardy.
<bob2> eep
<Peng> abentley: Upgrading from what to Hardy?
<abentley> Peng: Feisty
<Peng> Oh.
<abentley> Now, it's a Xen box, so not your standard install target.  But still ...
<Peng> Gutsy to Hardy was trivial for me, but then, that server (VPS) didn't have much of anything installed at the time.
<abentley> Peng: The stuff failing was pretty basic stuff, like initramfs-tools
<RAOF> You did go through gutsy, right?
<abentley> RAOF: Yep.  Gutsy was where the problems started.
<RAOF> Eh.
<RAOF> I'm not sure if I've never had problems updating or whether I just don't remember them ;)
<gour> i see that opensolaris uses bzr-0.7 when evaluating and it looks speed was their concern  for 'cons'
<gour> same with mozilla...
<bob2> 'cons'?
<gour> opposite of 'pro'
<bob2> ah
<Peng> 0.7?
<bob2> thought it might be run by lisp nerds
<Peng> gour: Bzr has gotten a lot faster, of course, (and better in every other way) but it still has problems with huge projects.
<AfC> gour: that is true, but then when they were evaluating bzr 0.7 was all that was out. Personally I think they were short sighted in their decision, but it is difficult to fault the "set criterion and then pick the one that scores best" approach. It's called "engineering" :)
<gour> i do not plan to use bzr for such big project(s), but i'm more interested to hear about other kinds of problem i had with darcs-1 like  doppleganger bug and exponential time
<rockstar> 0.7?  That's older than what's in Gutsy.
<james_w> hi AfC
<AfC> It's unfortunate, because the Bazaar project lost out on a significant adoption opportunity there. While no one really cared about OpenSolaris, as such, it was obvious that whatever they picked would be adopted by the Java Engineering team at Sun, which in turn is propagating out via Open Java rapidly.
<gour> rockstar: see http://www.opensolaris.org/os/community/tools/scm/bzr-eval/
<AfC> james_w: hey James. Been a  while. I hope you're well.
<james_w> I'm good thanks, how are you?
<gour> AfC: with mozilla it was similar situation?
<AfC> james_w: Just about to go for a run, actually. Thought I would chime in before I set off.
<james_w> so you're ready to make a quick exit
<gour> so, bzr probably does not have 'doppelganger' problem by design?
<james_w> gour: not that we know of
<gour> that's nice...i was bitten by it in darcs several times...
<AfC> gour: if you're talking about http://research.operationaldynamics.com/blogs/andrew/software/version-control/red-giant-bugs.html then, no, Bazaar doesn't have that problem
<AfC> gour: let me put it this way. If you are doing work with Bazaar and you have a project that is so large or a use pattern that is so unusual so as to cause Bazaar problems, I can only suggest that you will likely find interest here and likely will find that if you can offer your repository to the Bazaar hackers to work with that they will be able to use it in their tests and optimizations.
<gour> here it is in more detail - http://wiki.darcs.net/DarcsWiki/ConflictsFAQ
<gour> AfC: thanks. i had similar experience with darcs (droundy was inspecting my repos), but, unfortunately not easy to fix those design-issues
<AfC> gour: otherwise, asking "is it fast enough" is all a bit silly, really. If it wasn't, there wouldn't be so many people here using it quite happily. Could it be faster? Probably, but that's the wrong question. Does it work reliably? Does it prevent you from shooting yourself in the foot and thereby loosing data? Does it have a clean and consistent user interface? are far more relevant.
<gour> another nice thing i see in bzr is bzr-svn (i might soon switch to NixOS and they stil use svn)
<AfC> gour: as I noted, we used Darcs for years, loved it, and miss it still.
<Peng> gour: Yeah, bzr-svn rocks.
<gour> AfC: right. git is like automatic gun to shoot your foot all the time :-D
<bob2> and fast like a greased fox
<gour> AfC: my 'speed' argument was just in the light of bzr vs. hg for solaris and mozilla
<gour> for me it's not so important - finally, that's why we use dvcs ;)
<AfC> gour: but Bazaar is an improvement in many other areas, so we swallow our impatience with the less-then-Darcs user interface and abysmal lack of cherry picking support in favour of having a robust tool with a vibrant and intelligent group of hackers working on it.
<gour> AfC: so far (reading user manual etc.) i like bzr, today i'll try with some tests...interface looks nice (i won't even compare it to git's surprises)
 * gour --> breakfast. bbs
<asabil> AfC: maybe I can convince you to hack on bzr-interactive ? :p
<fullermd> Pshaw.  git's interface makes perfect sense if you follow a few simple steps.
<fullermd> First, you become Linus...
<AfC> fullermd: no, you've got to learn Finnish first.
<fullermd> Ah, no wonder it doesn't work right.  I keep mixing up those Scandinavian countries.
<fullermd> % git de bork bork bork
<fullermd> git: 'de' is not a git-command. See 'git --help'.
 * AfC goes out
<AfC> What is the version of bzr-svn you have to have to work with bzr 1.4?
<luks> AfC: there isn't one that works with 1.4, as far as I know
<bob2> 0.4.10 is compatible with 1.4 and 1.5
 * igc dinner
<gour> i see that bzr help formats shows plethora of different formats...will this trend to continue or is it reasonable to expect bzr to settle on some proven one?
<Peng> gour: Well, they probably thought they were going to settle on each one as they created it.
<Peng> gour: But yes, it should go down.
<gour> Peng: the 0.92 format is that git-like 'pack' format?
<Peng> gour: I'm sure the implementation is different, but it's the same idea, yeah.
<Peng> gour: BTW, there are 5 or 6 more hidden formats! ;)
<gour> only?
<gour> :-D
<Peng> gour: Whenever they've changed the branch, repository or working directory format, they've added a new format to the formats list, and pretty much all of them are still supported.
<Peng> gour: E.g., I think dirstate is just knit with a different working tree format. dirstate-tags is just dirstate, only the branch supports tags. pack-0.92 uses the same branch and working tree formats as dirstate-tags, but an entirely new repo format.
<gour> in any case, 0.92 is default now and recommended one?
<Peng> gour: Also, there are now multiple variations of the same base format: There's pack-0.92; rich-root-pack, which is the same but supports slightly more meta data; and pack-0.92-subtree, which has experimental support for stuff similar to svn:externals.
<Peng> gour: pack-0.92 is.
<Peng> gour: They want to switch the default to a rich-root format soon, which will simplify things somewhat. (Rich roots are perfectly stable, but you can't downgrade from a rich-root format to a non-rich-root format.)
<gour> Peng: in 1.6 ?
<Peng> gour: Maybe.
<gour> it would be nice
<elmo> bzr: ERROR: Transport error: Server refuses to fullfil the request
<elmo> 'sup with that?
<Peng> elmo: Are you the guy from the mailing list?
<elmo> Peng: err, i don't know? if you mean, have I posted about this problem on the mailing list, then no
<elmo> I only ran into it 10 seconds ago
<Peng> elmo: Then, someone else has the same issue on the mailing list. :)
<elmo> ok
<elmo> apparently it's a 1.4 regression too
<elmo> someone else with 1.3 claims it WF him
<elmo> I'll try downgrading
<Peng> elmo: Run bzr with -Dhttp -Dtransport and pastebin the relevant section of your .bzr.log (warning, really long).
<Peng> elmo: Are you experiencing this with the same branch?
<elmo> Peng: same branch as what, sorry?
<elmo> wow, it really does work with 1.3
<james_w> elmo: I presume this isn't python-apt--debian-sid from mvo's people.debian.org you are trying to grab?
<elmo> it's http://bzr.debian.org/da-tools/da-tools/userdir-ldap-common
<elmo> 1.4 seems to a POST?
<elmo> which gets 403ed
<james_w> did 1.3 -> 1.4 have the addition of probing for the smart server?
<james_w> ah, yes, it seems so.
<james_w> elmo: I think nosmart+http:// is the transport that forces that off, which should allow you to work around this.
<elmo> james_w: 'apt-get install bzr/hardy' is good too :-) thanks
<elmo> filed as #230223
<james_w> thanks
<awilkins> jam: Ping?
<Kemurii> Hi, I'm having a rather small Mercurial repo, and need to move it to Bazaar.. So, I'm using fast-import:   bzr init-repo new.bzr ; hg-fast-export.py --repo=../old.hg | bzr fast-import -  .. I copied first all files from old.hg..  but, it says "bzr: ERROR: No WorkingTree exists for" ... I'm missing a step somewhere?
<mwhudson> Kemurii: init-repo doesn't make a branch or a tree
<mwhudson> try bzr init-repo new.bzr; bzr init new.bzr/import-branch; cd new.bzr/import-branch
<mwhudson> then the same commands again
<Kemurii> ah, mm
<Peng> Kemurii: Just out of curiosity, why move from hg to bzr?
<gour> same question here as well
<Kemurii> Peng: company policy, I'm sticking with Mercurial for personal stuff
<Peng> Kemurii: Oh. That sucks.
<Peng> At least the company policy isn't VSS or something.
<Kemurii> well, 'company policy', nothing says I have to do it in bzr, but well.. :)
<Kemurii> mwhudson: hehe, that somehow worked :)  thanks!
<mwhudson> Kemurii: no worries
<Peng> Kemurii: Oh, good.
<Kemurii> mtaylor: here?
<Kemurii> woohoo, pushed to parent, nice nice
<Kemurii> now I have to learn typing 'bzr' instead of hg or bk
 * awilkins proposes the evil solution of aliasing hg and bk to something that mocks and ridicules you
<awilkins> random-insult.sh should do
<awilkins> Kemurii: Your company policy is highly enlightened. I know shops that are still using VSS and moving to TFS
<awilkins> (blech)
<Kinnison> Kemurii: because my prompt knows what vcs I'm using, I am tempted to start using 'vcs' as the command and let my shell sort it all out for me :-)
<Kemurii> awilkins: not sure it's policy yet, just 1st option for VCS now
<Kemurii> Kinnison: now that's an idea :)
<awilkins> At least in SVN shops you can still use bzr.
<awilkins> I'm the svn server admin here, and I use bzr these days.
<Kinnison> vcs () { if [ "x$_VCS" = "x" ] then bzr "$@"; else $_VCS "$@" ; fi }
<Kinnison> that should do the trick for me
<Kemurii> hehe
<Peng> TFS?
<Kemurii> anyway, thanks again guys, back to work, I mean lunch, cheers
<awilkins> Team Foundation Server (with all new VSS! Blech!)
<lamby> dato: I'm still failing at accessing that repo over http. I'm using your exact command too.
<pickscrape> Is there some way to suppress the deprecation notice output when running bzr?
<kaaloo> Hi, I was wondering if there was an issue with bzr-svn using authentication.conf ?  I'm using 1.3.1-1
<dato> lamby: odd
<dato> lamby: tried from another host?
<lamby> dato: Ah, that seems to have helped. I'll poke a little more.
<awilkins> kaaloo: I'm not sure it even uses authentication.conf
<pickscrape> Is there way to define location 'bookmarks', in the same way that the launchpad plugin lets you reference lp: ?
<pickscrape> e.g. so I can define the 'mine' refers to bzr+ssh://example.com/bzr, and subsequently use bzr branch mine:trunk
<Peng> pickscrape: THere's a bzr-bookmark or bzr-bookmarks plugin. Not sure how exactly it works.
<pickscrape> Oh, cool
<Odd_Bloke> lamby: What bzr version are you using?
<lamby> 1.4.
<lamby> Now this is interesting, can reproduce on 1.5~rc1 from a different host.
<lamby> Would you like a login? It's a testing machine anyway.
<james_w> lamby: hi
<lamby> Good afternoon.
<james_w> sorry, I missed the start of this
<james_w> is this a problem with http?
<lamby> This started on pkg-bazaar-maint.. So the testcase is "bzr get http://bzr.debian.org/pkg-bazaar/trac-bzr/unstable/ trac-bzr".
<james_w> ah yeah, I saw that
<james_w> is there a difference in whether pycurl is installed on these machines?
<lamby> Heh, psychic debugging.. Installing pycurl made it work.
<Odd_Bloke> I was going to suggest that yesterday, but thought it might be _too_ psychic to be right. :p
<james_w> bug 230223 may be relevant then
<ubottu> Launchpad bug 230223 in bzr "smart server probing in 1.4 breaks check outs of short bus http repositories [regression]" [High,Confirmed] https://launchpad.net/bugs/230223
<lamby> Ah yes, seems to be the same bug. tcpdump is confirming that only the POST is attempted, which 403s.
<james_w> hopefulls spiv or vila will be able to find a fix soon.
<lamby> Subtle ping.
<lamby> jelmer: bzr-gtk just uploaded with DM-Upload-Allowed: yes.  I'm still seeing the breakage when visualising via `olive-gtk` (when `bzr viz` works fine). Did you try a fix? Shall I file a bug?
<jam> james_w: well, there is already the workaround of nosmart+http://
<james_w> jam: true
<vila> james_w: you got the targets right :-) My plate is already pretty full so I'm not sure I can fix it quickly. But I think the diagnosis points to hpss probing, also bug #229076 is pretty similar
<ubottu> Launchpad bug 229076 in bzr "'Connection reset by peer' error when branching repository" [Undecided,New] https://launchpad.net/bugs/229076
<vila> hehe, nice point jam, indeed nosmart for the win :)
<vila> phoen
 * dato marks "upload bzr-gtk" off his TODO :)
<james_w> vila: yeah, I think that's what it is. It also appears to be a difference in the handling of 403 response between urllib and pycurl.
 * abentley really hopes we can get rid of pycurl soon.
<dato> sigh, I forgot to push to the bzrtools packaging branch again
<orospakr> Hey, is there a bazaar equivalent to git-archive?  I'd like to spit out a tarball of all the files that are in version control.
<james_w> export
<james_w> "bzr export <location> [<branch>]"
<james_w> location can end with .tar.gz to make a gzipped tarball
<james_w> note that it exports the last revision, not the working tree, so uncommitted changes won't be included.
<orospakr> that's exactly what I want. Thanks! :D
<jam> vila, james_w: there also seems to be a problem where you get the 403 a long time after you started downloading
<jam> At least, that is what Ben Finney's logs seem to indicate
<jam> I'm guessing a permissions issue, but I'm not positive
<james_w> jam: yeah, I saw that just now, I was going to look at the permissions on the directory that you pointed to, but I'm currently locked out of that machine.
<awilkins> jam: I've been having some success with your service plugin as a backend for bzr-eclipse
<ricardokirkner> hi, what is the best way to configure bzr over http with authentication? fastcgi or mod_python? or something else?
<awilkins> jam: I had to change it to threads rather than forks because the library implements ForkTCPServer with fork() (duH). No forks on Windows.
<jam> awilkins: I will warn you that bzrlib isn't particularly thread safe
<awilkins> jam: It should all be single-threaded access.
<jam> and you can fork under cygwin, so it *is* possible, but AIUI they had to jump through a lot of hoops to get it to work
<awilkins> jam: Yeah, I mean "the os module in CPython doesn't do fork()"
<awilkins> For the purpose I'm using it for, thread isn't so bad ; it gives charge of the process to the Eclipse instance with no extra steps involved.
<awilkins> Dammit, IO blocking again
<jam> awilkins: I would just mention that you probably want a plain TCPServer not a Forking* or a Threading*
<jam> I believe if you use the base class, you will get a single-threaded server
<jam> which is what you need anyway.
<awilkins> Perhaps I'll change it down one then...
<awilkins> It so annoying ; it works lovely when you run the tests one-class-at-a-time... then it blocks on IO when you run them as a block
<awilkins> Is JUnit multithreaded?
<jam> awilkins: I don't know about Junit, but enforcing multithreaded test running without requesting it seems like bad mojo
<awilkins> Or bad "juju" for JUnit :-)
<kaaloo> awilknis: thanks, I'll check the code, maybe there is a fix
<ricardokirkner> I am trying to set up a bzr repo for my project, which I migrated from svn. the bzr stuff is working ok, but I need to be able to checkout/checkin through http so as to mimick the previous setup. checkout through http is ok, but in order to commit, do I need webdav or anything like that? (I dont want to give the apache user full write permission to my repository)
<ricardokirkner> ok, I managed to checkout my branch using bzr+http and mod_python... now a strange thing happened... if I try to check out a normal branch, it complains about KnitpackRepository is not compatible with RemoteRepository, but if I checkout a lightweight branch, then it works...
<ricardokirkner> is this a feature or a bug?
<james_w> "checkout a lightweight branch"? I'm not sure what you mean, "checkout --lightweight"?
<ricardokirkner> yes
<james_w> and yes, there are two options, bzr+http with write access, or webdav. I've not used either, so I don't feel confident to explain the pros and cons.
<jam> ricardokirkner: you converted from svn
<jam> which means you need to use 'bzr init-repo --rich-root-pack' locally
<ricardokirkner> yes :$
<jam> the problem is that the RemoteRepository is hiding the "real" versions on each side to give you a clearer error
<jam> you can also do "bzr upgrade --rich-root-pack" in your local repository
<jam> and things should work
<jam> ricardokirkner: I would probably recommend using bzr+http with write access, but I would *probably* do it as bzr+https: and make sure you have proper authentication at the http layer
<ricardokirkner> jam, but then every developer will have to know that the project originally started in svn, and prepare a local repository by hand? isn't that a bit of counterproductive?
<jam> ricardokirkner: bzr-svn "jumped the gun" and started using some development formats
<jam> supported, but not default
<jam> we are working on making it the default format for 1.6
<ricardokirkner> jam, ok I think I understand. the correct behaviour should be that the bzr server tells the client which format that branch is, so that the client can create the repository in the correct format instead of assuming the default format. am I right?
<jam> ricardokirkner: you did 'bzr init-repo' on the local side first
<jam> if you did not do that
<jam> then doing "bzr branch" would preserve the source format
<jam> 'init-repo' is a good thing, but 'bzr branch' isn't going to upgrade your repo for you
<jam> as if you are using a specific format, there may be a reason
<jam> (old clients, etc.)
<ricardokirkner> no jam, I did not issue init-repo on the local side first
<ricardokirkner> I have a repo on the server side, but I just did a bzr co
<jam> ricardokirkner: hmm... that seems a bit weird, I'll try to check the code for a sec
<kaaloo> ok, update on my bzr-svn problem, of it not using authentication.conf, actually pycurl was not installed, now I'm getting a "certificate verification failed" error from pycurl, which is actually true since I had to deal with that using svn co, but here pycurl simply fails
<ricardokirkner> jam, if I try a bzr branch, then I get a traceback
<jam> ricardokirkner: ok, it does seem to be a problem with the RemoteRepository not reporting the right source format, I can reproduce it here trivially
<jam> ricardokirkner: interestingly 'bzr branch' works fine
<jam> ricardokirkner: can you paste your traceback
<jam> !paste
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<ricardokirkner> just a sec
<ricardokirkner> jam, http://paste.ubuntu.com/12071/
<gour> anyone uses fish shell? i just noticed it does not have bzr-completion :-(
<kaaloo> ok this is an old bug that hasn't been fixed in pycurl : https://bugs.launchpad.net/bzr/+bug/82086
<ubottu> Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Confirmed]
<dato> jam: your latest import cleanup to stats broke things... http://dpaste.com/49901/
<jam> dato: update to trunk, you are using the wrong one
<jam> lp:bzr-stats is the official trunk
<jam> not the one on bzr.arbash-meinel.com
<jam> I'll try to fix my branch
<dato> hm
<dato> ok, sorry for the noise.
<jam> dato: you aren't the first one, I was just being lazy about my branch
<jam> I'll redirect it to launchpad
<dato> I supposed update-mirrors now lives in... lp too?
<jam> dato: actually, I don't know if I ever moved that one, I should
<dato> haha
<jam> dato: some old code there :)
<jam> I believe Jelmer was interested in helping with stats, so I moved it to lp:
<jam> dato: I haven't touched update-mirrors since 2006-06-19
<jam> so almost 2yrs ago
<jam> I'm amazed it still works properly
<jam> I guess we have at least *some* api stability
<dato> *g*
<dato> it certainly does work, against 1.5 even
<jam> dato: can you try doing an update/pull/branch from my bzr.arbash-meinel.com/plugins/stats ?
<jam> I believe it should redirect you to lp:///bzr-stats now
<dato> stray \n in location, I'd say
<jam> dato: try again
<dato> works :)
<jam> dato: does it give you any indication, or just "work" but point at a different location when it is done
<jam> my understanding is it just works, but if you do "bzr info" you will find out it went somewhere else
<dato> yes, it changes your url
<kaaloo> hmm, unfortunately the pycurl http transport implementation doesn't seem to use AuthenticationConfig as does the urllib2 implementation :(
<dennda> http://paste.pocoo.org/show/50195/ <-- Urg, what's wrong?
<dennda> (This is arch linux)
<dennda> The very same command works well on my ubuntu box
<dennda> bzr 1.3
<kaaloo> ok, I think I see what's happening, the svn repository is being accessed through WebDav over https, and it requires authentication to checkout a revision.  Running bzr branch https://...  is not getting through to bzr-svn because of the authentication issue, when starts to check the branch format, it coughs on a 401.  On the other hand running bzr branch svn+https://.. tries to go through the svn smart server protocol which of course fails 
<james_w> dennda: it's something to do with paramiko.
<james_w> if you search for the error string you should find the bug report.
<mxpxpod> how would I undo a merge?
<LeoNerd> revert? uncommit..?
<asabil_> mxpxpod: bzr revert
<LeoNerd> merge backwards?
<asabil_> if you didn't commit
<mxpxpod> asabil_: revert still leaves pending merges in the status
<mxpxpod> ah, wait
<mxpxpod> n/m... I was doing bzr revert *
<asabil_> bzr revert --forget-merges
<asabil_> only reverts the merge status
<mxpxpod> nice, thanks
<abentley> mxpxpod: "revert" with no arguments will forget the merge status.  Supplying arguments prevents that.
<mxpxpod> abentley: thanks :)
<abentley> (revert with no arguments reverts all files too)
<jam> ricardokirkner: the exception shown here: http://paste.ubuntu.com/12071/ is a bug in 1.2.0 which has been fixed in later releases. You can get 1.5rc1 from http://launchpad.net/~bzr/+archive, or we can try to work out something else.
<jam> dennda: this is actually an interaction with a newer paramiko
<jam> if you use paramiko 1.7.2 you don't have that problem
<jam> paramiko 1.7.3 causes the "no attribute "get_name"" traceback
<ricardokirkner> jam, thank you for your help. what version do you suggest me to use? I was using 1.4 previously, but downgraded due to some issues with that version too.. what is the most stable version (with a good amount of support for svn) for use in production right now?
<dennda> jam: uff, I doubt I can install the older version through pacman that easily
<dennda> Is there some sort of push-history in bzr?
<jam> ricardokirkner: sorry, about the delay, I have a sick child here.
<jam> anyway, what problem were you having with 1.4?
<jam> dennda: push-history?
<dennda> jam: bzr stores the last push location
<dennda> I wonder if it stores the last N locations
<dennda> accessible via push N
<dennda> I will drop the net now, brb
<Stavros> hello
<Stavros> i want to use bzr for backups, to version a folder on a different hard disk, is there a way not to have the entire repository on both disks?
<Stavros> i would like to minimize disk space
<Stavros> so if i could have JUST the repo on the backup disk and JUST the working copy on my normal disk it would be ideal
<Stavros> is that possible?
<beuno> Stavros, maybe something along the lines of a lightweight checkiut
<beuno> but, if you have large binary files, it might not be a good idea to use bzr
<Stavros> beuno: hmm, yes, how do i do that?
<Stavros> hmm
<Stavros> i have large binary files but they don't change much
<Stavros> they're mostly pictures and such
<beuno> Stavros, bzr uses a lot of ram for binary files
<Stavros> i'd use git for backup (is that better for binaries?) but its windows support is lacking
<Stavros> oh
<Stavros> hmm
<beuno> is this going to be one way syincing?
<Stavros> yes
<Stavros> mostly added files
<Stavros> no changed ones
<beuno> Stavros, bzr will use aprox 3x the file size in RAM
<demod> sounds like a job for rsync or rsnapshot
<beuno> just so you can calculate what it will take
<beuno> but yeah, rsynce sounds like a better candidate
<Stavros> i do use rsync, i wanted a better solution because rsync takes ages
<demod> thats odd, rsync should be rather fast since it's only checking file size and modification time (iirc)
<Stavros> hmm, indeed
<Stavros> maybe it's because around 10 mb
<brilliantnut> hi, I've been around asking this a long time ago, but what is the best way to have a central repository with LDAP based authentication?
<brilliantnut> basically, we looked at bzr+http earlier, but there were some open bugs concerning those, so we left it at that... this was around 1.0
<jam> brilliantnut: you could use 'bzr+ssh' and have ssh use pam+ldap for authentication
<jam> I believe you can even put ssh keys into ldap
<pickscrape> Anyone know the bzr-svn syntax for subversion.conf for explicitly specifying the branches in the svn repository?
<pickscrape> bzr svn-branching-scheme --set is crashing for me
<brilliantnut> incidentally, this was the exact suggestion we got the last time around, but we came back to bzr+http for some reason... We really need to bzr+http to work...
<brilliantnut> jam: we have followed instructions on http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#serving-bazaar-with-fastcgi
<jam> brilliantnut: I'm not sure what your current state is. You followed the instructions and it didn't work?
<brilliantnut> jam: yes. We followed the instructions on the link that I just posted.
<brilliantnut> /home/tech-admin/data/bzr is the repository, and is mapped to http://ourserver/bzr, /home/tech-admin/data/bzr/HEAD is the root branch.
<brilliantnut> bzr branch http://<credentials>@ourserver/bzr works just fine
<brilliantnut> actually scratch that
<brilliantnut> bzr branch http://<credentials>@ourserver/bzr/HEAD works just fine
<brilliantnut> bzr branch bzr+http://<credentials>@ourserver/bzr/HEAD gives an error: bzr: ERROR: No repository present: "bzr+http://<credentials>@ourserver/bzr/HEAD/"
<brilliantnut> I could pastebin the bzr-smart.py and relevant portions of our httpd if needed...
<bob2> also logs
<brilliantnut> http://paste.ubuntu.com/12141/
<brilliantnut> There are no relevant logs in error.log with that error... access.log shows a 401 followed by several 200s... post which I get the "No repository present" error.
<bob2> adoes http://blahblah/.bzr/smart 404?
<brilliantnut> no, no 404.
<brilliantnut> 401 Unauthorized
<bob2> great
<brilliantnut> which is fine, since it tries to access without auth first, then I provide credentials, and it goes ahead to 200s
<brilliantnut> all the 200s are http://blahblah/bzr/HEAD/.bzr/smart
<bob2> perhaps "bzr -Dhpss co http://blah" will be enlkightening
<deepjoy> this is what we saw as brilliantnut described http://paste.ubuntu.com/12142/
<brilliantnut> deepjoy is with me, by the way...
<jam> brilliantnut, deepjoy: There is a plugin you might try
<jam> 'bzr co lp:bzr-hello ~/.bazaar/plugins/hello
<jam> it adds a "bzr hello URL" command
<jam> which just tries to send the "hello" request to the server
<jam> that can be a "is the smart server running" check
<jam> It does look like the POST is getting through
<jam> You have a "/bzr/.bzr/repository/" directory?
<jam> (I'm just checking where the actual repository is at, and that the smart server was told that it has access to it)
<jam> Otherwise you might have restricted the smart server to only serve things underneath /bzr/HEAD
<jam> which would prevent it from reaching the repo at /bzr/...
<deepjoy> jam: we can branch using the http protocol
<deepjoy> jam: it's only when we use bzr+http that we have trouble
<deepjoy> jam: no the config does not include HEAD anywhere
<jam> deepjoy: I understand that. I'm saying that you may have configured the bzr server with the wrong chroot
<jam> I don't know for user
<jam> sure
<jam> you could try sending a
<jam> bzr hello bzr+http://.../bzr/
<jam> versus
<jam> bzr hello bzr+http://.../bzr/HEAD
<jam> if the former fails but the latter works
<jam> then you are unable to contact the smart server via bzr/.bzr/smart (as opposed to bzr/HEAD/.bzr/smart)
<jam> deepjoy: alternatively, it could be a problem with your Apache config
<jam> depending on what rule you used to redirect POST => .bzr/smart to the cgi script
<deepjoy> I'll post the relevant configs. just gimme a moment
<jam> I'm not a huge expert on this, spiv knows more
<jam> I'm just trying to point out some things to try
<deepjoy> apache conf http://paste.ubuntu.com/12145/
<jam> deepjoy: that apache conf *looks* correct to me. Can you try installing the 'bzr-hello' plugin and see if you can talk to "bzr+http://..../bzr" ?
<jam> deepjoy: and, of course, make sure you've restarted apache since whenever you last changed the config files
<jam> Apache config always feels like shooting in the dark to me. As a stray '/' can totally break things.
<deepjoy> bzr-smart.py http://paste.ubuntu.com/12146/
<deepjoy> jam: yes we restarted apache even if the change was only at the py file
<deepjoy> apache is serving up trac on the same virtualhost also on mod_python
<jam> deepjoy: I'm wondering about the line in smart.py:
<jam> prefix='/bzr/',
<jam> You might try
<jam> prefix='/bzr',
<jam> I'm not guaranteeing anything here, just something to try
<brilliantnut> we've tried both of them :)
<jam> spiv should be on in another 15min or so, and he's had more experience with this
<jam> brilliantnut: do you have the "POST" program installed?
<brilliantnut> yes.
<jam> you should be able to do
<jam> echo "hello" > POST http://.../bzr/.bzr/smart
<jam> It should  return "ok\012"
<jam> sorry \001 or \x01 or ^A depending on how you want to view that character
<jam> but on your terminal, you should see something "ok 2"
<brilliantnut> just a sec, sanitizing the conf again.
<jam> spiv, igc, poolie: are you guys there?
#bzr 2008-05-15
<brilliantnut> jam: got an errorâºincomplete request for that.
 * AfC waves to jam
<igc> morning
 * jam waves at AfC
<brilliantnut> jam: I just got an OK for the request... the problem was \r\n on win
<jam> brilliantnut: ah, ok
<jam> yeah, you need plain '\n'
<brilliantnut> so, the bzr smart server *is* up at that url
<Odd_Bloke> Good morning, Australasians.
<spiv> Good morning.
<jam> brilliantnut: you can try something like:
<jam> echo -ne "BzrDir.find_repository\001.\n" | POST ...
<jam> It an return: norepository
<jam> or: okâºâºnoâºno
<jam> It *can* return one or the other
<brilliantnut> okâº..âºnoâºno
<jam> or even: errorâºNot a branch: ...
<jam> brilliantnut: so we can find the repository....
<brilliantnut> right.
<jam> brilliantnut: what path did you POST to, btw
<jam> Since it seems to say that the repository is found in ".."
<brilliantnut> http://<creds>@<server>/bzr/HEAD/.bzr/smart
<spiv> vila: have you seen https://bugs.edge.launchpad.net/bzr/+bug/230223 ?
<ubottu> Launchpad bug 230223 in bzr "smart server probing in 1.4 breaks check outs of short bus http repositories [regression]" [High,Confirmed]
<brilliantnut> without HEAD it gives okâºâºnoâºno
<brilliantnut> jam: that does make sense though... we did init-repo is /home/tech-admin/data/bzr/ and then init in /home/tech-admin/data/bzr/HEAD
<jam> brilliantnut: right, that is what I thought you did
<jam> I'm trying to understand the other error, then
<brilliantnut> bzr log bzr+http://<creds>@<server>/bzr/ gives "Not a branch:"
<brilliantnut> and bzr log bzr+http://<creds>@<server>/bzr/HEAD gives "No repository present:"
<jam> brilliantnut: well I would expect the "Not a branch" since HEAD is the branch, "bzr/" is the repository
<jam> I' don't know why you are getting the other error
<brilliantnut> so, when I'm accessing the branch, it wants a repository, and vice versa :(
<jam> brilliantnut: well, it can find the repository from the branch, which is why it is confusing
<jam> can you paste the output of ~/.bzr.log if you run
<jam> bzr log -Dhpss -Dhttp bzr+http://..../bzr/HEAD
<jam> brilliantnut: and unfortunately, it is now time for me to spend with my family, but maybe spiv will peek his head in here and help
<igc> morning Odd_Bloke
<brilliantnut> jam: thanks for your help.
<poolie> good morning
<poolie> hi markh
<markh> hi poolie
<brilliantnut> output of .bzr.log after bzr log -Dhpss -Dhttp bzr+http://..../bzr/HEAD http://paste.ubuntu.com/12151/
<brilliantnut> http://paste.ubuntu.com/12151/
<brilliantnut> spiv: jam said you might be able to help with our problem...
<spiv> brilliantnut: I'll take a look
<libwilliam> I have a question regarding embedding bazaar's api's in my C code. I am getting fairly familiar with the python C api but I don't know enough about Python in general to understand what I am missing. Without all of the details I am trying to load a working tree object by... http://pastebin.com/m5abe9728   Now it says 'No module names workingtree' and that is where not knowing much about python is hurting me. I am unsure if I am supposed to d
<libwilliam> o some special linking in my makefile to link to the bzrlib or where to look for information.
<spiv> brilliantnut: strange, it repeatedly tries to do BzrDir.find_repositoryV2 in HEAD, rather than in bzar.
<spiv> brilliantnut: that looks like a bug in the client to me.  Which version of bzr is that?
<spiv> libwilliam: the module is called "bzrlib.workingtree"
<spiv> libwilliam: or rather, the workingtree module is in the bzrlib package.
<brilliantnut> spivl, I'm on 1.6 dev (latest checkout of bzr.dev), deepjoy is on 1.5rc1, and we've also tried using 1.3 earlier with identical results. The server is 1.3 (from fedora EPEL)
<brilliantnut> spiv:  ^^^^
<spiv> brilliantnut: ok, thanks
<spiv> brilliantnut: looks like bug report time :(
<spiv> The server appears to be working correctly, at least from that snippet.
<spiv> I'll file a bug report, I'll try to deal with it soon.
<spiv> It looks pretty severe to me.
<libwilliam> spiv: thanks, im building right now to try it out. So as long as bazaar is installed using bzrlib.workingtree should work do I have to specify to link against it(im new)
<spiv> libwilliam: no, you can't "link" Python modules.
<spiv> You need to import python code, as you're doing.
<spiv> You might want to read the python tutorial, especially the section about modules and packages: http://docs.python.org/tut/node8.html
<spiv> The background information that gives you should help you make sense of the C APIs.
<libwilliam> spiv: alright, im only used to using c and the makefile pain so not sure how anything python related words.
<libwilliam> spiv: im looking at it now, thanks for the help
<brilliantnut> spiv: This is similar happened to us when we last tried it after 1.0 released, and apparently there was a patch underway to fix this or something... unfortunately, we only got time to get back to this now...
<spiv> brilliantnut: yeah, this is definitely supposed to be working now :(
<brilliantnut> spiv: do you need further information from us to help fix this?
<spiv> brilliantnut: I don't think so at this stage
<brilliantnut> deepjoy and I have access on both the server and client... we could give you test credentials to our repository, if it would help.
<spiv> brilliantnut: I'll tell you the bug number in a moment, if you could subscribe to that in case we do need more information, that would be good.
<spiv> brilliantnut: bug #230550
<ubottu> Launchpad bug 230550 in bzr "bzr+http repeatedly queries the wrong location for BzrDir.find_repositoryV2" [Undecided,New] https://launchpad.net/bugs/230550
<spiv> brilliantnut: thanks very much for reporting this
<brilliantnut> spiv: subscribed.
<jam> spiv: is this fallout from your "post to the same URL" patch?
<jam> I think the client thinks it is doing
<jam> transport.clone('..')
<jam> but then it ends up posting to the same URL
<jam> spiv: just a guess, though
<jam> certainly RemoteBzrDir has been stupid about opening a containing repo for a long time
<jam> it has the RPC's to just open it directly, but it still does a VFS walk
<spiv> jam: it seems likely to be involved, yeah
<brilliantnut> spiv: one more thing, there is an inconsistency in the documentation section 10.4 (the part we were referring to). 10.4.1 (example) says /srv/example.com/www/code/, but the code snippets in section 10.4.3 have /srv/example.com/code (missing www)
<brilliantnut> also, the modpywsgi link is broken
<hersonls> I have a question, I can convert it into a project ï»¿svn to bzr?
<hersonls> I have a question, I can convert it a project ï»¿into ï»¿svn to bzr?
<Peng> hersonls: bzr-svn.
<hersonls> Peng: what is this?
<hersonls> Peng: bzr plugin?
<AfC> hersonls: one-way conversion (never to go back) is do-able and pretty easy.
<Peng> hersonls: Yes, it's a plugin.
<AfC> hersonls: on the other hand, if you need to _continue_ to interact with the old central Subversion repository, then that is also possible.
<AfC> hersonls: in both cases, the 'bzr-svn' plugin will help you do this.
<Peng> hersonls: http://bazaar-vcs.org/BzrForeignBranches/Subversion
<hersonls> :D
<AfC> hersonls: there are also other tools that can do the first
<hersonls> tanks
 * AfC wonders if svn2bzr is still maintained.
<Peng> AfC: Dunno. With bzr-svn, I don't really care.
<AfC> Peng: granted, but bzr-svn can be quite difficult to get to run. If all you're after is a never-look-back one-time conversion, then other tools are worth considering.
<Peng> True.
<bob2> abentley: be gets a shoutout in lwn this week
<Peng> bob2: Whowhat?
<abentley> bob2: wow.
<abentley> And I thought nobody cared.
<bob2> you were just like two years ahead of the world
<libwilliam> http://pastebin.com/m686a55f Now I am coming across a problem with trying to specify a directory of where to open a working tree from. Looking at the pastebin link I specify /home/will/bzrtest but no it tries to open the directory I am currently in /home/will/apps/svn/anjuta
<bob2> Peng: www.bugseverywhere.org
<abentley> Peng: be= Bugs Everywhere, a distributed bugtracker I wrote for use with Arch and Bazaar.
<Peng> Oh.
<Peng> Oh!
<Peng> I misread "be" as "he". As in "him".
<Peng> I really need to sleep.
<Peng> Congratulations. :)
<Peng> It has a domain name now too? Nifty.
<bob2> haha, with rcs support
 * Peng goes to bed.
<spiv> libwilliam: hmm, strange
<spiv> libwilliam: maybe an odd interaction with the fact that WorkingTree.open is a staticmethod?
<spiv> I wouldn't expect that to be the case.
<libwilliam> when I directly pass in "/home/will/bzrtest" into the method instead of converting to a py_string it correctly tries that directory but with the screwed up characters No such file: u'/home/will/bzrtest/\x01'
<spiv> Oh, right.
<spiv> The "s" format means a C string, not a PyObject
<spiv> (see "Parsing arguments and building values" in the Python/C API Reference Manual)
<libwilliam> alright I brought it up, thanks again
<poolie> hersonls: hello
<hersonls> poolie: hi
<hersonls> poolie: ï»¿ Bazaar is reflected in some other vcs to be build as is currently?
<poolie> i don't understand, can you restate the question?
<hersonls> yeah
<hersonls> sorry for my english
<hersonls> have any influence of another vcs, in the building bazaar?
<hersonls> poolie: you understand now?
<poolie> yes
<poolie> bzr takes ideas from several places: monotone, arch, baz, svn, git
<hersonls> poolie: bazaar have news?
<hersonls> ( reminding you these questions are for an article )
<poolie> oh i see
<poolie> hersonls: yes, see for example http://jam-bazaar.blogspot.com/2008/05/this-week-in-bazaar-first-edition.html
<bimberi> haha "Launchpad developer and wanted criminal"
<TFKyle> hmm, re: http://jam-bazaar.blogspot.com/2008/05/creating-new-launchpad-project-redux.html , are you supposed to use bazaar as the super-project for all plugins?
 * ig1 lunch
<poolie> igc, ig1, i approved your "for 1.5" patch; if you want me to read anything else in particular please let me know
<ig1> thanks poolie. The only tweak I want to do is to move Miscellaneous Topics ahead of the plugin tour.
<ig1> That will mean a minor rewording of the 'port 2' intro as well
<ig1> s/port/part/
<igc> poolie: I'd like your opinion on the Zen doc patch as well but it can wait if you're busy on other things
<poolie> i suspect people are keen for me to finish their raise recommendations :)
 * fullermd could use one while you're at it.
<igc> sure :-)
<fbond> Any ideas on this?
<fbond> bzr: ERROR: Must end write group before releasing write lock on KnitPackRepository
<fbond> Got that while pulling.
<jam> TFKyle: you certainly don't have to, I do it because then you can see them all as part of the project
 * igc pick up kids
<vila> spiv: yes, I've seen bug #230223, a bit short of time though, I agree with you that it may be related to error handling but I also suspect some bad interaction with connection sharing, also bug #229076 is weird, pycurl works while urllib got a connection reset so early I wonder why...
<ubottu> Launchpad bug 230223 in bzr "smart server probing in 1.4 breaks check outs of short bus http repositories [regression]" [High,Confirmed] https://launchpad.net/bugs/230223
<ubottu> Launchpad bug 229076 in bzr "'Connection reset by peer' error when branching repository" [Undecided,Confirmed] https://launchpad.net/bugs/229076
<spiv> vila: that is odd
<vila> spiv: pfew such a relief, I'm glad you share the feeling :-)
<spiv> vila: thanks for taking a look.  I was asking just in case you knew the answer instantly :)
<vila> spiv: I had a look a few days ago at #230223 and -Dhttp revealed that the POST failed for unclear reasons and then a new connection is issued 90 seconds later (sounds like sone timeout) which made me suspect some bad reuse of the connection, but I didn't have time to dig further
<vila> so my first reaction is to suspect some bad handling of the socket when POST errors, but I may be wrong
<vila> and again, I really really want to be able to apply some parts of the test suite against a real server, that's my #1 TODO since it will simplify a lot of other tasks (https for urllib, list_dir for webdav, just to name a few)
<vila> regarding #229076, a telnet session under wireshark gives only a few packets, but I'm not expert in diagnosing at that level and some help here will be very appreciated
 * gour is preparing to adopt bzr's terminology - {standalone,shared} branch, {shared} repository, checkout, tree etc. which, afaics, differs a bit from darcs' lingo
<AfC> I just blogged about my experience using Bazaar to import and then publish a mirror of GTK. Hopefully that will be of some interest in GNOME land.
<gour> url?
<gour> otoh, i don't know why, but i simply love/like bzr. git was never serious candidate and hg did not penetrate my mind when playing with it
<gour> ahh, found GTK post...
<poolie> gour: i'm glad you like it
* poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org/ |
<gour> poolie: i really does
* poolie changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.5rc1, May 9 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<gour> it looks svn-1.5 (containing reqs for bzr-svn) should be soon out?
<TFKyle> gour: seems like it, it's at -rc5 atm
<vila> poolie: now that the topic is up-to-date, do you have a few seconds to inspect a wireshark trace ? Like the one #229706 can produce ;-)
<gour> soon, we can try bzr-svn without patching
<gour> AfC: cool note at the end of your blog post ;)
<gour> hey, bzr viz is really cool!
<TFKyle> visualize++
<poolie> :)
 * TFKyle wonders if bzr isn't supposed to work with py 2.6/trunk or if it's just something with the gzip stuff on his windows machine
 * gour is sold. visualize will impress his windoze friends
<poolie> vila, sure, url?
<poolie> vila, really #229706 "gobuntu-desktop installation does not remove non-free software"?
<vila> #229076
<vila> grrr, damn typos !
<vila> back in ~30 mins, daughter to school time
<poolie> vila, happy to look at it
<poolie> maybe just attach it to that bug?
<gour> am i right in understanding that i'm supposed to do bzr branch 'repo', then create 'working copy, hack in there, pull to 'repo' to keep it update and then bzr merge 'cause, according to docs for pull, "This command only works if your local (destination) branch is either an older copy of the parent branch with no new commits of its own, or if the most recent commit in your local branch has been merged into the parent branch." while in
<gour> e.g. darcs i can select patches while pulling and resolve potential conflicts?
<jamesh> gour: if you have diverged from the branch you are pulling from, you need to merge
<gour> jamesh: right. darcs' can pull no matter of adding new stuff
<jamesh> gour: yep.  Darcs has a different model to Bazaar
<jamesh> gour: I guess you'd have to do something to resolve conflicts in Darcs if the two diverged branches changed the same sections of code though
<gour> true. it presents branch as set of patches...otoh, bazaar avoids with its model, some scalability problems
<gour> jamesh: sure...darcs will mark conflicts
<gour> but, afaiu, bzr does not allow to pull even if there are no conflicts, right?
<jamesh> gour: Bazaar is snapshot oriented rather than delta oriented
<jamesh> gour: provided the deltas can be applied on top of each other Darcs doesn't consider there to be a conflict
<gour> yes. it's just the other model, as in hg, but, somehow, hg did not appeal to me as much as bzr
<jamesh> gour: in contrast, combining the changes in Bazaar results in a new tree snapshot (and revision).
<jamesh> there are pros and cons to both systems
<gour> right, darcs allows fine cherrypicking, the other model is more robust & safe
<jamesh> a Bazaar revision represents a particular tree state, so you can do things like verify that a test suite passes before accepting a commit
<jamesh> in contrast, you can only make those sort of assertions in Darcs against the entire set of deltas in the branch
<gour> well, in darcs you can do that as well with --pre-hook switch while darcs record
<AfC> ... on the other hand, extracting small and/or unrelated changes out of the middle of a branch and applying them to another branch is something that Bazaar's current UI doesn't help very much with.
<AfC> ï»¿That's fine, except that I know that a number of us feel the desire to do this sort of thing quite frequently, and so hopefully someday Bazaar will evolve some capabilities to help smooth the way in such scenarios.
<jamesh> pulling one branch into another won't necessarily leave you with a tree with all the tests passing, even if both branches passed before hand
<jamesh> (not all conflicts are textual)
<jamesh> AfC: cherry picking has been on the todo list for a long time :()
<AfC> yeah well
<jamesh> that should have been :(
<gour> jamesh: if you tag then you know that all the patches before have to pass
<gour> and darcs record --pre-hook will do the right thing, check new patch(es) before commit
<jamesh> gour: well, a pull could insert patches into that existing sequence, right?
<AfC> gour: maybe it would help you if I were to point out that most of the people working on Bazaar are world class experts in the version control field; notably, most of them used Darcs at one point or another. You don't really need to explain what it does here.
<gour> ok
<gour> is improving speed the main concern of bzr-dev atm?
 * gour is reading user-guide
<vila> poolie: wireshark traces added to bug #229076 for a failing telnet session (7 packets) and a succeeding pycurl session (only the first 52 packets)
<ubottu> Launchpad bug 229076 in bzr "'Connection reset by peer' error when branching repository" [Undecided,Confirmed] https://launchpad.net/bugs/229076
<spiv> gour: I'd say it's the main one, yes.  That said, there's feature work happening too.
<spiv> Our speed is already good enough in lots of cases, though.  We're just trying to make sure it's good enough for even more cases :)
<fullermd> I was thinking about speed earlier today...
<spiv> vila: that is weird
<vila> spiv: trying to tie 'vila', 'odd' and 'weird' in your comments when fullermd is around is naughty...
<vila> :-)
<fullermd> vila isn't odd.  2 vowels, 2 consonants; that's an even number of evens, adding and summing to the same even.  Total non-odd.
<fullermd> Which is weird, when you think about it.
 * vila hopes google doesn't index IRC logs...
<vila> seriously, is anyone able to reproduce the telnet session ?
<gour> i'm  noticing some ambiguity while reading docs. any preferred pastebin i should use to write the details?
<vila> !paste
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<gour> ta
<fullermd> Speedwise:   * /src - Convert Time: ~6h20m, Git Repo Size: 495M (before repack 2.2G, repack time ~18hours), CVS Repo Size: 2.3G
 * fullermd is guessing a bzr conversion wouldn't even get a significant way through in 24 hours...
<poolie> vila, thanks
<jamesh> fullermd: don't most things add and sum to the same thing?
<fullermd> jamesh: Yes, but they don't multiply and sum, which is totally what I wrote if you disregard my fingers and go straight to my mind   :P
 * igc dinner
<gour> ok, here it is: http://paste.ubuntu.com/12203/ anyone can comment on it?
<uniscript> how do I set up a remote repository (well via mount) and then make the directory I am in be a lightweight bound checkout of that remote repo, without changing the files in this directory or creating a copy?
<uniscript> I can create the remote repo or branch
<uniscript> but what do I say in my tree of stuff to say: create me a .bzr dir here that contains info for a bound lightweight checkout of that remote branch over there?
<gour> i've another 'doc-bug' report, but let's hear the feedback on the first one 1st
<gour> ok, here is the other one if someone bothers to look at http://paste.ubuntu.com/12204/
<jamesh> uniscript: "bzr reconfigure" is probably what you're after
<jamesh> for the last bit
<uniscript> so bzr init, bzr bind, bzr reconfigure?
<uniscript> (in outline)
<uniscript> oh --bind-to
<uniscript> thanks
<AfC> I would have thought the bzr documentation would be in a bzr branch somewhere, but I can't find it off the cuff.
<fullermd> Most of it's in with bzr...
<AfC> Ah, of course.
<Jc2k> lo AfC
<AfC> Someone about to join who is attempting to get the GTK branch I blogged about today at http://research.operationaldynamics.com/blogs/andrew/#bzr-branch-of-gtk
<AfC> but is getting... ah, there he is :)
<Jc2k> john@cocacola:~/gnome/gtk+$ bzr branch http://www.gnome.org/~afcowie/bzr/gtk+/trunk
<Jc2k> bzr: ERROR: Connection error: while sending GET /%7Eafcowie/bzr/gtk%2B/trunk/.bzr/branch-format: (104, 'Connection reset by peer')
<AfC> I already asked what version he was using
<AfC> Ahem, please excuse me.
<Jc2k> :)
<AfC> I assume John to be a him, sorry
<Jc2k> you are correct ;)
<AfC> ... and he indicated trouble with bzr both 1.3.1 and 1.5rc1
<AfC> Let me try branching raw
<fullermd> Isn't that the thing vila was just looking at?
<Jc2k> whoops, its 1.3-1 (debian package version) not 1.3.1
<vila> yup, something is weird here, *server* log may help, from here it looks like the server just close the connection, so I'm a bit short of info to understand
<vila> especially when using pycurl (instead of the urllib based http client imlpementation) just works...
<james_w> vila: hi, you were looking at gnome.org in that bug report weren't you?
<AfC> I don't have access to the HTTP server logs, sorry
<vila> james_w: hi, see bug #229076 for details
<ubottu> Launchpad bug 229076 in bzr "'Connection reset by peer' error when branching repository" [Undecided,Confirmed] https://launchpad.net/bugs/229076
<AfC> (it's just a public_html directory in a user account on the server that GNOME hackers can use.
<AfC> Not a server I control)
<james_w> Jc2k: installing python-pycurl will probably get you moving.
<vila> AfC: and do you know someone who can look at those logs ?
<Jc2k> james_w: will try now
<fullermd> There's certainly something weird with the server.
<vila> AfC: and can you tell me me how you upload that branch ? Do you use pycurl ?
<fullermd> % ( echo 'GET / HTTP/1.0' ; echo 'host: www.gnome.org' ; echo ) | nc www.gnome.org 80
<AfC> vila: Yes, but that's a pretty bloody busy server, and the GNOME sys admin team is in over their heads today (as are most sysadmins on the planet)
<fullermd> just dumps me right back at the prompt (i.e., closed connection with no data passed back)
<AfC> vila: I uploaded with bzr+ssh
<vila> fullermd: thanks for confirming that
<fullermd> Presumably it's doing one of those weird "detect if the far end is a 'real' browser by random connection fingerprint stuff, else ignore" things that's all the rage.
<vila> AfC: Huh ? There is a smart server there ???
<vila> the POST command got a 404 when bzr probes for it...
 * AfC has a normal `bzr branch http://` running on his URL right now, and it's 2/5 inventory texts and 17 MB in
<AfC> vila: what are you talking about?
<vila> fullermd: how can it do that ? You can try again without the 'host' header and get the same behavior
 * Jc2k installed python-pycurl and its working \o/
<vila> Jc2k: ahpy for you :)
<AfC> vila: I would (on a normal day) have SSH access to that machine. So once I got Olav to install Bazaar on it, I just pushed a branch up there with bzr push bzr+ssh://...
<james_w> vila: it's got a smart server accessible over ssh, but it's not set up for bzr+http://
<Jc2k> should the package depend on python-pycurl?
<fullermd> vila: I don't recall offhand.  But it apparently can be done with some degree of accuracy, by details of the timing and packet structure and whatnot.  At least, as long as you only care about Mozilla/IE/Opera/etc.
<vila> james_w: ghaaa, of course
<vila> AfC: james_w is obviously right :)
<AfC> Jc2k: it would seem so. It's an optional "does something different at runtime if found" dependency.
<james_w> Jc2k: we would like to move away from pycurl, however there are two things to fix, one is the couple of bugs that have been found in the last week or so, and the other is doing something with SSL certificates.
<vila> fullermd: my my my, are we getting bitten because we are too slow between connectin and sending the GET ? I can hardly believe it >-/
<james_w> Jc2k: though there could be a dependency in the meantime.
<vila> fullermd: I thought about something like that but discarded it as too 4th-dimension-y
<vila> and why on earth would they want to do that ???
<fullermd> The theory is to avoid robots/scrapers/etc.
<fullermd> I don't know much about it; just seen some references in passing.
<vila> anyway, if that's the case, we need to at least check with them and try to find a solution
<fullermd> Can't coax anything out of google in a little trying.
<vila> does anybody knows one of those gnome sysdamins ?
<vila> AfC: I should have missed something but why all admins of the planet are so busy today ?
<james_w> vila: AfC does, but as he said they will be very busy today
<james_w> vila: http://www.ubuntu.com/usn/usn-612-1
<james_w> http://lists.debian.org/debian-security-announce/2008/msg00152.html
<vila> james_w: oh, that one, I think I applied the update a couple of days ago already
<AfC> vila: http://blog.drinsama.de/erich/en/linux/2008051401-consequences-of-sslssh-weakness.html and http://mail.gnome.org/archives/devel-announce-list/2008-May/msg00002.html
<AfC> Erich's blog post was excellent reading.
<vila> AfC: thanks, read both, I should check *when* I created my ssh keys, the good news is that I kept *all* of them under bzr ;-)
<vila> james_w: that includes keys uploaded to lp I presume, time to update them ?
<matkor> Hi ! gtk masters, 'Graph' object has no attribute 'iter_ancestry' is gtk related ?
<bob2> vila: they all got killed anyway
<matkor> its bzr 1.4.0 and olive -r 486 (tagged as 0.94.0) ?
<bob2> that sounds a lot more like a bzr thing than a gtk thing
<vila> bob2: the keys uploaded on lp ?
<james_w> vila: yes, though my DSA key was still there yesterday, so it might have been a selective deletion.
<james_w> matkor: yeah, I think that's a bzr thing.
<matkor> james_w, bob: Where are docs around graph: Graph(KnitParentsProvider(KnitVersionedFile(file:///home/users/matkor/.bzr/repository/revisions))) ?
<james_w> I'm not sure
<gour> when not using lockstep dev, checkouts are not required?
<james_w> http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.graph.Graph.html
<Ng> does bzr do clever things with its output? (where "clever" is some magic I can't clearly define)
<james_w> gour: yes, if you're not doing lockstep then checkouts are not what you want
<Ng> on hardy, doing "bzr diff | pastebinit" doesn't work
<Ng> but something like "echo foo | pastebinit" does
<matkor> james_w: Thank you very much
<james_w> gour: though you can use commit --local, but I'd recommend using a branch
<james_w> hi Ng
<Ng> hey :)
<james_w> "doesn't work"?
<Ng> pastebinit gives an error which its author tells me means it didn't receive any input
<james_w> wow, yeah
<gour> james_w: thanks
<james_w> Ng: bzr diff exits with 0 when piped to pastebinit, so it's not looking for the changes correctly, and I guess outputting nothing to match the "no changes" status
<lifeless> 'sup
<james_w> hi lifeless
<poolie> hello lifeless
<poolie> just leaving now
<poolie> night all
<james_w> hi poolie
<james_w> good night
<poolie> enjoy Prague
<james_w> thanks.
<poolie> I hear it's Pragmatic :)
<poolie> badabing
<james_w> boo
<gour> are there any 'Cons' in using shared repos?
<intellectronica> hi, i'm suffering from some kind of strange corruption pushing a branch
<intellectronica> when i look at the pushed branch, only the last few revision seem to be there
<Ng> james_w: I get this whether there are changes or not, but even 'echo "" | pastebinit' works. I guess I'm wondering if bzr should notice that stdout isn't a terminal and just send text, but I'm guessing wildly ;)
<intellectronica> and one i try to branch from it, i get the error NotLefthandHistory: Supplied history does not follow left-hand parents
<james_w> Ng: yeah, but "bzr diff | cat" works
<lifeless> it reminds me of dunedin
<lifeless> Ng: utf8 is text :P
<Ng> james_w: sure, and | less. so is the conclusion here that pastebinit is broken somehow?
<lifeless> that would be my first guess
<james_w> intellectronica: that is strange. You should only get the branch error message on push.
<james_w> intellectronica: is this a public branch?
<Ng> although at some point, bzr merge --preview failed to work with |less, so I'm not entirely convinced you guys aren't to blame somehow ;)
<intellectronica> james_w: it isn't, srry
<lifeless> ess
<james_w> Ng: could be, I don't know if it does anything funny with stdin.
<lifeless> intellectronica: there was a bug
<lifeless> intellectronica: use an older, or newer bzr and it should go away
<intellectronica> lifeless:  older than 1.5rc1, you mean?
<intellectronica> there is no newer packaged version, afaik
<james_w> Ng: pastebinit is at least a little broken
<james_w> Ng: "list index out of range"
<Ng> yeah, a quick read of the code for stdin suggests it calls .read() on stdin twice
<james_w> content=l_r[0][0].read()
<Ng> quite why that works with some stuff and not with others, I don't know, but is seems like a highly suspect thing to do, to me
<Ng> hmm, maybe not
 * Ng shrugs, I'm not going to start debugging this right now ;)
<james_w> "When the time-out is reached without a file descriptor becoming ready, three empty lists are returned. "
<james_w> so something bzr is doing means that pastebinit's stdin is not ready
<james_w> (sleep 2; echo a) | pastebinit
<intellectronica> lifeless: no, downgrading to 1.3.1 doesn't seem to help
<lifeless> interewsting
<lifeless> it may be something else I guess
<lifeless> I'm a little shell shocked - just ogt off th eplane
<intellectronica> i have 6277 revisions locally, but when i push i get only the last 167 branches
<intellectronica> lifeless: ah, are you doing the prague thing?
<Ng> james_w: ooh, good catch
<lifeless> yes
<intellectronica> cool
<james_w> Anyone know a better way to know if stdin is going to have data for you than "select.select([sys.stdin],[],[],0)" ?
<lifeless> if you're non blocking, no - other than to say 'use twistd ffs'
<mwhudson> james_w: the FIONREAD ioctl?
<james_w> I guess what it should do is first look for filename arguments, rather than looking for stdin
<james_w> that would allow you to run "pastebinit" and type what you want. It does have the same problem as "patch patch_filename" though.
<james_w> Ng: bug 230649 if you care enough to subscribe.
<ubottu> Launchpad bug 230649 in pastebinit "Fails to read from stdin if the process producing data is slow to start" [Undecided,New] https://launchpad.net/bugs/230649
<lifeless> I'm not sure why it wants to be nonblocking anyway
<Ng> james_w: cool thanks :)
<matkor> Who is now responsible for merging bugfixes for olive-gtk ? Jelmer Vernooij  ? Szilveszter Farkas ? I have one pretty straightforward typo fix in https://code.launchpad.net/~matkor/bzr-gtk/trunk-matkor ...
<jelmer> matkor: sorry, I don't have time at the moment. please send a merge request to the bzr-gtk mailing list
<matkor> Should I mark somehow that I am killing given bug (https://bugs.launchpad.net/bzr-gtk/+bug/218406) during commit ?
<ubottu> Launchpad bug 218406 in bzr-gtk "olive-gtk.desktop lists incorrect categories" [Undecided,New]
<lifeless> matkor: --fixes
<lifeless> matkor:  -- fixes
<lifeless> meh, sorry - latency
<james_w> matkor: "bzr commit --fixes lp:218406" to be exact
<matkor> ok thanks
<matkor> james_w, lifeless: Is launchpad such smart, so when my revision with --fixes will get merged into mainline, descriptions on https://bugs.launchpad.net/bzr-gtk/+bug/218406 will get updated :) ?
<ubottu> Launchpad bug 218406 in bzr-gtk "olive-gtk.desktop lists incorrect categories" [Undecided,New]
<james_w> matkor: no, it's not that smart yet.
<sidnei> jelmer: hi there?
<jelmer> hi sidnei
<sidnei> jelmer: trying to get bzr-svn going on osx, using python-svn from macports
<sidnei> jelmer: is that 'metze' patch the only one required?
<jelmer> sidnei: yes, but you may want the other one as well since it fixes some memory leaks
<sidnei> jelmer: odd, after applying the patch it is still complaining that the version isn't good enough
<sidnei> jelmer: this is subversion 1.4.6
<jelmer> sidnei: one of the common problems is that SWIG has to be forced to rerun
<sidnei> jelmer: ah. that might be it then
<matkor> How are release files ( *.tgz ) generated ? Is it done from bzr ?
<matkor> bzr export ?
<lifeless> bzr export can do that yes
<igc> hi lifeless - hope you had a good trip
<lifeless> mixed as these things are
<lifeless> I'm sneezing constantly at the moment :(
<igc> gour: thanks for the doc feedback. Please raise bugs in LP for things you'd like improved and tag them as 'documentation'.
<igc> lifeless: :-(
<igc> travel sucks - seeing other places in neat though
<igc> s/in/is/
<spiv> Interesting snippet on git not quite satisfying the kernel devs: http://kerneltrap.org/mailarchive/linux-kernel/2008/5/14/1815584
<fbond> Any ideas on this?
<fbond> bzr: ERROR: Must end write group before releasing write lock on KnitPackRepository
<fbond> Got that while pulling.
<spiv> fbond: that sounds like a bzr bug
<spiv> fbond: which bzr version?
<lifeless> spiv: I would guess a network error or something triggering that
<fbond> spiv: sorry, one sec; took a phone call and I have to fire up my laptop to get the version.
<spiv> lifeless: any tips for diagnosing the trigger?  I'm about to go to bed.
<spiv> (for fbond's issue)
<lifeless> well, I would guess exception Ai s being raised and not being caught, triggering unllock()
<lifeless> the backtrace in ~/.bzr.log will confirm/deny that the lock decorator is triggering this
<lifeless> I *think* it logs the original exception in that case too
<spiv> lifeless: oh, so it's similar to the TooManyConcurrentRequests error?
<lifeless> yes
<spiv> I know in the TooManyConcurrentRequests case, the original error is just completely discarded :(
<lifeless> something somewhere failing to cleanup properly; and the usual cause for that is hard to reproduce locall things e.g. network
 * spiv nods
<spiv> Someone (possibly me) should write tests for the improved lock decorators I have in the branch on https://bugs.edge.launchpad.net/bzr/+bug/125784
<ubottu> Launchpad bug 125784 in bzr "TooManyConcurrentRequests when using smart server over ssh" [High,Confirmed]
<fbond> spiv: bzr 1.3.1
<fbond> pulling from same via bzr+ssh
<spiv> ISTR to poolie was going to do that at some point, but I guess it never happened.
<fbond> spiv: Can I do something to generate a useful log file?
<spiv> Unfortunately this cold/flu I'm recovering from is wiping me out, so I definitely need to go to bed.
<lifeless> spiv: I hope I haven't een incubating on the plane
<fbond> spiv: Okay, feel better.
<spiv> fbond: "bzr --version" will tell you where you log file is.  You could try "bzr -Dhpss ..." if you're using bzr+ssh, which might give a very indirect indication of where the problem is.
<fbond> I'll be back later with a log file.
<jelmer> james_w: where does the master branch of bzr-builddeb live these days?
<james_w> jelmer: it's on launchpad at the moment, as I was having problems with alioth a while back, let me grab the location
<james_w> https://code.launchpad.net/~james-w/bzr-builddeb/trunk
<jelmer> thanks
<gour> igc: thank you for review. i'll do it
<james_w> jelmer: hi, are you still around?
<jelmer> james_w, yep
<james_w> jelmer: cool, can I ask a favour?
<jelmer> james_w: depending on what it is, sure :-)
<james_w> I'm trying to clean up the branches for builddeb, would you do a couple of things on lp for me, as I don't have permission?
<james_w> https://code.edge.launchpad.net/~jelmer/bzr-builddeb/trunk
<james_w> can you either change the ownership to ~bzr-builddeb-hackers, or delete it if it's not possible.
<james_w> Ah, it's a mirrored branch, that should not be needed.
<jelmer> Looks like I can only change the ownership to teams I'm in
<james_w> you could join :-)
<james_w> https://code.edge.launchpad.net/~jelmer/bzr-builddeb/jelmer <- that could be marked merged
<jelmer> just attempted to do so :-) Still needs approval
<james_w> thanks
<james_w> I'll merge your patch once I've cleaned up a bit, sorry I didn't get to it before.
<jelmer> I've changed the ownership of the mirrorred branch
<jelmer> james_w: thanks
<james_w> the patch you sent is pretty large, did you use an old parent branch when creating it?
<jelmer> ah, ouch - yes, it's using the wrong submit branch
<jelmer> I'll resend
<james_w> is https://code.edge.launchpad.net/~jelmer/bzr-builddeb/452130 the same code?
<james_w> I can just merge from there if it is.
<jelmer> that's the old one, which will cause conflicts when merging
<jelmer> james_w, sent
<james_w> thanks
<gour> igc: where can i tag bug report as documentation?
<gour> there is bzr-book, but i'm not sure it's the right one
<james_w> gour: with an actual tag
<james_w> "Edit Description/Tags" in the top left box.
<igc> gour: as james_w says
<james_w> hi igc
<igc> hi james_w
<gour> this comes AFTER submitting bug?
<igc> yes
<gour> ok
<gour> the tag 'documentation' hasn't yet been used by Bazaar before ?
<gour> should i create a new one?
<lifeless> no
<gour> :-/
 * gour is confused
<lifeless> if you look at the current tags
<james_w> gour: "doc" is what we use apparently.
<lifeless> you can see that there is a tag doc
<gour> lifeless: somehow i do not see list of tags
<lifeless> on the left hand side there is probably a collapsed area
<gour> it isn't...ok, i tagged as 'doc'
<james_w> they're shown on https://bugs.launchpad.net/bzr/
<lifeless> interesting tags on this bug : https://bugs.edge.launchpad.net/bzr/+bug/209046
<ubottu> Launchpad bug 209046 in bzr "Crash when comitting with non-English description" [Undecided,New]
<lifeless> please don't fix, I'm going to show the lp ui guys
<gour> done, https://bugs.launchpad.net/bzr/+bug/230734
<ubottu> Launchpad bug 230734 in bzr "make some terms in documentation more clear" [Undecided,New]
<gour> btw, who is keeping the track about the numbers of bzr users?
<gour> james_w: it would be nice that the list is at hand when filling the bug report
<james_w> gour: yeah, at least when adding tags.
<lifeless> indeed
<lifeless> gour: I think we have a bug open about tag suggestion
<jelmer> hmm, bzrlib.config is a mess.. What's the difference between get_value(), get_option() and get_user_option() ?
<jelmer> or maybe I'm missing the big picture here somewhere
<lifeless> woo
<lifeless> I have verieonedfiles with annotate()
<lifeless> and all that shitt
<jelmer> w00t
<james_w> woo
<lifeless> now to add it to repository and deprecate KnitVersionedFile
<lifeless> jelmer: I'm in prague
<jelmer> lifeless, ahh
<james_w> would it be cruel to put lifeless on a plane half the way around the world whenever there's a big job to be done?
<lifeless> james_w: I thought that that was what happened already?
<james_w> heh
<lifeless> james_w: are ou here for fosscamp?
<james_w> lifeless: no, just UDS, I arrive on Sunday.
<igc> go lifeless go
<igc> (sounds better than go speed-racer go)
<igc> must be time for sleep
<jelmer> igc: You're in .eu as well then I guess ? :-)
<igc> night all
<igc> nope - here in Brisbane
<jelmer> apparently not :-) g'night Ian
<igc> night
<gour> night
<statik> is there a way to prune all but the last month of history from a branch?
<james_w> statik: short answer, no.
<james_w> medium answer, it's something that we would want to support somewhat at some point.
<statik> james_w: i like short answers :) thanks, guess i'll need to wait for history horizons then
<james_w> long answer, I think you can do it now, but it would be a bit dirty.
<james_w> statik: yep, that would be the best solution.
<james_w> thanks jelmer, all merged up. I made +svn work as well. I'm working towards releasing a new package today.
<jelmer> james_w: cool, thanks!
<james_w> jelmer: did you see that bzr-dbus is causing deprecation warnings with 1.5?
<jelmer> james_w: yeah
<jelmer> james_w: I was hoping upstream would merge the fix for that first though
<jelmer> then again, merging it first shouldn't cause any problems..
<james_w> ah, I thought I had seen you propose a fix, but I just looked at the code and it wasn't changed, so I thought I was imagining it.
<gour> hmm, svn-1.5 is expected in 1st week of June
<james_w> ah wow, that will be interesting.
<pickscrape> The glacial rate of svn development depresses me
<pickscrape> Then again, it's quicker than svk's current rate of development
<gour> nice news for bzr-svn
<rockstar> +1 gour
<radix> is that the one where they added merge tracking?
<james_w> dato: nice catch, I'll fix that in a moment, thanks.
<jelmer> rockstar, yes
<jelmer> sorry
<jelmer> radix, yes
<james_w> thanks jelmer
<radix> interesting
<ricardokirkner> hi. I am having some issues trying to set up bzr+http on my apache. I think I have the apache config finally ok, but I am getting errors when committing. I get bzr: ERROR: No repository present: "bzr+http://...
<ricardokirkner> I cannot find out where it is failing.. any hints?
<james_w> ricardokirkner: have you looked in ~/.bzr.log ?
<james_w> "-Dhttp -Dhpss -Dtransport" as options to bzr will print more information there about what it is doing.
<dennda> Is there something that helps me push to several locations without always entering the location again?
<ricardokirkner> james_w, that should appear in my log? or are those options I should use when calling bzr?
<james_w> dennda: there is a "bookmarks" plugin that allows you to shorted the URLS
<james_w> dennda: or you want to push to several locations at the same time?
<dennda> james_w: both sounds interesting
<dennda> james_w: but I think bookmarks is what I was asking for
<james_w> ricardokirkner: they are global options to bzr, so "bzr -Dhttp -Dhpss -Dtransport commit"
<dennda> what's the name of the plugin?
<ricardokirkner> I'll try that...
<james_w> dennda: good, because I don't know of a way to push to multiple locations :-)
<james_w> dennda: bzr-bookmarks.
<james_w> dennda: https://edge.launchpad.net/bzr-bookmarks/
<dennda> hm.. is there any documentation on how to use it?
<pickscrape> What's the best transport for a central server with flexible permission options (i.e. write access for different groups for different branches)?
<pickscrape> I'm currently playing with bzr+ssh, but wonder if some other might be faster/more flexible
<awilkins> Probably sftp or bzr+ssh
<pickscrape> Presumably sftp wouldn't take advantage of the smart server?
<awilkins> pickscrape: Nope. It's probably the quickest for initial checkouts though
<ricardokirkner> james_w, using bzr+http I get NoRepositoryFound, but when using http alone I get IncompatibleRepositories: Repository KnitPackRepository(...) is not compatible with repository KnitPackRepository(...)
<james_w> dennda: I don't know, sorry.
<james_w> ricardokirkner: is there anything useful in the log file?
<dennda> thanks james_w
<jelmer> ricardokirkner: Are you trying to branch into a repository?
<ricardokirkner> james_w, I created a repo in my server, then I did a checkout to another machine. in that host I did a change and commited.
<ricardokirkner> the repo on the server is in rich-root-pack format (because it was migrated from svn)
<jelmer> ricardokirkner, but what repository are you trying to copy into locally?
<jelmer> that should be a rich-root-pack repository as well
<ricardokirkner> well, I didn't explicitely create a repo locally, but just did a checkout, and the checkout format is rich-root-pack
<ricardokirkner> actually, in the log file I get <RepositoryFormatKnitPack4> for both locations
<ricardokirkner> aparently, the last thing tried was a Branch.unlock operation
<ricardokirkner> but just before the traceback I get a result 'ok' response
<pickscrape> Is there any expectation that the smart server will become a useful standalone server in the centralised sense (e.g. akin to svnserve)?
<ricardokirkner> james_w, if you want I can paste the log
<james_w> ricardokirkner: that would probably help
<james_w> pickscrape: what do you need that it doesn't do?
<pickscrape> e.g. user authentication, init.d scripts to start it up (could be a distro thing)
<pickscrape> Just thinking that it might have less of an overhead than going through ssh and starting up bzr every time.
<james_w> well it's started on demand
<james_w> authentication has been discussed, but there are no immediate plans for it.
<pickscrape> I understand that what I'm after is very much for a centralised workflow.
<james_w> there's a reticence to get involved in authentication, as it's problematic. We'd rather leave it to existing, tested technologies, at least for now.
<pickscrape> Understood.
<jelmer> dato/james_w: any chance you can upload bzr-email ? It hasn't had any uploads with DM-Upload-Allowed yet
<ricardokirkner> james_w, http://paste.ubuntu.com/12258/
<james_w> jelmer: you're uploads that have the wrong size for the orig.tar.gz, are they caused by builddeb as well?
<james_w> your uploads, sorry.
<james_w> jelmer: I wish I could, but I ain't no DD.
<jelmer> james_w: Yes, those are also caused by the timestamp in the tarball being incorrect
<james_w> ah, it changes the size, ok.
<james_w> I was just thinking of writing the patch to bzr to allow me to fix that.
<jelmer> james_w: A fix for that bug would be really nice
<james_w> ricardokirkner: can you provide the output of "bzr info" in the branch and "bzr info sftp://path/on/server/" please?
<ricardokirkner> james_w, http://paste.ubuntu.com/12263/
<ricardokirkner> sorry.. that entry has a typo
<ricardokirkner> no, my mistake, its correct
<james_w> ricardokirkner: so, it looks like it's done the commit, and then fails when fetching the revisions back to the local repository.
<james_w> does it fail if you bind to a bzr+ssh:// URL to the same branch?
<ricardokirkner> james_w, bzr+ssh: works fine
<james_w> sounds like a bug then, if you do "bzr init-repo --rich-root-pack test && cd test && bzr branch http://whatever" do you get the same error?
<ricardokirkner> james_w, I created the repo, did a branch, could commit (because it was a branch), but when pushing to the server, I get the same error
<james_w> ricardokirkner: sounds like a bug to me
<ricardokirkner> mhh.. ok, thank you very much for your help.... i will have to look for another option then
<ricardokirkner> until I manage to get spare time to hunt the bug
<ricardokirkner> james_w, what would you recommend me to do to setup authentication for a central server setup, so that I need to have a user in order to commit to the central branch?
<james_w> ricardokirkner: are you happy to give out ssh accounts?
<ricardokirkner> james_w, well, I know that possibility, what I didn't want to do that
<demod> ricardokirkner: there is also the possibility of using the http wsgi smart server (which leaves authentication and encryption to htaccess and https), however, last time i tried it it didn't exactly work out (but that might have been a misconfiguration on my side, since i haven't used it before)
<ricardokirkner> demod, I was trying that too, but it wasn't working either ... probably because of a configuration issue too
<demod> ;)
<james_w> ricardokirkner: there is a webdav plugin as well.
<demod> james_w: i thought that one isn't working anymore since bzr 1.0 or so
<ricardokirkner> yes, but it states that it doesn't work with bzr > 1.0  (although I haven't tried it to confirm this)
<vila> james_w: Did you summon me by my webdav name ?
<james_w> vila: do you have it on highlight, or are you just tuned to it?
<vila> The webdav plugin lacks list_dir, it's on my TODO list, but I can give delays...
<james_w> ah yeah, I remember now.
<vila> james_w: just passing around :)
<james_w> ricardokirkner: if you can file that bug then it may be fixed for the 1.6 release this month, but I don't know where to start looking yet.
<james_w> vila: how is your kitchen?
<ricardokirkner> james_w, I'll try to file a bug now, thank you
<vila> hehe, we still need to finish.... I don't know the name in english, what you put on walls in kitchen or bathrooms and is not paint
<ricardokirkner> james_w, the strange thing is I tried to do the same thing using a pristine repo that was created exclusively using bzr (with the default repo format), and I keep getting the same issue
<radix> wallpaper?
<radix> paneling?
<radix> tiles?
<demod> tiles
<james_w> food?
<vila> radix: :) Not wallpaper, may be tiles, it generally comes in 10x10 to 30x30 centimeters, can be white or colored
<james_w> ricardokirkner: yeah, you're investigations seem to indicate that the http remote implementation is messing up the calculation of compatible formats.
<vila> james_w: lol
<demod> vila: http://www.atelierkk.nl/images/la%20fontaine/la-fontain-bruin.jpg like those? ,)
<ricardokirkner> james_w, thank you for formulating the problem so nicely :-), now I can file the bug :-p
<vila> demod: yup ! :)
<demod> vila: images.google.com be praised ,)
<vila> demod: hoooo, cheater ;-)
<demod> vila: you don't want any drawing from me; neither with gimp or otherwise ,)
<vila> demod: Ok, I'll try to remember that :) How about pictures for bzr data model ?
<gour> james_w: 1.6. is coming this month?
<james_w> gour: ah, no, some days slipped by without me noticing
<demod> vila: give me some handdrawn template and i might consider it ,)
<james_w> make it "within the month".
<gour> james_w: :-)
<vila> demod: hehe. Not me, ask hard-core bzr devs ;-)
<demod> vila: I'd rather not, someone might actually take the offer and i'm supposed to get some assignments done ,)
<vila> demod: too bad, I'd like to do it my self, but lack the time, I thought I found a valiant volunteer ;)
<demod> sorry ,)
 * gour is reading bzr manual
<gour> this sounds interesting: '...it can be really hard to "unlearn" the please-let-me-avoid-merging-at-any-cost habit.'
<gour> does bzr extmerge works with emacs' ediff?
<pickscrape> Not that I can see at the moment
<b0ef> if I do a checkout from foo to bar, then remove foo and put another repository there, named foo and try to update bar, why is that possible?
<b0ef> is there no check that foo is the repository you did the initial checkout from?
<demod> b0ef: i get an error message when trying to bzr merge them (bzr 1.5rc1)
<vila> gour: what do you mean by 'bzr extmerge with emacs' ?
<pickscrape> I presumed he was referring to the extmerge plugin.
<vila> you can use M-x shell-command-on-region RET bzr merge --preview
<b0ef> demod: you tried this?
<vila> or M-x shell-command-on-region RET bzr diff
<demod> b0ef: yes
<pickscrape> extmerge is for dealing with conflicts
<vila> also, opening files with conflicts triggers the smerge mode
<gour> vila: right, i think about extmerge plugin
<b0ef> demod: so this is a clear bug that it doesn't check that it's the same repository, then?
<vila> and there is the excellent DVC emacs package
<gour> i still did not try DVC in emacs...so far used darcssum.el
<vila> gour: synchronicity :)
<demod> b0ef: "bzr pull" says that the branches have diverged and that i got to merge them but "bzr merge" notices that they don't share any ancestors
<gour> yeah, another good point to use bzr
<vila> gour: try it !
<gour> vila: will do for sure ;)
<demod> b0ef: well, a tiny one ,)
<vila> I run dvc-status and dvc-diff hourly if not minutely
<b0ef> demod: well, if you keep changing foo and keep updating your initial checkout you will have a shitload of "pending merges" in your checkout directory
<b0ef> this must be a bug
<gour> vila: still reading user-guide, 5th chapter
<kdawkins> hey guys... am in the right place to ask for some bzr help?
<vila> gour: DVC has a user guide ? Updated and not mentioning tla ?
<vila> or xtla (can't remember who DVC is the son of ;)
<gour> vila: no, bzr's user-guide. but there is, afaik, DVC manual as well
<james_w> kdawkins: couldn't be in a better place :-)
<kdawkins> right on...
<vila> gour: ha, ok
<demod> b0ef: hm, i actually don't have a clue how/if pending merges are handled, you might have a point there
<kdawkins> i am new to bzr... svn user, struggling with bzr's distributed model
<kdawkins> my colleague has a branch, let's call it jonny-fixing-x
<gour> kdawkins: you mean, enjoying distributed model ;)
<kdawkins> to review his code, i do bzr branch ....url/jonny-fixing-x
<kdawkins> gour: hah yeah
<kdawkins> and i get a new dir jonny-fixing-x in my filesystem
<kdawkins> so far so good.
<kdawkins> i find a problem with it
<kdawkins> and fix it
<kdawkins> how do i commit it back to the server for him to review?
<james_w> kdawkins: keep asking your question, but I'll just mention http://bazaar-vcs.org/BzrForSVNUsers in case you haven't found it yet
<james_w> kdawkins: there are a few options, you could ask him to pull from you to review it.
<james_w> you could use "bzr send" to email him the changes for him to review and then possibly apply (or generate a text file you can give to him by any other means)
<kdawkins> he's not online though, and i want to keep working on his code
<kdawkins> ideally, he'd merge it into trunk since it's been reviewed and i'd branch off that and keep going, no?
<gour> what is usual lingo used in bzr for 'trunk', i.e. how to name it?
<james_w> can you merge it to trunk, or does he have to review it first?
<kdawkins> he has to review, i think
<kdawkins> so i can't merge because there's a shitload of changes on his branch
<kdawkins> can i create my own branch from his?
<james_w> gour: "trunk" is the most common one, sometimes people say "HEAD" to mean the tip of a particular branch, trunk if not specified.
<kdawkins> and work on that?
<james_w> that's what you did with "branch ...url/jonny-fixing-x" at the start.
<james_w> you get a separate branch, and you can work and commit however you like on that without affecting him at all.
<kdawkins> ok
<kdawkins> that's very unclear from the docs.
<kdawkins> it says "to get a named branch, do bzr branch foo"
<kdawkins> i took that to mean "to get jonny's branch"
<kdawkins> not "to make my own branch from foo"
<kdawkins> fair enough
<kdawkins> ok, so i can hack away all i want
<james_w> yeah, it's the latter, if you can suggest a better way of explaining it we would be happy to fix it.
<gour> james_w: is the 'trunk' (or main branch) used in real repos as well (as it is common in svn)?
<kdawkins> i think the "get a branch" bit is confusing... maybe "to make a new branch ..." instead
<james_w> "get your own copy of the branch"?
<james_w> "make a new branch based on..."?
<kdawkins> but then that sounds like it's not a new branch
 * gour submitted today a bug (launchpad) to clarify some terminology as well
<kdawkins> yeah the latter
<demod> I always liked the "clone" alias... ,)
<pickscrape> "get your own branch of the branch"
<kdawkins> that is perfect
<james_w> gour: I'm not sure I understand your question, could you explain it please?
<james_w> kdawkins: which one?
<kdawkins> "make a  new branch based on..."
<kdawkins> thx a ton for the help!
<james_w> great, I'll add it to gours bug, it's easier to roll these doc changes up.
<james_w> kdawkins: thanks you, it's always good to improve the documentation. If you have any more questions please ask.
<kdawkins> ohhhh i will :)
<gour> james_w: does people use the folder name 'trunk' to name 'HEAD' in their bzr repos? i'm aware the 'trunk' is same as 'HEAD', but i'm curious what is the bzr-way to name it, not to call it
<james_w> ah, "trunk" is common yes
<james_w> bzr is bzr.dev
<james_w> so several projects copy that.
<gour> thanks
<james_w> ah, just missed him, his patch is submitted.
<Jc2k> *
<gour> bzr send help says that merge directive provides: An _optional_ patch that is a preview of the changes requested
<gour> what does it mean 'optional' ?
<pickscrape> I think it means it is possible to exclude it, which threw me a bit too.
<gour> hmm, having patch is nice if one has to send to non-bzr user...
<pickscrape> --no-patch excludes the patch
<pickscrape> For me, 'optional' usually means you don't get it by default.
<gour> and what provides --no-bundle then?
<pickscrape> I'm not sure what you mean
<gour> ahh, --no-bundle means one has to retrieve separately
<pickscrape> By default you get both (bear in mind I'm new to this too) :)
<gour> i wonder how one get _patch_ only if required to send to non-bzr party?
<pickscrape> --no-bundle
<pickscrape> The patch is great even if the recipient is using bzr though, especially if he's running Thunderbird with the Colored Diffs plugin.
<gour> ok. will try it tomorrow..now i discovered there is no Gnus listed as mail client :-/
 * gour finished readng 6th ch. of user-guide...now best practices
<pickscrape> No idea about anything Emacs-related I'm afraid...
<gour> probably some devs use emacs/gnus
<gour> otoh, i wonder why bzr is not more widely adopted..
<pickscrape> Total speculation, but I believe performance held it up in the early days.
<gour> i find it is superb...very nicely crafted
<pickscrape> Again, I'm new here, so there could be any number of other reasons
<pickscrape> For me it's like choosing Postgres over MySQL.
<gour> what's the use of e.g git with such complex model...one has to think more about the tool than the work to be done
<pickscrape> Design properly first, then optimise.
<gour> right
<gour> premature optimization is root of...
<gour> :-)
<pickscrape> And now we see benchmarks showing Postgres to scale much better than MySQL.
<pickscrape> I also like the regular release schedule
<pickscrape> Though the 'harmony' of the PPA archive is currently a bit worrysome. I'm hoping that will improve though soon.
<gour> huh, i was really not aware (until few days ago) that bzr releases so regularly
<pickscrape> Yeah, about once a month I think.
 * gour uses archlinux and soon will move to nixos
<fbond> bzr-svn segfaults in push
<fbond> I'm using bzr 1.3.1, bzr-svn 0.4.9 from PPA...
<fbond> Any ideas?
<jelmer> fbond, please file a bug report with a gdb backtrace
<fbond> jelmer: Okay, will do.
<fbond> jelmer: I'm installing python-subversion-dbgsym, libsvn1-dbgsym.  That should be all, right?
<jelmer> yes, I think so
<vila> gour: no need for a Gnus mail client, just add 'mail_client = emacsclient' in ~/.bazaar/bazaar.conf and add (server-start) to your ~/.gnus
<fbond> https://bugs.launchpad.net/bzr-svn/+bug/230853
<ubottu> Launchpad bug 230853 in bzr-svn "segfault while push" [Undecided,New]
<jelmer> fbond, what version bzr/bzr-svn ?
<fbond> I'm using bzr 1.3.1, bzr-svn 0.4.9 from PPA...
<jelmer> ah, right. Any chance you can try with 0.4.10 ?
<fbond> Will that work with 1.3.1?
<clsk> does bazaar suport keywords like svn's $Id$ ?
<jelmer> no, only >= 1.4
<fbond> jelmer: Okay, I guess I can upgrade to 1.5rc1
<fbond> That is in the PPA.
<vila> cslk: igc has a related work in progress
<brettcannon> I was hoping someone here could help me figure out what the best practice would be for handling multiple developers needing to push to a master branch online.
<brettcannon> Anyone up for trying to help me?
<Peng> Python?
<brettcannon> Yeah, it was a situation that came up while we were working on something for Python.
<brettcannon> Basically what happened is I branched off our trunk locally to work on something.
<brettcannon> People then said they wanted to chip in, so I pushed my branch up to my users space on code.python.org.
<brettcannon> I was committing locally, people were doing their thing, but then it came to do merges from my pushed branch (based on what other people had done) and merging from the trunk.
<brettcannon> It was not clear to me exactly how to handle pulling changes people pushed to my public branch and from the trunk.
<brettcannon> Someone had me to a bind to my public branch, but that made my commits get pushed immediately, which I don't want because it locked the branch down for so long that it held up other developers.
<brettcannon> So, my question is how can I do commits locally, occasionally merge from the trunk (which is what I originally branched off of), merge from my branch that I pushed publicly, and all the while still commit locally and occasionally push to my public branch?
<clsk> bzr commit --local
<fbond> jelmer: same thing with 0.4.10
<jelmer> hmm
<Peng> brettcannon: bzr unbind?
<clsk> if you've already binded
<brettcannon> clsk: Well, I want to know what to do in the future (the branch is dead at this point).
<james_w> brettcannon: use "bzr merge" to integrate the changes locally and then push them back out?
<clsk> what do you mean by dead?
<brettcannon> james_w: Right, but ``bzr merge`` pulled from the trunk since I branched from that. What about the changes pushed to the public copy of my branch?
<james_w> brettcannon: bzr merge URL
<brettcannon> clsk: It is no longer being developed on. The issue we created for is finished. I just want to know what to do the next time this situation comes up with a new branch.
<brettcannon> james_w: I have to specify the URL every time? There isn't some way for bzr to know that I pushed the branch somewhere and so I want to pull from it on occasion?
<james_w> it currently only remembers one merge location
<jelmer> fbond, I've reassigned it to python-subversion
<james_w> you can use a "bookmarks" plugin to shorten the URLs, but you still have to provide one.
<brettcannon> james_w: Damn, I was afraid of that.
<radix> brettcannon: you can have "bzr merge" work with one remembered URL.
<james_w> if someone can provide a good UI for having multiple merge locations then it may implemented, but I haven't seen a suggestion yet.
<radix> brettcannon: If you want to change the remembered URL, use "bzr merge --remember URL", and it'll merge the URL and also remember it for next time.
<radix> I just use environment variables that specify the root of various repositories, personally
<fbond> jelmer: Okay.  Now what?  Is there anything I can do to get my changes to the svn repository?
<brettcannon> radix: That might be best in this situation since remembering ``../trunk`` is a lot easier than http://code.python.org/python/users/brett/issue2750-simplejson. =)
<radix> brettcannon: right. I'd set PYTHONBZR to "http://code.python.org/python/users" or something
<jelmer> fbond, I'm not sure. It's pretty hard to debug for me if I can't reproduce :-/
<jelmer> and this appears to be pretty deep inside of the svn code
<jelmer> fbond: I can give some suggestions for debugging
<brettcannon> radix: Possibly, although it's still easier for me to remember where I keep my local branch.
<fbond> jelmer: Ack.  I recently upgraded bzr-svn & bzr on the client, plus I also upgraded svn on the server.
<fbond> Never had this problem before.
<jelmer> fbond: you may want to try over svn+ssh://
<fbond> jelmer: Okay, will do.
<brettcannon> Thanks for the help guys! I will update the bzr guide for Python developers with the info.
<fbond> jelmer: Funny, I restarted apache on the server, and then pushed the revisions up one-at-time with ``bzr push -r x'', ``bzr push -r x+1'' and things mostly worked.
<fbond> jelmer: I didn't get the segfault.
<jelmer> fbond: ok, odd...
<fbond> I now have an AssertionError on a higher-numbered revision.
<fbond> I'll open a new bug
<fbond> https://bugs.launchpad.net/bzr-svn/+bug/230863
<ubottu> Launchpad bug 230863 in bzr-svn "AssertionError on push -r x" [Undecided,New]
<fbond> And the svn repo is a bit odd.  My last pushed revision is *there*, but bzr missing indicates that it is different from the one that I have.
<jelmer> fbond, You need to clear out your svn-cache
<jelmer> fbond, How did you push, using 0.4.10 ?
<fbond> jelmer: yes.
<l3on> Hi all!.... while I pushing up some files in a LP repo, I recived this error -> http://paste.ubuntu.com/12304/
<l3on> It gets me out ad locks repo... :/
<fbond> jelmer: Oh, this might be important:
<fbond> I recently did a dist-upgrade on the server.
<fbond> Ran into a funny issue with svn, had to dump and load all my repos to get them back in order.
<jelmer> fbond: you'd have to clear out your cache to get "bzr missing" to work again I suspect
<beuno> l3on, start by unlocking it: bzr break-lock bzr+ssh://l3on@bazaar.launchpad.net/~ubuntu-it-wiki/wiki-ubuntu-it/wiki-repo
<fbond> jelmer: How do I clear out the cache?
<beuno> l3on, you might have to do that a few times to get it unlocked
<jelmer> fbond: rm -rf ~/.bazaar/svn-cache
<fbond> Is my svn repo now in a bad state?
<fbond> (I have a backup)
<beuno> l3on, and it seems you've hit bug #125784
<ubottu> Launchpad bug 125784 in bzr "TooManyConcurrentRequests when using smart server over ssh" [High,Confirmed] https://launchpad.net/bugs/125784
<l3on> oh damn !
<jelmer> fbond: no
<fbond> Oh, bzr missing looks good now.
<fbond> Should I continue pushing?
<fbond> Yep, push is working now.
<fbond> jelmer: Thanks for the help.
<l3on> beuno: and now ? how can I do ?
<fbond> Not sure what was going on.
<beuno> l3on, it might be worth trying to push with sftp instead
<james_w> hi beuno
<beuno> hey james_w!  you in prague already?
<james_w> no, I go on Sunday. No Fosscamp fun for me.
<fbond> jelmer: Should I close both of those bugs as invalid, or let them stand?
<l3on> beuno: do you mean instead of ssh  ?
<beuno> l3on, yeap, instead of bzr+ssh
<jelmer> fbond: Please leave them open, even while they are not reproducible they are still bugs.
<l3on> ok, I'll contact repo admin to request this solution
<l3on> tnx
<fbond> jelmer: Will do.  Thanks very much!
<beuno> james_w, well, I guess you can't be everywhere  :)
<l3on> beuno: just another question: Launchpad is able to make repo in sftp way ?
<beuno> l3on, yeap, you can use either anytime
<beuno> you don't need special settings from the branch admin, just use sftp
<l3on> just a bzr push sftp://l3on@bazaar.launchpad.net/~ubuntu-it-wiki/wiki-ubuntu-it/wiki-repo ?
<beuno> l3on, yeap
<l3on> ok I'm try
<beuno> it doesn't make a difference how you push/pull
<beuno> (well, it does, but performance-wise, which probably isn't your concern right now)
<l3on> l3on@SubMission:~/wiki-repo $ bzr push sftp://l3on@bazaar.launchpad.net/~ubuntu-it-wiki/wiki-ubuntu-it/wiki-repo
<l3on> bzr: ERROR: Unsupported protocol for url "sftp://l3on@bazaar.launchpad.net/~ubuntu-it-wiki/wiki-ubuntu-it/wiki-repo": Unable to import paramiko (required for sftp support): No module named paramiko
<beuno> l3on, seems you need paramiko installed
<beuno> l3on, sudo aptitude install python-paramiko
<l3on> yep found
<l3on> l3on@SubMission:~/wiki-repo $ bzr push sftp://l3on@bazaar.launchpad.net/~ubuntu-it-wiki/wiki-ubuntu-it/wiki-repo
<l3on> \  0/0                                                                                                                                     Read from remote host bazaar.launchpad.net: Connection reset by peer
<l3on> bzr: ERROR: [Errno 32] Broken pipe
<l3on> great!
<beuno> l3on, sounds like a conectivity problem to me
<l3on> ok, I'll try it later
<l3on> Pushed up to revision 8. finally works !
<beuno> l3on, :)
<l3on> damn it, 2 ours to get a push -.-
<poolie> hello all
<beuno> hey poolie
<james_w> hi poolie
<igc> morning
<beuno> mornin' igc
<poolie> hello igc
#bzr 2008-05-16
<jml> hey guys.
 * beuno waves at jml 
<jml> I'm just catching up on some older email and came across Soren's post to the ml about bug 227340
<ubottu> Launchpad bug 227340 in bzr "Simple way to prepare patches for submission" [Undecided,New] https://launchpad.net/bugs/227340
<james_w> hi jml
<james_w> jml: you got my email ok? (I'm not after a response to it, I just want to check you got it)
<jml> james_w: yes I did, thanks for sending it.
<james_w> no problem, thanks for reading it
 * james_w hopes he at least got that far :-)
<jml> yeah I did.
<jml> I'm a little behind in email, I've been buried hip deep in a thorny branch and have only just surfaced.
<jml> (yay metaphor mixing!)
<fbond> Okay, I was here earlier about this:
<fbond> bzr: ERROR: Must end write group before releasing write lock on KnitPackRepository('file:///home/forest/.bzr/repository/')
<fbond> I have a log file, anyone care to look at it?
<fbond> I use this branch many times a day, and never had this issue before.
<fbond> This error was encountered while pulling over bzr+ssh
<james_w> fbond: if you stick the log up then I can take a look.
<fbond> http://pastebin.ubuntu.com/12337/
<fbond> james_w: thanks
<james_w> fbond: ah, it's autopacking when it errors it seems, that would explain why it is happening on this pull in particular.
<james_w> I'm not sure how to get more information at this point though.
<fbond> james_w: If I manually pack, perhaps that will help?
<fbond> james_w: I already tried reconcile.
<james_w> fbond: yes, I think that will help, but it would only be temporary, and it would hide the problems.
<james_w> can you save the branch (cp -a, not branch), then pack and try again?
<james_w> it will allow you to work, but we can look deeper in to it when we have a better chance of getting the needed information.
<fbond> james_w: Should I just cp -a the .bzr dir?
<fbond> james_w: And what ought I do with the branch so that it can be looked at?
<james_w> that should be enough
<james_w> are you willing to just keep it around for a few days and then ping me? It's not a good week for me to debug it.
<fbond> james_w: Okay, `bzr pack' fixed things WRT pull.
<james_w> is it a public project?
<fbond> james_w: No, it's actually my home directory :)
<fbond> Going all the way back to November of 2006.
<james_w> sure, if you're willing to keep it around then we can work out how to get the information we want.
<fbond> james_w: Okay, perhaps a bug would be a good idea.
<james_w> yeah, I think so, we can always close it :-)
<james_w> it will probably break later, but "bzr pack" will save you most times.
<fbond> james_w: So this is an error in the repository data?
<james_w> I expect it's a logic problem in the code with exceptions or something
<fbond> https://bugs.launchpad.net/bzr/+bug/230902
<ubottu> Launchpad bug 230902 in bzr "BzrError: Must end write group before releasing write lock on KnitPackRepository" [Undecided,New]
<james_w> though the data could cause the exception and this is just masking it.
<fbond> james_w: I push/pull this branch all over the place, and haven't seen this issue with any of the other branches out there.
<fbond> james_w: Anyway, thanks for the help.  Feel free to ping me for more info.
<james_w> no problem, as I said it's not a good week, if I've not got back to you for a while please kick me.
<james_w> though the bug will help with that.
<fbond> That's what I figured.
<Verterok> moin
<beuno> is LP painfully slow for bzr or is it just me?
<mwhudson> it shouldn't be particularly slow
<mwhudson> (the machine seems quiet right now)
<beuno> hrm, I can't do anything with bzr+ssh, but I'm able to branch/checkout with http
<spiv> beuno: strange
<spiv> beuno: which branch?
<beuno> spiv, any branch
<beuno> I've tried with lp:bzrtools and lp:bzr-xmloutput
<beuno> they stall for ages downloading small amounts of bytes
<beuno> everything else here works fone
<beuno> *fine
<mwhudson> beuno: getting new branches?
<beuno> http is fast
<beuno> mwhudson, seems like anything with ssh
<mwhudson> you can always try bzr -Dhttps lp://
<mwhudson> see if it really is the server taking a long time to respond
<spiv> I just grabbed lp:tribunal with no trouble.
<beuno> mwhudson, branching through http works fine
<beuno> bzr co http://bazaar.launchpad.net/%7Eabentley/bzrtools/bzrtools.dev/
<beuno> completed in a minute or so
<mwhudson> beuno: yes, so the problem is why is ssh different?
<spiv> And I just branched bzrtools over bzr+ssh in 42s
<mwhudson> and it's interesting to know whether it's the smart server being dumb, the server being slow to respond
<mwhudson> or something else entirely
<spiv> beuno: could you try with -Dhpss, and paste bin the relevant .bzr.log please
<beuno> spiv, sure, on it
<spiv> Because it's certainly working just fine from here.
<beuno> spiv, http://paste.ubuntu.com/12352/
<spiv> beuno: and it doesn't stall completely?  The chunks still come through, just very slowly?
<beuno> spiv, chunks, slowly
<spiv> 19.111                1113 byte chunk read
<spiv> 37.564                33346 byte chunk read
<spiv> That snippet is weird.
<spiv> It took less than a second for the corresponding transfer for me.
<spiv> You're getting less than 2k per second.
<beuno> spiv, it goes on: http://paste.ubuntu.com/12353/
<beuno> http is perfectly fine
<spiv> What SSH client is it using?
<spiv> (there should be a line like 2.456  ssh implementation is OpenSSH
<spiv> )
<spiv> Could you try comparing with sftp://... rather than bzr+ssh://...?
<beuno> spiv, yeap, OpenSSH, it's Ubuntu Hardy standard install
<spiv> That's very odd.
<spiv> Literally all that's happening in the server at that point is just writes bytes down the wire, as fast as it can.
<spiv> I'm using OpenSSH and Ubuntu Hardy too.
<spiv> So at this point I start to suspect weird voodoo like MTU strangeness.
<beuno> spiv, branching with sftp now...
<beuno> spiv, it's stuck at: http://paste.ubuntu.com/12356/
<spiv> Right, it's taking significantly longer than HTTP?
<spiv> Ok, there's something funny going on with SSH connections for you.
<beuno> spiv, yeap
<beuno> ssh: connect to host code.launchpad.net port 22: Connection timed out
<spiv> Oh, oops.
<spiv> *bazaar*.launchpad.net
<spiv> Not code.launchpad.net
<beuno> right, bazaar.lp gave my a branch not found
<spiv> Oh, right, dang.
<spiv> sftp only gives you access to your own branches :(
<beuno> let me do it with one of mine then
<beuno> hm, it worked fairly well with sftp
<beuno> let me try that smae branch with bzr+ssh
<beuno> spiv, sftp is fine, bzr+ssh is painfully slow
<spiv> beuno: that is bizarre.
<spiv> Do you have access to bzr+ssh servers anywhere else?
<beuno> spiv, this is the full log: http://paste.ubuntu.com/12357/
<beuno> spiv, yeah, I'll try it on a different server
<spiv> beuno: thanks
<spiv> beuno: I'd be mildly interested in a tcpdump of a bzr+ssh session too.
<spiv> beuno: although I don't really expect it to help much.
<beuno> damn ssh keys, I have to re-enable access to everywhere  :(
<beuno> spiv, other ssh work fine
<spiv> beuno: wow
<beuno> hmmm
<beuno> the log output is similar though
<beuno> 29.547                1107 byte chunk read
<beuno> 37.620                41644 byte chunk read
<beuno> 37.624                923 byte chunk read
<beuno> 37.625                903 byte chunk read
<beuno> it's not a massive improvement over LP
<beuno> spiv, I'll try and gather more information, but it might my ISPs fault
<beuno> (it's odd that http works fine though)
<spiv> It is odd.
<beuno> well, I'll wait around and see if anyone complains
<spiv> It really shouldn't take 8s to send 40k though, unless you're on dial-up :)
<beuno> right, and that's to a different server
<spiv> Right.
<beuno> would be wierd that my ISP is playing around with SSH port...
<beuno> meh, anyway, it must be something on my side
<beuno> thanks spiv  :)
<spiv> It's possible that the way SSH packaging the transfer is bumping into TCP MTU settings or something that HTTP doesn't, just by luck.
<spiv> I used to have an ADSL connection where a bad MTU setting or something would cause large rsyncs to fail, but everything always seemed fine.
<spiv> It was a real pain in the neck to figure out :)
<beuno> I hope it's a temporary thing, because it may be months to switch ISP
<spiv> Well, in the end it was a misconfiguration on my end.
<spiv> (My MTU setting or whatever it was didn't match what the ISP said to use)
<beuno> ah, well, there really isn't anything to configure, it's a standard linksys router with dhcp, from a cablemodem
<spiv> Ah, ok.
<spiv> I'd try looking at tcpdumps (on both ends), maybe something will become obvious.
<beuno> spiv, will do, thanks again
<spiv> If you do figure out, let me know.  I'm very curious! :)
<beuno> spiv, hehe, absolutely
<libwilliam> I am looking through the API's and am not seeing a way of checking to see if a directory is a valid branch. Is there anything like this?
<spiv> libwilliam: there is
<libwilliam> check runs consistency checks, but not seeing where it shows how to interpret the error
<spiv> Well, "check" is more in depth than just "is this a valid branch".
<Odd_Bloke> libwilliam: Yes, you try Branch.open(<URL>) and if it raises a particular exception, <URL> isn't a branch.
<spiv> Depending on what you mean by "valid", I guess.
<beuno> libwilliam, http://bazaar-vcs.org/Integrating_with_Bazaar might be worth taking a look at
<Odd_Bloke> "NotBranchError", I think.
<libwilliam> by valid I mean being able to open a WorkingTree out of it.
<libwilliam> I'll try the open method and check for an exception, sorry to keep bugging, thanks again
<spiv> A WorkingTree is a separate concept to a Branch.
<spiv> You want WorkingTree.open, I thin.
<Odd_Bloke> If you want a WorkingTree, you'll... yeah.
<Odd_Bloke> I thin so too.
<spiv> Odd_Bloke: :)
<libwilliam> ok, i already have that part in so that shouldn't be so bad.
<rockstar> Alright, interesting problem:  Developer branches a bzr repo, deletes the .bzr folder, and does bzr init again.  When I go to merge back into target repo, it complains that they have no common ancestor (obviously).  Is there a way to merge them manually?
<rockstar> The target for the merge is identical to what the user branched two weeks ago.
<rockstar> But he's got ~35 versions in his broken repo.
<beuno> rockstar, I know that is some kind of magic using bzr merge -1..
<beuno> to merge unrelated branches
<beuno> but I'm not 100% sure how it works
<rockstar> Yea, looking through that now.
<jml> want to rename threads :(
<rockstar> Well, I guess I could have him re-branch and then make patches from the old repo and put them in the proper branch.
<mwhudson> rockstar: i think all the fileids will be different, which will make like painful
 * AfC speculates that this might be a legitimate cause for using `rebase`
<mwhudson> s/like/life/
<Odd_Bloke> mwhudson: If he made actual patches, rather than bundles, it'd be fine.
<rockstar> mwhudson, I suspected as much.
<AfC> Though I too thought that there was a way (magic or otherwise) to treat the empty branch as a common revision.
<mwhudson> yes, so patches are probably the way to go
<rockstar> But to do that for 35 revs would be rough.
<mwhudson> ...so long as there aren't any renames or kind changes...
<mwhudson> rockstar: sounds like a job for a shell script to me!
<rockstar> Well, it's not my problem...  It's someone else's...
<AfC> Hm. Yeah, revno 0
<AfC> ï»¿Well, `bzr merge -r 0..-1 $other` will pull it in. You'll have a right lovely mess trying to resolve the conflicts, though. That probably is no better than making patches.
<rockstar> AfC, tried that, looks like the original repository is old.
<rockstar> bzr: ERROR: Repository KnitPackRepository('file:///home/rockstar/Projects/entertainer/backend-refactoring/.bzr/repository/') is not compatible with repository KnitRepository('file:///home/rockstar/Projects/entertainer/entertainer/.bzr/repository/')
<beuno> rockstar, it might be the other way around  -1..0
<rockstar> And apparently, bzr upgrade doesn't work on the older repo...  *sigh*
<Odd_Bloke> rockstar: What message do you get?
<rockstar> On the upgrade?
<Odd_Bloke> Yeah.
<rockstar> bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>.  Does not support rich root data.
<mwhudson> upgrade --rich-root-pack then
<rockstar> Yea, I was thinking I would try that.
<mwhudson> these two errors are actually reporting the same problem
<mwhudson> (badly)
<rockstar> :)
<rockstar> bzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack4>.  Does not support nested trees
<mwhudson> oh
<mwhudson> is there pack-with-subree?
<mwhudson> +t
<rockstar> --development-subtree
<rockstar> Holy hell that worked
<jamesh> rockstar: in the short term, you probably want to avoid subtree format if possible
<rockstar> jamesh, well, ideally, I'd like all of these branches to be in the same format.
<jamesh> if you aren't using subtree features (e.g. if it is just an old bzr-svn import), you might be able to pull the branch into a rich-root-pack repo
<rockstar> jamesh, that's exactly how this branch was created.  With bzr-svn.  Version is now unknown (that system was wiped and re-installed with a new OS)
<jamesh> rockstar: right.  While you can't "bzr upgrade" from subtree to non-subtree, you can branch from one format to the other
<jamesh> provided no subtree features were used
<jamesh> (which is probably the case if it is a bzr-svn branch)
<rockstar> I created a new folder, bzr init, and then a pull from another branch.  No go.
<jamesh> rockstar: try "bzr init --rich-root-pack"
<rockstar> jamesh, looks like that's working.
<jamesh> while you can sometimes pull from subtree formats to rich-root, you can't pull to the default format
<jamesh> and rich-root is closer to the main supported formats
<rockstar> Yea, I've been trying to get into bzr development so I can start understanding all these terms.  :)
<jamesh> as I understand it, the differences are something like this:
<Odd_Bloke> abentley is working on the One Format, to in the darkness bind them, I believe.
<jamesh> in the default format, the file ID for the root directory of all branches is the special value "TREE_ROOT"
<jamesh> for rich-root, it gets a pseudo-random file ID like all other directories
<rockstar> Odd_Bloke, yea, we talked about that in Dunedin last week
<jamesh> for subtree formats, directories in the branch can be references to other branches
<jamesh> so provided there are no subtree references, you can go subtree -> rich-root
<jamesh> but you can't go rich-root -> default without losing information
 * igc lunch
<AfC> Odd_Bloke: that was hilarious
<rockstar> Come to think of it, Dunedin is in the same country as Mordor
<mwhudson> different island though
<rockstar> Yea, don't you live down the street from the eye?
<Odd_Bloke> Canonical's London offices are _near_ the London Eye...
<mwhudson> it's a pretty long street
<mwhudson> i guess about 2.5 hours drive
<gour> pygi: morning
<poolie> spiv: how did you go with protocol 3 landings?
<spiv> poolie: Running the final-final local test run now before I fire off to PQM.
<poolie> yay!
<spiv> The last change was updating the protocol version marker to say "bzr 1.6" :)
<poolie> possibly we should have some kind of NEXT_RELEASE marker that's updated during the release
<poolie> or immediately before merging
<spiv> I haven't found it to be a significant burden for my work.
<poolie> well, clearly you can just do it now, but i mean a convention
<poolie> suppose it is no worse to just take a guess at it
<spiv> (Not arguing against, just saying it wouldn't make a big difference to me)
<spiv> poolie: actually, one last thing before I fire it off: the NEWS entry.
<spiv> poolie: here's a first stab: http://rafb.net/p/1U7kMG26.html
<spiv> poolie: Any suggestions for improving that?
<spiv> Hmm, I guess there's a bug number somewhere I can include too.
<poolie> probably
<poolie> probably there is a bug
<poolie> that looks good; the last sentence could be less passive though
<poolie> how about this (if it is correct):
<spiv> It addresses parts of https://bugs.edge.launchpad.net/bzr/+bug/83935
<ubottu> Launchpad bug 83935 in bzr "improvements to bzr protocol" [High,Confirmed]
<poolie> Bazaar 1.6 will interoperate with 0.9 and later versions, but servers should be upgraded when possible.
<poolie> you should get extra points for closing a 5-digit bug number :)
<poolie> spiv, i think you should close that with this landing
<spiv> Well, point 4 in that bug (authentication) is still open.
<spiv> But really that ought to be its own bug
<poolie> i think 3 and 4 should become separate wishlist bugs
<awilkins> can you split bugs?
<spiv> (maybe there already is one?)
<poolie> awilkins: only by hand
<awilkins> Yick
<poolie> but there's a bug requesting that! :)
<awilkins> You'd think with all the slitting and joining of branches you could do the same with bugs
<awilkins>  :-)
<spiv> poolie: Actually, it will only interoperate with 0.16 and up; the autodetection doesn't try to detect v1 servers.
<poolie> ok
<poolie> i wasn't sure of the number
<spiv> It's possible to reinstate that, but it's hard to do it 100% robustly.
<poolie> i think it's reasonable
<spiv> Phew :)
<poolie> but news should say what it is
<spiv> True.
<poolie> can you work out a good phrasing to explain the impact of old servers?
<spiv> "Bazaar 1.6 no longer interoperates with 0.15 and early via these protocols.  Use alternatives like SFTP or upgrade those servers." ?
<spiv> s/early/earlier/
<poolie> yeah
<spiv> Ok.
<poolie> sounds good
<poolie> but isn't there an impact with 1.5 and earlier too? it needs to reconnect?
<poolie> btw can i check you give a message in that case?
<spiv> Yeah, it will reconnect, and it does give a warning about that now.
<poolie> great
<spiv> Oh, I see the reply I sent to your review was still sitting in my editor, oops.
<fullermd> I don't think it has a prayer of interoperating with 0.9 smart servers   :p
 * spiv sends it
<spiv> fullermd: yeah, I think 0.11 had the first hpss
<fullermd> 's the number I recall, yah.
<spiv> "Server does not understand Bazaar network protocol %d, reconnecting.  (Upgrade the server to avoid this.)
<spiv> "
 * spiv fixes the %d.
<spiv> (Hooray for dogfooding.)
<gour> do you recommend DVC for emacs+bzr combo?
<poolie> yes
<poolie> i think that's the best option
<poolie> i don't use emacs often though
<gour> thanks
<vila> yes
<vila>  i think that's the best option
<poolie> hello vila!
<Odd_Bloke> vila: o/
<vila> I use emacs often
<vila> :)
<vila> poolie, Odd_Bloke: hi !
<awilkins> Last time I used emacs was MicroEmacs on the Amiga about 15-20 years ago
<vila> first time I used emacs was epsilon circa 88 :-)
<vila> under DOS wayyyy before windows
<awilkins> Heh, I think this was around the time of "GEM"
<vila> GEM ! Yeah, we code a prolog interpreter under GEM in 87 ! :-)
<Odd_Bloke> I've never used emacs.
<Odd_Bloke> I like my pinky finger too much. :p
<poolie> i might leave early today i think :)
<poolie> spiv, can we have a quick call?
<awilkins> I keep wondering if I should try it, being a slightly sim-ish person at the moment
<vila> poolie: Did you have a look at wireshark traces ?
<awilkins> s/sim-ish/vim-ish
<vila> awilkins: use whatever fits your needs
<poolie> vila, no, will look now
<vila> poolie: thanks a lot
<poolie> !!
<spiv> poolie: sure.
<uniscript> when merge has a conflict, 4 files are generated. Is there any way to make all 4 files contain the non-conflicting changes that have been merged?
<uniscript> currently they are just copies of their corresponding originals plus one to show all the conflicts
<Odd_Bloke> uniscript: Is this before or after you've resolved the conflicts?
<uniscript> before
<vila> the one showing the conflicts includes the non-conflicting changes
<uniscript> right, so I'll have to parse that to generate the 3 files with non-conflicting changes.
<uniscript> Is the clash marker consistent across all merge methods?
<poolie> vila, replied
<poolie> i replied*
<Odd_Bloke> uniscript: Why do you want the 3 files with non-conflicting changes?
<uniscript> because I want to track the conflicts and just the conflicts
<uniscript> it's part of a sync operation I'm writing
<uniscript> that allows conflict resolution to be delayed
<vila> poolie: great, having the server logs will help alot (mneptok can provide that ?).
<vila> sending the other headers is not an option though :) The connection get closed as soon as the GET is sent.
<poolie> should do
<poolie> vila, see my latest post
<poolie> spiv, will call
<spiv> poolie: ok
<vila> poolie: hmmm, yeah, I could try that, thanks for the hint
<gour> i installed DVC and it loads, but, based on manual, emacs complains that C-x T is undefined
 * awilkins tries the Emacs tutor
<gour> awilkins: welcome ;)
<awilkins> I hate it already I'm afraid
<awilkins> M-v to move back a screen? This places ones fingers in an unnatural contortion.
<awilkins> And I have double-jointed fingers
<AfC> Oh goodie! An editor flamewar in a version control channel!
<fullermd> Y'know who else used emacs?!  THE NAZIS!
<awilkins> "I hate it" isn't flaming
<awilkins> "It's a pile of crap" would be flaming
 * awilkins has unwittingly started a meta-flamewar
<spiv> AfC: all that's missing a GPL vs. BSD licence fight.
<fullermd> I thought those were on indefinite hiatus until the GPLv2 vs. GPLv3 flamewars settled out.
<AfC> Cats lovers vs Dog lovers, man
<gour> awilkins: you're free to rebind everything to whatever you like ;)
 * awilkins rebinds page up and down to page up and down
<poolie> night!
<AfC> awilkins: whoa, that's innovative.
<gour> :-)
<gour> poolie: night...here is 10am, we're not going to sleep (yet)
<fullermd> I tried to remap Page Up to "power down system", but I think Apple would sue me for patent infringement...
<gour> :-D
<awilkins> I think I'd enjoy learning Lisp though (if it wasn't for the syntax :-)  )
<bob2> try dylan
<AfC> God I wish Bazaar actually gave useful feedback when pulling a large project. Sitting on "Copying invenory texts 2/5" for the last 9 minutes is thunderingly uninspiring.
<awilkins> I open a file browser and watch the pack files gurgle around
<fullermd> I comfort myself by saying "If I used git, it would be done by now, and I could spend the time bzr is copying trying to figure out what command to run next"
<gour> lol
<AfC> Hm. `baobab` as Bazaar progress user interface.
<awilkins> I don't think git can speed up a slow network connection though
<awilkins> Although sometimes I do find myself thinking "Hmm, git would do this better" when refactoring chunks of code out into separate files.
<awilkins> BUt that's based on zero real-world experience of git
<awilkins> I seem to have absorbed the fact that it versions chunks of code and not files
<igc> night all
<gour> heh, 1.5 tomorrow, 1.6 in few weeks :-D
<gour> it looks i'm catching the bzr train in right moment
<Kinnison> My only issue with bzr's speed is that I have yet to see it fill my link when pulling/branching
<awilkins> How fast is your link?
<Kinnison> 10Mbps
<awilkins> Not filling 10Mbps is unlikely to be bzrs fault (unless you can verify that you can get a full 10Mbps to the target repo).
<AfC> Kinnison: yeah, I have the same complaint
<AfC> Kinnison: (where target has ~100x what I have)
<Kinnison> mmm, the vast majority of large projects I talk to are launchpad so it could be them
 * Kinnison ponders branching to his colo server and trying from there since I know I get the full 1.1MB/s (10Mbps) to that one
<awilkins> I remember thinking that using a diff algorithm that focussed less on space and more on speed might improve matters, having watched it peg the CPU.
<awilkins> But without profiling of course, that is mere speculation
<Kinnison> :-)
<awilkins> 'twas my major nitpick of SVK ; mirroring a remote repo should be I/O bound, not CPU bound, especially in SVK where the source and target use the same repo format.
<jamesh> Kinnison: lucky for you, bazaar.launchpad.net is in the same country
<Kinnison> jamesh: It ought to be bandwidth rather than latency bound with TCP and packs though, surely?
<jamesh> Kinnison: there are probably still a number of round trips to be killed off
<jamesh> Kinnison: how much they affect things probably depends both on your latency and how much data you're transferring
<spiv> Definitely there are plenty of round trips to kill off, still.
<Kinnison> nod.
<spiv> Killing some of them is my goal next week :)
 * Kinnison is lucky for his ping-time to LP
<Kinnison> ca. 15ms
<jamesh> maybe we should move bazaar.launchpad.net down to australia
<jamesh> that'd improve performance
<spiv> Or rather, faster pushing in general is.  In additional to unnecessary round trips, there's also just plain old unnecessary work.
<lifeless> Kinnison: raw pack pulls should saturate your link
<Kinnison> lifeless: upsettingly they don't tend to
<Kinnison> lifeless: although I cannot work out why, since I'm not CPU bound or anything
<lifeless> Kinnison: are you using sftp or bzr+ssh ?
<Kinnison> lifeless: http
<lifeless> Kinnison: try sftp
<Kinnison> for pulling?
<Kinnison> really?
<lifeless> sure
<Kinnison> okay, what's the sftp url for bzr itself?
<spiv> I don't think there is one.  There is a bzr+ssh URL.
<lifeless> sftp://bazaar.launchpad.net/~bzr/bzr/bzr.dev I think; but you currently have to be in ~bzr to read that
<Kinnison> aah
<Kinnison> :-(
<spiv> (Unless you are in the 'bzr' team, as lifeless says)
<jamesh> lifeless: I don't think branches you don't own are available via sftp
 * Kinnison tries a 5.8MB fetch from his own server
<Kinnison> it's managing ca. 14kB/s over sftp
<Kinnison> neither end is heavily CPU bound
<gour> will 1.6 change its default format?
<Kinnison> hmm, http sucks too, I wonder if this is old enough to be pre-pack
<Kinnison> urgh it is, no wonder it sucked
<Kinnison> sorry, I need to sort a remote pack repo first
<AfC> spiv: I assume you have enough repos to test from, but I now have a few projects that are rather large and for whom both I/O and CPU seem underwhelmed. Given the audience is a sceptical one, it might be worth tackling them...
<spiv> AfC: I'm seeing plenty of room for improvement just with bzr.dev, but I'd be happy to have some other real-world datasets to play with.
<AfC> spiv: someone took my GTK ball and has run with it; he's done most of svn.gnome.org now.
<spiv> (And also with the Launchpad codebase, which is pretty big and has a large history.)
<AfC> s/someone/Jc2k/
<spiv> I'm particularly interesting projects that have a very branch-heavy history (like bzr and launchpad), because that's where some of the problems are.
<jamesh> given that svn.gnome.org is in the Canonical data centre, it'd probably make sense to do a migration there
<spiv> i.e. traversing complicated graphs, rather than mostly linear ones.  Although obviously they need to work well too...
<gour> spiv: have you tried to play with ghc?
<spiv> gour: no; is it in bzr?
<AfC> whatever, it's done now.
<gour> spiv: no, it was in CVS, now is in darcs, but there are problems
<spiv> gour: ah, ok.
<gour> spiv: someone was doing darcs --> git and it was sloooow
<jamesh> AfC: I'm not saying what you did was unimportant.  Just that maintaining mirrors from there would probably be more efficient
<AfC> He's in the UK
<jamesh> and in general, pulling the converted bzr branch is faster than pulling with bzr-svn
<spiv> Interesting.  I don't know what the state of darcs -> bzr is like at the moment.  Probably just tailor?
<AfC> and I'm bitching about the performance of pulling the converted bzr branch
<jamesh> AfC: I'm talking about machines that are in the same room
<AfC> jamesh: he was given rsync access to the entire repo, so is doing svn+file://.
<gour> spiv: see http://nominolo.blogspot.com/2008/05/thing-that-should-not-be-or-how-to.html
<jamesh> AfC: ah.
<gour> yes, probably tailor...i'm interested for it as well
<gour> in any case, i think ghc is nice for bzr testing
<gour> 18500 patches, 12yrs history
<jamesh> gour: it sounds like a good example of a long linear history
<jamesh> gour: spiv is talking about also testing on branches where sizeof(ancestry)/sizeof(linear history) > 1
<jamesh> that is, where there is a more complex graph
<fullermd> Considering the effects emacs shows on sizeof(linear history)...
<gour> i see
<gour> darcs is not so big but had two branches for a long time: main + unstable which are merged recently
 * spiv -> dinner
 * Kinnison cheers as bzr gets 1.2MB/s over sftp from his colo box
 * Kinnison bounces lifeless
<Kinnison> mmm interesting. http took marginally less cpu, but twice as long wallclock
<Kinnison> sftp for the win, thanks lifeless
 * Kinnison manages to get bzr-svn to break
 * Kinnison tries to see if we do anonymous access to this svn repo so I can report the issue
<lifeless> vila: ^ I think its http buffering
<vila> lifeless: sounds plausible enough, I wonder why we never encounter it before, but some bugs just love to stay dormant like that, I'll have a look asap
 * vila gotta run now
<lifeless> vila: we encounter it always I think
<lifeless> vila: bye
<vila> lifeless: sry, I'm in a hurry, but I'd be very interested in discussing it a couple of minutes with you, cu later
 * Odd_Bloke impotently shakes his fist at the mutable-commit-messages ML discussion.
<jelmer> hi Odd_Bloke
<Odd_Bloke> jelmer: o/
<jelmer> Odd_Bloke: any news on file-type-specific merges ? :-)
<Odd_Bloke> jelmer: Yeah, I'm starting on it after exams. :p
<jelmer> ah, ok
<pygi> morning gour
<gour> pygi: it's noon (by Son) already ;)
<dennda> Doesn't bzr allow to bzr push sftp://... to another port than 22?
<james_w> dennda: I would have thought that it does, how are you specifying the port?
<dennda> james_w: tried adding -p $port and -P $port
<dennda> does accept neither of those
<james_w> ah, no, it won't
<james_w> try sftp://server:port/path/
<dennda> great, thanks. I was almost working around that with .ssh/config :)
<dennda> uff, takes ages to push 2,9 MB
<gour> to import darcs repos, tailor is the only solution?
<dennda> hu... it says it created a new branch remotely but all it did was creating a .bzr directory. the actual branch doesn't contain anything else
<luks> dennda: .bzr is the actual branch
<gour> dennda: you mean no working tree?
<dennda> luks: yes, I know. but the location to where I pushed is empty except the .bzr folder
<dennda> gour: yes
<luks> dennda: yes, that's correct
<luks> bzr push will never create or update remote working tree
<luks> only the branch
<dennda> so I need to branch that again?
<luks> why?
<dennda> I need a working tree remotely
<james_w> dennda: ssh in and run "bzr checkout ." in the directory
<luks> http://bazaar-vcs.org/FAQ#head-942dfcf9fc6787bb81dd6c1ffe0c32b16c71d496
<dennda> james_w: done that, worked. although I used branch instead of checkout
<Peng> ...You branched a branch to the same directory?
<james_w> when you push again "bzr update" will update the working tree, to automate this you may want to look at the "push-and-update" plugin.
<dennda> and branched to another directory
<daniels> this might strike you guys as a stupid question, but how do i actually check out a tag?
<daniels> bzr tags shows me the tag i want, with its revision number, but neither bzr checkout nor bzr branch seem to do what i want (make my working copy be that tag)
<luks> bzr checkout -r tag:foo ?
<james_w> if you just want your tree to be that tag for a minute to look at it then use "revert"
<james_w> if you want a separate branch at that tag then use "branch -r tag:foo branch new-branch"
<james_w> I'm not sure if checkout does it, I know pull will, but bear in mind that that will make your current branch tip
<james_w> hard to get at
 * gour is looking for some advice to import darcs repos
<daniels> okay, so what i probably want is: bzr branch -r tag:the-tag-name directory-the-repo-is-in directory-to-check-that-tag-out-into
<TFKyle> not sure if there's anything better, but tried tailor already gour?
<james_w> daniels: yup, that's what I'd suggest. Though by "directory-the-repo-is-in" do you mean "the directory of the branch"?
<james_w> you point it to a branch, not to a shared repository (init-repo) if you are using them.
<daniels> james_w: yeah, that's done what i want, brilliant -- ta
<gour> TFKyle: i did in the past, but not with bzr
<daniels> (and yeah, i mean directory of the branch.  my terminology is heavily git influenced, and i'm only using bzr because one particular project does.)
<james_w> daniels: ah yeah, I know this is a pain when changing between the two.
<daniels> james_w, luks: cheers for the help
<CroX> What bugtracker system do you people use when working with Bazaar? I had wanted something that integrates with the VCS.
<james_w> there is a trac-bzr plugin
<james_w> launchpad has some integration
<james_w> there is bugs-everywhere if you want to get really integrated.
<CroX> Know anything about Mantis' possibilities?
<CroX> Never heard of that one. I'll need to check it out.
<james_w> I haven't heard of any integration with mantis
<igc> gour: can you try fastimport for getting from darc to bzr? You'll need http://repo.or.cz/w/darcs2git.git as the front-end
<gour> igc: do you think it's better than tailor?
<igc> gour: well I wrote bzr-fastimport so I hope so :-)
<gour> igc: ohh, let me try it then ;)
<igc> seriously, ...
<igc> it will convert a repo, not just a branch
<igc> assuming the exporter does the right thing
<gour> so, i need to install plugin 1st
<igc> yes. See http://bazaar-vcs.org/BzrFastImport
<igc> and that links to http://bazaar-vcs.org/BzrFastImport/FrontEnds where ...
<igc> I'd love to move Darcs "up the page" if that makes sense
<gour> ok, plugin is installed and listed in bzr...what's next
<gour> igc: how do i get darcs2git?
<igc> gour: git clone http://repo.or.cz/w/darcs2git.git
<spiv> vila: thanks for finding the dupe of that smart server auth bug, I looked but couldn't find it.
<igc> gour: I'd like to bundle this if it works and licensing permits
<igc> that's why someone testing it is good :-)
<gour> igc: some problems http://rafb.net/p/f7pChO29.html
<gour> i'm totally ignorant of git - another reason to move to bzr
<igc> gour: ah - I got that link from http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-0c139c28cd0c9c34c6e08375ef10ad5ed5810271
<igc> gour: try git clone http://repo.or.cz/r/darcs2git.git
<igc> note the 'r' instead of the 'w'
<igc> sorry for the wrong url
<gour> will it work with http://git.sanityinc.com/?p=darcs-to-git.git ?
<gour> that one was ok
<igc> gour: don't know - probably not
<gour> ok, let me try yours
<igc> the key thing is generating the 'fastimport' stream - not getting it into git
<gour> done.
<gour> igc: i invoked  python ~/repos/git/darcs2git/darcs2git.py | bzr fast-import -
<igc> gour: cool
<gour> but got: bzr: ERROR: line 1: Invalid command 'Usage: darcs2git [OPTIONS] DARCS-REPO'
<igc> gour: ok, so get the export part working first
<gour> you mean without piping?
<igc> i.e. just do ... python dards2git.py WHATEVER > myrepo.fi
<igc> you can then inspect that file to confirm things look ok
<igc> if so, then do ...
<igc> bzr fastimport myrepo.fi
<igc> gour: how's your python coding skills?
<igc> you might want to manually inspect darcs2git.py before running it
<gour> igc: none
<gour> it does something..
<igc> in particular, you don't want it implicity piping the 'output' to git-fast-import
<igc> because we want to consume the output instead
<gour> hmm
<gour> maybe i should try with some smaller repo
<gour> igc: does darcs2git works with darcs-2 format repos?
<igc> gour: I have no idea sorry
<igc> gour: if darcs-to-git works, then you can always use it and then use git-fast-export
<igc> gour: that may be easiest in the short term
<gour> igc: it works with older format. i changed it create darcs-2. let's see
<gour> when i s/darcs init/darcs init --darcs-2, it crashes
<TFKyle> jam: hmm, I could be blind, but I don't see the bzr-merged plugin anywhere
<TFKyle> (well, on the plugins page, and bzr ls lp:bzr-merged == no such project
<lifeless> jam: yo
<pickscrape> Any idea when bzrtools 1.5 is going to hit the bzr PPA?
<jelmer> pickscrape, poolie should be able to tell you
<pickscrape> One of my worries about rolling bzr to my team is that the packages in the PPA rarely seems to be consistent with each other.
<pickscrape> At least they haven't in the time I've been using it.
<lifeless> pickscrape: thisi s a liimtation with ppa's, we're looking at ways to address this including a more stable ppa for users
<pickscrape> Would "more stable" mean missing on on monthly releases, or just more consistent and excluding things like RCs?
<pickscrape> s/on on /out on/
<lifeless> nore consistent and not having rc's
<pickscrape> That sounds perfect. :)
<madduck> bzr: ERROR: pycurl.error: (60, 'server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt')
<madduck> how can i work around that? bzr *should* really be giving me a choice here, no?
<lifeless> its comeing up from curl
<madduck> but shouldn't bzr catch it and handle it appropriately?
<lifeless> apparently its not that easy
<madduck> so i can't clone this repo...?
<madduck> https://penta.debconf.org/~joerg/bzr/debconf8 ftw
<lifeless> try
<lifeless> https+urllib:/...
<madduck> that works
<james_w> hi madduck
<madduck> hi!
<jam> morning lifeless
<jam> TFKyle: I believe 'merged' is a plugin that statik uses, I'm not sure where he got it
<jam> I believe he said it was public, and he was asking the author if they would mind hosting on LP
<madduck> thanks, lifeless !
<lifeless> jam: :pserver: support for cvsps would be nice
<bac> hi jam -- i was trying to update a very old version of a rocketfuel trunk (on a laptop i haven't used in a while) and i got  raise AssertionError('%d != %d' % (len(history), revno))
<bac> AssertionError: 25 != 6299
<bac> jam: it's probably easier for me to start from scratch, unless this represents a bzr bug you'd like to investigate
<james_w> bac: hi, that's a bug that has been filed I think.
<bac> james_w: ok, thanks.  is there a work-around?
<james_w> I'm looking for the bug now, I don't remember the details.
<bac> james_w: thanks.  as i said it isn't imperative that this repo be repaired.
<james_w> https://bugs.edge.launchpad.net/bzr/+bug/177855 looks like it
<ubottu> Launchpad bug 177855 in bzr "assertionerror trips on pull --overwrite in dirstate branch with non-canonical history" [High,Fix released]
<james_w> what version of bzr are you running?
<bac> 1.5rc1
<james_w> hmm, I guess it's a different bug then.
<james_w> are you doing a "pull" or an "update"?
<bac> james_w: i was attempting a pull
<james_w> I'm not sure how to debug that, sorry.
<bac> james_w: ok.  not a problem.
<gour> tailor rocks in comparison with darc2-git
<ricardokirkner> hi. what authentication scheme is mostly used in order to share a common branch for a project, using bzr? on the other hand, what guarantees that the user committing a change is actually the person that is authenticated? (for example, I can authenticate using user1 but in my bazaar config I specify myself as user2; in that way I 'could' blame user2 for introducing mistakes, or something like that)
<james_w> I don't think there is any protection against that.
<jam> bac, james_w: The "fix" is that you have to run "bzr reconcile" on the branch
<jam> ricardokirkner: the fix is to gpg sign your commits
<bac> jam: thanks
<ricardokirkner> jam, thanks for the idea, though in our case that might be a little bit overkill. but don't mind, my previous question was more out of curiosity than of need
<jam> ricardokirkner: we trust the user, partially because you may be "pushing" code from someone else
<jam> And that *should* be valid
<igc> night all - have a good weekend
<gour> igc: night
<igc> hope the release good well jam
<beuno> jam, if you need any help with the packaging today, let me know
 * beuno ducks
<jam> igc: good night
<jam> beuno: I might, how did you do the earlier ones?
<jam> (we'll be marking these as 1.5.0, just to get the ordering correct)
<beuno> jam, I basically followed the docs
<jam> beuno: ok, I was just wondering if you used builddeb or something like that
<beuno> and, for the first one, I built it in a pbuilder enviroment
<jam> pbuilder?
<beuno> to make sure it was clean
<beuno> jam, it's a clean chroot-like enviroment, which doesn't save changes done to it
<beuno> do you can build anything you want, and will always reset to a clean system
<beuno> but just following the docs wirks fine
<beuno> s/wirks/works
<beuno> anyway, I'll be happy to help out
<jam> beuno: we'll see how things go here, I have to wait for PQM to merge everything anyway
<beuno> jam, good luck with that  :)
<jam> beuno: well, the submissions are in the queue
<beuno> jam, but they only get in if they pass all tests, right?
<awilkins> I love it when you hammer the keyboard for three hours straight and at the end of it have to patch less than 30 lines of code to fix the bugs :-)
<pickscrape> From time to time you write code that really does work first time. Those moments are special :)
<awilkins> The best bit it is that it's some really nasty/elegant (depending on your tastes) Java code thats very heavy with generics
<awilkins> Ok, I was only refactoring it....
<lifeless> awilkins: depends how long those lines are :)
<nv1> Thinking of using bzr for project revision control at my company.  I understand tha Bazaar is GPL, so what are rules of using bzrlib from proprietary Python code? Should subprocess only be used?
<awilkins> Does that particular restriction apply to scripting code? My understanding was that it applies when you link.... but IANAL
<nv1> that is what I am wondering
<lifeless> nv1: hi
<lifeless> there may be a delay; evolution is saturating my homelink
<lifeless> nv1: as long as you don't distribute your code you can do anything - the GPL licence applies to *distribution* not use.
<nv1> I am thinking they are both (bzrlib and proprietary code) running in the same process... but no traditional C-style linking goes on
<TFKyle> I think it depends on who you ask, GNU seem to say that even importing shouldn't be allowed, but I disagree sort of
<nv1> we sell our product and it gets installed on customer's systems
<awilkins> That's rather broader than "at my company"
<nv1> yes
<vila> Then you distribute it and are bound by the GPL
<TFKyle> vila: are you bound by the GPL just for the bzr code or any code that imports bzr though?
<nv1> If we import bzrlib, but if we call it via subprocess then I understand that it is not
<TFKyle> s/bzr/bzrlib/
<vila> IANAL, but AIUI, playing tricks with the GPL is quite risky
<luks> TFKyle: any code that links to (imports) GPL-licensed code
<lifeless> whoa no
<awilkins> Release it GPL and charge for support, not the actual program ?
<lifeless> slow down folk
<lifeless> linking invokes the gpl because the output copies data from the input
<TFKyle> luks: is importing really linking though? and what't the "level" of linkage?
<luks> TFKyle: well, that's always questionable. but there are companies that run busineses based on that, so I guess they checked with enough lawyers
<TFKyle> s/what't/what's/, I can't type properly these days
<lifeless> http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
<nv1> I don't want to take advantage and skirt the law on GPL, if it is a gray area I'd rather play it safe
<lifeless> this mentions the FSF stance, which we share
<lifeless> which is that a GPL'd module in an interpreted language requires that users of it also be GPL
<awilkins> Yeah, but it's not just the interpreter being GPL ; the code running in the interpreter is GPL too
<luks> lifeless: using a GPL interpretter and importing GPLed code are different things
<lifeless> luks: I know that; please a) read what I said, and b) read the thing I linked to
<awilkins> The bottom two paragraphs of that section are relevant
<lifeless> nv1: we would expect that a proprietary piece of code could only use bzr if it was not being distributed
<TFKyle> lifeless: another random question, can you get around that by not requiring the module exist but working with it if it does? (remember reading something about that somewhere else in the FAQ, wrt. dynamic linking)
<lifeless> nv1: which is to say that you should use bzr via a subprocess
<lifeless> nv1: you will likely find the 'ide integration' work being done of great interest, because it is aimed at providing a low level machine readable interface to bzr
<nv1> lifeless: makes sense too me
<nv1> I suspected that
<lifeless> nv1: suitable for use by IDE's (including visual studio etc)
<TFKyle> (well, by that I mean continuing to work without having to import the module)
<lifeless> TFKyle: the usual example for that is a BSD readline and a GPL readline
<nv1> bzr is used as a backend for our project models (written in an s-expression format)
<lifeless> nv1: cool
<awilkins> Having some reasonable success here using bzr over a socket in Eclipse.
<nv1> s/used/hoping to use
<awilkins> That's not linking
<pickscrape> I had an idea last night that could be pretty cool (if it's not been done already).
<nv1> awilkins: that means to get status we'd have to either 'import bzrlib; bzrlib.get_status...' OR call via subprocess "bzr status" and parse the output
<pickscrape> Would I be right in thinking that a bundle which represents a number of commits includes the commit log for each of those commits?
<lifeless> TFKyle: I'm not really that interested in looking at 'ways around' the GPL :). Bzr is free software, folk that build on bzr to make bigger things which are not free software can't really expect to be working with the same interface as free software does
<awilkins> nv1: There is expressly an XML output plugin for such a thing. Grab the bzr-eclipse source for examples if you are a Java type of person.
<lifeless> awilkins: we're folding that into the core FWIW
<lifeless> pickscrape: it does, yes.
<pickscrape> Then how difficult would it be for bzr visualize to be able to load up a bundle, appending it to what it's currently displaying?
<awilkins> pickscrape: I think a bundle is to all intents and purposes the only stable implementation of a shallow branch :-)
<nv1> lifeless: No problem with that ,we use python, linux plenty of other free software here, but we don't want to take advantage and skirt the law
<pickscrape> That would allow a review of the bundle on a change by change basis to supplement the whole diff.
<nv1> awilkins: thanks, that would be helpful to use
<lifeless> nv1: I appreciate that :). And I'm glad that you want to use bzr
<lifeless> pickscrape: it would be nice; bundles are essentially a static partial-branch anyway
<pickscrape> Then I thought that Bundle Buggy could potentially do the same thing too.
<vila> pickscrape: you can pull or merge a bundle and then you have a real branch to work with
<nv1> all: thanks for help and for your time!
<lifeless> vila: its not as convenient though :)
<cr3> I'm trying to branch a project and I get: bzr: ERROR: Revision {email-200804...} not present in "revisions.kndx"
<pickscrape> My idea is just for review purposes. Basically looking at each diff can sometimes give a better understanding than the whole lumped patch
<pickscrape> Is it worth a wishlist bug for bzr+gtk do you think?
<lifeless> pickscrape: definitely
<pickscrape> ok
<jam> beuno: well, a lot of the changes are doc only, but it turns out I accidently submitted them to bzr.dev instead of bzr-1.5. So they ended up failing right away with NEWS conflicts, which is good for me :)
<jam> beuno: So I have 1 more to go, so maybe in 1-2hrs...
<beuno> jam, I'll be around for at least 6 more  :)
<Lo-lan-do> G'day all
<Lo-lan-do> I seem to have a problem with bzr and bzr-svn in sid
<Lo-lan-do> $ bzr checkout http://svn.gnome.org/svn/f-spot/trunk
<Lo-lan-do> bzr: ERROR: Transport error: Server refuses to fullfil the request
<Lo-lan-do> I guess I need to poke jelmer, unless someone already knows about it :-)
<jam> Lo-lan-do: this sounds like a recurring problem we have been seeing with the gnome.org servers
<jam> let me look up the bug
<jam> Lo-lan-do: possibly bug #229076
<ubottu> Launchpad bug 229076 in bzr "'Connection reset by peer' error when branching repository" [Undecided,Confirmed] https://launchpad.net/bugs/229076
<cr3> the problem doesn't occur if I use sftp rather than bzr+ssh
<awilkins> Lo-lan-do: try
<awilkins> bzr checkout svn+http://svn.gnome.org/svn/f-spot/trunk
<Lo-lan-do> awilkins: Seems to work better indeed.  Thanks!
<jam> statik: ping
<statik> jam: hi there
<jam> statik: where is the 'merged' plugin
<abentley> Is anyone here from fluendo?
<jam> I've gotten several requests for it, probably by the same person
<statik> jam: bazaar.launchpad.net/~jml/bzr-removable/trunk
<jam> statik: that is "merged" with a name like "removable" ?
<statik> jam: we'll have to beat up jml and teach him how to name plugins
<jam> statik: so should it be locally called "removable"?
<statik> i guess if a branch is merged that makes it removable
<asabil> abentley: you will catch more fluendo people is you ask in #gstreamer :p
<jam> I'm guessing he started it thinking XX and ended up writing YY
<statik> jam: I think with this plugin you have to add a symlink in your plugin dir, because of how the tree is laid out
<abentley> asabil: Yes, but someone from fluendo is trying to use bundle buggy, and has misconfigured it to spam me.
<asabil> lol, I see :)
<lifeless> abentley: I humbly suggest different default config values :)
<abentley> Well, I take your point, but there are no defaults, only examples.
<abentley> I like to use examples that I know work.
<lifeless> root@localhost then?
<jam> statik: looking at the log, the last entry is:
<jam>  Add a command to show reasons why a branch cannot be removed.
<jam>  This branch adds 'unremovable' and renames the existing command
<jam>  'merged-branches' to 'removable'. Both commands have the same structure and
<jam>  use similar code.
<lifeless> anyhow, I would personally use @example.com
<jam> statik: so it seems like the plugin name has officially changed, along with the command
<statik> jam: that makes more sense.
<statik> i've renamed it locally now
<jam> statik: I updated the blog post as well
<statik> excellen
<statik> t
<lifeless> abentley: jam: we don't seem to use @property much - is there a reason (other than propertes being a rate thing to use)
<lifeless> s/rate/rare/
<jam> lifeless: because pretending a method is an attribute is something we try to avoid
<jam> I believe
<jam> from what I remember, we only really use it for things which used to be attributes
<jam> but we wanted to make readonly
<jam> like WT.branch
<lifeless> well, we tend to use
<lifeless> def _foo
<lifeless> foo = property(_foo_
<lifeless> there
<jam> lifeless: I think also because for "@property" you can't do read + write portions
<jam> so if you want an attribute that can be set under certain conditions
<lifeless> thats more likely; anyhow, I have a attribute I want to add for these stores
<jam> you have to do "foo = property(reader, writer, doc)"
<lifeless> and RemoteRepository needs to forward in the interim
<jam> lifeless: I don't have any problem with @property, but do you need to forward "setters" as well?
<asabil> jam: there are various recipes to have RW properties
<lifeless> no
<lifeless> someone setting this attribute gets to keep all the pieces
<lifeless> gnight
<pickscrape> Does there exist a plugin to diff openoffice documents?
<demod> pickscrape: i doubt it unless you are using some xml format (.fodt) or use the diff tools plugin to call something external
<beuno> vila, ping
<fbond> lifeless: ought I be able to merge between threads in a loom?
<fbond> i.e. what if I want to move changes down the loom to a lower thread.  My first instinct was: `bzr switch {thread below where I want the changes}; bzr create-thread foo; bzr merge -r thread:bar..thread:baz'
<fbond> But that gets me a traceback :)
<fbond> Which is obviously a bug, one way or another.  I'm wondering if my expectation for it to do the right thing is reasonable?
<krow> Hi!
<krow> Is there a simple "how to host my code with bzr with https"
<krow> ?
<beuno> vila, unping, email  :)
<beuno> krow, are you having problems using https?
<krow> beuno: I want to find a hgweb like CGI for bzr. Looking through the manual it implies that this is not an option.
<krow> beuno: So I am wondering if it exists outside of the manual.
<beuno> krow, well, have you seen loggerhead?
<krow> beuno: I've seen it mentioned, but the link I found to it was dead.
<krow> beuno: I am assuming someone must have done this/wanted it :)
<beuno> krow, https://launchpad.net/loggerhead/
<beuno> krow, working demo: http://bazaar.launchpad.net/~mwhudson/loggerhead/better-navigation/files
<krow> beuno: Can you push to it via https but allow others to browse via http? It works under apache?
<beuno> krow, no and no  :)
<krow> beuno: Know of anything that does?
<beuno> krow, not with bzr, no
<krow> beuno: Gotcha...
<pickscrape> demod: amazing what you learn. I wasn't aware of .fodt files: this has actually pointed me at something else I'd been looking for for a while. :)
<beuno> krow, their will be something eventually, so keep your eye out for it  :)
<demod> pickscrape: ,)
<pickscrape> Shame it's stuffed everything into three lines though...
<pickscrape> ï»¿Is there a decent demonstration of loggerhead anywhere on the net?
<beuno> pickscrape, on launchpad  :)
<beuno> (code browse *is* loggerhead)
<pickscrape> eeeeenteresting....
<beuno> isn't it?
<pickscrape> I'm now thinking about using the trac bzr plugin just to track 'mainline' changes and using loggerhead for all other branches etc.
<pickscrape> Loadsa options...
<ricardokirkner> hi, I was trying out the sftp (and bzr+ssh) transports. I tried (but was unable to achieve it successfully) to connect using a user that could be authenticated by ssh, but who was not allowed a shell on that machine (which are my requirements). Is this possible in some way? I want to use authentication to check out and commit branches, but I dont want to give those users shell access to my host
<pickscrape> git provides a 'restricted shell' for this purpose. I wonder how hard it would be to do the same for bzr?
<ricardokirkner> I am not asking for this to be part of bzr (because I know this has been discussed several times), but merely if anyone has had any experience with this kind of scenarios
<fullermd> Any of the random "restricted shells" out there should work; you just list bzr as an allowed command.
<ricardokirkner> so, what I need (on the server side) is to be able to execute the bzr client, even if I have the bzr smart server running?
<ricardokirkner> fullermd, just to clarify, I am calling the bzr client from a remote machine, not trying to invoke it in the machine I dont have shell access to (but which has the bzr smart server running)
<jam> beuno: 1.5-final has been officially finished at http://bazaar-vcs.org/bzr/bzr.1.5, I'll try to put together the tarball and the debs, but I might end up asking for help
<beuno> jam, congrats  :)
<beuno> and, sure, I'll be here
* beuno changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | bzr-1.5 is out! | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
#bzr 2008-05-17
<jam> beuno: I leave the debs up to you. If you can't get to it, that's fine. I uploaded the tarballs to launchpad, and updated the download pages
<beuno> jam, np, I'll upload them in a few hours
<fullermd> Hmm...
<fullermd>  Source of the stable release for any platform
<fullermd> 	
<fullermd> bzr-1.5.tar.gz
<fullermd> But above it, "The current stable version is 1.4, released May 02, 2008."
<bignose> How does the recipient of a 'bzr send' apply the bundle to their branch?
<spiv> bignose: "bzr merge FILE"
<bignose> spiv: thanks. (I think I knew that, but forgot it :-)
<Peng> So, how awesome is protocol 3?
<Peng> Ohnoes, bzr claims my bzr+http server is still using protocol 2.
<Peng> So it reconnects 3 times.
<spiv> 3 times sounds excessive.
<spiv> (Although "reconnection" doesn't really apply to bzr+http either)
<Peng> It was just a "bzr info" too.
<Peng> Oh wow.
<Peng> My HTTP smart server script is busted.
<Peng> And has been for a while now.
<Peng> I messed up sys.path so it uses the system bzr instead of bzr.dev.
<Peng> Ok, now it works.
<bignose> Using the 'bzr-svn' plugin to connect to Subversion repositories over SSH, Bazaar attempts to connect *three times* for operations like 'push'.
<bignose> Whereas to a Bazaar repository over SSH, just once.
<bignose> porquois?
<bignose> and how can I bring it down to just one connection?
<bignose> s/attempts to connect/starts a new connection/
<spiv> bignose: sounds like a bug in the bzr-svn plugin
<spiv> You could workaround it by configuring OpenSSH to do connection sharing (the ControlMaster option in your .ssh/config, IIRC).
<spiv> (Or if it's just typing a password three times that's bugging you, switching to using publickey auth and using a key agent)
<Peng> Aww, the bzr-hello plugin is out-of-date.
<bignose> spiv: which only works if the server is accepting public-key auth
<bignose> spiv: which, in the wake of DSA-1571, some servers are not yet doing.
<lifeless> fbond: its in the todo that bzr should allow thread reorganisation
<lifeless> fbond: a cherrypick like that is a good mannual representation of wat bzr would need to do internally; a traceback is definitely an error
<lifeless> fbond: could you please file a bug?
<fbond> lifeless: Okay, let me see if I can reprouce.
<fbond> https://bugs.launchpad.net/bzr-loom/+bug/231283
<ubottu> Launchpad bug 231283 in bzr-loom "Merging a cherry-picked thread into another thread results in error" [Undecided,New]
<fbond> lifeless: I'm using loom pretty heavily, so there probably aren't many bugs that are getting by me :)
<lifeless> fbond: great
<fbond> lifeless: I can sense your excitement ...
<pickscrape> Is --rich-root-pack safe/sensible to use now?
<bob2_> should be safe, sensible if you need it (ie bzr-svn)
<pickscrape> Other than enabling things that bzr-svn needs, does it provide any other user-visible advantages? (performance etc)
<lifeless> no
<lifeless> for now, only use it if you need it
<lifeless> old bzr's interoperate with glitches with it and normal repositories, and itws a one-way conversion
 * beuno starts packaging 1.5 for ppa
<beuno> lifeless, you might have a good answer for this. Considering I can copy packages on LP PPA now, I should loose the ~distro1 bit of the version, upload one, and copy for the rest, right?
<pickscrape> lifeless: thanks for the clarification. i'll stick with the default for now then :)
<beuno> ok, 1.5 is in PPA, 'm off to bed
<lifeless> beuno: no idea
<lifeless> spiv: hi
<gour> do i understand correctly that 'checkouts' can be useful in the situation when 'gatekeeper' is reviewing merge-bundles received from other developers and then wants to commit to the main branch on public server?
<lifeless> yes
<gour> (ub)bind mechanism is quite cool...man, i like bzr
 * gour puts his ad-hat labelled 'Go bzr'
<lifeless> :)
<gour> too bad many are just looking time in benchmark tests...
<lifeless> indeed, it is frustrating
<gour> as i wrote on ml, bzr is *powerful* with *simple* model and *safe*
<gour> but, i'm sure, it will change...
<lifeless> which 'it' ? ;)
<gour> don't know why, but hg does not offer (much) more, but is seems too complicated...i was reading (~0.97-98) the 'book', but didn't grok it
<gour> the 1st one ;)
<gour> too late for the 2nd one :-)
<gour> what's the status of support for nestedtrees?
<lifeless> coming along
<lifeless> I think it will happen for real shortly after the windows line nding filteriting support ian is hacking on at the moment
<gour> ohh...here one gets one (pleasant) surprise after another
<gour> line-ending will make it for 1.6?
 * gour is reading sharedrepositorylayouts docs
<gour> ..where it says: "...because Bazaar supports (and recommends) creating repositories with no working trees" i understand that in DVCS environment i want to have working tree in my shared repo containing all required branches, but i do not want to have trees on the 'public' server...or do i miss something?
 * gour is coming from darcs background and no shared repos, so he requires some time to adjust to new capabilities and choose the right layout :-/
<Peng> gour: You sound correct.
<bob2> I tend to have --no-trees everywhere, and work in lightweight checkouts from the local repository
<gour> Peng: good. it sounds logical to have full repo locally
<gour> bob2: what is advantage of that?
<bob2> I use "bzr switch" a lot to switch the one checkout between multiple branches in the repo
<gour> bob2: ahh, 'bzr switch' is not (yet) in my propsed toolbox
<Jc2k> jelmer: bzr-svn question: does svn-import involve python-subversion (more importantly, does it leak the same as if i branch
<Jc2k> )
<jelmer> Jc2k, yes
<jelmer> Jc2k, are you using the memory leak patch for python-subversion ?
<Jc2k> jelmer: debian etch, so i have one patch i think
<Jc2k> but as soon as i get into the > 5000 revisions, i run out of memory
<jelmer> Jc2k: you should be able to pull incrementally, e.g. 1000 revisions at a time
<Jc2k> ah, i've been doing 2000 at a time
<jelmer> The Debian etch python-subversion package indeed doesn't contain the leak fixes
<fullermd> 2000 won't work, 'cuz it's a leap year...
<Jc2k> etch-backports perhaps..
<Jc2k> i'll have a look later
<Jc2k> i'm sure 1000 at a time will be fine for now
<nekohayo> abentley: making the file ids match? how the heck do I do that? :)
<gour> what is missing in bzr's cherrypicking with bzr merge -r X foo ?
<jelmer> gour: Missing in what sense?
<gour> is it this "...Bazaar does not currently track cherrypicks.." ?
<bob2> it will confuse merge later on
<gour> jelmer: i heard there are ideas to improve it
<gour> bob2: thanks. confirmed
<gour> bzr merge --uncommitted is a nice one...
<gour> is there a real need for 'rebase' command (provided by plugin) ?
<lifeless> no
<gour> so, it's only for 'refugees' from dumber VCSs
<gour> until they become accustomed to powerful bzr ;)
<gour> hey, bzr commit can work with roundup tracker as well...surprise, surprise
 * gour finished reading user-guide...it's time for user-reference
<gour> now i see reference for bob2's style in the user-reference
<ricardokirkner> hi. I am struggling with this for a while now. I want bzr to authenticate users for checkout and commit (like I had on a svn installation), but I don't want to have to setup a shell user account for each one of them. Actually, I already have all the users on a ldap directory. Could it be somehow possible to grant access to users authenticated through ldap, but without having to give those users shell access?
<ricardokirkner> (that is actually how I am doing today.. svn authenticates to ldap, but the users cannot access shell on the server)
<sabdfl> ricardokirkner: i'm not sure you need to grant shell access, you can setup a restricted login which only lets them run ssh
<jelmer> ricardokirkner: svn uses LDAP via apache's mod_auth_ldap ?
<ricardokirkner> jelmer,  actually through mod_svn_dav
<ricardokirkner> and maybe mod_auth_ldap too , I am not quite sure on that
<ricardokirkner> I have apache standard acl but pointing to an ldap branch (which I didnt create but someone else, that's why I am not sure on the details)
<sabdfl> ricardokirkner: https://lists.ubuntu.com/archives/bazaar/2008q1/037100.html
<ricardokirkner> sabdfl, thanks, I was just recently looking at the bzr_access tool, but that would require each user to have their ssh-key to be uploaded to the server, and thus use passwordless authentication, which is not exactly what I  was looking for.  besides, I would need to create a unique user that would hold all the ssh keys, right? and then I have to specify all my users ssh-keys in that users authorized_key file, right?
<ricardokirkner> I can currently make my system authenticate users to ldap (via pam) but don't allow them login access,. I don't get why I need login access in order to push my changes
<ricardokirkner> I also tried the bzr smart server, thinking that maybe the default transport (sftp) was actually trying to execute the bzr client on the server side, and that was the reason for it to require login access, but I got the same results
<Peng> sftp doesn't execute the bzr client on the server side. It uses SFTP.
<Peng> bzr+ssh does execute the bzr client on the server side.
<ricardokirkner> Peng, thanks for clarifying that
<Peng> If you're using bzr+ssh, I would think you do need logins: it basically sshes in and runs "bzr serve --inet --directory=/".
<Peng> I dunno how SFTP works.
<lifeless> Peng: sftp and ssh are the same as far as auth goes
<lifeless> Peng: 'login' means 'have a shell account' - you don't need that for sfpt or bzr+ssh
<Peng> Oh.
<Peng> Okies.
<Peng> Is "okies" annoying?
<radix> who you callin' a oakie
<ricardokirkner> lifeless, if you don't need a shell account for sftp or bzr+ssh, how comes I cannot checkout/commit/... when I have my shell set up to /bin/false?
<lifeless> ricardokirkner: you need a sufficient shell to spawn bzr
<lifeless> ricardokirkner: because of how ssh hands off its commands; thats what the bzr_access program does AIUI
<ricardokirkner> but then, I need one user that has a valid login shell, in that users .ssh/authenticated_keys file I setup one line per developer pointing to the bzr_access file, and I need to have bzr_access.conf in my repo giving the current access for each developer, right?
<lifeless> vila: rfc 2616 section 4.2 - I've quoted the relevant bit for you in bugmail
<lifeless> ricardokirkner: that sounds plausible yes
<ricardokirkner> now, when I do bzr co sftp://user@host/path/to/bzr/branch, I have to specify the user that has a valid login, right?
<ricardokirkner> that seems like a lot of work
<lifeless> hmm
<Peng> Does bzr_access work with sftp?
<lifeless> Peng: I wouldn't expect it too; I could be wrong
<vila> lifeless: "Field names
<vila>    are case-insensitive." ?
<ricardokirkner> it is quite a turn down for people trying to migrate form another authentication scheme... (I am trying to convince my boss to migrate  from svn to bzr, but with so many hindrances, I am quite unsuccessful)
<lifeless> vila: yup
<lifeless> vila: field name -- header name
<vila> so www.gnone.org is buggy. I will commit a patch working around the problem anyway.
<lifeless> indeed
<vila> lifeless: ok, the patch is one line code and ~20 comment lines of explanations :)
<lifeless> ricardokirkner: so what you had with svn was a one time setup against ldap, and that was that ?
<lifeless> ricardokirkner: and are you aware you can run bzr's smart server via http ?
<lifeless> so you should b e able to use the same apache setup to authenticate users for bzr
<ricardokirkner> lifeless, I am aware of bzr+http, but I cannot get it to give me write access
<ricardokirkner> that is what this is all about
<ricardokirkner> authentication through bzr+http is working perfectlyu
<ricardokirkner> but the problem is I cannot write to the repo
<lifeless> does the apache user have write permission?
<ricardokirkner> I am using a bzr user for the smart server, and the apache user belongs to the bzr group, and the repo has group write permissions. that should be enough, right?
<gour> ricardokirkner: talk to your boss about bzr's advantages ;)
<MachinShin> hey guys q. trying to check out a project and i get "unable to create symlink", i'm on windows, seems there's a plugin: https://launchpad.net/bzr-win32symlinks  that can resolve it, but how do i install it?
<lifeless> ricardokirkner: well, if apache is setuiding sure
<ricardokirkner> gour, I have already been, but when it comes to the real life, and you spend about a week trying to reproduce the old setup and you don't get it (which might be my fault, I dont say its bzr fault), you cannot expect much credibility
<lifeless> MachinShin: bzr --version will tell you the plugin directory - put the plugin in that directory with a simple name like 'win32symlinks'
<gour> ricardokirkner: maybe it's time to 'upgrade' the old setup
<lifeless> ricardokirkner: I'm happy to debug this from first principles; I can tell you my first guesses are one of two things:either bzr is not finding the smart server and is using http, or the back end user doesn't have write permission in the repoisotry
<lifeless> gour: ricardokirkner seems to have head screwed on straight
<lifeless> gour: more sysadmin overhead would not be a win on its own.
<MachinShin> lifeless: ok thanks, i'll try that
<ricardokirkner> lifeless, sorry for my bad english, but what does 'have head screwed on straight' mean?
<gour> ricardokirkner: we pray that you succeed in adopting bzr
<ricardokirkner> gour, I hope so too, for I am unwilling to give up, although it certainly drains one's energy
<ricardokirkner> (to be unsuccessful)
<gour> changing paradigms is never easy, but it pays off in the long run
<MachinShin> annoying that it hasn't been integrated into bzr yet, the plugin is nearly 2 years old :/ seems like base functionality
<lifeless> ricardokirkner: it means you are doing things well, sensibly
<ricardokirkner> lifeless, well, thank you for that :-)
 * beuno grumbles. I lost access to my server and, with it, access to several pings during the night
<lifeless> MachinShin: win32 has several different symlink answers though;
<beuno> vila, emails answered  :)
<MachinShin> lifeless: ok, pick one then :)
<lifeless> MachinShin: remember the link and don't make on disk, cygwin symlnks, .lnk files etc
<vila> beuno: thanks, dinner time here, gotta go
<Pilky> anybody have a clue how long it usually takes between a new version of bazaar being released and the OS X installer packages appearing?
<lifeless> a day or so I think
<Pilky> good good
<MachinShin> lifeless: the cygwin solution this plugin uses seemed to work for me :)
<MachinShin> anyways thanks for the help :) i'm good to go now
<lifeless> ricardokirkner: so; first test, with bzr+http -
<ricardokirkner> I am right at it...
<lifeless> ricardokirkner: do soemething like 'bzr info -Dhpss bzr+http://YOURURLHERE'
<lifeless> ricardokirkner: and check in ~/.bzr.log
<ricardokirkner> ok
<lifeless> if a hpss server is present, you will see debug details, about the time each command takes to run
 * gour thinks that #bzr community rocks
<lifeless> thanks :)
<gour> as well as bzr itself ;)
<ricardokirkner> lifeless, ok, I think I am getting closer to the problem. apparently it is seeing the smart server, but cannot find the repository, because it is constantly asking for the same location (although being told to descend  in the hierarchy). I think I have seen this issue in the past few days being mentioned. I am using bzr 1.4... maybe this was fixed in 1.5?
<lifeless> 1.4 should work fine - you have 1.4 on client and server?
<lifeless> feel free to pastebin the log message, it might help me be clear on what you are seeing
<ricardokirkner> yes, just upgraded 1.5 in client, and was about to do the same on server
<ricardokirkner> I get: BzrDir.find_repositoryV2', '.', which returns 'ok', '..', 'yes', 'no', 'no', but the next line is again BzrDir.find_repositoryV2', '.'
<ricardokirkner> always to the same url
<ricardokirkner> in (to ... )
<ricardokirkner> lifeless, ok, this is actually a reported bug: #230550
<Pilky> just had a friend ask me if there's any hosted services for bazaar similar to gitnub, anyone know of any (this is for private projects so launchpad is out)
<Peng> Lau...oh, private.
<Pilky> heh
<lifeless> statik: ^
<lifeless> bug 230550
<ubottu> Launchpad bug 230550 in bzr "bzr+http repeatedly queries the wrong location for BzrDir.find_repositoryV2" [Undecided,New] https://launchpad.net/bugs/230550
<lifeless> ricardokirkner: garh;
<lifeless> ricardokirkner: I suspect its something reusing a smart medium rather than recreating, and normalising from the original path; or some such
<lifeless> spiv: ^ for when you get up on Monday :)
<lifeless> ricardokirkner: its bedtime for me; but if its not been looked at tomorrow I'll have a peek
<ricardokirkner> lifeless, thank you very much for your help
<ricardokirkner> goodnight :-)
<lifeless> night :)
<Peng> Anyone interested in making bzr-hello compatible with bzr.dev? :D
<weigon> jelmer: does bzr-svn 0.4.9 work with bzr 1.5 ?
<weigon> the ubuntu package says no
<Peng> weigon: 0.4.10 does.
<weigon> k
<weigon> which brings us to:
<weigon> bzr-svn: Depends: python-central (>= 0.6.6) but 0.6.5ubuntu1 is to be installed
<weigon> taking jelmers .debs. from samba.org
<gour> there is no wonder that someone is lifeless here if there are 423 bugs related to him
<beuno> anyone around?
<beuno> all ssh keys seem to get rejected in LP
<Peng> Hey, you're right.
 * gour wants to upload ssh key
<Peng> Launchpad is broked right now. See #launchpad
<gour> right, it behaves strangely
<j^> http://launchpadlibrarian.net/14566578/bzr-1.5.tar.gz times out here, where can i find a copy of bzr-1.5.tar.gz?
<beuno> j^, launchpadlibrarian is down
<j^> and that is the only place i can find 1.5?
<beuno> they're working in it
<j^> great, hope its not all that big of a problem, good luck
<beuno> j^, librarian es back up
<j^> beuno, thanks
<Pilky> I'm getting a little confused between init-repo and init, am I correct in thinking that all the former does is set up stuff to aid in performance and the latter is what creates the actual .bzr file and allows me to start doing version control
<Pilky> s/file/folder
<Peng> Pilky: init-repo creates a shared repository and init creates a branch. Both involve .bzr directories.
<Peng> Pilky: But you're basically correct.
<Pilky> ok, just double checking
<Pilky> thanks :)
<Pilky> and I could commit directly into a shared repository if I wanted?
<radix> no, you can only commit to branches
<Pilky> ok
<radix> the branch will store the revision data in the shared repository, if there is one
<Pilky> if I've just started version control on a project by doing init, can I create a folder, do init-repo and then move the existing project into that?
<radix> Pilky: you should use 'bzr branch' to migrate the branch into the new shared repository
<Peng> Pilky: Well, yeah, but it won't use the shared repo. 'bzr reconfigure' may be able to help.
<ricardokirkner> radix, and what happens it the repo's .bzr folder suddenly disappears? is then the branch corrupt, and all data lost? or is it possible to recover it?
<Pilky> ok, fair enough, thanks
<radix> ricardokirkner: if you lose the shared repository's .bzr folder, then yes, you're up a creek
<radix> ricardokirkner: that's where all the revision data is stored
<Pilky> ricardokirkner: at that point you start doing backups ;)
<ricardokirkner> yeah.. it was a curiosity. what is stored in the branches .bzr folder, when you have a shared repo?
<ricardokirkner> i guess branch-only data... but the question is actually
<ricardokirkner> whenever you commit something , the branch first asks the repo if that information is already shared and stores it in the repo (and otherwise in the branch) or how is that made?
<Peng> ricardokirkner: A branch is basically just a list of revisions, and some configuration data (like the parent branch, where you push, etc.). A repo is a big pile of revisions, and it's what takes up all the disk space. Shared repos let multiple branches use the same repo, so if they're related, they don't duplicate the data.
<radix> to be specific, a branch is just a list of revision IDs
<Peng> Yeah.
<Peng> (In fact, in recent formats, .bzr/branch just stores the most recent revision ID, and the rest of the data is figured out from there. But anyway...)
<ricardokirkner> Peng, so actually all the data is stored in the shared repo, and the branch only holds the revision ids
<Peng> ricardokirkner: Yes.
<ricardokirkner> so that in the worst case, if a branch .bzr folder, it could (theoretcally) be reconstructed
<ricardokirkner> if a branch .bzr folder is "lost"
<Peng> ricardokirkner: Yeah, it could.
<ricardokirkner> ok, i understand, thanks
<pickscrape> What would be the pros/cons of bzr+ssh vs bzr+http?
<pickscrape> Security being a non-issue since this would be on an internal network.
<jelmer> weigon, no, you need 0.4.10 for bzr >= 1.4
<ricardokirkner> pickscrape, from what I was trying out at our company, using bzr+http you can use ldap authentication without having to have a shell account for each user
<ricardokirkner> on the other hand, ssh is more secure, but you say that doesn't matter to you
<pickscrape> And are you able to use standard apache configuration directive to, say restrict certain users to certain branches etc?
<ricardokirkner> generally speaking, I think using bzr+http gives you more authentication options
<weigon> jelmer: and the py-central dependency in your .deb packages ? is that a must ?
<pickscrape> Any experience on the performance differences between the two?
<weigon> you require 0.6.6, ubuntu hardy has 0.6.5
<ricardokirkner> pickscrape, I think it might be possible, but you will have to try it out
<pickscrape> Oh yes, I have a lot of experimentation to do :)
<ricardokirkner> pickscrape, no
<pickscrape> Always handy to be armed with as much knowledge as you can though before wading in...
<ricardokirkner> :-)
<ricardokirkner> I was having this issue the whole week with bzr+http
<ricardokirkner> and I just found out that it wasn't working because some bug introduced in bzr 1.4
<ricardokirkner> so you have to be careful
<ricardokirkner> bzr+http is somewhat buggy
<pickscrape> I'll keep that in mind.
<jelmer> weigon, It's added by python-central itself
<ricardokirkner> I mean, not so well tested as bzr+ssh
<pickscrape> I'm mostly concerned with which one gives the best performance and authentication options
<jelmer> weigon: it's not there in the source package
<pickscrape> I can imagine that ssh might have more overhead (logging in, starting shell, encryption etc)
<jelmer> weigon: you should be able to just rebuild the package to get rid of that dependency
<weigon> jelmer: ok, I'll build the package from source there
<weigon> yep
<ricardokirkner> pickscrape, I imagine that too... but I wouldn't worry too much about that, since bzr is inherently slow
<ricardokirkner> so I don't think that any option would provide significant improvements
<Peng> If for some reason you're using knits and don't want to upgrade to packs, hpss makes a huge difference.
<message144> Hi.. Just curious about something. I am considering switching my project to bzr. I read an article that said that bzr has not really experienced wide project adoption except for Ubuntu. I am curious if there are any opinions as to why this is the case?
<j^> is there something like svn:externals in bzr by now?
<Peng> j^: It's in progress.
<Pilky> message144: I was reading something earlier about how there were quite a few largish projects that used it but moved away due to early performance problems
<Peng> Yeah. Bazaar lost out on the big projects (OpenSolaris, Mozilla) due to performance.
<Peng> It's getting better all the time, and is definitely good enough for non-huge projects though..
<message144> hmm.. performance is the least of my concerns
<Pilky> it's still not the fastest now, though I'd take an extra second or two to execute a command over having to try and wrap my head around git
<Peng> In some specific areas, I think it is the fastest, or at least really close.
<Peng> But generally not.
<message144> My biggest concern more than anything else is community support, ease-of-use, then data integrity
<Pilky> message144: I believe drupal uses bzr
<message144> perfromance is lowest on my list of priorities
<ricardokirkner> well, I must say, community support is superb
<ricardokirkner> :-)
<pickscrape> Yes, I've been very pleased with the community support.
<pickscrape> I'm not scared of asking 'silly' questions like I was in the git community.
<j^> is i have an svn branch is there any chance bzr-svn would pick that up so the two bzr repositories would have a common ancestor?
<message144> yeah i felt pretty stupid asking some pretty basic stuff in #git
<message144> heh
<Pilky> message144: also, while it's not big in terms of code, the Sparkle update system for the Mac moved over to bzr a little while ago
<jelmer> j^: can you rephrase perhaps? I don't really understand what you mean
<weigon> jelmer: dpkg-buildpackage -uc -b ... works as expected, thx
<Peng> j^: If two people use bzr-svn to branch from svn, the two bzr branches will be related.
<j^> jelmer, i started a branch in svn, now i checkout trunk and the branch via bzr-svn the bzr repository of the branch only starts at the point of the last svn copy
<j^> if bzr-svn would also checkout the things before the copy they should have a common root
<jelmer> j^: it should follow copies of the branch root - is that what you mean?
<j^> with bzr-svn 0.4.10 it stops here i.e. bzr branch https://svn.xiph.org/branches/theora-thusnelda has only  83 revisions
<jelmer> j^: /trunk/theora is not considered a branch so it's not made part of the history
<j^> those are all commits that happened in the branch. the branch was started with svn copy trunk/theora branch/theora-thusnelda
<jelmer> if it was copied from /trunk or /branches/foo, it would've followed the copy
<jelmer>  /trunk/theora not being considered as a branch is bug 130372
<ubottu> Launchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/130372
<j^> ic
<j^> otherwise the new version works great
#bzr 2008-05-18
<jelmer> w00t, got "bzr builddeb <remote-url>" working :-)
<alecwh> ï»¿Hello! I want my bzr repository to be something that any user can just clone for the latest version possible of the software. The only problem is, I have a "config.php" file that needs to be changed after a clone, because a variable needs to be set to "$installed = 'no';". However, my local copy has it to 'yes' because that's what I use for myself. So, is there any way that bzr can just "ignore" that config.php to any changes, and just leave 
<bob2> have a seperate branch
<bob2> although then you can only merge one way
<alecwh> oh, so just merge branches whenever I make a change?
<alecwh> but that will merge the config.php's (and probably have a merge conflict), because they are different, correct?
<jelmer> alecwh: alternatively, you may just want to include a file "local-config.php" from your config.php that isn't versioned
<jelmer> perhaps only if it exists, and set "$installed = 'yes'" if it doesn't
<alecwh> jelmer: good idea actually... but if bzr doesn't recognize it, then it won't be uploaded with the repository.
<jelmer> alecwh: yes, but you would be the only one who would have to have that file
<jelmer> users who wouldn't have it would just get the default configuration
<alecwh> oh okay. I'll try that out, thanks jelmer.
<alecwh> =)
<alecwh> wait - what does bzr ignore do?
<bob2> stop bzr status complaining about files being unknown and 'bzr add .' from adding them
<alecwh> oh, ok.
<bob2> (you can still add them by giving their specific name)
<nekohayo> ugh, for some reason I am still not able to rebase with bzr 1.5, getting tracebacks, can anyone help me figure out if it's me doing something wrong or if it's a bug?
<jearl> cspam
<alecwh> I'm trying to get bazaar to work with http://cia.vc to send my commits to IRC channels, but I'm stuck. Does anybody know how to do this?
<bob2> you're using the bzr cia thing?
<gour> is this "Another possible use for a checkout is to use it with a treeless repository containing your branches, where you maintain only one working tree by switching the master branch that the checkout points to when you want to work on a different branch." common 'bzr-idiom' when for local development?
<gour> s/when for/for
<gour> my xdg_email is empty...anyone use Gnus with bzr?
<vila> gour: I use bzr and I use Gnus, what is your question :)
<bob2> I don't even have a xdg_mail
<vila> gour: no need for a Gnus mail client, just add 'mail_client = emacsclient' in ~/.bazaar/bazaar.conf and add (server-start) to your ~/.gnus
<vila> gour: I said ^ a few days ago, did you read it ?
<gour> thanks
<gour> vila: no, i missed it
<vila> gour: hmm, yeah, re-reading logs, you left just before I posted it :) Sorry, I missed that detail :-/
<gour> ta
<vila> gour: what exactly means 'ta'
<vila> I understand the 't' is for thanks but the 'a' ?
<gour> 'alot'
<spiv> "ta" is just a short way to say "thanks".
<gour> :-)
<vila> spiv: hi !
<spiv> vila: good evening
<vila> I'm looking at bug #230223, but I feel out of my league :-/
<ubottu> Launchpad bug 230223 in bzr "smart server probing in 1.4 breaks check outs of short bus http repositories [regression]" [High,Confirmed] https://launchpad.net/bugs/230223
<spiv> vila: sorry, I'm just passing through...
<vila> my understanding so far is that smart server probing is not prepared to receive a 403
<vila> spiv: ok, no worries
 * spiv -> dinner
<alefteris> i upgraded my local branch to rich-root-pack, then I'm trying to do the same with the launchpad.net hosted branch, but I get this: "bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format."
<alefteris> when i try to do bzr info at the launchpad branch i get "Standalone branch (format: unnamed)". What am I doing wrong?
<lifeless> alefteris: for the launchpad branch you need to upgrade using sftp; that should work
<alefteris> lifeless, thanks, I had to install paramiko as well and all went fine :)
<jelmer> nekohayo, please file a bug report
<lifeless> jelmer: bzr pull from bzr-svn - is it mainly slow cause of bzr ?
<jelmer> lifeless: yes
<jelmer> lifeless, there are some minor bits that can be improved in the fetch code of bzr-svn but it's mainly in the bzr-side of things
<jelmer> lifeless, are you doing a pull that appears to be too slow?
<bob2> did the bzr-gtk trunk get rebased?
<jelmer> bob2
<jelmer> no
<lifeless> jelmer: I was showing ted gould from inkscape
<lifeless> jelmer: and it was doing a revision every 30-40 seconds ot so
<lifeless> which is rather appalling :P
<bob2> oh, bah, ~bzr/bzr-gtk got killed 6 months ago and I didn't notice
<jelmer> lifeless: Wow, ok. Worst I've seen is once every couple of seconds
<jelmer> lifeless: Any idea what is being so slow?
<jelmer> lifeless, are you trying this with a local svn repository?
<jelmer> sourceforge can be really slow sometimes
<jelmer> lifeless: I'm just trying it as well now, and it's taking 2 seconds to reply to each request
<jelmer> lifeless: so, when are shallow branches going to land ? :-P
<lifeless> jelmer: argh, 2 second latency on the server is explainable :)
<lifeless> jelmer: could we show that in thhe ui/log file somehow ?
<jelmer> lifeless: we are, but the progress bar is sometimes hidden for some unexplainable reason
<jelmer> there are progress bars being displayed from inside bzr-svn
<jelmer> s/displayed/created
<hsn_> zr: ERROR: No such file: 'http://bazaar-vcs.org/bzr/bzr.dev/.bzr/repository/indices/b072a80d0242839227870cba3a3e0f9b.rix'
<hsn_> repo moved?
<lifeless> hsn_: probably a push going through at the time you were reading
<lifeless> hsn_: just try again
<lifeless> hsn_: there is a bug open - this is something we should retry on
<hsn_> lifeless: it works now
<jelmer> lifeless: inkscape isn't exactly fast here either; does about one revision every two or three seconds
<jelmer> lifeless: seriously though - what's still left for shallwo branches?
<lifeless> jelmer: thats faster than we were seeing
<lifeless> jelmer: well the prototype branch is there for testing; you should be able to do bzr-svn work for it now
<lifeless> jelmer: I'm working on optimisations now - inpartcular exposing historic texts on all repositories
<jelmer> lifeless: where's the branch?
<lifeless> jelmer: mumbke shallow-branch or somthing
<lifeless> http://www.google.com/search?q=bzr+shallow+branch&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a
<lifeless> its in that list :)
 * jelmer wished he could do "lp list-branches bzr | grep shallow"
<jelmer> lifeless: how stable is that API supposed to be, and what are the chances it's going to be in 1.6 ?
 * jelmer doesn't want to go through similar issues as rich roots
<lifeless> jelmer: hopefully the external API is done
<lifeless> I would like it if you worked with me on a beta-bzr-svn branch to use it
<lifeless> jelmer: that would be better than waiting for me to be 'done' and then findingout its missing/bad for you
<lifeless> jelmer: just don't offer it to 'users'.
<jelmer> lifeless: I'm happy to work on "beta" support in bzr-svn, I'm just trying to avoid participating in the process too early
<jelmer> and having to maintain a bzr-svn branch through API changes and months of bzr releases
<acuster> hey jelmer! Any chance you'd be willing to flesh out your answer to the last FAQ: http://samba.org/~jelmer/bzr-svn/FAQ.html ?
<jelmer> acuster: What specifically?
<acuster> it bit me enough that I'm being pushed towards mercurial but I suspect bzr handles svn copy better than hg
<acuster> I did a push back to svn, possibly with an --overwrite I don't remember, and the operation deleted the whole trunk and pushed us back to where I had converted from
<acuster> so I gather I deeply misunderstood how bzr and svn go together
<acuster> so specifically
<acuster> that and it are vague
<acuster> I'd like a recepie possibly with why
<lifeless> jelmer: I would help maintain such a branch
<lifeless> jelmer: work goes >> when many hands
<jelmer> acuster: I updated the FAQ
<acuster> thanks
<jelmer> lifeless: Thanks, that'd help
<acuster> I'll try to get a better grip on my question when I can use 1.5 on this hardy
<lifeless> jelmer: have you seen my status mails ?
<jelmer> lifeless: no, I haven't - a quick search for "shallow" in my bzr mailbox doesn't list anything
<jelmer> lifeless: also, the only "shallow" branch from you on launchpad is 11 weeks was last changed in february
<bob2> it's on p.u.c
<jelmer> http://people.ubuntu.com/~robertc/baz2.0/shallow-branch/ ? that's the one that hasn't hcanged since feb
<nekohayo> jelmer: hey, it seems it stopped giving me tracebacks! http://pastebin.ca/1021882 but I get a bunch of conflicts. should bzr replay be done with -r2.. (revision 2 is identical in contents) or the revision that followed?
<jelmer> nekohayo: the branches probably have different file ids
<nekohayo> jelmer: well, I assume so, they were different branches... what do I do?
<jelmer> the maptree stuff should be able to help there (it makes rebase/replay use paths rather than file ids) but that's not hooked up to the rebase ui yet (only used by svn-upgrade)
<jelmer> so it's not really possible to use rebase/replay in this case
<nekohayo> >_<?!
<nekohayo> I don't exactly see what's so unusual with my case :|
<jelmer> different file ids
<nekohayo> jelmer: what is a fileid actually? and how could branches that were not historically connected ever have matching file ids?
<jelmer> nekohayo: a file id is a unique string that identifies a file. It's generated when it is first added to bzr
<jelmer> nekohayo: there's no way for historically not connected branches to have the same file ids
<nekohayo> so there's no way to go further now? solving the conflicts wouldn't do it?
<jelmer> nekohayo: you can use diff + patch manually to replay each commit so you end up using the file ids from the branch you're building on rather than the branch you're replaying
<nekohayo> basically recommitting everything by hand
<jelmer> yes
<jelmer> I'm not aware of any bzr plugins at that can do that for you
<jelmer> rebase/replay could do it if you hooked up the maptree stuff
<nekohayo> how hard is that?
<jelmer> should be a matter of adding a call to MapTree() in the function that replays a delta in rebase
<lifeless> jelmer: yes, thats right - I've been working on 'VersionedFiles' the consolidation of knits etc
<lifeless> jelmer: that will let me loosen the constraint on version locking in shallow-ranch, and also get good performance for checkout() over the network.
<nekohayo> rebase.py:410:def replay_delta_workingtree(wt, oldrevid, newrevid, newparents,
<nekohayo> jelmer: I see that there is a file bzr-rebase/site-packages/bzrlib/plugins/rebase/test_maptree.py
<nekohayo> but I don't understand it
<jelmer> nekohayo: you'd need the code in maptree.py
<jelmer> and wrap the other tree specified to merge in replay_delta_workingtree() with MapTree()
<nekohayo> x_x beyond my skillset I guess
<nekohayo> or is there a bug/blueprint I can subscribe to for rebase to support maptree?
<jelmer> no, though you could file one
<Verterok> Hi
<Verterok> nekohayo, jelmer: maybe using fastexport/fastimport to replay the commit?
<Verterok> s/commit/commits/
<lifeless> jelmer: so look for those mails :)
<lifeless> vila: isn't your new POST bug a dupe?
<vila> lifeless: I was unsure and wanted a reference to put in my merge request for #230223
<vila> lifeless: bug #231649 is for the *test* servers
<ubottu> Launchpad bug 231649 in bzr "http test server can't handle POST" [Undecided,Confirmed] https://launchpad.net/bugs/231649
<lifeless> vila: anyhow, do you have time to look at http vs sftp pull performance?
<vila> ghaaa, still trying to clean up my plate, I think I shoudl decline :-/
<vila> I really really really want to write that use-a-real-server-for-tests plugin now
<vila> lifeless: wait a minute, what are you talking about ? http vs sftp ? Care to help me page in ?
<lifeless> vila: couple days ago
<lifeless> vila: kinnison was saying 'pull never utilises full bandwidth'
<lifeless> vila: I said 'try sftp'; he did and it maxed his link out
<lifeless> vila: he had been pulling over http
<vila> so sftp utilizes full bandwidth but http not ? If it's with urllib, that's a regression from the time I rewrote the streaming part.
<vila> trying.
<vila> branch uses full bandwidth AFAICS, or not ? Seems like many pack files are involved.
<vila> sftp doing asynchronous IO thanks to paramiko may explain a bit of difference
<nekohayo> jelmer: think that could work?
<jelmer> nekohayo, not familiar enough with fastexport/fastimport
<nekohayo> Verterok: never tried them, any pointers how to go about it?
<vila> lifeless: indeed, pull seems worst than branch for bandwith (did a test with bzr branch -r 3300 bzr.dev tests; cd test; bzr pull bzr.dev
<jelmer> lifeless, any chance you can merge bzr.dev in your shallow branch branch?
<Verterok> nekohayo: I'm not an expert, but played a bit with it :)
<Verterok> nekohayo: first do an fastexport of the branch, then you can write your own  processor to filter whatever you need to
<Verterok> and do a fastimport, using the your custom proccessor
<lifeless> jelmer: I will, once I have all tests passing with no repository._revision_store
<lifeless> jelmer: e.g. probably tomorrow
<jelmer> lifeless, ok
<vila> lifeless: bzr: ERROR: Not a branch: "sftp://vila@bazaar.launchpad.net/~bzr/bzr/trunk/ ???
<bob2> are you a member of the bzr group?
<vila> bob2: I hope so :)
<bob2> hehe
<lifeless> vila: ?
<vila> lifeless: shouldn't there be a branch there ?
<lifeless> interesting
<lifeless> vila: no
<lifeless> vila: its not hosted on launchpad
<lifeless> vila: its mirrored there only
<vila> simple, clear. Thanks lifeless :)
<abentley> vila: We are hoping to make our sftp and bzr+ssh services behave the same.  So that branch might be available on sftp after the next launchpad release.
<abentley> vila: I worked on that with jml.  It was rather tricky because the sftp server is twisted, and bzr+ssh is synchronous.
<vila> abentley: thanks for the info, what I was searching for was a branch that I can access with http and sftp with the same network context cot ompare respective performances, I totally forgot that I was accessing different hosts on lp, so...
<vila> s/cot/to/
<abentley> vila: I think the host is the same in both cases.  The problem is really that there are two different areas on launchpad; the hosted area and the mirrored area.  http gives access only to the mirrored area (which contains copies of hosted branches).  sftp gives access only to the hosted area.
<abentley> bzr+ssh gives access to both, preferring hosted.
<vila> abentley: thks.
<abentley> np
<vila> grr, what is the difference between code.lp.net and bazaar.lp.net ? bazaar is giving me a 502 Bad Gateway after a 215s timeout where code seems to issue a redirection (triggering a bug in the nosmart+ decorator by the way) 8-(
<beuno> vila, I think code.lp is used for the web app, and bazaar.lp is for actual branches
<beuno> morning  :)
<vila> beuno: hi :)
<vila> !paste
<ubottu> pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic)
<lifeless> see you all tomorrow
<MachinShin> hey guys, getting this error, what can i do to fix it? ->bzr: ERROR: Unsupported protocol for url "sftp://<censored>/trunk": Unable to import paramiko (required for sftp support): No module named paramiko"
<mwhudson> beuno: damn loggerhead -- i bounced it
<jelmer> MachinShin, install paramiko
<MachinShin> thanks jelmer
<Peng> Ok, this is weird. I'm reading Ben Finney's posts on the mailing list while watching the Star Trek TOS episode about Lt. Cmdr. Ben Finney.
<pickscrape> Maybe they used bzr for source control when programming the LCARS system?
<thumper> morning
<thumper> jelmer: are you available for a few questions?
<jelmer> thumper, hi
<jelmer> thumper, sure
<thumper> jelmer: There are two branches on launchpad that are causing many errors right now
<thumper> jelmer: and both are bzr-svn branches
<thumper> jelmer: one is yours, and one is a friends
<thumper> jelmer: LP is failing to scan them properly as it is failing some basic integrity checks on revisions
<thumper> jelmer: one thing we do is to check the revisions to make sure that the parentage hasn't changed
<thumper> jelmer: but for these two branches it appears that between scans, the parents of some revisions did change
<thumper> jelmer: I was under the impression that bzr revisions didn't change once they were created
<jelmer> thumper, that's correct
<thumper> s/didn't/shouldn't/ ?
<jelmer> which branches are these?
<thumper> https://code.launchpad.net/~jelmer/python/trunk is one
<thumper> RevisionModifiedError: parent svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:55872 was added since last scan
<thumper> jelmer: that is the error I am seeing
<jelmer> to which revision was that parent added?
<thumper> jelmer: unfortunately I don't think I have that information easily to hand
<thumper> jelmer: what can I provide in order to help track this down?
<jelmer> thumper: details about which revision apparently changed parents
<thumper> ok
<thumper> is that all?
<jelmer> thumper: Also, is this integrity checking done across branches?
<thumper> jelmer: yes
<thumper> that may be the underlying problem
<thumper> we store a copy of the revisions in the database
<jelmer> in that case it's probably that one of the branches was created using an experimental version of bzr-svn
<thumper> which includes parentage
<thumper> hmm...
<thumper> this is an interesting problem to solve then
<jelmer> thumper: I think one of the branches just has to be thrashed
<thumper> jelmer: is there any way to determine which branch is the one created with the experimental bzr-svn?
<jelmer> well, recreating that branch using a stable version of bzr-svn
<thumper> jelmer: ok, thanks
<xif> How, and how well, does bzr support the following development process:
<xif> The project has the following root directories: /linux, /osx, and /osx-diffs. Each time a developer commits /linux/foo.conf, the SCM applies the /osx-diffs/foo.conf.diff to it, and then commits it /osx/foo.conf.
<xif> (commits it as the file /osx/foo.conf)
<thumper> xif: sounds like a candidate for looms
<thumper> xif: as long as you didn't have bidirectional diff application
<thumper> xif: you could have /linux as the base thread
<thumper> xif: and /osx os the next thread
<thumper> xif: and the difference between them is effectively the /osx-diffs
<thumper> xif: there is an export-loom command that can create branches for each thread
<xif> thumper: very cool... I'm looking at this right now
<thumper> xif: you would commit on /linux
<thumper> xif: then switch up to /osx
<thumper> xif: and merge, resolve and commit
<thumper> at least that is how I think it would work
<xif> yeah, it definitely looks interesting...
<xif> I'm reading about it right now: http://blogs.gnome.org/jamesh/2008/04/01/bzr-loom/
<xif> thumper: thanks for the recommendation :)
<thumper> xif: np
<Peng> Wouldn't branches work too?
<xif> Peng: how, exactly?
<Peng> I dunno.
<Peng> I have very little experience with looms, but how are looms better than branches for this? Avoiding lots of merge revisions?
<awilkins> I have a feeling I should have used looms for one of my projects after reading that page
<awilkins> My example is patches to a set of model files (written as Java) ; one set of patches that was compatible with the old model, one that was for the new software and wasn't
<awilkins> I was managing that as two branches ; and I was making compatible changes in one branch and merging up to the other, but it sounds like I should have made a loom and had a compatible thread and an incompatible thread
<awilkins> It would at least have beem more conveneient
 * awilkins is tired and his fingers are slipping
<awilkins> I still don't think it easily addresses what to do when you are making changes and one part of them should be in a thread lower than you are on... I think you might have to shelve the bits that go in the higher thread, jump down a thread, commit, jump up adnd unshelve and commit
<awilkins> Anyhow, gnight.
<igc> morning
#bzr 2009-05-11
<igc> morning all
<igc> moening lifless, mwhudson
<igc> let's try that again ...
<mwhudson> hi igc
<igc> morning lifeless, mwhudson
<mwhudson> :)
<jml> lifeless: why doesn't aws-status read my access key from the same file as ec2test?
<jml> i.e. ~/.ec2/aws_id
<lifeless> it uses the same variables as bzr ec2test
<lifeless> and if it doesn't find it it will look in gnome-keyring too
<lifeless> you could file a bug to have it look at a file as well; AFAIK the amazon toolchain just looks for environment variables, which is why I copied that
<jml> lifeless: ok.
<jml> lifeless: the real answer might be "Why does Launchpad's ec2test use a non-standard file"
 * jml makes a note
<lifeless> of course, if the amazon toolchain does read a file, a bug on txaws is definitely in order
<jml> lifeless: yeah. I'll chase it up later.
<lifeless> thanks
<AfC1> lifeless: Robert, you're signing emails with a key that's not on the public keyservers. You might want to upload it somewhere.
<lifeless> AfC: odd, I have. it just hasn't propogated ><
<AfC> lifeless: It's not on subkeys.pgp.net or pgp.mit.edu
<AfC> lifeless: I would have thought you would have uploaded to them directly, seeing as how they're the main ones
 * igc working on branch-specific rules today
<lifeless> igc: you were going to mail about the issue; have I missed that ?
<igc> lifeless: nope - sending it today
<poolie> good morning
<thumper> how worried should I be about 2485 revisions missing parents in ancestry and 3547 inconsistent parents?
<lifeless> thumper: it will be affecting the output of annotate
<lifeless> the 2485 are the unimported arch revisions
<thumper> 2645 ghost revisions
<lifeless> oh hmm
<igc> morning poolie
<lifeless> then its filled in ghosts
<bob2> would it be sensible to have 'bzr bind' with no args pick one of the configured urls (maybe in order: parent, push, merge)?
<lifeless> you should reconcile anyhow
<poolie> helol igc
<lifeless> bob2: confusing
<poolie> will comment on your docs soon
<lifeless> bob2: as it already has a saved bound location
<thumper> lifeless: what will reconcile do?
<poolie> bob2: if it guaranteed to rebind just where it was last bound
<poolie> what he said
<lifeless> it will rewrite the parents
<thumper> to what?
<lifeless> to the correct value based on the data available in the repository
<bob2> lifeless: hm, I meant, only if it didn't have a previously saved one
<lifeless> bob2: still confusing, no
<bob2> ok
<lifeless> bob2: as in
<lifeless> bind (grabs parent)
<lifeless> pull x (sets parent in master and local)
<lifeless> unbind
<lifeless> bind
<lifeless> (does not grab parent)
<bignose> with Loggerhead, browsing a file gives me the âannotateâ view
<thumper> what's the status of bzr-hg?
<bignose> how can I just view the content of the file from head, without annotation?
<bignose> i.e. the URL formed has â¦/trunk/annotate/head%3A/README
<bignose> what URL should I use instead to just display the raw content of that revision of the file?
<lifeless> mwhudson: ^
<mwhudson> bignose: there is no view to display the raw content
<bignose> :-(
<mwhudson> bignose: because we're worried about xss attacks
<mwhudson> bignose: there is a branch which adds it somewhere, but we need a way to turn it off
<mwhudson> bignose: https://code.edge.launchpad.net/~intellectronica/loggerhead/view-file is one
<bignose> mwhudson: thanks for the response.
<lifeless> mwhudson: 'if hacked(): disable_it_now()' ?
<mwhudson> bignose: np
<mwhudson> lifeless: yeah
<lifeless> it would be nice to be able to get at plain text versions
<lifeless> its a pity that browser authors are insane
<bignose> mwhudson: actually on second thought: what XSS vulnerability?
<lifeless> [content sniffing]
<lifeless> bignose: I could upload arbitrary html to my branch
<bignose> shouldn't it be just a matter of serving the file as âContent-Type: text/plainâ?
<mwhudson> ha, ha, yes, it should
<lifeless> bignose: many browsers sniff content and ignore content-type
<lifeless> bignose: and there is now a 'standard' under discussion for controlling when the do this. Its insane
<bob2> haha
<bob2> is it enabled via a meta tag?
<bignose> lifeless: those broswers deserve to get pwned then :-)
<bignose> hmm, though I guess in that case it's the site getting pwned.
<lifeless> its batshit insane
<lifeless> and es
<lifeless> *yes*
<lifeless> http://www.nabble.com/NEW-ISSUE:-content-sniffing-td22795699.html
<lifeless> I should raise this on the wg
<bignose> yes, please. that's intentional brokenness
<bignose> it's like Reply-To field munging, except with hideous security vulnerability
<lifeless> http://tools.ietf.org/html/draft-abarth-mime-sniff-00 is the spec
<lifeless> mwhudson: in theory if you avoid all the holes in that, it would be safe to present it as application/octet-stream. Note that I haven't read the algorithm in sufficient detail to comment.
<lifeless> I just followed the surface discussions
<mwhudson> lifeless: that would be nice
<bignose> eugh. âtext/plainâ would be better
<lifeless> bignose: what would be? (no quotes please)
<bignose> content which can't display well as âtext/plainâ should be downloaded anyway IMAO
<mwhudson> but the fact remains that it's going to require a lot more effort to get right than it should
<bignose> lifeless: fix yer UTF-8 man :-)
<bignose> lifeless: text/plain
<lifeless> bignose: I want to; its somewhere down in xlib
<lifeless> bignose: we don't know what the type is as bzr doesn't encode mime types in its store
<bignose> (specifically in the context of showing content of a file under VCS)
<lifeless> bignose: so text/plain would be a guess, and work badly with showing a jpg, for instance
<bignose> lifeless: yes, that's why I'm saying the common denominator should be text/plain
<lifeless> its also likely that text/plain is one of the ones browsers sniff-up to html
<bignose> right, and application/octet-stream would be *just as bad* for non-text content
<bignose> lifeless: this was in direct response to you saying if-the-sniffing-problems-are-resolved
<lifeless> bignose: oh; so they won't be. Browsers are out there (including FF as far as I know)
<lifeless> the only way to resolve it is to implement http/2.0 and have a very large blacklist hammer for any nonconformant browsers that appear
 * bignose deprecates stupid people.
<lifeless> pragmatically thats not happening, so we have to a) convince authors not to be idiots from here on out, and b) work within the limits of whats out there
<lifeless> 'resist the temptation to guess' isn't something that ie or mozilla had heard, I guess.
<mwhudson> lifeless: i think the correct response to the issue in http://tools.ietf.org/html/draft-abarth-mime-sniff-00 involves a time machine and a very large bat
<eferraiuolo> I was wondering if it's built in or if you need the bzr-git plugin to run: bzr branch git:// commands?
<mwhudson> eferraiuolo: you need the git plugin
<eferraiuolo> mwhudson: cool, well I'm about to branch it then :-)
<Peng_> eferraiuolo: bzr-git depends on dulwich as well.
<lifeless> poolie: I think a script is better than trying to get all devs to change their bug filing behaviour :)
<poolie> it seems to me the importance needs to come from a human
<poolie> i don't see how a script can generate it
<poolie> it could make them all default to wishlist i guess
<poolie> that might force people to dtrt
<lifeless> medium seems fine to me
<lifeless> anyhow, my previous comment was 'when I've thought about I do', which seems valid to me
 * igc lunch
<poolie> BB seems to be down..
<lifeless> mondayitis
<poolie> not a good day for servers apparaently
<jelmer_> mwhudson: main improvement is that dpush to remote git repositories works now
<jelmer_> mwhudson: and pull from remote git repositories only does one smart protocol command now
<mwhudson> jelmer_: so nothing very interesting from a launchpad pov
<jelmer_> mwhudson: no, not really
<mwhudson> cool, less work for me :)
<mwhudson> jelmer_: i set up a samba import on staging :)
<jelmer_> mwhudson: :-)
<jelmer_> mwhudson: are there other git branches there yet that I can look at?
<mwhudson> well, some on staging
<jelmer_> which ones?
<mwhudson> but staging has just gone *bang*
<mwhudson> jelmer_: etckeeper, gedit, banshee
<jelmer_> re
<jelmer_> thumper: it can view history but that's it, no fetch
<lifeless> jelmer_: are you going to do some stuff to it?
<jelmer_> lifeless: Don't have anything planned atm, would be interested in doing so
<thumper> jelmer: what?
<jelmer_> thumper: bzr-hg
<thumper> jelmer: ah
<thumper> jelmer: how big a repo can bzr-git handle right now?
<jelmer_> thumper: I've imported samba on my desktop machine
<thumper> jelmer_: how big is that?
<thumper> in the big picture of things
<thumper> say compared to the kernel
<thumper> or evolution
<jelmer_> thumper: IIRC it's ~70k revisions, about ~3k files in the tree on average
<jelmer_> I'm not sure what the numbers are for the kernel
<jelmer_> evolution is smaller than samba, at least
<lifeless> less commits more files for the kernel, IIRC
<jelmer_> thumper: the #1 bottleneck is the inventory handling in bzr
<lifeless> jelmer_: in dev6 still?
<wgrant> Does CHK fix that?
<jelmer_> lifeless: dev6 is significantly better, but afaik the lp imports are still using 1.9
<jelmer_> lifeless: with dev6 inventory handling accounts for 20% of the CPU time during git imports
<lifeless> jelmer_: thats good; should be lower though
<jml> where is the mainline commit message policy for bzr documented?
<jml> I didn't realize that NEWS conflicts can never auto-resolve.
<igc> lifeless, poolie, jam: status update & proposed direction for branch-specific rules sent to the list now
<igc> jelmer_: ^^^
<poolie> hi igc
<poolie> igc re bug 345693 being closed
<ubottu> Launchpad bug 345693 in bzr-usertest "should test "bzr ls -r -1"" [Undecided,Fix released] https://launchpad.net/bugs/345693
<poolie> does that mean we should cross "Check performance of full inventory extraction" off the brisbane-core list?
 * igc looks
<poolie> ok so i see that means we now have a usertest for it
<poolie> and iirc it didn't turn out to be too slow?
<igc> poolie: I think it was slower but it's not a major deal for ls
<poolie> ok
<igc> it may be for other commands though
<poolie> so, not too many of them should be using it
<poolie> i'll cross it off for now
<igc> poolie: ok. I'll rerun the benchmark soon as well to see where it's at
<igc> poolie: on another topic, abentley has appointed you as the reviewer for his compositetree patch
<igc> poolie: that makes you the bottleneck :-)
<igc> poolie: he wants you to say wwhether the design doc is now sufficient or not to proceed
<poolie> :)
<poolie> ok
<lifeless> popping up to the chemist, back soon
<lifeless> jelmer_: oh, I know why it was slow for you to push cross-format
<lifeless> jelmer_: it's john's changes to IDS
<lifeless> poolie: 374726 for vila
<lifeless> poolie: I suspect thats more than a day to have a good answer on
<lifeless> poolie: so I'll look for other things tomorrow
<poolie> bug 374726
<vila> hi all
<ubottu> Launchpad bug 374726 in bzr "annotate performance on development-rich--root" [High,Triaged] https://launchpad.net/bugs/374726
<poolie> hello vila
<vila> hmm thanks for the gift lifeless :)
<lifeless> vila: anytime
<lifeless> vila: I know you've looked at annotate recently :)
<vila> lifeless: yup
<vila> and from what I recall before paging in I can't see why it could become slower... I'll see
<lifeless> well, if you bench a few juicy files from bzr and emacs and its fine, then we'll know :)
<vila> ...and mysql :)
<lifeless> indeed
<lifeless> I built drizzle on the weekend
<lifeless> ... and found [and fixed some] bugs :)
<vila> sheesh, wrong button
<lifeless> haha
<lifeless> poolie: I've done as much wiki gardening as I think is useful for a few days
<lifeless> back to check for a bit then signoff
 * vila teach himself: heron is the background means no menu bar at the top of the screen
<igc> hi vila
<vila> hi Ian
<vila> BB is down
 * lifeless halt()s
<Peng_> lifeless: Good night. :)
<poolie> vila: can you try using lp reviews for some things?
<poolie> you may get less outages
<vila> poolie: sure, old habits... but in that case it's a bzr-gtk critical bug that got affected to bzr instead
<poolie> oh ok
<poolie> i just meant in general
<vila> poolie: sure, my last submission(s?) to BB were followed by a 'damn it, use lp reviews ! You already pushed your branch ! You just have to use lp-open instead of bzr send !!!' :)
<vila> spiv: I noticed that you have added some 'if token is not None: xxx.leave_lock_in_place()' at the *end* of one (may be two so far) tests,
<vila> spiv: Am I right thinking that you forgot to delete them after having written more focused tests ?
<spiv> vila: hmm, which tests?
<vila> spiv: bzrlib/tests/per_repository/test_write_group.py test_abort_write_group_does_not_raise_when_suppressed
<vila> spiv: bzrlib/tests/test_pack_repository.py test_abort_write_group_does_not_raise_when_suppressed and test_abort_write_group_does_raise_when_not_suppressed
<spiv> vila: those two lines are there to suppress "object was locked when gc'd" warnings when possible
<vila> spiv: haaa, so if I get rid of the warning you din't mind me deleting them then ?
<spiv> vila: I suppose we could also achieve that by renaming foo back to repo and doing an unlock.
<vila> yup: self.addCleanup(t.rename, 'foo', 'repo')
<spiv> I don't mind you deleting them, but how are you going to get rid of the warning?
<spiv> Ok.
 * igc dinner
<vila> lifeless: I know you're aware of the problem but I thought I'll share the fun anyway: Ran 1 test in 0.027s
<vila> FAILED (errors=2)
<vila> observed with an error in a cleanup hook :)
<lifeless> yes, its by design ugly though it is
<lifeless> vila: feel free to fix; though I think its low priority - its cosmetic not functional
<vila> lifeless: naah, just surprising, I think the fix could be a bit hard to get rigth though and not worth the effort right now (test errors should be fixed anyway)
<vila> and it's true that there was 2 errors...
<jelmer_> mwhudson: what does lp run, dapper or hardy?
<jelmer_> vila, lifeless: do you know perhaps?
<vila> jelmer: I'd say dapper but since I'm not sure, you'd better check with a LOSA
<elmo> jelmer_: hardy
<vila> elmo: do you when it was upgraded ?
<vila> yeah, know is missing of course :)
<elmo> vila: not offhand; over 6 months ago?  I can find out exactly, if you really need to know
<jelmer_> elmo: thanks
<vila> elmo: thanks, that's precise enough :)
<vila> abentley: BB is down
<vila> abentley: but hi first, sorry :)
<abentley> vila: Restarted.
<abentley> vila: hi :-)
<vila> abentley: how strange... For http://bundlebuggy.aaronbentley.com/project/bzr-gtk/request/<m2tz3x6rw6.fsf%40free.fr>, I got an ack email  to bazaar@list.canonical.com, which was wrong since it's for bzr-gtk, yet, on BB, it's correctly affected to bzr-gtk...
<abentley> vila: Any reviewer can reassign a merge request to the correct project.
<vila> but as soon as I got the ack email I tried to do that, BB has been down since
<vila> and http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cm2tz3x6rw6.fsf%40free.fr%3E is also valid 8-)
<vila> BB is too magick :)
<vila> jelmer: any change you can review the abvove ?
<jelmer_> vila: sure, one sec
<cornucopic> vila, Hello
<vila> cornucopic: hi, how is your patch for #372800 going ?
<cornucopic> vila, Just resumed looking at it. To make sure, that I am in sync with you on the bug, can you please take a look the bug report?
<cornucopic> vila, the description: https://bugs.launchpad.net/bzr/+bug/372800
<ubottu> Ubuntu bug 372800 in bzr "Wrong behavior of SMTP authentication during post commit email" [Undecided,In progress]
<vila> cornucopic: I,m pretty we are sync, how about you submit a patch so we can discuss on concrete code :)
<vila> s/pretty/pretty sure/
<cornucopic> vila, Hmm..Okay :) As you suggest.. !
<rbriggsatuiowa> I tried to shelve a delete and the unshelve failed miserably
<rbriggsatuiowa> the ticket here https://bugs.launchpad.net/bzr/+bug/319790 seems to indicate this is fixed in later versions - what version will work (ie: is this in a release or dev version?)
<ubottu> Ubuntu bug 319790 in bzr "bzr unshelve crashes losing all changes" [High,Fix released]
<vila> rbriggsatuiowa: 1.13 should include it AFAICS
<vila_> rbriggsatuiowa: 1.13 should include it AFAICS (just got a crash here, don't know if you got that)
<rbriggsatuiowa> I'm building 1.14 right now and can't find a --prefix option for setup.py ...
<rbriggsatuiowa> I was running 1.10
<vila_> rbriggsatuiowa: you know you can run from source right ?
<rbriggsatuiowa> ahh - thanks
<cornucopic> vila, I can safely use a string function to extract the port number from smtp_server ?
<vila> cornucopic: yes, use split()
<SamB> you mean .split(':'), yes ?
<cornucopic> SamB, vila, yes
 * SamB meant that question for vila ;-)
<rbriggsatuiowa> vila: 1.14 worked for me - thanks
<vila> rbriggsatuiowa: always happy to help (TM)
<SamB> rbriggsatuiowa: you maybe want --home ~
<SamB> that's what I use
<rbriggsatuiowa> yeah - that's what I found once I read the FAQ (:))
<SamB> It was used in some example in the Python documentation
<rbriggsatuiowa> I'm too used to the --prefix configure option
<SamB> hehe
<SamB> I was pleased to see that git's build system defaults to installing in $HOME
<rbriggsatuiowa> weird - I've always been a big fan of installing into /opt/app and fixing PATH when I do source installs
<rbriggsatuiowa> makes it easy to hose old versions without hurting other apps - but a pain to maintain (have to set pythonpath as well)
<vila> rbriggsatuiowa: old SunOS user maybe ? :-)
<vila> rbriggsatuiowa: what os/version are you using right now ?
<rbriggsatuiowa> gentoo
<rbriggsatuiowa> the bzr version is way out of date
<rbriggsatuiowa> 1.9
<rbriggsatuiowa> I started using /opt when running rocks clustering stuff at work
<vila> rbriggsatuiowa: rocks clustering, I see :)
<rbriggsatuiowa> yeah - it's supposed to simplify clustering stuff - I found it a little binding
<rbriggsatuiowa> I haven't used it in four years though, so it might be better
<amit> vila, can you please take a look at http://pastebin.com/m6a72d8ad? Is this on the correct road?
<Guest98791> vila, amit here..
<vila> Guest98791: please, send a proper submission to the list or do a merge proposal from launchpad, it's far easier and efficient to review code in context than in pastebin/IRC, thanks in advance :)
<Guest98791> vila, Ok. cool. Thanks.
<cornucopic> the bzr-email plugin replaces the bzr installation's 'smtp_connection.py' ?
<cornucopic> apparently, it uses its own copy of smtp_connection
<cornucopic> and not the globally installed one
<jelmer_> jam: hi
<jelmer_> jam: when you talk about chk stacking you mean chk stacked on chk right?
<jam> jelmer_: yes
<jam> I think I have it all working
<jam> I'm just doing testing
<jelmer_> nice
<jam> and uncovering stuff like: bug #375019
<ubottu> Launchpad bug 375019 in bzr "auto-stack logic selects wrong repo format" [Undecided,New] https://launchpad.net/bugs/375019
<jam> hey vila... you know, we really should start chatting more often
<jam> I got out of the habit with multiple conferences, and getting sick, but I'd like to catch up sometime
<jelmer_> jam: whoops
<jelmer_> jam: what about chk stacking on 1.9 and vice versa?
<jelmer_> jam: 1.9-rr on chk I mean
<jam> jelmer_: ATM we can't stack across serialization formats
<jam> so no stacking 1.9-rr <=> dev6
<jam> or svn <=> bzr anything
<jam> etc
<jelmer_> ah, ok
<jelmer_> jam: svn <=> bzr has worked for quite a while :-)
<jam> jelmer_: how did you manage that?
<jelmer_> jam: bzr-svn provides fake VersionedFiles implementations
<jam> Given that I get:
<jam> bzr: ERROR: CHKInventoryRepository('file:///C:/Users/jameinel/dev/%2Ctmp/d6rr/.bzr/repository/')
<jam> is not compatible with
<jam> KnitPackRepository('file:///C:/Users/jameinel/dev/%2Ctmp/d6rr-b-stacked/.bzr/repository/')
<jam> different serializers
<jelmer_> that call Repository.get_revision() under the hood
<jelmer_> and serialize again using the serialization format that 1.9-rich-root uses
<jam> jelmer_: so it would fail for dev6, because you are explicitly casting to 1.9-rr ?
<jelmer_> jam: yeah
<jam> (also, you can stack 0.92 => 1.9 because the serializer didn't change)
<jelmer_> jam: ok, so I guess we'll need something more generic at some point anyway
<vila> jam: definitely, I was hoping to call you today but... so many things to do :)
<jam> vila: not a big deal. I just saw your email, and realized we haven't talked in a while. Maybe tomorrow.
<vila> jam: sure
<Peng_> Space Shuttle! :D
<Tak> couldn't see very well from here
<Peng_> I couldn't see it at all. It was cloudy, and the trajectory may have interfered.
<beuno> jam, w0000000t!
 * beuno dances
<LarstiQ> beuno: you received some lettuce in the mail? :)
<beuno> jam, EVEN BETTER!
<beuno> a patch for stacking on brisbane-core
<Kissaki> yo, can you with bzr commit -m "" how can I add newlines?
<Kissaki> aka line breaks
<beuno> Kissaki, I think you need to drop the -m, and jump into an editor
<LarstiQ> it can be done with -m
<Kissaki> hm, ok
<Kissaki> thx
<Kissaki> can=can't ? ^^
<LarstiQ> Kissaki: what I do is bzr ci -m 'Added foo.<hit enter>Added bar.'
<LarstiQ> Kissaki: ie, let my shell handle the newlines
<LarstiQ> Kissaki: can
<Kissaki> tried \n, but that didn't work :/
<LarstiQ> Kissaki: have you tried an actual literal enter?
<Kissaki> hm?
<LarstiQ> Kissaki: use the enter key.
<Kissaki> pressing it will exec the cmd ofc
<Peng_> Kissaki: Depending on your shell, if you're inside quote marks, it won't.
<Kissaki> using windows cmd right now
<LarstiQ> ah. windows cmd
<LarstiQ> Kissaki: I don't know if the windows shell has support for multiline editing
<LarstiQ> Kissaki: I'd leave off -m and spawn a commit editor then.
<Kissaki> well, I'll try copy paste for comment next time
<Kissaki> commit editor? is that something special?
<LarstiQ> I doubt tricks like bzr ci -m `cat` will work on windows?
<Kissaki> yeah
<LarstiQ> Kissaki: it looks at $VISUAL or $EDITOR, and will spawn notepad on windows if it can't find anything else
<LarstiQ> Kissaki: also, you configure what editor to use for commit messages, see `bzr help configuration`
<sidnei> is there an argument for reading the commit message from a file? in svn you can do svn ci -F <filename> or something
<LarstiQ> which might come in handy on windows
<LarstiQ> sidnei: oooh, good one!
<LarstiQ> that was even my first patch for bzr, shame I don't remember :/
<LarstiQ> Kissaki: as sidnei said, you can use -F
<luks> Kissaki: have you tried bzr qci
<Kissaki> no
<luks> it might not be what you want, but just in case
<sidnei> qci is cool too
<Kissaki> don't even know what ci is
<luks> commit
<Kissaki> ah
<luks> (and qcommit)
<Kissaki> what's the difference?
<luks> it opens a dialog window
<GaryvdM> nothing - qcli is an alias
<luks> where you can type the commit messages, select files, see diffs, etc.
<GaryvdM> qcli is an alias for qcommit
<luks> *message
<LarstiQ> GaryvdM: qcli or qci?
<GaryvdM> err qci
<Kissaki> oh, nice
<Peng_> jam: You left a "bork" in bzrlib/repofmt/groupcompress_repo.py in the dev6 stacking patch. :P
<Kissaki> qcommit indeed does open a commit window/dialog/editor thingy
<Kissaki> thx
<jam> Peng nice catch :)
<jam> though that would hint that the code isn't exercised (as I thought it wasn't)
<Peng_> :D
<LeoNerd> Uhh... Where'd 'bzr revert' move my file to?
<LeoNerd> It always used to keep a backup
<beuno> LeoNerd, ~filename~
<LeoNerd> I don't see one
<beuno> LeoNerd, ls -la?
<LeoNerd> In the directory it used to live, or in the treeroot?
<LeoNerd> Well. it's absent either way
<LarstiQ> LeoNerd: it doesn't leave backups if it can be constructed otherwise, afaik.
<LeoNerd> Hrm...
<LeoNerd> it was locally modified
<eka> hi all
<eka> is there any way to work using bzr with a git repo?
<mwhudson> eka: yes, 'bzr-git'
<eka> mwhudson: it's stable?
<mwhudson> eka: it's moving quite quickly, but mostly in a positive direction :)
<mwhudson> eka: it works pretty well, in my testing
<eka> mwhudson: thanks for the tip
<mwhudson> (launchpad will be using it to import git repositories into bzr soon)
<jam> lifeless: ping
<jelmer> mwhudson: so, bzr-git now supports using tdb to store its cache data
<jelmer> mwhudson: which is significantly faster than sqlite
<adamfast> I've got a question - a while back I upgraded via the installer to 1.13.2 (and then today to 1.14.1) but I keep getting a "bzr: WARNING: bzrlib version doesn't match the bzr program." the bzrlib version is 1, 14, 1, 'final' and bzr --version tells me it's 1.14.1. Has anyone seen this before?
<adamfast> (I should mention I'm using a Mac with the Leopard Python 2.5)
<thumper> adamfast: my guess is that the bzr executable isn't the one you installed
<adamfast> any idea what the/a possible fix could be? Try to delete all the files and run the installer again?
<mwhudson> jelmer: tdb?
<mwhudson> jelmer: is it packaged for hardy?
<jelmer> mwhudson: yep
<thumper> jelmer: is it chosen automagically?
<mwhudson> jelmer: hmm, where is the cache stored between runs?
<jelmer> thumper: yep, we also still support sqlite
<jelmer> thumper: and if tdb is not there sqlite is used like it was before, it'll just be slower
<jelmer> thumper: (slower than tdb, not slower than it is with sqlite now obviously)
<jelmer> mwhudson: it's in .bzr/repository/git.[t]db
<mwhudson> jelmer: does push preserve it?
<Peng_> Can you upgrade a repo from sqlite to tdb?
<jelmer> mwhudson: no, but if it's not there bzr-git will regenerate it
<mwhudson> jelmer: how bad is that, relatively speaking?
<mwhudson> (because it seems with the system we have in place we'll regenerate it each time)
<jelmer> mwhudson: one sec, I'll try on a bzr.dev repo
<thumper> lifeless: you up yet?
<jelmer> mwhudson: I guess it would be nice if push could preserve it I guess but we'd need better hooks for that
<jelmer> mwhudson: also, if you don't keep this database around you'll hit problems when there are revisions that contain characters that can't be represented in XML
<mwhudson> jelmer: well, it would be easy enough to preserve it by hand, esp if bzr-git can tell me where it should go for a branch
<thumper> jelmer, mwhudson: well that is a handy thing to know
<mwhudson> thumper: indeed
<Peng_> Why's lp:dulwich a remote branch?
<jelmer> mwhudson: regenerating the sha map takes 16 seconds for 1000 revisions (bzr-git)
<jelmer> mwhudson: try 'bzr git-object' in any bzr branch to generate a full map
<mwhudson> jelmer: will it need to do that for a pull where the remote tip hasn't changed?
<jelmer> mwhudson: I'm not entirely sure
<jelmer> mwhudson: it shouldn't need to, but I don't know what it does atm
<jelmer> mwhudson: only one way to find out :-)
<mwhudson> jelmer: :)
<lifeless> thumper: yes
<lifeless> thumper: but I'm doing bio stuff
<thumper> lifeless: I've just done mine :)
<thumper> lifeless: why does pack take so long with bbc?
<thumper> packing launchpad with packs took under 3m
<thumper> packing launchpad in bbc took over 3 hours
<thumper> although packing packs went from 1.1G to 1.1G (not much change :)
<thumper> packing bbc went from 248M to 137M
<thumper> for the pack dir at least
<lifeless> for xml based formats all pack does is reduce latency
<lifeless> for the chk formats, we recompress
<thumper> lifeless: is this going to happen automatically when combining packs?
<thumper> lifeless: because if it does, it will make for very slow pushes :)
<lifeless> thumper: 'bzr pack' recombines all history. of course its slow
<mwhudson> jelmer: it seems maybe not
<thumper> lifeless: but what about the autopack?
<lifeless> autopack doesn't do a full pack
<thumper> so it will still be fast?
<lifeless> yes
<lifeless> kindof an obvious question :)
<thumper> cool
<jelmer> lifeless: is it right that running 'bzr pack' in a dev6 repo multiple times gives "Pack already exists ..." after the first time ?
<thumper> just making sure :)
<lifeless> jelmer: file a bug please
<lifeless> jelmer: its because we don't short-circuit pack and avoid doing it in dev6
<jelmer> lifeless:  I guess that's a "no"
<lifeless> jelmer: its not the desired behaviour :)
<lifeless> thumper: autopack has a exponential backoff on frequency for a given text
<lifeless> thumper: 10 autopacks of 10 revs in the first 99 commits, then one of 100 revs, and so on
<lifeless> if you've got 100K commits, it will be a very long time before autopack decides to rewrite the 100K pack when you push a single revision
<thumper> lifeless: just saying "yes it'll be fast" is good enough for me
<lifeless> thumper: sure, but you may as well understand it too ;)
<beuno> lifeless, https://pastebin.canonical.com/17459/    bug?
<thumper> lifeless: however your explination doesn't help me understand because I'm missing too much context :)
<lifeless> thumper: ok. In short - autopack may do a full pack, but its very rare, and becomes more rare thelarger the repo
<lifeless> thumper: theres a heuristic, which seems to work well.
<lifeless> beuno: bug
<beuno> lifeless, danke. What does --default-rich-root default to in bzr.dev?   0.92 still?
<lifeless> I'm not sure. that was on branch anyhow
<jelmer> beuno: rich-root-pack
<beuno> ah, lh is 1.9
<beuno> so I guess it's trying to do 1.9 -> rich-root-pack
<beuno> so failing
<lifeless> beuno: its the branch object thats failing
<lifeless> nothing to do with roots
<beuno> oh
<beuno> k, bug files
<beuno> and filed
<jelmer> heh, dpush from svn into git works (-:
<jelmer> secretly bzr is just tailor Done Right [tm] ;-)
<lifeless> jelmer: lol; scary, and 'No'
<beuno> nice. Loggerhead in bbc is ~40% smaller, and "bzr log -v" takes less than half the time
<beuno> (compared to 1.9)
<luks> beuno: out of curiosity, how long is that? :)
<luks> I'd expect that to still be unusable
<beuno> luks, 3.7sec to 1.6sec
<lifeless> beuno: be sure to bzr check ;; bzr reconcile before migrating
<beuno> pretty usable
<luks> what? log -v does still all the deltas?
<lifeless> beuno: I encourage you to migrate to rich roots soon; see the thread on bzrtools which has migrated to rich roots already
<beuno> lifeless, I will, although I'm just fooling around now, to try and hash out any obvious problems
<beuno> lifeless, I'm more than happy to, if we can get mwhudson and Peng_ on board
<jam> lifeless: I have to go now, but if I get some time, I'd like to chat after a few hours
<lifeless> beuno: thats part of the process; read my mails ;)
<lifeless> jam: sure
<lifeless> jam: ping me
<lifeless> jam: I'm going to be poking at check, then presentations
<mwhudson> beuno: sure, no problems at all with going to rich root
<beuno> lifeless, both check and reconcile?
<lifeless> beuno: yes, or just reconcile
<beuno> mwhudson, what happens with the existing stacked branches?
<Peng_> beuno: My position on rich-roots hasn't changed. I'm on board, pending that email from a few weeks ago about changing how converting worked.
<beuno> they all break?
<lifeless> beuno: with a check afterwards
<mwhudson> beuno: well that's the fun part :)
<Peng_> Or whatever it was about.
<mwhudson> beuno: i'm sure lifeless talks about that too in his mails
<lifeless> beuno: 1) read my mails about this; 2) reply with anything unclear so we can capture it and improve - please
<beuno> Peng_, mwhudson, ok, I may attempt to upgrade trunk later today then
<beuno> check and reconcile looked ok on lh bbc
<lifeless> beuno: read the mail first; doing it today would pretty much break all the rules
<beuno> even when going from plain 1.9 -> bbc
<beuno> ok, *today* I may read lifeless's email more carefully
<beuno> and see where that takes me
<lifeless> Peng_: noone has altering the conversion process in their queue that I know of
<beuno> lifeless, any hint on how to find that email?
<lifeless> Subject: 	[DRAFT][RFC] Migrating to rich roots
<beuno> loggerhead is very spify on bbc: http://bazaar.launchpad.net/~beuno/%2Bjunk/loggerhead-bbc/changes
<lifeless> spify?
<lifeless> do you mean fast or pretty?
<beuno> fast
<lifeless> 3 seconds to toggle a >
<lifeless> :<
<beuno> not sure what that means
<lifeless> in the changes pge
<lifeless> there are > beside each rev
<lifeless> if I click one, its about 3 seconds, sometimes up to 5, before the expanded content is complete
<beuno> I clicked on expand all
<beuno> and it took ~2-3 seconds to bring all of them in
<Peng_> lifeless: I dunno. There was some email about somehting or other. I still don't know what it was about. :P
<lifeless> beuno: 10 seconds to do that for me
<lifeless> beuno: where are you at the moment
<lifeless> Peng_: I do
<beuno> lifeless, argentina
<lifeless> strange :-)
<beuno> lifeless, so upgrading to rich-roots breaks stacked branches. Can they be upgraded as well, or are they just discarded?
<Peng_> Whoever did it first had to wait for the cache to be generated.
<lifeless> Peng_: I did it second
<lifeless> beuno: clean your eyes
<lifeless> 3) Users migrate their own branches before this time, including lp
<lifeless> hosted branches and particularly stacked branches.
<beuno> lifeless, I don't follow
<lifeless> Peng_: its possible its slower now its cached
<beuno> current branches stacked can be upgraded to rich-root, even though the stacked-on branch isn't rich-root?
<Peng_> Stupid question that I can figure out on my own: is it possible to push to a lightweight checkout on a remote server, where the branch is stored on the same server?
<Peng_> s/can/should/
<lifeless> beuno: yes, they will break after the upgrade; then when the stacked on is a matching format again, they will work again
<beuno> lifeless, gotcha
<lifeless> Peng_: it should be yes, unless the the server is chrooted so as to divide them
<lifeless> Peng_: but it may not work dependign on the path in iuse in the checkout
<Peng_> lifeless: In this case, no chroot, but they're totally different paths.
<Peng_> Maybe I should use a stacked branch instead.
<lifeless> Peng_: there's always a chroot
<lifeless> Peng_: ChrootTransportDecorator
<Peng_> Eh.
<beuno> it pretty much sucks that all branches tied to merge proposals will break, unless we hunt down each and upgrade (which takes ages remotely)
<lifeless> Peng_: and the jail
<awilcox> okay it has been a few days so I think I will reask my question.  Is there any way to utilise Bazaar in XCode?
<Peng_> Yeah, I love the jail.
<lifeless> Peng_: the jail works with the chroot decorator
<lifeless> awilcox: no idea sorry; have you checked the IDE page?
<awilcox> lifeless: I have and it said that CVS, SVN, and Perforce are supported natively, but others can use a plug-in interface
<lifeless> awilcox: I mean our one
<lifeless> on bazaar-vcs.org
<awilcox> I googled, and some people mentioned projects for a plug-in, but I haven't found the actual code.
<Peng_> The situation is, I have branches of one project in 3 different locations, with a checkout in 1 of them, and want to get rid of one of the duplicate repositories. (The other can stay, I guess. Although I could convert it to a stacked branch too, hmm.)
<awilcox> ohhhh sorry.
<awilcox> http://bazaar-vcs.org/IDEIntegration doesn't even have XCode listed.
<lifeless> :(
<lifeless> care to add it?
<awilcox> I don't see a way to edit the page
<lifeless> bottom of the page is an edit link
<lifeless> if you're logged in
<awilcox> ah.  I don't have an account.
<lifeless> if you don't have an account you can just create one, or I can add xcode to it for you (but I don't know anything about xcode which is why I asked you to add it :))
 * beuno -> off for a while
<Raim> hi
<Peng_> Hello
<Raim> I am trying to branch using bzr 1.9 as client from a server with bzr 1.5 using the bzr+ssh:// protocol
<Raim> are these versions known to be incompatible?
<mwhudson> Raim: no
<Raim> so I am seeing these messages and it fails: http://pbot.rmdir.de/0347a921ae170e1ba6dfb075de29c6d0
#bzr 2009-05-12
<Raim> I understand the first two about the protocol version, but the third sounds like server and client can't communicate
<Peng_> If the server doesn't support protocol v2, it is far older than 1.5.
<Raim> oh wait
<Raim> gah, the network I am connecting to is not homogenous, this is actually an older Debian box with 0.11.0
<Peng_> Wow, that's *ancient*.
<Peng_> Raim: You'd have to use sftp; modern clients dropped support for smart servers that old.
<Peng_> 0.11? What disk format would that use? I didn't even use bzr back then...
<Raim> Peng_: nah, I just have to use another server which also has access to the NFS share where the repo lives
<Raim> Peng_: works fine now. I just made a bad assumption and did not check the versions properly
<Peng_> OK, that works too.
<igc> morning
<Peng_> Good morning.
<igc> hi Peng_
<lifeless> hi igc
<igc> hi lifeless
<abentley> lifeless: Thanks for the review.
<lifeless> abentley: no probs
<lifeless> abentley: you registered it with the new hooks registry; all was good in the world
 * igc out for a few hours - chemo day - bbl
<poolie> hello all
<poolie> good luck igc
<igc> thanks poolie
<abentley> poolie: hi there.
<abentley> igc: good luck.
<poolie> hi abentley
<poolie> abentley: i heard you made me the reviewer for the nested trees doc
<poolie> i'll do something on it today
<abentley> poolie: Maybe we could have a quick chat?
<poolie> abentley: sure, can you wait 5m?
<abentley> poolie: sure.
<lifeless> jelmer: so did you upload subunit? or should I
<jelmer> lifeless: I did some work on it (fixing lintian warnings and the like)
<lifeless> oh noes
<jelmer> s/warnings/issues pointed out by lintian/
<jelmer> I also sent in a merge request for a shell bug
<jelmer> did you see that one?
<lifeless> no
<jelmer> lp:~jelmer/subunit/merge
<lifeless> nice, https://code.edge.launchpad.net/~subunit/  shows package branches now
<jml> lifeless: it's shown package branches forever :)
<lifeless> jml: oh cool
<jml> lifeless: drop the tilde and they'll disappear
<lifeless> jelmer: I can see the reviews, but I didn't et mail
<jml> lifeless: they are also very badly sorted.
<lifeless> jml: how can I debug this
<lifeless> jml: I don't get notification on merge proposals to subunit trunk
<lifeless> I'm subscribed
<thumper> lifeless: how did ~subunit get 1 registered branch?
<lifeless> I checked my subscription and it says all code review stuff
<thumper> nm
<jml> lifeless: https://code.edge.launchpad.net/~subunit/subunit/trunk says you aren't subscribed.
<thumper> it is old
<jml> oh subunit developers
<jml> wait no
<lifeless> I can't tell whats going on
<lifeless> jelmer: land it
<jelmer> lifeless: ack
<lifeless> thumper: what do you mean by 'it is old'?
<lifeless> jml: so even though subunit-developers is the default review team, they are not notified?
<thumper> lifeless: before we had a registrant for branches
<lifeless> thumper: I would like a clear thing saying whether I will get notified about a given branch
<lifeless> thumper: at the moment I can't tell
 * lifeless files a few bugs
<thumper> if you are not subscribed, you don't get anything
<thumper> lifeless: assign to beuno :)
<lifeless> thumper: I'll let you decide
<BasicOSX> lifeless:  tracking down the 1.13.2 == 1.14.xx, I introduced the issue into the 1.13 branch when I merged ~spiv/bzr/stacking-inventory  into 1.1.13 branch as part of the fix to Bug 354036
<ubottu> Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Undecided,Confirmed] https://launchpad.net/bugs/354036
<BasicOSX> There was a bug task for 1.13, assigned to me. I need help understanding what I should have done, since a flatout merge of spiv's branch was not the right thing to do
<BasicOSX> revno: 4112.1.1 [merge] is the offending revno
<BasicOSX> I can post to the ML if that is better
<lifeless> BasicOSX: you should done a cherrypick into your local branch
<lifeless> BasicOSX: the easiest way to make this happen is to:
<lifeless>  - get the branch you want merged to trunk if it isn't already
<lifeless>  - bzr merge -c <trunkrevno> bzr.dev in your release branch
<lifeless>  - bzr commit
<lifeless>  - submit to pqm for that release branch
<BasicOSX> making notes
<lifeless> 'bzr merge' should never be used from a feature branch to a release branch, unless the feature branch is intended specifically for that release
<BasicOSX> I see that now. In the past someone has done the cherrypicking for me (not an excuse)
<BasicOSX> To fix the mess, do I issue bzr uncommits?
<lifeless> mail the list re the mess
<BasicOSX> ok
<lifeless> we need to consider who may have 1.13.14
<poolie> abentley: i reviewed the docs and posted a comment
<poolie> looking at the other threads now
<abentley> poolie: thanks.
<kvanderw> Running 'bzr' on my /home/me directory. Also, /home/me/fw02/root.  When in /home/me/fw02/root it is referencing the .bazaar/bazaar.conf file in /home/me and not the one in /home/me/fw02/root. Is that the way it should be?
<kvanderw> solo mode if it makes any difference.
<spiv> kvanderw: the .bazaar/bazaar.conf file has user-wide configuration, so bzr always looks it up in your home directory.
<spiv> kvanderw: so yes, that's expected behaviour.
<spiv> kvanderw: perhaps you are getting confused with the .bzr directory that is part of branches, repositories and working trees?
<kvanderw> spiv: Thanks... just making me wonder... The subdir is an rsync copy of a firewall. I had forgotten that I had installed bzr over my home directory.
<kvanderw> Just bad management from a noob :)
<kvanderw> spiv: though, it sounds like, even if I put it outside that dir structure, it still always looks to my 'home' dir for the conf.  No prob... Just trying to learn the ropes.
<kvanderw> spiv: Thanks!
<spiv> kvanderw: right
<lifeless> spiv: is this a TODO?
<lifeless> +    # Also, perf tests:
<lifeless> +    # - if all invs present, then no texts are checked
<spiv> lifeless: oops, yes.
<spiv> lifeless: actually, I was intending to not bother as it seemed too much hassle for minimal benefit...
<lifeless> have you done a user level perf test
<lifeless> say to people?
<spiv> Not explicitly, I have done a bit of branching locally to confirm that the final form of the fix really did fix the original issue and didn't notice any slowdown in branching all of bzr.dev locally.
<lifeless> I'll let you make the call
<spiv> I'll run another quick experiment.
<lifeless> what do you think of my -Dhpss backtrace patch?
<spiv> I don't think I've seen it... where is it?
<spiv> Oh, something to do with getting backtraces from _ensure_real?
<spiv> lifeless: I like the idea of making the remaining VFS causes easier to identify, but I'm fairly sure I haven't seen an actual patch for it.
<lifeless> spiv: yes
<lifeless> spiv: no idea where it went
<lifeless> resending
<lifeless> spiv: its hit the list
<spiv> Cool, I'll take a look.
<spiv> lifeless: thanks for the review, btw
<jam> lifeless or spiv: PendingAncestryResult.get_keys() returns ghosts, is it supposed to?
<jam> The StreamSource code then calls Graph.iter_topological_order(keys)
<jam> which strips ghosts
<jam> so StreamSource works
<jam> but it is causing stacking w/ bbc to fail
<jam> spiv: also, why in your new code did you create 1 set per key, rather than having a single set?
<jam> I'm a bit concerned about having 100k sets in memory
<jam> (unlikely to be intentional for something which is stacked, though)
<spiv> jam: heh
<jam> I just don't see what it gets you
<jam> versus 1 big set
<spiv> jam: I just sent mail on this :)
<jam> since you only call stuff like 'get_referrers()'
<spiv> jam: before I saw that you were on IRC
<jam> spiv: :) I just got the email
<jam> spiv: are there direct tests of PendingAncestryResult?
<spiv> jam: there are some in test_graph
<jam> yeah, I just found it
<jam> no tests for ghosts
<lifeless> jam: PAR returning ghosts is sarguably a bug
<jam> I guess that leaves it open for me to interpret :)
<lifeless> jam: I see no reason to keep that
<jam> lifeless: agreed, just wanted to make sure everyone else thought so, too
<lifeless> jam: IDS breaks streaming push cross-format :(
<lifeless> which I knew
<lifeless> but jelmer filed a bug saying 'it go sloweth'
<jam> lifeless: does it go 'slowether' than doing it any other way?
<lifeless> jam: much
<jam> interesting, considering it goes *much* faster locally
<lifeless> spiv: inventory deltas top of the pile now?
<jam> it doesn't really query the target
<lifeless> jam: latency
<jam> I suppose this is a 'pull' issue?
<jam> I would assume it is faster for 'push'
<lifeless> jam: push
<spiv> lifeless: theoretically yes, but I'm on leave from tomorrow till All Hands
<lifeless> jam: no, every write is a round trip
<lifeless> spiv: oh, I didn't know.
<jam> lifeless: well, isn't that just NewPack.set_buffer_size() ?
<lifeless> spiv: I will see if I can squeeze it in; please ensure you have it pushed and a mail to me with the url of the current state
<jam> Considering we hold a write group for 100 revisions at a time
<spiv> Crap, I haven't mailed the about that yet... I'll do that now.
<jam> And we transfer texts 'in bulk' as well
<lifeless> jam: even so, its still many round trips rather than streaming
<lifeless> and each commit is about 10 round trips
<lifeless> and then a re-read to refresh data
<lifeless> jam: I can pretty much guarantee that disabling IDS over the network will be faster in all cases
<lifeless> jam: particularly if we do what I propose and set the fetch order to gc-optimal
<jam> well, other than the 4-5 things I listed, sure...
<jam> IDS wasn't specifically tuned for remote ops
<lifeless> I realise IDS is fast locally
<lifeless> AFAICT there are two specific issues; long conversion times, and writing many small chk pages meaning we can't really do gc-optimal cross-format
<lifeless> because we'll get optimal texts but not optimal chk pages
<lifeless> I don't want to delete IDS until there is a better option; if thats even possible. However I also want network ops to be fast
<lifeless> I'd like to see IDS split into a sink and stream pair and just hooked into the generic paths
<jam> lifeless: so other than wanting to trigger commit_write_group on the target
<jam> I'm pretty sure all the work is done in the source
<jam> and there isn't specific chatter between both sides
<lifeless> I suggest we add a stream flag saying 'the data from start to here is topologically consistent'
<lifeless> we should design this next week/sprint week
<jam> I guess it switches from texts => inventories => revisions
<lifeless> I have a few things I want to include
<jam> oh, and it wants 'add_inventory_by_delta'
<jam> which requires 'streaming inventory deltas'
<lifeless> jam: network deltas will cover that
<jam> which you keep claiming exists somewhere :)
<lifeless> yes, spivs laptop
<spiv> The delta serialisation is already in bzr.dev
<spiv> It just isn't hooked up to anything yet.
<lifeless> spiv: oh you landed that?
<spiv> lifeless: we did :P
<lifeless> spiv: sweet, I hadn't noticed.
<lifeless> spiv: there's no other outstading branch then is there
<spiv> Yeah, I forgot too until I went over my old branches looking for half-done work :)
<spiv> Right, no other outstanding branch.
<lifeless> ok
<lifeless> jam: ^
<jam> spiv: where is it?
<lifeless> jam: small amount of glue left; get_delta(); serialise(); yield;
<spiv> jam: bzrlib/inventory_delta.py
<jam> spiv: .... PendingAncestryResult.get_recipe() does not return ghosts as 'exclude_keys'
<jam> Which makes 'bzr branch from-stacked' search all the chk pages, and want to copy all texts that are referenced from the stacked branch...
<spiv> jam: PendingAncestryResult doesn't have any exclude keys
<lifeless> jam: par is a full-history grab
<spiv> it's just "get me the ancestry for <heads>"
<jam> lifeless: but on a Stacked location, *without* fallbacks set
<jam> ...
<jam> which is how the stacking code works
<spiv> If you want "get me the keys from <heads> to <stop_keys>", that's SearchResult
<lifeless> jam: so I think you still have a bug :)
<lifeless> jam: here is how it is meant to work
<lifeless> the server gets a par for the branch tip
<lifeless> it then finds all the revisions it actually has
<lifeless> it then calculates a delta for the new content in all those revisions and sends that
<lifeless> it should have enough data in the inventories to do that, *because* we include the adjacent inventories
<jam> spiv: so the idea was that if we have 'exclude_keys' *already* computed from the search result, why should I compute them *again*
<jam> now, PAR may never have excluded_keys
<lifeless> in this situation note that there are no exclude keys
<lifeless> and cannot be, because we're always grabbing all the history if we have a par
<jam> so... can I just never trust the recipe?
<lifeless> its never used if we have a shared repo
<jam> or should I trust it, unless it is empty?
<lifeless> jam: the recipe is completely accurate
<jam> note that PAR without stacking
<jam> will have no exclude keys
<jam> and require searching the *entier* graph to find that it is correct
<lifeless> jam: I don't understand why you think you can't trust it
<spiv> what do you mean "find that it is correct"?
<jam> lifeless: I want to transmit all revisions from the stacked branch
<lifeless> jam: yes, which the par will have found
<jam> And all inventories for only those revisions, and no chk pages for previous revisions
<jam> I was using the 'exclude_keys' to figure out what inventories *not* to transmit
<jam> rather than doing another get_parent_map call
<lifeless> exclude_keys is wrong wrong tool to use
<jam> because it is redundant with SearchKey
<jam> SearchResult
<jam> sorry
<jam> lifeless: except SearchResult has already done that sort of get_parent_map for me
<jam> and avoids having to do double duty
<jam> especially on a 'branch everything from a non stacked branch' case
<lifeless> jam: you want to send search.get_keys()
<jam> lifeless: and *not* send get_parent_map(search.get_keys()).itervalues().discard(search.get_keys())
<jam> yse
<jam> yes
<jam> I just didn't want to have to re-compute 'exclude_keys' for the case when SearchResult has already *done* that.
<lifeless> so, feel free to improve PAR is perhaps the right answer
<jam> well, I don't like doing:         _, _, exclude_keys, _ = search.get_recipe()
<lifeless> its sketchy, it was created to avoid the 'billion round trips to find graph' case
<jam> so I would rather do it a different way
<jam> like "search.get_tails()" (get_exclude_keys(), etc)
<jam> and PAR could compute that when it computes get_keys()
<lifeless> I don't think andrew or I are tightly attached to any of these internals
<jam> though I notice that the Result objects often don't actually cache anything
<jam> so it seems a bit off to assume that get_keys() is called before get_tails()
<jam> lifeless: I'm trying to understand what you *do* like, so I can not make a mess
<jam> In the short term, I can just do another get_parent_map()
<jam> it just seemed redundant
<jam> (not that we don't do that *all the time* already...)
<lifeless> jam: Whats wrong with _, _, exclude_keys, _ = search.get_recipe()
<lifeless> is it doing more work
<lifeless> or is it ignore the variables you don't want that you don't like?
<jam> lifeless: get_recipe() seems like it should really be opaque
<spiv> jam: I think our graph search stuff is pretty primitive at the moment, so I'm definitely in favour of improving it.
<lifeless> jam: unfortunately, and I sighed when I realised, we messed up PAR and its not as opaque as it could be
<lifeless> jam: that said, if you want to add methods that you'll like that would be fine.
<lifeless> jam: caching should be done with care, obviously.
<jam> lifeless: well, you cache 'heads'... I suppose caching 'self.tails' if we have encountered them?
<lifeless> jam: right
<lifeless> jam: you actually want to cache ghosts in this case
<jam> right
<jam> and really only ghosts, since PAR is 'everything that you can reach'
<spiv> Yeah, the step from generalising SearchResult to SearchResult+PendingAncestryResult wasn't perfect.
 * igc back - chemo delayed for a week
<jam> hey igc, glad to hear you feel well today, sorry to hear it is because of delayed chemo
<igc> hi jam! yeah - I feel fine fwiw
<ziroday> Hi, when branching from https://code.launchpad.net/~breathe-dev/breathe-icon-set/trunk I got http://pastebin.com/m6ad04457
<ziroday> err http://pastebin.com/m64c5c70a sorry
<lifeless> ziroday: I suspect a broken http proxy at your ISP
<lifeless> ziroday: can you try using bzr+ssh please
<ziroday> lifeless: doing so now
<lifeless> ok
<SamB> maybe something should be added to the smart protocol to help diagnose buggy http proxies ?
<lifeless> SamB: patches considered helpful :)
<lifeless> (in general its hard to tell 'bad proxy' from 'data attack'
<SamB> some kind of handshake to be used after that kind of error to check for typical bugs, maybe?
<SamB> lifeless: data attack?
<lifeless> SamB: that error isnt from the smart protocol though
<lifeless> SamB: a bad proxy gives bad bytes that it claims where what you asked for, but aren't.
<SamB> oh, you mean it doesn't just get confused ?
<SamB> or munge data ... or something like that?
<lifeless> there are all sorts of things which may be causing it
<lifeless> but we haven't detected an http protocol issue if we get the errror that ziroday saw
<lifeless> but if it is (and ssh working says it is) the http proxy, then the proxy is effectively hostile
<ziroday> well it appears to be working via bzr+ssh, I'll just advise the loco to use that
<SamB> lifeless: yeah, what I'm saying is that if you get something like that, it might be a good time to check for such bugs in any proxy ;-)
<spiv> SamB: yes, but exactly which bugs, and how?  There are an infinite number of ways a proxy can screw up your data...
<lifeless> ziroday: cool
<ziroday> lifeless: spiv SamB: thanks for all the help, you've made my day :)
<SamB> spiv: frequently seen bugs, I guess
<lifeless> SamB: I agree with the sentiment, I'm not smart enough to see how to do it though
<lifeless> SamB: because the symptoms are 'sometimes, when you ask for data you get different data'
<SamB> yeah, me neither!
<SamB> well, mostly because I don't know what any of those bugs are
<lifeless> SamB: many of these intercepting proxies are proprietary
<lifeless> so very few people will know exactly what the bug i
<lifeless> s
<SamB> well, I mean, what kind of corruptions they create
<SamB> or at least what kind of data they are likely to corrupt
<lifeless> who knows ;)
 * mwhudson is pretty sure his isp uses good ol' squid
<SamB> if I knew that, I might be able to cook up an http smart-server handshake protocol that would allow the client to construct a desired HTTP response and see if it comes through unscathed ...
<SamB> and some probe data to check for common bugs
<lifeless> SamB: this isn' smart-server related
<lifeless> SamB: this is simple plain HTTP GET's failing.
<SamB> well, yes, I know ... but I figure you'd need cooperation from the remote that plain-old HTTP isn't going to give you
<lifeless> I think it would be undesirable for bzr to issue arbitrary gets when something goes wrong on HTTP. In some organisations that would get a sysop coming around to your desk to 'talk' to you.
<SamB> hmm.
<SamB> a much simpler idea would be to simply point out that that type of exception is often caused by <foo>, where <foo> is derived from the access method in use ...
<lifeless> thats possible. Which comes back to - corrupt data has a pretty good chance of causing a zlib decompression error
<lifeless> you might like to file a bug about that approach
 * SamB should file a bug against himself for being too lazy to file a bug ...
<Logomachist> You guys know if there are any books on Bazaar?
<poolie> Logomachist: there's a book in progress, for now the best docs are the user guide on doc.bazaar-vcs.org
<poolie> hello vila
<Logomachist> Cool. Thanks Poolie
<thumper> what is the difference between:   2645 ghost revisions
<thumper>   2485 revisions missing parents in ancestry
<thumper> in bzr check?
<thumper> I get this after reconcile
<lifeless> the former is ghosts, the latter is revisions that are present and should have been fixed up
<lifeless> I think
<thumper> lifeless: what, if anything, should or could I do about them?
<lifeless> if reconcile left it like that, file a bug
<lifeless> I'm currently overhauling check
<lifeless> and will make sure its actually a relevant warning
<thumper> ok
<thumper> lifeless: what information would you like in the bug report?
<thumper> it is the launchpad branch
<thumper> I reconciled the 1.6 branch
<thumper> then ran check
<thumper> and that is what it said
<lifeless> sure that would be fine.
<thumper> however it did fix the 3547 inconsistent parents
<lifeless> thumper: thats good and will help annotate give better answers
<lifeless> sadness IllegalUseOfScopeReplacer:
<lifeless> can't figure out why I'd get that in bzrlib.smart.medium
<Peng_> What *are* inconsistent parents?
<lifeless> Peng_: when the cached index <> the revisions list of parents
<lifeless> 65->61 seconds for check tests
<lifeless> poolie: ping
<lifeless> poolie: I need a pointer; whats the current idiom for doing 'I have three tasks, they may take varying time each'
<poolie> one minute
<lifeless> sure
<lifeless> I'll just delete progress for now ;)
<poolie> lifeless: and they hppen sequentially?
<poolie> i guess you should still use phases
<poolie> i don't think that's quite right
<poolie> or maybe the api is right and the way they're used is not always optimal
<poolie> at any rate i don't have a clear better answer
<lifeless> well
<lifeless> gnerators but yes there are some fairly discrete phases
<poolie> did that answer your queston? you can call
<lifeless> sufficiently
<lifeless> I've spend the whole day on check so far
<lifeless> it is faster
<lifeless> but I'm not done
<poolie> igc, i sent a response to your doc
<poolie> about nested trees
<poolie> it was good, but it opened up some questions for me
<igc> poolie: thanks
<igc> poolie: that's good - that was the point of writing it :-)
<poolie> indeed :)
<Peng_> lifeless: OK, thanks. :) How's that fixed? Change the index?
 * Peng_ goes to bed. I shouldn't ask questions right before leaving. :\
<vila> hi all
<lifeless> poolie: there appears to be significant overlap between the _render stuff in progress view, and progressbar
<lifeless> poolie: I'd like to encourage you to delete a bunch of stuff
<mwhudson> i owe poolie a patch in this area too
<lifeless> hmmm
<lifeless> bzr: ERROR: Server sent an unexpected error: ('error', "'pqm@pqm.ubuntu.com-20090505195559-0qmeyyua7e407sym'")
<lifeless> not encouraging
<lifeless> spiv: you seen that pushing to lp?
<spiv> lifeless: no, I haven't.
<spiv> That is worrisome.
<lifeless> lp:~lifeless/bzr/check
<spiv> lifeless: in reply to which verb?
<lifeless> which is a tad ironic
<spiv> Heh.
<lifeless> oh, I see
<lifeless>   File "/home/robertc/.bazaar/plugins/branchfeed/branch_feed.py", line 41, in post_change_hook
<lifeless>     BranchFeed(change.branch).update()
<lifeless> it doesn't handle ghosts yet.
<lifeless> mea culpa.
<lifeless> its odd that its getting a nonstacked repo or whatever is going on
<spiv> branchfeed?  Does that generate RSS or something?
<lifeless> yes
<lifeless> https://edge.launchpad.net/bzr-branchfeed
 * jml wants 1.15dev on Launchpad
<jml> HPSS calls: 72 (23 vfs)
<jml> hmm.
<jml> 49 is still a lot.
<lifeless> jml: doing what
<lifeless> and is that against 1.15?
<jml> lifeless: pushing up a new stacked branch. no, it's not against 1.15: from 1.15dev to 1.14
<lifeless> it'll drop more than just removing the vfs calls
<lifeless> you're paying probes to find things that are in 1.15 etc too
<jml> lifeless: *nod* I saw a few unrecognized method errors in the .bzr.log.
<lifeless> and other things like ghost handling are more efficient, you won't see that in the log
<mwhudson> jml: feel free to ec2test -b bzr=lp:bzr
<jml> mwhudson: yeah. I might do that.
<jml> I'm reminded that I should also upgrade twisted.
<jml> I might go for a walk then write some talks instead.
<Demosthenes> any pointers to how to make a precommit hook that can change the working tree?
<lifeless> bzr help hooks
<lifeless> there is a hook type documented there that can do that
<Demosthenes> yep. saw that. it says write a python plugin.
<Demosthenes> i wasn't planning on becoming a bzr dev. i wanted to run a shellscript to generate a report each time i commit.
<lifeless> MutableTree.start_commit
<lifeless> Demosthenes: nothing to do with being a bzr dev
<Demosthenes> i did find a web page on pre_commit, with a helpful prewritten plugin that'd call $treeroot/precommit for you
<lifeless> its just the language hooks run in; or you can install jelmer's shell-hooks plugin
<Demosthenes> but as i understand it, precommits can't edit the tree
<lifeless> right
<lifeless> where is this page?
<Demosthenes> http://schettino72.wordpress.com/2008/01/20/how-to-execute-tests-on-a-bazaar-pre-commit-hook/
<Demosthenes> but i think you gave me the answer, shell-hooks.
<Demosthenes> oh heck. the shell-hooks doesn't support start_commit
<Demosthenes> so back to step one.
<lifeless> http://paste.ubuntu.com/170347/
<lifeless> enjoy
<Demosthenes> hey cool, i'll give it a whirl
<Demosthenes> you ought to post that somewhere so others can use it
<lifeless> oh, the error will fail
<lifeless> sec
<lifeless> http://paste.ubuntu.com/170351/ updated
<Demosthenes> look like it works great!
<Demosthenes> i do appreciate it, i'm just stumped that something simple like that was difficult
<lifeless> cool
<poolie> lifeless: if you're still here: yes, i know, i really want to delete it too
<lifeless> http://webpagetest.org/ is really quite nice
<gcerquant> lifeless: nice (based on the screencast). But it couldn't connect to my website
<gcerquant> now I am wondering if it's a problem with the test tool or with my server
<lifeless> gcerquant: I've pointed it a few sites successfully
<gcerquant> that is even more worrying :-/
<lifeless> e.g. http://pagetest.getrpo.com/result/NSB/ most recently
<gcerquant> i am now trying an other test
 * igc diiner
<gcerquant> looks like I have a DNS problem: testing from Dulles, VA, I get a DNS lookup failed. and from New Zealand, it works fine
<gcerquant> lifeless: thanks a lot for this really neat tool (which also let me know about this problem)
<lifeless> gcerquant: :)
<lifeless> I only heard abou it today, myself
<awilkins> gcerquant: Try setting your DNS to opendns
<awilkins> gcerquant: The commonest reason I run into for DNS problems these days is a DNS daemon on the local wireless router crashing
<awilkins> Usually fixable by router-reboot
<gcerquant> It is (on my personal machine). But the requests are done with a machine I don't have control over... and it shows something is broken somewhere
<awilkins> gcerquant: I hate infrastructure that breaks that other people have control over
<gcerquant> I had similar problem with potential customers that had Verizon as their ISP. Don't know how widespread the problem is
<gcerquant> me too
<Lorem> Hi to all!
<Lorem> i have a question
<Lorem> i need to change my working directory to its parent, what is the best way?
<vila> cd ..
<GaryvdM> Lorem_: can you maybe explain in more detail?
<awilkins> I think he means "I want to move my root to a subfolder of root and commit new content into root"
<Lorem_> awilkins, vice versa
<Lorem_> ah!!! no
<Lorem_> awilkins you are right
<Lorem_> is exactly what i want to do
<awilkins> One aims to please ...
<awilkins> :-)
<Mez> is there a way to enable a postcommit hook for ANY branch on a system? (an overarching bazaar.conf)
<james_w> "[/]" in locations.conf?
<Lorem_> awilkins: i need to do that because i want to devide my project into 2 separete parts
<Mez> james_w: It could be ran as different users though.
<james_w> true
<Mez> james_w: can you specify a post-commit hook from with the branch config ? (somewhere in .bzr?)
<james_w> dunno
<james_w> depends on the hook
<Mez> james_w: basically I wanna setup the system so that it'll send a commit email whenever someone commits to any branch within /home/bzr (no matter who they login as - which is generally done through a bound branch)
<andriijas> how do i check out a project from launchpad?
<awilkins> andriijas: bzr branch lp:projectname
<andriijas> ty
<RaceCondition> are there any plans to make the bzr command a little bit faster? at least comparable to hg which it is currently not...
<lifeless> RaceCondition: we're working on performance all the time
<RaceCondition> but what's causing the current slowness of bzr?
<lifeless> RaceCondition: doing what
<RaceCondition> even bzr status
<lifeless> how long is that taking for you?
<RaceCondition> well not much, but still significantly longer than git status/hg status
<lifeless> all three commands do different things
<lifeless> so its hard to just compare them; however, bzr st for me is 0.3 seconds
<lifeless> on my encrypted-disk slowish laptop
<RaceCondition> 0.3 seconds is a lot
<lifeless> it takes 0.24 seconds to load python and bzrlib
<lifeless> we want to reduce that; its the major part of 'bzr status' these days.
<RaceCondition> well it's obvious there's some constant overhead to all of the commands
<RaceCondition> how come hg loads so fast?
<RaceCondition> I mean I understand git, but hg is Python just like bzr...
<lifeless> hg's code is very very lean, this has some advantages and some disadvantages
<RaceCondition> what do you mean by lean?
<RaceCondition> optimized?
<lifeless> small
<RaceCondition> oh
<RaceCondition> so does the larger code size of bzr somehow result in more/better features?
<Mez> lifeless: how would I setup a server so that any commit to /home/bzr (or sub branches) would generate a commit email? (these commits are generally though bound brnaches)
<lifeless> yes, but its not all needed and that is one of the things we're changing
<lifeless> I have to get back to the regional board emeting though,s orry
<lifeless> Mez: install bzr-email, setup the config in locations.con
<Mez> lifeless: I've tried that on the server. it doesnt work
<lifeless> Mez: bzr versions? maybe file a bug on bzr-email with your config details and what you tried
<Mez> 1.14
<Mez> ah, oops
<Goundy> Guys I registred a branch on launchpad.
<Mez> not the same user
<Mez> damnit for different users :(
<Goundy> Then I did: bzr branch mainline/ myWorkBranche/
<Goundy> Now I want to push myWorkBranch so I create a new branch on launchpad
<Goundy> How to do this ?
<RaceCondition> lifeless: just how long is it estimated that the feature cleanup will take?
<Goundy> I tried a push but it says no new revision de push
<Mez> but still didn't work :(
<lifeless> Goundy: bzr push lp:~USERNAME/PROJECT/NEWBRANCHNAME
<lifeless> Mez: file a bug please; bzr version for client and server and bzr-email version/revno
<Goundy> lifeless yea Indeed it worked right now thank you very much dude ;)
<lifeless> RaceCondition: no specific ETA; removing 0.24 seconds of constant overhead is less important than removing minutes of overhead on slow commands
<lifeless> RaceCondition: on other machines it can be much lower too
<RaceCondition> lifeless: I mean, will it be more like 2 months or more like 12 months?
<lifeless> RaceCondition: I don't know
<RaceCondition> and can I somehow track the progress you're making on this?
<lifeless> sure, use bzr :)
<lifeless> seriously though, the issues are tightly coupled to how python loads code, its not a simple thing to fix.
<RaceCondition> lifeless: what about keeping a persistent process in memory somehow?
<RaceCondition> so bzr status would just IPC that persistent process
<luks> https://launchpad.net/bzr-service
<RaceCondition> how do I use it? is it a replacement bzr command?
<luks> I don't know actually, I just remembered seeing someting like that
<lifeless> RaceCondition: there is a small C binary, bzr-client, that can talk to it
<RaceCondition> lifeless: so will this change the way I use the bzr command?
<lifeless> RaceCondition: I'd expect so; I don't know if it is a maintained plugin or not.
<RaceCondition> well there's no point in better performance if it kills the usability...
<spiv> RaceCondition: also, hg uses a more aggressive lazy-import module than bzr I think.
<RaceCondition> spiv: and it's difficult to do the same in bzr?
<spiv> RaceCondition: I'm pretty sure there's probably still some relatively low-hanging fruit in cleaning up our imports, though.
<RaceCondition> yeah
<RaceCondition> I have a feeling that performance is currently the main thing keeping bzr back, I myself at least am considering switching to hg because of this...
<RaceCondition> but I'll wait if you say it'll be fixed more or less
<spiv> At the moment it's quite common for all the repo formats to get loaded, for instance.  And perhaps we should break up the bzrlib.errors module and put more of the exception definitions closer to the code that uses them.
<lifeless> RaceCondition: performance as a whole is really important to us - just look at how much faster network push has gotten, or commit.
<luks> bzrlib.builtins is pretty huge
<spiv> Just the amount of time for Python to execute that many "class" statements is starting to be noticeable for us, and we always import bzrlib.errors for any command.
<RaceCondition> spiv: still, what about integrating the bzr-service approach to bzr itself?
<lifeless> luks: yes it is. I have some work in progress to radically shrink it. Needs details done.
<RaceCondition> I mean this would mean you won't have to do any refactoring to lose the startup overhead
<spiv> RaceCondition: I'm not very interested in that approach personally, but if someone wants to work on that I wouldn't discourage them.
<spiv> If I ever get enough spare time I'd rather attack the problem at the source (things bzrlib could do better, things python itself could do better)
<RaceCondition> well I'll be waiting :)
<spiv> It's always a challenge finding the right trade-off with this sort of thing.  For example, in general I've quite liked having lots of fairly fine-grained exceptions in bzrlib.errors, it's pretty convenient for maintainability of the code, but it's turned out to be a minor (and I do stress it's only minor) performance issue.
 * awilkins is pretty happy with bzr performance ; no, it's not git, but it's rather faster than SVN and more compatible with win32 than git is
<awilkins> More performance is always welcomed though :-)
<lifeless> awilkins: have you tried out 1.14 client and server yet?
<awilkins> lifeless: 1.14 client is pretty nippy, I keep meaning to upgrade the server but it's not heavily used
<awilkins> I suppose I use the server when I'm serving from my laptop to share it with my desktop
<awilkins> I only ever try git to see if it got less scary on win32 though
<awilkins> Although ATM most of my actual functioning work is being done on Jaunty because I got tired of the slothware that infests our corporate win32 installs
<awilkins> It's actually faster to work on an external USB laptop drive than it is to use the internal drive with the win32 install
<lifeless> nice
<lifeless> you might like to test the 1.14 http server deployment carefully
<awilkins> Why carefully?
<lifeless> there is a bug open that the new jail for hpss servers may break http deployments
<lifeless> I think its unrelated, but not 100%
<lifeless> not 100% sure I mean.
<awilkins> The last time I upgraded it the problem was that it defaulted to logging instead of not logging and the permissions errors were killing it
<awilkins> Not your typical server install ; IIS 6 on win2k3 server running in PyISAPIe
<lifeless> I know :)
<awilkins> I have a very small incentive to upgrade it - most of the operations are being done to a file share and the server is only for external use avoiding the VPN
<awilkins> Ah, yes
<lifeless> we've made hpss operations _much_ better in 1.14 and 1.15;but if you're happy - great.
<awilkins> Most of our external users are no longer working for us at the moment
<lifeless> heh
<awilkins> I'm really the person who uses it the most ; I can't stand fiddling about with VPN and file-share access sucks across it anyway
<awilkins> And I only use it when a user has a problem in their branch they need examining
 * awilkins feels motivated
<awilkins> It's running.... 1.9
<lifeless> heh
<lifeless> iz stable
<awilkins> Of course, our proxy server is so bad that you can't actually download 4.5 MB without it choking...
<awilkins> lifeless: Yup, jail break: 'chroot-59278864:///
<awilkins> Nice.
<lifeless> awilkins: damn
<lifeless> awilkins: 1.12 for you then :(
<lifeless> 1.13.2 happens to be == 1.14
 * lifeless hunts down the bug to confirm
<awilkins> https://bugs.launchpad.net/bzr/+bug/348308.
<ubottu> Ubuntu bug 348308 in bzr "Smart server jail breaks bzr+http with shared repos" [High,Triaged]
<lifeless> awilkins: if you could get a backtrace and perhaps put a few details in there that would be awesome
<awilkins> It doesn't seem to emit a backtrace
 * awilkins tries again
<awilkins> Or maybe I have logging off
<lifeless> Peng_ has done so I just noticed
<lifeless> don't worry, I'll follow up with his log info
<awilkins> Aha
<awilkins> Yes
 * awilkins is tempted to just drop the resgistration of _pre_open_hook
<lifeless> you can do that too
<awilkins> Commenting out _install_hook() on lin 75 of request.py is sufficient for the overly trusting
<awilkins> It's running under  user impersonation anyway and the users concerned only have rights for the repo folders
<lifeless> the jail is to stop the server making http requests to the world ;)
<lifeless> you need write access to make it do that, naturally.
<lifeless> so its not a panic thing
<awilkins> I have assessed the risks (ie - it was unjailed before anyway) and considered them to be manageable
<lifeless> :)
<lifeless> do let me know how it feels otherwise
<lifeless> should be noticable snappier
<awilkins> Well, quite snappy on a "no revisions to pull" from inside the network
<lifeless> :)
<awilkins> Has some issues with commands that write though
<awilkins> I'm running a check on the repo
<maxb_> What is bzr's equivalent to "update -r NNN" in other VCSes? To temporarily set the working tree back to an earlier state
<LeoNerd> revert ?
<maxb_> huh, ok. My intuition derived from other VCSes led me astray :-)
<AmanicA> jelmer: do you know of a workaround for that "OperationalError: database is locked" bug?
<AmanicA> my branch is locked and it does not seem to go away
<AmanicA> sould I delete my cache?
<jelmer> AmanicA: you mean the bzr-svn one?
<AmanicA> yes
<AmanicA> sorry
<jelmer> AmanicA: I pushed a change to bzr-svn 0.6 the other day that allows it to use tdb rather than sqlite
<AmanicA> I saw stuff like that yes
<jelmer> AmanicA: tdb allows multiple writers (i.e. no more locking madness)
<AmanicA> cool
<AmanicA> how do I activate that?
<jelmer> AmanicA: install python-tdb
<AmanicA> ok thx
<AmanicA> btw I found a workaround myself
<AmanicA> lsof |grep svn |less
<jelmer> AmanicA: ah :-)
<AmanicA> and kill the nasty processes holding the lock
<AmanicA> I'll stick that on the bug page
<jonnydee> hi :) when I revert to an earlier revision, how can I ged rid of the marked changes reportet by "bzr st" ?
<jonnydee> AFAIR I have to call another command after invoking "bzr revert -r <revspec>"....
<igc> night all
<james_w> jonnydee: plain "bzr revert" will remove any changes reported by "bzr st"
<jonnydee> james_W: but I thought a plain 'bzr revert'  will revert to the last revision again...?
<james_w> yes
<jonnydee> But I just would like to "travel in time" and go to a specific revision by executing "bzr revert -r <revspec>". Now I want that 'bzr st' doesn't print anything...
<jelmer> jonnydee: I think "bzr update -r" is supposed to do that, but I'm not sure if it's implemented yet
<jonnydee> jelmer: OK, I see. That's what I need, thanks :)
<maxb_> LeoNerd: aha, my intuition wasn't so wrong after all (and bzr revert's help is really misleading)
<jelmer> Yeah, I think we need to fix that..
<LeoNerd> maxb_: Oh.. I presumed you'd already tried 'bzr up -r' and failed.. :)
<maxb_> I did. Per above, it's not implemented
<LeoNerd> Oh..
<maxb_> jelmer: The bit which really confuses me is why "bzr revert" and "bzr revert ." behave differently
<LeoNerd> Hm? It's it   bzr merge .   ?
 * maxb_ has no idea what LeoNerd is talking about :-)
<LeoNerd> Hm.. thatsaid, I'm not sure I do either. perhaps I lost the plot...
<jam> maxb_: 'bzr revert' revert everything in the tree, 'bzr revert .' revert everything underneath the current working directory
<jam> bzr has a concept about the 'whole tree' which svn doesn't have
<jam> jonnydee: you could 'bzr pull -r XXX . --overwrite'
<jam> however, you won't have a way to go back to where you were
<jam> without another branch
<jam> I believe the sticking point for why 'bzr update -r XXX' failed to get implemented
<jam> was where to look up 'XXX' in a heavy checkout situation
<jam> since you could have a local branch and a remote branch, and XXX means different things in each
<maxb_> jam: Sorry, I should have been clearer: the bit which confuses me is what the rationale is for "bzr revert" and "bzr revert ." (in the tree root) behave differently - i.e. in respect to merge records
<jam> maxb_: 'bzr revert .' is only reverting files/dirs, the meta-info isn't under '.'
<jam> I could certainly agree with having a different flag for that
<jelmer> +1
<LeoNerd> Ya.. revert is getting a little overloaded lately..
<LeoNerd> bzr revert should be roughly bzr diff | patch -R
<maxb_> jam: ok, that kind of makes sense. My naive assumption based on using other SCMs was that "resetting merge info" included "resetting the parent of the working tree" - which it actually doesn't, hence my confusion
<maxb_> Regarding the aforementioned lookup problem in heavy checkouts, surely the only sensible answer is "whatever revert -r XXX" does in that case?
<jam> maxb_: 'update' things about the master branch, 'revert' never does (IIRC)
<jam> s/things/thinks/
<jam> for example, 'bzr revert -r -1' does not do the same thing thing 'bzr update' would do. And I would consider "bzr update" ~= "bzr update -r -1"
<maxb_> oh. Um
<maxb_> bzr update is overloaded in the heavy checkout scenario, to mean both "change my local tree's parent" and "get changes from remote branch"
<maxb_> Ok, I understand the conundrum now
<jam> maxb_: right
<jam> and we sort of fell down a "we can't decide so we didn't do anything" pit
<maxb_> understandable, though regrettable
<der|> hi, I would like to create a bzr server on my machine, can you please point me to the right direction on doing that ?, thanks....
<der|> ok never mind, reading the docs :)
<SamB> der|: well, if you just want to provide read-only access, the simplest thing is to just put a repo up on your HTTP server
<cornucopic> Hi all
<cornucopic> bzr-email uses its 'own' smtp_connection.py. Whereas that is understood, why are  certain methods not present there, as compared to the bzrlib/smtp_connection.py ?
<cornucopic> like, for eg. the code in _authenticate() is different for the two
<jelmer> cornucopic: I think that's mainly for historical reasons
<cornucopic> jelmer, What about less/wrong functionality ?
<cornucopic> jelmer, from the looks of it, the former won't look for a username  in authentication.conf , if not specified in bazaar.conf.
<cornucopic> that is one.
<jelmer> cornucopic: I think one has just been patched while the other hasn't
<jelmer> cornucopic: ideally they should be the same
<cornucopic> jelmer, Yes. probably
<ronny> jelmer: what are the plans wrt dulwich workdir support?
<ronny> currently i have to deal with the fact that git wont tell me some data below at least 3 subprocess invocations
<jelmer> ronny: it's there
<jelmer> ronny: :-)
<ronny> jelmer: did the repo url change at some point?
<jelmer> ronny: well, work dir in the sense that we now have a index writer/reader and a function to commit trees
<jelmer> ronny: http://people.samba.org/bzr/jelmer/dulwich/trunk
<jelmer> ronny: or git://git.samba.org/jelmer/dulwich.git
<ronny> jelmer: well, i kinda need something like git status +
<ronny> ie all status information for all files in a workdir
<jelmer> ronny: what exactly do you need? Something to tell you which files are out of date wrt the index?
<ronny> jelmer: i need to know what the vcs thinks about all files in a workdir + what files are missing (and if the index know they are missing)
<SamB> ronny: bzr status ?
<jelmer> ronny: can you perhaps file a bug about what you're looking for (including a suggested API)?
<SamB> oh, are you working in a git checkout ?
<SamB> I mean, a native git checkout ?
<SamB> with a .git directory, not a .bzr directory?
<jelmer> ronny: API as in what it would return/yield, I guess the arguments would be a base path and an index object
<jelmer> SamB: this is actually not related to bzr :-)
<SamB> oh! how confusing.
<SamB> jelmer: what is it about ?
<SamB> oh, dulwich ...
<jelmer> SamB: dulwich (http://samba.org/~jelmer/dulwich)
<SamB> bzr-git's backend ?
<jelmer> SamB: yep, but not tied to bzr in any way
<SamB> I know
<SamB> oh, that's such a pythonic way to name it :-)
<SamB> jelmer: hmm ... I can't seem to clone your repository ...
<SamB> git doesn't seem to like the nested ".git" directories
<jelmer> SamB: yes, that's a git bug
<SamB> jelmer: is it recognized as a bug by the maintainers?
<jelmer> SamB: not sure, I haven't followed up on it
<SamB> I have this feeling the behaviour is intentional ...
<SamB> since it seems like those directories would be really confusing to work with
<SamB> for both humans and tools alike
<jelmer> SamB: I don't see what the problem is for humans
<SamB> well, mostly what the tools would do if invoked from the subdirectory, I guess
<jelmer> use the closest .git directory
<SamB> well, yes, that could get confusing ;-)
<CaMason> is it possible for me to have a 'reference' to an external svn project in my bzr project? I'm using some libs that are hosted on svn
<CaMason> nvm I'll use checkout instead
<pygi> CaMason: not yet
<CaMason> pygi, ok no worries. It was a svn tag anyway :)
<der|> hi, I've created a branch on my computer. A remote user downloaded my branch, he committed the changes, but when trying to push, it gives an error
<beuno> der|, what error?
<der|> bzr: ERROR: Cannot lock LockDir(sftp://host/var/bzr/bzr_test/.bzr/branch/lock): Permission denied: "/var/bzr/bzr_test/.bzr/branch/lock/5mc4cplu0h.tmp": [Errno 13] Permission denied
<der|> I've used bzr with launchpad, haven't tried using my pc as a server though, where the main  branch would be located
<pzico> Hi, I have registered new launchpad project, but I'm a bit unsure how should I name branches. Should the name of the main branch be linux or ubuntu or dev.. or should I divide different parts in separate branches like python functionality in it's own and C in it's own.
<SamB> pzico: generally, you put the whole code tree in one branch, and call it something like lp:~pzico/fooproject/trunk
<pzico> Maybe I need some practical tutorial. Somehow those launchpad examples only mixed my head.
<SamB> and then you make other branches for topics and stuff
<pzico> does that mean that the trunk is also a folder on my home directory where I also made bzr init command?
<SamB> not exactly
<SamB> that's your local repository, where you work
<SamB> you would push that to the lp url, though
<SamB> oh, the ~pzico in the launchpad url just means that it's one of your branches
<pzico> hmm, by taking couple of random examples of existing projects, why can't I see trunk used as a branch name?
<SamB> the next bit, fooproject, should be the exact URL name of your launchpad project
<SamB> pzico: well, often it gets abbreviated to just lp:fooproject
<SamB> the third bit is whatever you like ...
<pzico> so the trunk is a sensible name for the initial development branch?
<SamB> yup
<pzico> thanks, I just did my first push :D
<pzico> Launchpad says: A development focus branch hasn't been specified, set it now.
<pzico> Should I put here also that same?
<pzico> I chose the same. I guess I got it all working.
<pzico> Is it a good practice to have a separate branch for documentation or to include in trunk under specific folder name?
<der|> I've created a bzr server on my machine, and I'm trying to commit the changes to the server, but it gives the following error: This transport does not update the working tree of: bzr://localhost/projects/bzr_test/trunk/. See 'bzr help working-trees' for more information.
<der|> bzr: ERROR: Cannot lock LockDir(chroot-33399120:///projects/bzr_test/trunk/.bzr/branch/lock): Transport operation not possible: readonly transport
<LarstiQ> pzico: normally, I'd keep everything pertaining to a project in one and the same branch
<LarstiQ> der|: those are two different things
<der|> LarstiQ, sorry, I'm a little bit confused here :)
<LarstiQ> der|: the readonly mention seems to me like you didn't specify --allow-writes
<der|> LarstiQ, uhm.... right....
<der|> LarstiQ, the --allow-writes should be passed when running bzr init right ?
<LarstiQ> der|: to bzr serve
<der|> LarstiQ, ah, good, let me try that
<LarstiQ> der|: that is how you are running the server, right?
<der|> LarstiQ, correct
<LarstiQ> ok then
<der|> what's the difference between the checkout and the branch commands ?
<LarstiQ> der|: as to not upating the workingtree, a workingtree is usually not needed on a server hosting bzr branches
<der|> LarstiQ, and why is that ?
<LarstiQ> der|: checkouts bundle commit/publish and if you branch you decouple those.
<LarstiQ> der|: all the required data for bzr to operate is stored in .bzr/
<der|> LarstiQ, yes
<der|> LarstiQ, so, that means that if I'm going to have a server hosting bzr branches, I need working trees or normal trees ?
<LarstiQ> der|: that means you only need branches
<LarstiQ> der|: so on the server, go to /projects/bzr_test/trunk and do `bzr remove-tree`
<der|> LarstiQ, ok
<der|> LarstiQ, done
<der|> LarstiQ, after I remove the working tree, I can push to that tree right ?
<LarstiQ> der|: s/tree/branch/, yes :)
<der|> LarstiQ, ah, I think I get it, correct me if I'm wrong..... so working trees are good with local branches
<LarstiQ> der|: correct!
<der|> LarstiQ, so let's say, /var/bzr/stuff
<der|> LarstiQ, but, when I use a server, working trees are not needed, and we need branches
<LarstiQ> for editing files, using them, etc.
<LarstiQ> der|: basically.
<der|> LarstiQ, and, by default, bzr creates working trees with bzr-init right ?
<LarstiQ> der|: yes
<der|> LarstiQ, ah ok
<der|> LarstiQ, I'm a 3D artist, and I'm using bzr to keep track of the changes
<LarstiQ> and bzr will not create working trees if you push to a remote server
<LarstiQ> der|: cool :)
<der|> along with qbzr, I created a small tool to make things faster
<der|> let me show you
<der|> LarstiQ, I'm doing this:  http://ernestomendez.wordpress.com
<LarstiQ> der|: so if you do `bzr init; bzr add; bz ci` locally, and then `bzr push to/server`, it will do the right thing
<der|> LarstiQ, I'm using the qbzr plugin, along with a small gui I did for qbzr, to access stuff fast... Here's the screenshot:  http://imagebin.org/48617
<LarstiQ> der|: so your tool is the list of actions on the right?
<der|> yeah
<LarstiQ> der|: how does it work, does it call the qcommands from the dir you started the tool from?
<der|> LarstiQ, and I created a small .desktop file inside the project, with the variable Path= set as the working directory, where the project is located
<LarstiQ> aah
<der|> :D
<der|> smart huh :P
<LarstiQ> :)
<der|> I had to read the .desktop file specification, was breaking my head
<LarstiQ> der|: have you thought of contributing this to the qbzr plugin?
<der|> LarstiQ, well, it would be my pleasure :D
<der|> LarstiQ, I didn't know that would be of some use for you guys
<der|> LarstiQ, and the cool thing, it doesn't use any .glade file, just pure code
<LarstiQ> der|: you mention .glade, does that mean it uses gtk?
<der|> LarstiQ, yeah, it's written in python/gtk  (pygtk)
<LarstiQ> ah ok
<der|> but surely the guy can be implemented on qt
<LarstiQ> der|: qbzr is written in pyqt
 * LarstiQ nods
<LarstiQ> luks: would something like der|'s http://imagebin.org/48617 be useful to qbzr?
<der|> LarstiQ, I mean, it's cool since you access all qbzr's commands easily, without having to use the command line
 * LarstiQ nods
<LarstiQ> der|: I think there is a use for it, but I'm not a qbzr contributor.
<der|> LarstiQ, ah, and the cool thing is, when you don't have a .bzr directory in it, the only button it has is 'Initialize Branch' which is bzr qinit
<luks> hm, I'd rather add nautilus menu items
<luks> so you don't have to launch any app
<der|> yeah, nautilus-scripts would do the job too
<LarstiQ> right, but you need to bring the menu up each and every time
<der|> yeah
<der|> on this case, you bring up the small app, then you just click, it won't close
<der|> that way you can see the logs, then add the files,then commit etc
<LarstiQ> qbrowse comes closeish
<LarstiQ> qbrowse \o/
<LarstiQ> luks: thanks for that btw :)
<luks> there is (unfinished and dead) bzr qbzr, which had this ambition
<der|> luks, LarstiQ you can have the code here: http://dpaste.com/43453/
<LeoNerd> Ahah. I think I've found a bug... 'bzr revert' will save an old copy of a file to foo.~1~, unless it was modified by a merge. But now since 'bzr shelve' is implemented using a merge, it won't save one if you shelve/unshelve/revert
<jnz_> Hi, I'm having a problem supporting sftp into bzr, that is this: https://bugs.launchpad.net/ubuntu/+source/python-crypto/+bug/79519 . But I haven't understool how to resolve it.
<ubottu> Launchpad bug 79519 in python-crypto "ImportError: No module named Crypto.Util.randpool" [High,Won't fix]
<jnz_> *understood
<jnz_> uh great :D
 * LarstiQ looks at the bug
<jnz_> I'm not using ubuntu
<LarstiQ> jnz_: so the ubuntu bug doesn't apply to you :) Do you have pycrypto installed?
<LarstiQ> without paramiko won't work, without which bzr can't support sftp/ssh
<LarstiQ> LeoNerd: ah, good catch
<jnz_> uhm I have read that was needed only m2crypto, however I don't have it (no module named pycrypto)
<LarstiQ> jnz_: python -c 'import Crypto' ?
<jnz_> no module named Crypto
<LarstiQ> jnz_: then you don't have it installed
<LarstiQ> jnz_: if your package management doesn't provide it, http://pypi.python.org/pypi/pycrypto
<LarstiQ> hmm, maybe that is old
<LarstiQ> but no, that is what I've got installed on Debian
<jnz_> I've installed it, but the problem remains, http://pastebin.com/m1721b456 (localhost is just for the test)
<LarstiQ> jnz_: now it mentions you don't have paramiko installed
<jnz_> It's strange, if I open the python shell and try with `import paramiko' I get only warning message, but if I run the bzr command no module paramiko is found
<LarstiQ> jnz_: does your bzr use the same python install as `python` from the commandline?
<LarstiQ> jnz_: see `bzr --version`
<chrismurf> Hi - I just performed a merge, and now 'bzr info' shows a 'submit branch' related to my repository.  What is that, and how do I get rid of it?
<jnz_> ok resolved, thanks LarstiQ
<chrismurf> now I have a "public branch" too.  How do I just get rid of the 'related branches' -- they aren't valid locations.
<LarstiQ> chrismurf: just like with pull --remember you can change those lcocations merge sets.
<chrismurf> LarstiQ, I'm sorry; I don't understand?
<LarstiQ> chrismurf: all the related branches get set by bzr commands if they're empty, or if you pass --remember to the relevant command
<chrismurf> okay - so given that I now have the related branches, how do I get rid of them?
<LarstiQ> chrismurf: is it your aim to have no related branhces at all, or different ones?
<chrismurf> I didn't use '--remember' so, I'm not sure where they came from?
<chrismurf> in this case, none
<chrismurf> it's pointing at a temporary merge directory I created
<chrismurf> which I doubt does harm, but that directory is going to go away
<LarstiQ> chrismurf: the going away is fine
<LarstiQ> chrismurf: they serve as defaults so you can do `bzr merge` without specifying an argument
<LarstiQ> but anyway
<LarstiQ> chrismurf: .bzr/branch/branch.conf
<chrismurf> Ah!  Thank you
<chrismurf> and thank you for explaining their purpose
<LarstiQ> and as useful shorthands
<chrismurf> been using BZR mostly for client-server style interactions for a while now
<LarstiQ> say, `bzr missing nosmart+:parent/../sibling`
<chrismurf> but starting to use it more as a DVCS, and still learning
<LarstiQ> chrismurf: righ
<LarstiQ> chrismurf: main thing to remember, all branches are equal, none is technically special, it's just convenients for us humans :)
<chrismurf> right :-)
<chrismurf> so - hand editing branch.conf is a not-awful way to change such things?
<chrismurf> since they're just convenience tags for me anyway?
<LarstiQ> chrismurf: I think it's a bit of a ui wart, but yes, that's ok
<LarstiQ> nothing in bzr will miss 'm
<chrismurf> okay - and there's no "bzr get-rid-of-shortcuts" I should know :-)
<LarstiQ> indeed
<chrismurf> well, again, many thanks
<LarstiQ> np
<LarstiQ> chrismurf: feel free to ask more questions on your path to DVCS nirvana ;)
<luke-jr_> If I 'bzr commit', and 'bzr uncommit', will that commit be kept in the repository under its 'revid' in case I ever want to dig it out in the future?
<lifeless> luke-jr_: yes until you garbage collect (there is a plugi to do this), or if you branch to a new repo it won't be copied across
<lifeless> moin
<luke-jr_> I see.
<luke-jr_> so it wouldn't get sent with a push, either?
<luke-jr_> is there a good way to save scraps better? ;)
<jam> morning lifeless
<jam> luke-jr_: create a branch for them?
<luke-jr_> jam: by "scraps" I mean "broken and never worked or even compiled" ;)
<jam> luke-jr_: if you have a commit that you want to save, I recommend creating a branch for them
<jam> I personally have no qualms committing broken code
<jam> I just don't merge it to 'trunk'
<luke-jr_> i c
<jam> lifeless: I've been working on some slides, they are still pretty rough
<jam> I was thinking to upload them somewhere if you wanted to then take over
<jam> would you prefer a bzr branch?
<jam> (I'm using .odp)
<lifeless> jam: branch or mail is fine
<lifeless> branch would be the canonical way :P
<jam> lifeless: yeah, I just feel a little silly uploading a work-in progress to a +junk branch, but that was my original idea
<lifeless> doit ;)
<lifeless> we can't merge, so lets be careful about handing off
<beuno> in bbc  :)
<lifeless> beuno: ?
<beuno> in dev6-r-r format
<beuno> dogfoooooood!
<bob2> congrats on becoming an adaptive vcs
<lifeless> jam: drop me a mail when you've pushed;
<jam> lifeless: lp:~jameinel/+junk/karmic_presentations
<jam> I'm out for the night
<AmanicA> dam its late if the americans goes to bed before you
<jelmer> it's not a problem until you go to bed after the Californians ;-)
<lifeless> AmanicA: the americans always go to bed before me
<AmanicA> :)
<AmanicA> like right after you get up
<lifeless> :)
<mwhudson> actually, not always
<mwhudson> sometimes they are still around when i quit work, which is not really right :)
<jelmer> lifeless: around?
<lifeless> yes!
<jelmer> lifeless: CHKMap, is that usable for a single file (like knits are), and could I use it to store arbitrary data?
<jelmer> I'm using a knit for the file id map in bzr-svn atm, and from what I've seen a CHKMap would both be faster and more efficient
<lifeless> jelmer: you need a pack repository style container
<lifeless> same as bzr-search does
<jelmer> lifeless: but it can store just arbitrary data (I need path string -> tuple of 3 strings) ?
<lifeless> chkmap is str->str
<lifeless> encode as you like on top
<lifeless> actually I like
<jelmer> neat, I'll go check that out
<lifeless> its tuple->str
<lifeless> s/like/lie
<jelmer> mwhudson: looks like the linux kernel doesn't work with bzr-git yet
<jelmer> mwhudson: they use unusual file modes that aren't mappable to bzr inventory entry properties
<lifeless> oh?
<jelmer> those file modes are forbidden in git these days, but they used to be allowed
<jelmer> 644 and 755 are the only modes set by non-ancient versions of git
<jelmer> and the linux kernel has e.g. 664 in some places
<mwhudson> jelmer: weeeee!
#bzr 2009-05-13
<lifeless> jelmer: I wouldn't use chk_map unless you need updatable values
<lifeless> jelmer: if you just need key:value and they are immutable use BTreeIndex
<jelmer> lifeless: I need a big path -> tuple map that's different per revision but should have relatively small (line-based) differences between revisions
<jelmer> lifeless: very much like an inventory
<jelmer> s/line-based/path-based/
<lifeless> ok for that you want chkmap
<lifeless> you may want to look at chk inventories parent_id,basename->child_id map
<lifeless> as a related use of chk_map
<lifeless> we use two maps
<jelmer> lifeless: What about the Pack container bits from bzr-search, where should i be looking?
<lifeless> one for paths
<lifeless> one for the data
<lifeless> b.p.search.index
<lifeless> basically to work with chkmap you need a VersionedFiles object that supports hash naming
<lifeless> it might be possible to convince knits to do this
<lifeless> I'm not sure it would be a good idea ;)
<lifeless> so the layering is:
<lifeless> chkmap->VF
<lifeless> (KnitVersionedFiles|GroupCompressVersionedFiles)->(collection of btreeindex + pack files)
<lifeless> and its that last bit that bzr-search has a smallish implementation of
<jelmer> thanks
<jelmer> this is all a bit new to me, VersionedFiles are still very much an abstract thing to me
<lifeless> ok
<lifeless> I think you should learn about the internals here
<lifeless> its hampering bug fixing
<lifeless> also our layers could be better
<lifeless> got 20 minutes?
<lifeless> jelmer: ^
<jelmer> lifeless: if you can give a quick introduction that might help
<lifeless> thats my plan
<lifeless> so
<lifeless> one sec
<lifeless> jelmer: ok
<lifeless> jelmer: so lets start with VersionedFiles
<jelmer> lifeless: ok
<jelmer> lifeless: fwiw I'm familiar with the API
<jelmer> lifeless: just not how it works underneath
<lifeless> sure
<lifeless> so
<lifeless> Weaves work by having a thunk class, not very interesting.
<lifeless> more interesting is how Knits and Packs work for the KnitVersionedFiles clas
<lifeless> bring up knit.py
<lifeless> look for make_file_factory
<jelmer> right, I think that's what I'm using right now for the file id map
<thumper> hi people
<lifeless> so this creates the two key objects KVF needs to work
<poolie> hello all
<lifeless> an index, which is responsible for locating bytes and storing the graph
<thumper> is there documentation on using the merge sorted graph?
<lifeless> and an access object, which is responsible for taking index descriptions of content and reading them back, or for writing and returning index descriptions
<lifeless> hi thumper poolie no
<jelmer> hi thumper, poolie
<lifeless> jelmer: so _KndxIndex is the implemenetation of an index based on ,kndx files, and _KnitGraphIndex is the implementation of same building on the 'GraphIndex' interface
<lifeless> likewise _KnitKeyAccess and _DirectPackAccess
 * jelmer nods
<lifeless> so, to use chk_map on .kndx and .knit files, we'd create a KVF much like make_file_factory does
<lifeless> now if you look at KnitVersionedFiles itself
<lifeless> this is the common logic that actually cares about knit deltas, their constraints and needs and so on
<mwhudson> thumper: i can probably tell you more than you want to know :)
<lifeless> so it knows about delta chains (we'd want 0), annotations (0 again)
<lifeless> it also knows about fallbacks to other VF objects, which is much of how stacking works on the client
<thumper> what is the easiest way to get the revision_id for any mainline (non-dotted) revno?
<lifeless> branch.revno2revid
<thumper> lifeless: no attribute called ...
<lifeless> jelmer: ok, I'm not sure where to drill down into; we can look at how _DirectPackAccess and _KnitGraphIndex work
<lifeless> thumper: its roughly that
<lifeless> thumper: pydoc and / for the win
<thumper> lifeless: there are revision_id_to_revno
<lifeless> jelmer: or we can look at actually wiring up chk_map to .knit files for you
<thumper> lifeless: but not the other way around
<jelmer> lifeless: let's look at the latter first
<thumper> mwhudson: where is your pydoc stuff for bzr?
<jelmer> lifeless: actually working with this code should help
<lifeless> dotted_revno_to_revision_id and get_rev_id and
<lifeless> jelmer: ok
<lifeless> so
<lifeless> lets pop over to chkmap
<lifeless> CHKMap wants a store, root_key and a search key func
<lifeless> the search key func is for hashed keys
<lifeless> we can ignore that for now
<lifeless> root_key is something you need to store elsewhere
<lifeless> its the 'id' of a given version of a dict stored in a chk_map
<lifeless> so you'll need someplace to put that. perhaps another knit, or whatever.
<lifeless> to bootstrap, when you first start, you use from_dict
<lifeless> so -
<lifeless> my_map = CHKMap.from_dict(store, {}) is the minimal call
<lifeless> that will get a non-splitting map with single-element tuples as keys
<lifeless> what you probably want is maximum_size=4096
<lifeless> so to wire it up
<lifeless> store = get_a_versioned_files()
<lifeless> empty_map = CHKMap.from_dict(store, {}, maximum_size=4096)
 * jelmer nods
<lifeless> then you can stash stuff in it.
<lifeless> you can individually map() and unmap()
<lifeless> however its much better to use apply_delta
<lifeless> because map and unmap write on each change
<lifeless> apply_delta applies all the changes and then writes
<lifeless> the get_a_versioned_files call should return a VF whose key width is 1
<lifeless> and no graph
<lifeless> so lets pop back to knit.py
<lifeless> access = _KnitKeyAccess(transport, mapper); mapper=ConstantMapper('myknit'); index = _KndxIndex(transport, mapper, lambda:None, lambda:True, lambda:True)
<lifeless> You want ConstantMapper because you want the same .knit and .kndx file for all keys
<jelmer> ok
<lifeless> the lambdas are for handling lock/unlock callbacks
<lifeless> you should wire them up more carefully
<thumper> kudos to the bzr developers for making an api even I find easy!
<lifeless> before using with concurrent processes
<lifeless> then its just
<lifeless> store = KnitVersionedFiles(index, access, annotated=False, max_delta_chain=0)
<jelmer> lifeless: ok, let me give that a try
<jelmer> mwhudson: btw, I've "fixed" the bzr-git importing strange modes issue
<mwhudson> thumper: http://starship.python.net/crew/mwh/bzrlibapi/
<mwhudson> jelmer: cool
<jelmer> mwhudson: it just means it won't be able to regenerate the sha map correctly if you remove it
<jelmer> mwhudson: it'll also warn if it hits strange modes
<jelmer> mwhudson: same thing for the XML-invalid characters that are escaped
<mwhudson> jelmer: i'm not sure i understand
<mwhudson> jelmer: remove what?
<jelmer> mwhudson: git.[t]db
<jelmer> mwhudson: which contains the information of which bzr revid/fileid maps to which git sha
<mwhudson> jelmer: ok, but i still don't understand what that has to do with strange modes
<jelmer> mwhudson: git works with shas everywhere
<jelmer> mwhudson: so when we talk to it we need to tell it which shas we have
<mwhudson> jelmer: currently, the git.db does not persist between runs
<jelmer> mwhudson: we generate those shas from the bzr data we have by converting to git objects and shaing those
<jelmer> mwhudson: if we can't regenerate the exact same git object we can't find a particular sha
<mwhudson> jelmer: ahh
<mwhudson> jelmer: so "persisting the sha data between runs" has become a bit more important?
<jelmer> mwhudson: yeah, a bit. previously we would just flat out refuse to import anything with strange file modes, now we just warn
<jelmer> mwhudson: we could store the file modes in revision properties at some point
<jelmer> mwhudson: in which case we could regenerate the sha map correctly again
<jelmer> mwhudson: s/file modes/unusual file modes/ (they're really rare)
<mwhudson> jelmer: yes but the kernel is a pretty obvious target, i think we need to support that
<mwhudson> (ultimately, not necessarily in the next release)
<jelmer> mwhudson: sure
<jelmer> mwhudson: Storing in revision properties should fix this, and keeping the sha map around works around the problem
<jelmer> there's only 3 files in the kernel with unusual modes
<lifeless> jelmer: so how did that work?
<jelmer> lifeless: still working on it
<lifeless> ok
<lifeless> apply_delta is real simple
<lifeless> I'm going to start working on these presentations
<lifeless> gimme a shout anytime
<lifeless> jam: wow bvg is very, uhm, brief
<jelmer> lifeless: Hmm, CHKMap.from_dict() returns the new root key
<jelmer> lifeless: so I just use CHKMap(store, root_key) to get it out again?
<lifeless> yes
<lifeless> apply_delta also returns a replacement key
<lifeless> (from_dict is a shim around apply_delta)
<jelmer> ok, that's working now
<jelmer> lifeless: in the case of inventories, what do you use the key tuples for ?
<jelmer> and is there any reason why I might want e.g. the individual directory names in the tuple instead of just a 1-tuple with a path?
<lifeless> jelmer: size
<lifeless> we store inventories as two dicts
<lifeless> (parentid, child_name)->child_id
<lifeless> (fileid,) -> serialized_entry
<lifeless> the former gives us 'ls /foo/bar'
<lifeless> the latter gives us tree.inventory['fooid']
<lifeless> jelmer: what are you storing
<jelmer> lifeless: I'm storing unicode_path -> (file_id, revision_id, created_foreign_revid)
<lifeless> and on only ever lookup on path ?
<jelmer> lifeless: no, lookup by file id is also possible
<lifeless> s/on/you/
<lifeless> ok
<lifeless> so you'll need two maps
<lifeless> if you want fast lookup on fileid
<jelmer> lifeless: but lookup by file id is very rare ("bzr check" uses it)
<lifeless> check is getting overhauled ;)
<lifeless> this is for svn ?
<jelmer> lifeless: You're overhauling bzr-svn's check too ? ;-)
<lifeless> no, but the api calls bzr makes are being overhauled
<jelmer> lifeless: yeah, bzr-svn does check too (it checks the consistency of the bzr metadata)
<lifeless> so the access pattern is going to radically change
<lifeless> alrighty, we cn ignore it at your risk:)
<lifeless> so
<lifeless> do you need to iterate paths ?
<lifeless> or is it 'give me data for X'
<lifeless> amd do you need to do case-insensitive matches
<jelmer> I mostly need to just look at particular items
<jelmer> by path
<lifeless> so if you store every path you'll have a lot of duplicate data
<lifeless> the trie will reduce some/much of o that
<lifeless> but not all
<jelmer> duplicate in the sense that duplicate revids are used?
<lifeless> in particular leaf nodes have the full key of each item to allow finding the thing you asked for
<lifeless> no duplicate in the sense that foo/bar and foo/gam both have foo/ in the key
<jelmer> ah, right
<lifeless> so you should zcat your knit and ahve a look, we had some optimisation plans and I don't recall exactly what items jam got to
<lifeless> and what we deferred/didn't do.
<lifeless> anyhow
<jelmer> that's not worse than what we have now though
<lifeless> you could hash the keys (via the key func), you could use two dicts (parent,child)->filed, fileed->(revid, foreignid)
<lifeless> or you could say 'I'm happy as it stands'
<lifeless> a more important thing though
<lifeless> 'knits' load the full index always
<lifeless> this sucks for doing little operations
<lifeless> so when you hve this working we should look at backing it onto packs+btree indices
<jelmer> ok
<lifeless> man, I so want to code
<jelmer> what's stopping you?
<mwhudson> jelmer: thinking about it, i think relying on the sha map persisting is pretty smelly :)
<jelmer> mwhudson: yes, it is. that's why we're warning
<lifeless> jelmer: presentations to write
<jelmer> lifeless: ah. uds?
<lifeless> yes
<lifeless> and bzr and git are hot topics
<lifeless> likely ot have a hundred folk, I suspect
<jelmer> lifeless: uhm, how do I get my data out of a CHKMap?
<jelmer> other than iteritems()?
<lifeless> any way you want ? :)
<lifeless> iteritems
<jelmer> ok
<lifeless> and iter_changes
<lifeless> iteritems(['path1'])
<lifeless> is == __getitem__('path1'), if we had it
<lifeless> we don't because its not cheap and the api should reflect the reality
<jelmer> ValueError: Prefix has too many nulls versus width ?
<lifeless> ('path1',)
<jelmer> thanks
<igc> morning (at last)
<lifeless> igc: just :)
<igc> lifeless: :-)
<igc> hi
<igc> thanks for the review
<lifeless> no probs
<lifeless> I think its not much work to do your approach at the right layer
<lifeless> And I agree we can defer really deeply integrating it.
<lifeless> I do think its important to have tests, and that they are really best written against the right layer.
<igc> me too
<lifeless> I hope I suggested a reasonable way to do that
<igc> lifeless: I did
<igc> lifeless: I would really like to leverage the specfiic files masking at the layer below
<igc> while perhaps keeping the parent yielding ...
<igc> and exclude masking a layer above
<igc> lifeless: but I got a weird error from record_iter_changes when I tried
<igc> is that fixed by parent yielding do you know?
<lifeless> paste the error ?
<lifeless> Git pull of dulwich: 2.43 MiB  in 0m53.437s
<lifeless> Bzr pull of dulwich: 360KB in 0m36.602s
<lifeless> woo
<igc> lifeless: I'll need to change the code again and re-run. Will do later
<lifeless> jml: I think jam and I have to rename our talk
<lifeless> 'when bzr became faster than git'
<jml> lifeless: that's a very nice result.
<lifeless> igc: so, without seeing the error I can't do much more than guess
<thumper> lifeless: are those numbers representitive of normal usage?
<lifeless> thumper: 'bzr branch lp:~lifeless/dulwich/trunk-bbc
<lifeless> thumper: vs 'git init; git pull git://gitorious.org/dulwich/mainline.git'
<jml> lifeless: but were it me, I'd leave the talk with the same title and demonstrate its obsolescence with a big bar graph.
<lifeless> thumper: so, I'd say yes
<lifeless> jml: yes, I was jesting about the rename
<lifeless> the title is nice and contentious
<jml> lifeless: :D
<jml> very good result though.
<lifeless> I wanted to paste the result though
 * jml is keen to see the results for the kernel
<lifeless> I was thinking, 'lets get some numbers'.
<lifeless> and boom.
<lifeless> thumper: big histories may scale differently. I don't know precisely.
<thumper> lifeless: very cool
<lifeless> of course, over http it took 6 minutes to get dulwich bzr
<lifeless> don't mention the war
<thumper> lifeless: but git isn't using http is it?
<lifeless> no
<lifeless> git is using its native protocol
<thumper> lifeless: so we are still comparing oranges with tangerines rather than oranges to fork lifts
<bob2> is lp especially aggressive about packing things?
<thumper> bob2: no
<lifeless> thumper: yes, both protocols are fruity
<jelmer> lifeless: nice!
<jelmer> lifeless: do I explicitly have to remove entries from the chk map or is overwriting them fine as well?
<poolie> thumper: want to catch up about nested trees sometime?
<thumper> poolie: yes
<poolie> now?
<thumper> sure
<lifeless> jelmer: use apply delta
<poolie> thumper: call me?
<johnf> lifeless: you about?
<poolie> hello johnf
<lifeless> johnf: sure am
<johnf> poolie: howdy
<johnf> lifeless: re bug https://bugs.launchpad.net/bzr/+bug/243391
<ubottu> Ubuntu bug 243391 in bzr "TooManyConcurrentRequests during commit" [High,Fix released]
<lifeless> johnf: there's this theory I'm paid to do this sort of thing :)
<poolie> igc: one small chore for you next week: please moderate the mailing list
<poolie> it gets a ridiculous amount of spam but enough real posts are caught you do need to check it
<igc> poolie: sure
<johnf> I'm getting a similar error when an upstream router returns admin proibited. Would that be fixed or should I file another bug?
<lifeless> johnf: bzr version ?
<johnf> client 1.14.1 server 1.13
<lifeless> johnf: new bug, that was 1.8
<lifeless> johnf: I take it you've fixed your router though ? :>
<johnf> lifeless: no it's normal. Happens if the VPN is down
<lifeless> johnf: so, I suspect this is a variant of 'ssh tells us shit', unless you're committing over http
<johnf> lifeless: this is using bzr://
<lifeless> johnf: ok. please be sure to include that detail in your new bug report ;)
<lifeless> johnf: root cause will be that we try to perform an operation on the protocol object while its still thinking its busy
<johnf> lifeless:  I think I'll add to this bug as it seems to be the same problem https://bugs.launchpad.net/bzr/+bug/323456
<ubottu> Ubuntu bug 323456 in bzr "TooManyConcurrentRequests when committing and the smart server is offline" [Undecided,New]
<lifeless> gimme a sec to read it
<lifeless> yah, do it
<lifeless> or just metoo the bug
<lifeless> jelmer: can you suggest a midsize project with history in git and bzr - same history, as dulwich has
<lifeless> jelmer: I'd like to do a slightly less 'new project' test
<jelmer> lifeless: I'm using apply delta, but may be overwriting keys without removing the old data at the same key - is that a problem?
<jelmer> lifeless: hmm
<lifeless> jelmer: its expected
<jelmer> lifeless: cool, thanks
<lifeless> jelmer: you can't have a key repeated in a chkmap
<jelmer> lifeless: Not sure about other projects. You could use one from gnome that's available in both svn and git
<lifeless> jam: hi :)
<lifeless> jam: gathering data for our talk, I found:
<lifeless> 11:35 < lifeless> Git pull of dulwich: 2.43 MiB  in 0m53.437s
<lifeless> 11:35 < lifeless> Bzr pull of dulwich: 360KB in 0m36.602s
<lifeless> jelmer: I might ask a favour, if you're willing, as you have gitorious etc accounts
<lifeless> jelmer: put together a similar sample case, but something that is say 10x the size of dulwich
 * lifeless binds nose to ooo
<igc> lifeless: is pqm broken? I just tried resubmitting a patch and it fails pretty well instantly grumbling about 'subunit' I think
<lifeless> igc: forward to me please
<lifeless> it shouldn't be, as subunit is optional.
<igc> lifeless: I don't get an email either re success or failure as best I can tell
<lifeless> igc: and to land a patch making it mandatory the patch would have to pass
<igc> lifeless: I'll run the test suite on my integration branch and see if it's my fault
<lifeless> bug in pqm
<lifeless> it may be fixed i nwhich case we can just say 'spm please upgrade pqm'
<lifeless> lets start with that
<lifeless> spm: please upgrade pqm
<poolie> igc, abentley, i read through the updated design doc and i have some comments
<poolie> i know some of my questions on the user doc were answered in the design doc, but i wasn't always asking them for the sake of the answer
<poolie> more to say they should be described here
<igc> poolie: I'm planning to update the userdoc given the feedback from you and others
 * lifeless taps the mic
<lifeless> spm: ping
<lifeless> igc: I'm sorry you haven't had feedback from me yet
<lifeless> igc: feeling the crunch with allhands and 1.15
<lifeless> igc: your branch is probably faulty btw, I think its a bug in pqm that you don't get told, not a bug in pqm causing it to fail
<igc> poolie: but I don't think the userdoc is the critical path given abentley is working from the design doc
<igc> poolie: except for how the userdoc impacts the design doc
<spm> lifeless: sorry was on the phone. couple of minor family hassles atm. so upgrade pqm on balleny? I assume a bzr pull equiv would do the trick?
<lifeless> spm: yeah, cd ~/source/pqm; bzr pull
<lifeless> spm: then igc can try again
<lifeless> and we see what breaks.
<spm> oki. one sec or more...
<spm> lifeless: igc: upgraded. go for it.
<AfC> Is "1.9-rich-root" is the still the current public rich root format, or is there a newer one I should tell someone to use?
<lifeless> AfC: its what --default-rich-root will create.
<AfC> k
<lifeless> AfC: if you need working tree filters you can use 1.14-rich-root, but only windows users are likely to be desperate for that
<AfC> nah
<lifeless> and if you want to help beta test the bbc format you can use --development-rich-root
<lifeless> igc - thats what you hit in pqm https://bugs.edge.launchpad.net/pqm/+bug/340361
<ubottu> Ubuntu bug 340361 in pqm "bad format usage" [High,Confirmed]
<igc> lifeless: http://rafb.net/p/dMFRc592.html
<igc> lifeless: anything obviously wrong?
<igc> I trying to use a new integration branch fwiw
<igc> one on lp as poolie has requested
<lifeless> igc: your branch url is probably the problem
<lifeless> igc: two things
<lifeless> firstly, ~ianc/bzr/integration would be a better url
<lifeless> no point having your personal integration branch a team branch
<lifeless> secondly, I don't know if balleny can talk to lp
<igc> well, except lp fails whether I try to push to ~ian-clatworthy/bzr/ianc-integration :-(
<lifeless> spm: can you check that pqm user on ballent, outside chroot, can do 'bzr info bzr+ssh://bazaar.launchpad.net/%7Ebzr/bzr/ianc-integration/'
<lifeless> igc: it does, how ?
<lifeless> igc: or rather, in what way
<igc> grumbles about a read-only transport
<igc> and breaklock doesn't fix it
<lifeless> pastebin please
<spm> lifeless: it can yes.
<igc> lifeless: http://rafb.net/p/gnKmyI33.html
<igc> lifeless: looks like ~ian-clatworthy/bzr/integration has worked though
<lifeless> much nicer url :)
<igc> lifeless: well, except for the vfs noise: http://rafb.net/p/CMcA4E84.html
<lifeless> igc: yes, bzr is running 1.14
<lifeless> 1.15 will remove that for a simple push
<lifeless> dunno why you get that lock error
<lifeless> readonly transport means that lp thinks *you* can't write to it
<lifeless> file a question on launchpad-code
<lifeless> I suspect a bug
<igc> lifeless: ok, I'll try a http url to that new branch
<lifeless> igc: bzr+ssh should be ok, spm has confirmed it works
<lifeless> igc: what commit message were you giving pqm
<lifeless> ?
<igc> lifeless: see http://rafb.net/p/dMFRc592.html
<igc> maybe the & is causing an issue?
<lifeless> I would suspect so
<igc> lifeless: so neither changing to a http URL, nor changing & => 'and' fixed the problem
<igc> I added 'public_branch:policy' to branch.conf but that didn't help either
<igc> the full test suite passes locally
<igc> I don't have push_location:policy set to norecurse. Is that likely to cause an issue?
<lifeless> jml - whats up with https://code.edge.launchpad.net/~jelmer/pqm/merge
<lifeless> jml: I can't access it as 'lp:~jelmer/pqm/merge'
<thumper> lifeless: that is because there is nothing there
<lifeless> https://code.edge.launchpad.net/~jelmer/pqm/merge/+merge/6122 seemed to find something at some point
<thumper> lifeless: or broken
<lifeless> jelmer: ^^^^
<thumper> lifeless: probably created with bzr send
<lifeless> isn't that meant to create a working branch?
 * igc lunch
<bob2> no matter how many times I branch dulwich, git takes twice as long
<thumper> did I recall seing that bbc branches stack in 1.15dev?
<lifeless> yes
<lifeless> bob2: :)
<thumper> lifeless: cool
<lifeless> or at least, jam has it mostly going and we're aiming for 1.15
<lifeless> spm: please pull bzr from people.ubuntu.com/~robertc/pqm/trunk
<jml> bob2: given that the git version is almost seven times bigger, that's not surprising :)
<bob2> heh, even after a repack, it's 2x
<lifeless> jml: 7 times data sent
<lifeless> bob2: same history
<jml> lifeless: oh.
<lifeless> jml: ^ same history
<jml> lifeless: that's actually quite interesting :)
<spm> lifeless: balleny pqm update again?
<lifeless> jml: its why I chose dulwich, jelmer keeps them in sync
<lifeless> spm: please, from the url above
<bob2> hm, 5x repo size
<spm> lifeless: done. ddidn't restart the ui this time, appears unchanged.
<lifeless> igc: please try again
<lifeless> igc: I think you managed to have a revision that had a % in it. Odd though that may be. that or your url has a % in it
<lifeless> igc: and thank you for the excuse to write some code :)
<igc> lifeless: anytime :-)
<lifeless> igc: so on commit
<lifeless> igc: I think you should spend say 2 hours just doing it. At any blockage cry for a hand
<lifeless> if at the end of that it looks like indefinite deferral, stop and I'll cave or something
<lifeless> OTOH its in your head, and you've already figured out the bits needed.
<igc> lifeless: well, I'm not convinced the layering is right to be honest
<igc> record_iter_changes ...
<igc> claims to take the results of iter_changes but it doesn't
<igc> so you need to do the mssing -> delete dance for example
<lifeless> by which you mean iter_changes isn't compatible with it ?
<igc> so I wonder whether ...
<igc> record_iter_changes ought to be handling that, and the parent yielding
<igc> the trouble is ...
<igc> record_iter_changes is *5* pages in length
<igc> not exactly easy to hack on
<igc> lifeless: I've had terrible pain these last 24 hours and the pain killers aren't working ...
<igc> so apologies if I'm coming across grumpy
<lifeless> igc: ouch :(
<lifeless> not at all
<igc> dentist tomorrow but it's prably chemo frug related :-(
<lifeless> you raise a good point
<igc> s/frug/drug/
<lifeless> record iter changes is long, but mostly clear
<igc> so, reporting aside, maybe ...
<lifeless> the major data-assembly points can be turned into helpers without performance impact; its only the main loop we need to be really careful on
<igc> fliter_iter_changes needs to move into commitbuilder
<lifeless> commit.py needs:
<lifeless>  - reporting
<lifeless>  - awareness of missing->deleted changes so it can update the working tree
 * lifeless tries to remember what 'missing' files will do when sent to ric
<abentley> poolie: While those changes might improve the userdoc, I don't see that helping us decide how to move forward with nested trees.
<lifeless> get_file_with_stat will fail
<lifeless> igc: ok, so ric wants something that is a subset of iter-changes (no 'missing' status) and a superset ('add parents please')
<lifeless> igc: I think reporting should stay outside
<igc> me too
<lifeless> igc: ok, let me rephrase what I really want
<lifeless> I think its gotten lost
<igc> and btw, iter_changes needs to do more for commit than it currently does, e.g. unknown checking
<lifeless>  - specific tests for the handling of parent-adding and path-excluding
<lifeless> given that the interface isn't as crystal as I recall, I won't ask that those things be in the iter_changes interface, and certainly not as a rush just before 1.15
<lifeless> so I'm fine with them outside it.
<igc> and I'm happy to add those tests but ...
<igc> I don't think that ought to block my interim patch :-)
<lifeless> I think its easier to test those things if they are not embedded in Commit
<lifeless> igc: Given I think your patch has at least one bug which such tests will catch, I think it should
<lifeless> you'
<lifeless> ^typo
<igc> I think the parent yielding and excludes can be a decorator as you outlined and tested as such
<lifeless> great
<lifeless> with that done I'll be happy to approve ;)
<igc> do you want the missing -> delete dance done in the same decorator
<lifeless> if you want to move it across, that would be fine with me. OTOH its orthogonal to what you are trying to achieve.
<igc> do we know whether a pipeline of decorators is faster than one or vice versa?
<igc> I know that's ...
<igc> a bit like asking how long a piece of string is
<lifeless> there is a cost
<lifeless> OTOH specific file commits tend to be small anyway
<lifeless> commit [list of 4000 files] is rare
<igc> right
<igc> that's why I felt pushing the code down wouldn't gain much performance wise
<lifeless> the only really-big-list commits we see that people will notice a small percentage point on is first-commit
<lifeless> oh, pushing it down is about clarity and reuse for 'diff' and 'status', not about further performance wins.
<igc> and that won't have excludes and specific files most likely
<lifeless> exclude may gain substantially by pushing into iter_changes
<lifeless> (consider -x large-directory)
<lifeless> even an unchanged large directory will be a lot cheaper if you don't stat it at all
<lifeless> because you won't page it in from disk etc etc
<igc> lifeless: so wrt diff and status ...
<igc> neither take a -x flag do they?
<igc> and neither care about parent yielding?
<lifeless> no, because the code is trapped in commit :)
<lifeless> status should show what commit will do; it can't at the moment.
<lifeless> this was an oversight when the commit -x support was accepted
<igc> so, IIUIC, you're arging that status and diff ought to gain -x options once iter_changes supports an exclude parameter?
<lifeless> absolutely
<igc> arguing
<igc> and parent yielding? That still smells like a ric special need to me
<lifeless> bzr diff foo/bar -> A foo\nRM bar\n
<lifeless> iter_changes can't generate valid inventory deltas without parent yielding of new parents
<lifeless> that sharply limits its reuse in the core
<lifeless> I appreciate your arguments for doing less, now. But I think the reasons to push these things down to iter_changes at some point are pretty strong and valid
<lifeless> exclude for performance, yielding new parents for correctness in tools like fast-export, ric itself, various custom bits of code.
<igc> hmm - in some ways, CommitBuilder is the inventory-delta generator
<lifeless> anyhow - like I say, I've backed off from insisting you do the move to iter_changes; unless you're considering doing it, we're just idly chatting
<igc> lifeless: sorry, just trying to get the right long term layering clear in my mind
<lifeless> yes, thats a prime component of CommitBuilder.ric
 * igc heads back to coding
<lifeless> igc: thats cool; I didn't want you to be feeling that I was still asking for it, was all.
<igc> sure
<lifeless> igc: have you tried pqm again?
<igc> lifeless: looking much better thanks
<lifeless> great
<igc> thanks to spm too
<spm> igc: us qlder's need to look out for each other. ;-)
<igc> spm: absolutely :-)
<vila> hi all
<spm> morn vila!
<lifeless> hi vila
<lifeless> vila: how did you go with annotate?
<vila> I'll really start to day, I was hoping to quickly finish fixing a bug but bmuped on a test coverage hole :-/ Then I prepared a talk for all hands...
<vila> s/to day/today/
<lifeless> what talk are you giving?
<vila> lifeless: I don't know if I'm the one who will be giging it, but anyway, it's about mysql users
<vila> lifeless: but if you have some template around I'll buy it
<lifeless> lp:~lifeless/+junk/karmic_presentations
<vila> lifeless: perfect, thanks
<jnz__> Hi, bzr push --create-prefix raised an internal error after I've inserted the password:
<jnz__> bzr: ERROR: exceptions.AttributeError: 'str' object has no attribute 'get'
<jnz__> https://answers.launchpad.net/bzr/+question/69809
 * igc dinner
<awilkins> lifeless: The HTTP server seems to be broken for me as far back as 1.12
<awilkins> lifeless: I'm rolling back through versions to see where it starts working again
<Peng_> Whowhat is broken?
<awilkins> Peng_: bzr+http:// server, on Win2k3 server / IIS / PyISAPIe
<Peng_> Oh. What goes wrong?
<Peng_> (Not that I can help, but I'm curious.)
<awilkins> I'm geting "FileExists" exceptions
<awilkins> When pushing
<awilkins> Pulling appears to be fine
<Peng_> Oh.
<awilkins> Alas, different exceptions when I turn on server-side logging
 * awilkins cusses loudly
<awilkins> I upgraded the server to 1.14 and it stops working. I downgrade it back to 1.9, and it's still not working in exactly the same way.
<lifeless> awilkins: file bugs
<lifeless> awilkins: I'm about to start a social event, but I'll comment on them at a minumum tomorrow :)
<lifeless> awilkins: [of course, debugging it yourself is great too]
<awilkins> I don't think it's necessarily a bzr problem
<awilkins> Yes, I think a few hours with a filesystem debugger and contemplating dark thoughts about people who install antivirus on servers is required
<awilkins> It seems similar to a bug in the atomic rename thing
<awilkins> Well, "bug"
<awilkins> As in a "Windows is crap bug"
<awilkins> Can you reindex a repository?
<awilkins> I'm getting bzr: ERROR (ignored): GraphIndex('bzr+http://w .....
<awilkins> But that's not where it stops
<bialix> vila: hi
<vila> bialix: Hi Alexander
<bialix> bonjour monsieur
<bialix> I need to test some unicode thing
<bialix> please, tell me how you enter accented characters in French?
<jml> like in cafÃ©?
<bialix> yes
<jml> on my computer, I use the Compose key
<bialix> Hm? I don't see compose key
<vila> u"Cet Ã©tÃ© au cafÃ©".encode('UTF-8')
<vila> 'Cet \xc3\xa9t\xc3\xa9 au caf\xc3\xa9'
<jml> Compose+' Compose+e
<jml> bialix: it's kind of a virtual key, mine is bound to Right Alt
<vila> jml: compose key on windows ? :-)
<bialix> vila: I need to test command line behaviour
<jml> on Windows... who knows.
<bialix> maybe Vincent knows?
<jml> on OS X its Option-' e IIRC
<vila> bialix: I *never* use accented letters from command line, but the trick on windows I remember it via Alt-nnn sequences
<bialix> oh; I see
<vila> now, the sequence for accented letters... you may know better ? :-/
<bialix> â
<bialix> ââ
<bialix> h,,
<bialix> hmm
 * bialix going to test alt codes
<bialix> It seems like french keyboard layout very different from qwerty
<vila> oh, yes
<jml> I blame Napoleon :P
<bialix> :-)
<vila> Ã© is on '2' with a french layou
<vila> t
<bialix> yes; it is
<bialix> this will be enough for me, thanks
<vila> ok, np
<bialix> FranÃ§ais
<jnz__> Hi, there are some trouble if I use python 2.6 to run bazaar? I see that there are some warning using deprecated lib and an error trying to use `get' method in `str' (that doesn't exist now).
<james_w> jnz__: what's the full message?
<jnz__> AttributeError: 'str' object has no attribute 'get' https://answers.launchpad.net/bzr/+question/69809
<jnz__> it's the same bug I've reproduced
<jnz__> (but on linux)
<jnz__> the fact is that I can't remove svn plugin
<james_w> I thought that had been fixed, but I can't find the bug number now
<Peng_> That question links to the bug.
<Peng_> jnz__: The AttributeError has nothing to do with your Python version.
<Peng_> jnz__: If you're running a recent version of bzr, all of the deprecation warnings and other Python 2.6 issues should have been fixed. If you're still seeing any, they're probably in third-party libraries. In any case, file bugs if they haven't been fixed.
<Spaz> 'ello
<Spaz> i'm having a problem with loggerhead
<Spaz> http://pastebin.ca/1421449
<awilkins> "Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'get_bytes_as'")
<Spaz> i get that on every request.
<awilkins> That's from LP, on doing "bzr branch lp:bzr/1.14" ; oopsie
<Peng_> Spaz: What version of Loggerhead?
<Peng_> Oh, trunk.
<Peng_> Spaz: As a workaround, you can revert a few revisions; that code was only added recently.
<Spaz> ah ok
<Peng_> (in r335)
<Peng_> I honestly don't get it. branch_url is a method; it's defined 5 lines above!
<Peng_> My only guess is that some file, perhaps serve-branches, is from an old version that does something funny.
<Peng_> Oh, you're using start-loggerhead? I never tested that.
<Spaz> yep.
<Peng_> Hmm. I don't know the start-loggerhead code at all. :\
<Peng_> branch_url never used to be called, so if it was set to the wrong thing, it wouldn't have been noticed until I started using it in r335.
<Spaz> reverting r335 fixes it
<Spaz> Peng_, ^
<Peng_> Ah, I see where it goes wrong.
<Spaz> Peng_, you're a loggerhead dev? :p
<Peng_> Spaz: Allegedly.
<Spaz> :P
<Peng_> Um, I'm not sure what the solution should be, though. Easiest would probably just be renaming hte "branch_url" method so it won't get clobbered.
<Spaz> occam's razor :p
<Spaz> the simplest solution is usually the correct one
<Peng_> Not necessarily.
<Peng_> (Well, hence it saying "usually" instead of "always"...)
<Spaz> it's not always, but most of the time it is
<Spaz> at least i like to think so
<Spaz> :)
<Peng_> The method didn't have a great name anyway.
<Peng_> Y'know, if you used serve-branches, it wouldn't be broken. ;D
<Spaz> Peng_, start-loggerhead suits my needs better
<Spaz> :p
<Spaz> 1) looks better, 2) extremely small amount of projects
<Peng_> It looks better?
<Spaz> Peng_, see http://web-bzr.wilcox-tech.com :p
<Spaz> for one project it looks a lot nicer
<Spaz> oops awos-bzr.wilcox-tech.com
<Peng_> Oh, nifty.
<Peng_> But if people use start-loggerhead, I have to figure out how to use it so I can actually test it. :P
<Peng_> Spaz: I filed bug 375948.
<ubottu> Launchpad bug 375948 in loggerhead "loggerhead.apps.config clobbers BranchWSGIApp.branch_url method" [Undecided,New] https://launchpad.net/bugs/375948
<jelmer> I thought start-loggerhead was going away?
<Peng_> jelmer: That's the plan.
<Peng_> jelmer: But start-loggerhead can still do some things serve-branches can't.
<Peng_> Spaz: I've pushed a workaround to lp:loggerhead
<Spaz> thanks
<Peng_> Well, the good news is that from now on I'll test start-loggerhead. :P
<Spaz> hehe
<Peng_> Well, after converting one branch to a stacked branch, I saved 2 MB of disk space, but I can no longer push. Perhaps not worth it?
<jelmer> lifeless: ping
<Peng_> What's a simple command I can use that will lock the branch? Without having to use some "python -c 'import bzrlib'" magic?
<Peng_> (I don't want to leave the lock in place or anything, just see if one can be taken out.)
<Peng_> Never mind.
<Peng_> beuno: ping
<awilkins> Peng_: I think you just need to create a file in the right place
<awilkins> lifeless: ping?
<awilkins> I found the problem ; it's creating the same pack twice
<awilkins> Which win32 doesn't like because it's renaming a file from "upload" to "packs" but because they are named after their md5, the file is already there and on win32 you can't rename a file to an existing destination
<awilkins> Deleting the pack appears to have expunged the problem. Maybe it was linked to the jailbreak thing...
<awilkins> Maybe the jailbreak error puts the repo into this state.
<beuno> Peng_, hi
<Peng_> Ah, hello.
<Peng_> beuno: I was just curious, in Loggerhead, what is BranchWSGIApp.branch_link? All it says is that it's only used by LP.
<beuno> Peng_, I don't remember what we use it for
<beuno> but I can find the glue code and figure it out
<Peng_> beuno: Well, it's not important, so you don't have to bother.
<beuno> Peng_, I think it was something about showing the branch URL in LH
<igc> night all
<Peng_> igc: Good night.
<lifeless> awilkins: bzr is meant to not do that; ah
<lifeless> awilkins: bzr hada  stale pack it didn't knowabout anymore
<lifeless> awilkins: thats why the rename was being attempted at all
<lifeless> awilkins: please file a bug
<lifeless> awilkins: we should handle this case
<Peng_> beuno: Thanks for the review. :)
<beuno> Peng_, thanks for all the work
<Peng_> :)
<luke-jr_> blah, bzr-svn doesn't merge :<
<SamB> luke-jr: say what?
<luke-jr_> SamB: I can't merge svn commits and push my stuff to it
<luke-jr_> it errors
<jelmer> luke-jr_: what error do you get exactly?
<luke-jr_> I need to make a new branch of the svn, merge my bzr repo into that, then push that
<luke-jr_> bzr: ERROR: exceptions.AssertionError: Expected <CachingRevisionMetadata for revision 2422, path vxmlb/tags/no_spm_count_no_ext_grammars_no_playfile in repository 'f396537e-aa06-0410-a58a-90fff5392f0b'> got <CachingRevisionMetadata for revision 382, path tags/no_spm_count_no_ext_grammars_no_playfile in repository 'f396537e-aa06-0410-a58a-90fff5392f0b'>
<luke-jr_> oops, forgot to edit paths
<luke-jr_> don't store that in a bug report or such as-is please :)
<jelmer> luke-jr_: there's an open bug about this, will be fixed before 0.6.0 (i.e. in a few days)
<SamB> luke-jr: if there's some secret info in there, I can't imagine what it might be!
<SamB> or are you just embarrassed?
<phinze> seeking bzr one liner... how to determine when file "path/to/file" was removed?
<Peng_> "bzr log"...might work? in recent versions? if the file was deleted recently?
<Peng_> It won't be fast, since the only way to do it is to check each revision 1 at a time.
<phinze> bzr: ERROR: Path unknown at end or start of revision range:  .... on 1.14.1
<SamB> phinze: do you remember a revision where it was still alive ?
<Peng_> Guess not, then.
<phinze> yeah i've got one rev when it was alive
<SamB> maybe that can help?
<phinze> i'll try a bzr log $OLDREV.. --verbose --short | grep D | grep filename
<phinze> something like that
<phinze> and wait :)
<Peng_> Like I said, with the current design it can't be fast. For that reason, it's not encouraged by the UI..
<phinze> looks like it was in the last 20 revs
<phinze> i'll narrow it down
<phinze> might look into bzr-undelete plugin in the future
<phinze> https://launchpad.net/bzr-undelete
<SamB> did I mention the bisect plugin yet?
<bmorris> Does anybody know of a good tutorial for setting up the pqm?
<Ken69267> how does one checkout a branch from googlecode with bzr-svn? I can't seem to specify the username it wants for authentication
<Peng_> Ken69267: Yeah, that's kind of a bug. When Bazaar tries to detect what type of branch it is, it asks for .bzr/smart, and Google asks for auth.
<Peng_> Ken69267: You can use svn+http:// to work around it, depending on your version of bzr-svn.
<Ken69267> yeah I tried svn+https://, but my username is different than my shell. svn+https://username@ doesn't seem to work
<Peng_> Fortunately, I don't care about Google Code much, so I haven't bothered to solve this. Or bug jelmer much.
<Peng_> Not so fortunate for you, though. :\
<jelmer> Ken69267: if you don't specify a username bzr should ask you if you have a new enough bzr
<Lo-lan-do> Hi all
<jelmer> hey Lo-lan-do
<Lo-lan-do> :-)
<Lo-lan-do> I get different errors now... I'll pastebin them, shall I?
<jelmer> Lo-lan-do: can you mail them perhaps?
<Lo-lan-do> Sure
 * jelmer back in ~30 min
<Lo-lan-do> Mailed.  Take your time, I'm also struggling with an unrelated shared library problem :-)
<Ken69267> jelmer: bzr 1.14.1 and bzr-svn 0.5.4 here, doesn't prompt for username :/
<jelmer> Ken69267: you need bzr.dev I think
<jelmer> Ken69267: does http://username@... work (no svn+) ?
<Ken69267> jelmer: no, bzr bombs out with a pycurl error
<Ken69267> (with https://user@)
<jelmer> Ken69267: ah
<Ken69267> allwell, I rarely use googlecode anyway
<jelmer> Ken69267: so, this should be fixed in 1.15
<jelmer> Lo-lan-do: replied
<beuno> Peng_, ready for the rich-root-ization of LH?
<beuno> (I won't do it *now*, but in a few hours)
<Lo-lan-do> jelmer: Got it, thanks.
<Peng_> beuno: Ready as I'll ever be.
<Peng_> Upgrade stacked-on branches first, right?
<beuno> Peng_, yes, the ones you care about
<beuno> what I'm going to do
<beuno> is upload a new branch
<beuno> leave the current one as-is
<beuno> and just change the developemnt focus
<Peng_> Oh, why?
<beuno> *maybe* that won't break stacked-on branches
<Peng_> Ah.
<Lo-lan-do> jelmer: s/graphwalker/graph_walker/ in dulwich/repo.py:231
<beuno> Peng_, this is me trying to figure out the best upgrade strategy  :)
<jelmer> Lo-lan-do: thanks, fixed
<Peng_> I'm really apathetic at the moment, so I won't have any opinion unless someone makes a Rich-root-tan or something.
 * beuno hugs Peng_ 
<Peng_> :D
<Peng_> Anyway, switching out the branches makes sense, though it'll be inconvenient for subscribers.
<Lo-lan-do> jelmer: I still get NameError: global name 'BzrDir' is not defined; did you push?
<beuno> yeah, not sure what the best inconvenience is yet
<Peng_> And the linked bugs and merge proposals.
<jelmer> Lo-lan-do: yeah
<jelmer> Lo-lan-do: where are you pulling from?
<beuno> Peng_, so what do you think?  break all stacked-on branches or loose linkage?
<Peng_> I wonder if you could rename the branch, push a new non-rr branch as lp:~loggerhead-team/loggerhead/trunk, then upgrade the original branch to rr.
<Peng_> Did that make sense?
<beuno> ah
<Lo-lan-do> jelmer: http://people.samba.org/bzr/jelmer/bzr-git/trunk or lp:bzr-git
<Peng_> This sounds like a job for...staging.lp.net!
<beuno> Peng_, that's interesting
<Lo-lan-do> (And s/bzr-git/dulwich/ for dulwich)
<beuno> Peng_, are you going to try that?
<beuno> or want me to?
<jelmer> Lo-lan-do: hmm, odd, that location should work
<Peng_> beuno: Yeah, I'll try it.
<jelmer> Lo-lan-do: oops, forgot to commit
<jelmer> Lo-lan-do: sorry, pushed properly now
<beuno> Peng_, \o/
<Peng_> How do staging URLs work? lp://staging/~user/project/branch?
<beuno> yeap
<Peng_> Thanks.
<beuno> lifeless, igc, should the traceback for VFS usage be sput out to stdout instead of .bzr.log?
<Peng_> OK, what was my plan again? :P Blinkblink. Anyway.
<Peng_> I should be doing this on my faster machine with the better connection.
<beuno> Peng_, your amazing plan is:  rename trunk, push a non-r-r as trunk, upgrade old-trunk, rename old-trunk to new trunk, see if everything's alright  :)
<ja1> beuno: I that only happens when you use -Dhpss, IIRC
<Peng_> Crap, it tried to stack on lp:loggerhead, which obviously screwed up.
<ja1> And I think there is argument where it should go
<beuno> ja1, ah, makes sense
<Peng_> Actually, it says "not a branch".
<beuno> I have that set by default
<ja1> I think someone mentioned that it should be muttered(), and then realized that it also helps force us to fix things :)
<beuno> rockstar, how do you push to staging? mwhudson around yet?
<Lo-lan-do> jelmer: Yay, progress.  New errors at http://pastebin.com/d27aef86d :-)
<ja1> otherwise, I would think it should be 'noted' so it goes to stderr + .bzr.log
<Peng_> Screw it, I won't use staging.
<ja1> brb
<rockstar> beuno, bzr push lp://staging/...
<beuno> wow
<beuno> HPSS calls: 46 (11 vfs) SmartSSHClientMedium(connected=False, username=u'beuno', host='bazaar.launchpad.net', port=None)
<beuno> argh
<Peng_> How do you force a push to not stack? Downgrade to Branch6?
<beuno> I was about to ask that same thing  ;)
 * beuno will try pushing to +junk and then renaming
<Wyvern> Hey!
<Peng_> What will upgrading to rich-roots do to all of the stacked branches in lp:~*/loggerhead? This may be a problem.
<Wyvern> Question: How can I cancel an bzr add? That is before commit.
<Lo-lan-do> bzr rm --keep
<Wyvern> Thank you.
<Peng_> Great, push was taking forever because I forgot that ssh-agent wasn't running! :P
<Peng_> Using Branch6 did not prevent it from stacking.
<Peng_> So I'm kind of stuck now.
<Peng_> I suppose I could dig out bzr 1.5.
<jelmer> Lo-lan-do: pushed another fix
<Peng_> It may be possible to work around the default stacking policy by using a Branc6 mirrored branch.
<Lo-lan-do> jelmer: Yay, cloning a git branch through bzr-upplad-pack now works :-)
<jelmer> woot :-)
<Peng_> beuno: These stacking issues are really killing my attention span. :P
<beuno> Peng_, https://code.edge.launchpad.net/~loggerhead-team/loggerhead/rich-trunk
<beuno> :)
<beuno> (pushed to +junk, then moved it)
<Peng_> Ah, clever.
<beuno> Launchpad has trained me to be sneaky
<Peng_> Heheh, push peaked at 731 KB/sec. >:D
<Peng_> beuno: Wait, I didn't think this out. Could you do me a favor and subscribe to https://code.edge.launchpad.net/~mnordhoff/loggerhead/trunk ?
<Peng_> Wait.
 * beuno waits twice
<Peng_> Yeah, that branch.
<Peng_> Heh.
<Peng_> It would've been better to use staging so I could link it to a bug report, but oh well.
<beuno> Peng_, done
<Peng_> beuno: Thanks.
<Peng_> brb
<bialix> jam: hi
<bialix> yep
<bialix> jam: hi
<jam> hi bialix
<jam> having some networking issues here, so I may come and go
<bialix> I've prepared the patch for unicode cmd line @ win32
<Peng_> Is it just me or does branch --stacked make a painful number of ssh connections?
<bialix> jam: I suspect you're busy with other patches, I'm just hope you will be able to look at my patch
<bialix> Peng_: 3 or 4?
<Peng_> bialix: I killed it and fixed ssh-agent after 6.
<Peng_> OK, *maybe* 5.
<bialix> it does not sound right
<Peng_> Reconciling over bzr+ssh is not so efficient. :P
<beuno> Peng_, no, I did all of that locally  :)
<jam> bialix: I'll try to give it a shot.  I'll mention that with my network going wonky, I'm not getting all of my email
<Peng_> What's the easiest way to upgrade a remote branch? Doing it remotely? If so, and you need to do reconcile too...
<jam> if you want to CC my gmail account, it may be a bit more trustworthy
<Peng_> Anyway, this is just for fun anyway, and I hope LP won't mind wasting 30 MB of bandwidth. :P
<jam> Peng_: *reconciling* is not so efficient
<Peng_> So far it's at 18 MB of bandwidth. :D
<jam> bialix: So is this the problem that qbzr is trying to pass unicode arguments to a bzr subprocess?
<jam> and is going through "OEM" encoding
<bialix> jam: I'm using gmane, what about http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cguf7hb%24k3h%241%40ger.gmane.org%3E
<beuno> Peng_, it's called "research"
<jam> which fails for certain unrepresentable bits?
<bialix> jam: AFAICT, qbzr trying to pass unicode argumets to bzr. but any python program unable to retrieve unicode right, only as plain strings
<jam> bialix: but this only helps when using CreateProcessW
<jam> and *doesn't* do anything for the actual command line
<jam> At least, I'm pretty sure "cmd.exe" has a specific encoding
<jam> and isn't generic about Unicode support
<bialix> jam: I've tested manually in cmd.exe shell
<bialix> GetCommandLineW is able to get right unicode
<jam> bialix: sure, but it would other ways, too
<jam> My question is, can you type Ø¬ÙØ¬Ù in your Russian cmd.exe shell?
<bialix> "would other ways"?
<jam> bialix: if the strings are passed in as OEM, and then they are decoded from OEM
<jam> things should work
<bialix> I don't understand Arabic
<jam> bialix: you don't have to
<jam> it is just a few characters for you to try
<bialix> but I've learnt French, and I can type French in my shell
<jam> well, IDLE doesn't like me. Giving: Unsupported characters in input
<bialix> actually I have netbook with non-Russian Windows XP
<Lo-lan-do> jelmer: Minor patch: http://pastebin.com/f5f7eb376
<jam> bialix: so my point of using Arabic is that it is quite unlikely to be on a given code page
<bialix> there I can type non-russian characters without problem
<jam> unlike French characters
<bialix> French is from cp1251
<bialix> while Russian is cp1251
<jam> bialix: well, on a 'non-Russian" windows, I would want to try Russion chars
<jam> bialix: cp1251 == cp1251
<bialix> cp1251 has no room for non-cyrillic
<bialix> of course it works with Russian char
<jam> bialix: can you type a couple cyrillic chars for me to test with?
<jam> or give me their code points
<Peng_> So far, upgrade over bzr+ssh seems disgustingly inefficient.
<bialix> I'm just tested on my Russian Windows XP
<bialix> I can type French here too
<Peng_> I could probably twiddle with hitchhiker or sftp to accomplish the same thing, but that takes more thinking.
<bialix> jam: here is Test in Russian: Ð¢ÐµÑÑ
<jam> bialix: any chance you could put that in hex codes for me?
<jam> cygwin doesn't like it, and neither does IDLE
<jam> and vim just gives me ????
<jam> bialix: pasting those chars into cmd.exe gives me ????
<bialix> jam: are you using vim wit console or GUI interface?
<jam> bialix: vim w/ gui
<Peng_> What will changing the developer focus do? Change what new branches automatically stack on? Will it change old branches too? Cuz that'd be a problem.
<jam> It could just be Pidgin not copying them correctly
<jam> If I do 'chcp 1251' in cmd.exe I at least get characters when I paste your cyryllic
<bialix> jam: re cmd.exe: right-click on cmd.exe window button on task panel, select Properties -> Font -> Lucida Console
<jam> but it comes out as: pi sigma +/- >=
<bialix> Lucida is unicode font
<Peng_> FYI? Upgrade over bzr+ssh is horribly slow. Using hitchhiker is definitely a better idea.
<jam> bialix: ok, so it works if I 'chcp 1251' and then paste
<bialix> it will show you right characters
<jam> And it looks like Ð¢ÐµÑÑ
<jam> but with the default chcp (437) it fails
<bialix> yeah, is it
<bialix> try Lucida
<jam> ah, it worked this time
<jam> weird
<jelmer> Lo-lan-do: thanks
<bialix> default is OEM font it's not unicode
<jam> bialix: however, it gives me just [] for Arabic
 * bialix adding Arabic keyboard
<Peng_> beuno: This upgrade will probably take half an hour. Unless I get bored, kill it and do it more efficiently, you'll have to wait that long to see how it pans out. Although I've probably done enough now.
<beuno> Peng_, I have about half a million things to do today
<beuno> so I'll probably be around here forever
<bialix> jam: I have not Arabic keyboard settings on my Russian XP
<Peng_> beuno: Although I'm not finished, I'm pretty sure my evil plan will work. So I'd vote for doing it on lp:loggerhead.
<mwhudson> Peng_: loggerhead.apps.config is a terrible terrible thing
<Peng_> mwhudson: :D
<jam> bialix: you have Cut & Paste don't you?
<beuno> Peng_, I think it will. If it does, I will create a document so everyone else follows this path
<beuno> I'm willing to break everything in the name of research
<bialix> jam: yes, I can, but it seems my Russian XP lacks of Arabic fonts. I see 4 squares instead of real chars
<bialix> but Wordpad paste them OK
<mwhudson> Peng_: also i don't care about it at all from a launchapd pov, so pleae feel free to do whatever you like to it :)
<bialix> jam: will try with cmdline.py script
<Peng_> mwhudson: OK, thanks. :)
<jam> bialix: well, I *have* Arabic fonts installed, and I only see 4 squares in cmd.exe :)
<bialix> jam: cmdline.py is able to see it!
<bialix> C:\Temp>python cmdline.py Ø¬ÙØ¬Ù
<bialix> ['cmdline.py', '????']
<bialix> [u'cmdline.py', u'\u062c\u0648\u062c\u0648']
<bialix> ha!
<jam> bialix: your public branch is a bit wonky
<bialix> do you see it?
<jam> C:/work...
<jam> I don't know where 'cmdline.py' is
<jam> but your paste here looks appropriate
<bialix> http://launchpadlibrarian.net/26668118/cmdline.py
<Peng_> OK, I think I've got it all worked out, though I've never fully put it together.
<bialix> jam: my public branch is wonky 'coz I don;t have public branch
<jam> hmm... using python25 I get:
<jam> NameError: global name 'WINFUNCTYPE' is not defined
<Peng_> beuno: You want the rich version of trunk to be called "trunk-rich"?
<jam> ah, I know why
<jam> just a sec
<beuno> Peng_, I... don't care as much  :)
<jam> k, I get:
<bialix> C:\Temp>python -V
<bialix> Python 2.5.4
<jam> C:\Users\jameinel\dev\bzr\patches>C:\Python25\python cmdline.py Ø¬ÙØ¬Ù
<jam> ['cmdline.py', '????']
<jam> [u'cmdline.py', u'\u062c\u0648\u062c\u0648']
<jam> (I was accidentally just using 'python' which would be cygwin python)
<jam> Anyway, I get [] in the console
<jam> but it does seem to support those characters
<bialix> the same here
<jam> even if Lucida Console can't draw them
<bialix> yep
<jam> interestingly enough, I've already set my cygwin shell to use Lucida Console
<jam> Though in that shell
<jam> I can't write Arabic characters
<jam> weird
<bialix> IIRC in Vista there is another shell font used
<jam> (chcp is also not found)
<jam> bialix: there are only 2 choices
<jam> Lucida, and RAster
<jam> Raster
<jam> just interesting that cygwin.bat mutates its shell enough
<Peng_> beuno: Wait, you used "rich-trunk". Anyway, *I* like "trunk-rich". :P
<bialix> IMO raster is non-unicode
<beuno> Peng_, you've earned the right to name it whatever floats your boat
<bialix> jam: yes, cygwin does wonly things
<Peng_> beuno: Hehe, okay.
<bialix> jam: just curious: how you type Arabic on Windows?
<bialix> alt codes?
<Peng_> beuno or anyone interested: Here's the sequence of commands that should do it: http://paste.pocoo.org/show/117139/
<Peng_> It's not even that crazy.
<beuno> Peng_, so it's done?
<beuno> thanks for that, btw
<Peng_> beuno: I haven't actually done it yet. I could, though!
<Peng_> beuno: Do you want me to?
<beuno> Peng_, yes!
<beuno> go for it
<beuno> let me know if I need to change the dev focus
<beuno> or if you can
<jam> bialix: no, I have an alternate keyboard layout
<jam> and switch between them
<jam> Alt+Shift+0 == arabic
<jam> Alt+Shift+1 == qwerty
<jam> Alt+Shift+2 == dvorak
<Peng_> beuno: I've never done it before, but I probably can. Thanks, I'll ask you if I need to.
<bialix> ok, I understand
<jam> argh.... it seems when I contacted support to get my internet access working, they disabled my email account because I claimed not to use it
<jam> which I don't
<jam> but I use their server to forward my home email
<jam> (relay)
<Peng_> Whoops, I left that bzr upgrade over bzr+ssh running. It's at 56 MB of bandwidth and like 2/3 of the way through! :D
<bialix> jam: do you want more unicode testing from me?
<jam> bialix: I don't know any more I need right now
<jam> I'll play with it a bit and let you know
<bialix> thank you
 * bialix going offline
<bialix> bye
<rockstar> abentley, I don't see a way to get a branch's repository format.
<Peng_> Um, hmm. I may have just made lp:loggerhead stack on itself. Or something equally untoward. Oops.
<abentley> rockstar: branch.repository._format ?
<Peng_> beuno & mwhudson: lp:loggerhead has been upgraded to rich-roots. Here's the final list of commands, if I copied them down correctly: http://paste.pocoo.org/show/117145/
<Peng_> ...I guess I should upgrade my local branches.
<Peng_> Wait, you upgrade stacked-on before stacked branches, right?
<beuno> the other way around  :)
<Peng_> Oh, oops. OK, easy to fix.
<beuno> hrm
<Peng_> Yep, uh, that went disastrously.
<beuno> branches still seem to work
<beuno> https://code.edge.launchpad.net/~mwhudson/loggerhead/which-mainline-merged
<Peng_> They're explicitly stacked on lp:~loggerhead-team/loggerhead/trunk, and hopefully that won't get changed.
<beuno> well, the UI is wronk then
<beuno> but yes
<beuno> \o/
<beuno> success!
<beuno> Peng_, you've solved a very complicated problem for Launchpad
<beuno> I will make sure you get a tshirt
<beuno> please email me your address  :)
<james_w> hey thumper
<mwhudson> yeah, unfortunately stacked on is done by url on launchpad, not branch identity
<Peng_> mwhudson: That's a good thing for us here.
<james_w> launchpad has foxed me
<thumper> hey james_w
<james_w> https://code.edge.launchpad.net/~ubuntu-branches/
 * thumper looks
<james_w> I'm pretty sure these are supposed to be stacked
<beuno> mwhudson, that's a good think  ;)
<james_w> but apparently they aren't
<Peng_> beuno: A t-shirt? For reals?
<james_w> they're not development-rich-root
<beuno> Peng_, absolutely!
<mwhudson> so the thing to do now is upgrade all the stacked-on branches, then do the trunk switcheroo ?
<thumper> james_w: lemmie check it out
<james_w> thumper: if you can confirm that they're not stacked then I'll check my code
<Peng_> Hmm, I'm not sure what users should do now. I guess they should upgrade to rich-roots then pull --remember lp:loggerhead again. That's a bit of a pain.
 * beuno sents Peng_'s instrucitons to the list
<thumper> james_w: I was just looking at the stacking code earlier
<Peng_> And, since I went to effort to avoid violently breaking their branches, they'll never know they need to do it...
<thumper> james_w: I think there needs to be a branch associated with the development version of the source package
<thumper> james_w: and then that is used to stack
<thumper> james_w: yes not stacked
<james_w> yeah, I've tried to ensure I push and link the development focus branch first
<Peng_> mwhudson: I guess so. You don't *need* to do a switcheroo, though; I'm not sure what would be best.
<james_w> ok, thanks
<thumper> james_w: the UI would say if it was
<thumper> james_w: if it isn't stacking it is a bug
<james_w> I fear that I have just done a naÃ¯ve push, when I should do a push that optionally stacks
<thumper> james_w: is your script using bzrlib? or shell to push?
<james_w> bzrlib
<thumper> james_w: it is possible then that you aren't pushing with the stacking policy
<james_w> yeah
<thumper> james_w: as the remote site (launchpad) suggests a stacking branch
<thumper> james_w: but it is up to the client to use it
<thumper> which it normally does
<mwhudson> Peng_: well, you need to change the stacked on branch 'as' you upgrade
<Peng_> mwhudson: Ooh, that sounds frightening.
<Peng_> Hum.
<mwhudson> https://code.edge.launchpad.net/~mwhudson/loggerhead/which-mainline-merged is now stacked on the right thing
<mwhudson> but i had to fix it with sftp
<Peng_> I'm nuking and repushing my one stacked branch, but it was already broken anyways.
<Peng_> That's unideal.
<mwhudson> yeah
<Peng_> mwhudson: The easiest solution is leaving old branches  with plain roots.
<mwhudson> yeah
<Peng_> Crap, the branch is still broken. Never mind about stacking it, then.
<mwhudson> but it would be good to have a non sucky way of upgrading your launchpad branch if you wanted to
<Peng_> Yeah, I didn't think of that. :\
<mwhudson> i guess there's a plugin in our collective future!
<james_w> it's pretty annoying that you have to reimplement the logic of push if you want to push a branch
<james_w> and means that your code can get out of date
<mwhudson> i guess you can do get_command('push').run(...)
<mwhudson> (or however that's spelt)
<beuno> ok, I'mm all set up to be rich and root
<Peng_> And this encouraged me to fix my broken stacky branch. :)
<beuno> win-win
<lifeless> moin
<lifeless> beuno: yes
<lifeless> beuno: -Dhpss triggers it
<lifeless> beuno: end users will only be using -Dhpss on request
<jelmer> lifeless: moin
<jelmer> lifeless: I would be careful with the dulwich git repo, it's generated by dulwich not by git itself
<beuno> lifeless, WFM. I like that you're putting the pressure on. How can I help?  filing bugs when I see VFS calls?
<Peng_> Of course, due to bug whatever-it-is, the web page for lp:loggerhead won't show the new format until someone pushes to it...
<jelmer> lifeless: the client that pushed it was bzr-git with dulwich I mean, not sure how much post-processing the server does
<lifeless> beuno: you'll usually see them on lp when lp isn't running $today
<jelmer> lifeless: actually, scrap that
<jelmer> lifeless: as the server would generate a new pack when you clone it
<lifeless> beuno: e.g. bug filing isn't very useful, you need to be running alpha server <-> nightly
<jelmer> lifeless: please ignore the last 7 lines from me ^
<lifeless> jelmer: :)
<lifeless> jelmer: you send a pack, the server keeps it and can do as it wishes :)
<beuno> lifeless, gotcha. I may be able to do that with my office server, but I don't use it much these days. Maybe I can do a few tests and file them based on that (server runs nightlies)
<lifeless> jelmer: did you think about another project I can test with
<lifeless> beuno: sure, its mainly for spiv and I to make 'X is slow' from a user easier to diagnose
<lifeless> beuno: e.g. jelmers 'pushing cross-format is slow' [which is caused by IDS]
<lifeless> beuno: I don't object to you filing bugs, but be prepared for most to be either dups, or wishlist (because we're not aiming at e.g. 'bzr log lp$FOO' to be VFS free in this cycle
<jelmer> lifeless: you could try with etckeeper and the bzr etckeeper clone on staging that michael made
<lifeless> mwhudson: where is this thing
<jelmer> lp:~vcs-imports/etckeeper/trunk IIRC
<jelmer> and git://git.kitenet.net/etckeeper
<beuno> lifeless, my feelings won't get hurt, just trying to see how I can help. Maybe ping you/spiv before filing?
<mwhudson> it's gone now i guess
<lifeless> beuno: sure
<lifeless> beuno: data is good
<jelmer> lifeless: just install bzr-git and clone that git URL (-:
<Peng_> Uh-oh, LP broke my mirrored branches, since they're still stacked on the non-rich-root loggerhead branch.
<jelmer> lifeless: or http://people.samba.org/bzr/jelmer//etckeeper/trunk
 * beuno hides
<lifeless> jelmer: is that cronn'd?
<mwhudson> Peng_: oh god
<jelmer> lifeless: no, it's only kept up to date as I need it
<Peng_> This may have been a bad plan. :D
<Peng_> Well, the only problem is you have to change the stacked-on location. Which is definitely a problem on LP...
<jelmer> lifeless: also, I think I found a bug in CHKMap..
<mwhudson> Peng_: well, it probably makes sense to make the dev focus the new branch
<mwhudson> but argh argh argh, no way to win
<Peng_> mwhudson: The dev focus is the new branch.
<mwhudson> Peng_: i think the next time your mirrored branches are updated, they will be stacked on the new branch tehn
<Peng_> mwhudson: They aren't.
<lifeless> jelmer: kinda needs the same DAG to be a vaguely fair test
<jelmer> lifeless: bzr-git keeps the dag
<mwhudson> Peng_: "Last mirrored:  	5 hours ago"
<lifeless> jelmer: yes, but your copy isn't kept up to date, or so you just said
<jelmer> lifeless: I'm not sure I follow what that has to do with the DAG
<jelmer> lifeless: or are you looking at setting up some system to do continuous performance comparisons?
<lifeless> jelmer: no, I'm just doing adhoc ones now
<Peng_> mwhudson: Some of them have been mirrored.
<lifeless> jelmer: but if http://people.samba.org/bzr/jelmer//etckeeper/trunk is days or weeks old
<mwhudson> Peng_: got an example?
<lifeless> then its rather unfair to git
 * mwhudson digs out the code
<jelmer> lifeless: I just pushed to it, so it should be current atm
<lifeless> jelmer: also is your copy in dev6, and has a smart server?
<Peng_> mwhudson: https://code.edge.launchpad.net/~mnordhoff/loggerhead/333797-debug-print
<jelmer> lifeless: no, neither
<lifeless> jelmer: :( I know the results already then ;)
<lifeless> jelmer: however, I'll push a dev6 version to lp to test with
<lifeless> so whats this bug
<jelmer> lifeless: patch is on the way
<mwhudson> Peng_: i think i'm going to take up crying as a hobby
 * lifeless consoles mwhudson 
<Peng_> mwhudson: Be sure to drink lots of fluids!
<Peng_> Sorry about this.
<beuno> Peng_, I've said it before, but you're a fantastic test suite
<mwhudson> Peng_: not you fault, we were going to hit this sooner or later
<lifeless> oh, did beuno upgrade to rich root?
<beuno> lifeless, Peng_ did!
<Peng_> :D
<lifeless> Peng_: :)
<james_w> Peng_, beuno: you rock
<jelmer> lifeless: Another good test project might be samba if you're interested in trying something larger
<jelmer> lifeless: I don't think there's a lot of projects that keep mirrors in bzr *and* git as part of their daily workflow though
<lifeless> jelmer: bzr mirror with same dag of same ?
<jelmer> lifeless: Yeah, just give me a few minutes to update the bzr mirror and push it
<james_w> beuno: though your instructions require renaming a project branch to a junk branch in the UI?
<lifeless> jelmer: also re: being careful of dulwich, seems to me that something hosted on e.g. gitorious is kindof required to keep the repo in good order for the users
<Peng_> james_w: It's to get around LP's default stacking policy.
<james_w> yeah
<lifeless> any benchmark that starts 'now run repack --max-window --max-delta' ...
<lifeless> ;)
<lifeless> is broken
<james_w> it's just the option to do that might be removed from the UI
<beuno> james_w, yeah, and jml may remove that, but may also provide an API
<jelmer> lifeless: Yeah, as I mentioned I don't think my comment earlier was valid
<james_w> beuno: oh good, you're aware of it
<jelmer> lifeless: If you were comparing local bzr and a local git repo created using dulwich it would be a different story
<Peng_> james_w: ...That'd be unfortunate, I guess.
<beuno> jml, ^^^^
<lifeless> jelmer: dulwich doesn't generate optimal packs you mean?
<jelmer> beuno: so what do I do now with my local loggerhead branches?
<beuno> jelmer, either upgrade it to 1.9-r-r, or re-branch
<beuno> you have a nice --recurse plugin for upgrade
<beuno> which I used  :)
<Peng_> jelmer: Plus, "bzr pull --remember lp:loggerhead" again; it's moved.
<jelmer> lifeless: It should but might not perform as well for some reason.
<jelmer> lifeless: I haven't verified that it generates packs as optimal as regular git. I know it generates valid packs though.
<jelmer> beuno: thanks
<jml> beuno: renaming a project branch to a junk branch?
<beuno> jml, yes, and visa-versa
<jml> beuno: yeah, so we'll add an API for that -- what's the use case?
<beuno> jml, read the bzr mailing list
<beuno> the "upgrade story"   :)
<jml> it's already sounding uncompelling :)
<beuno> jml, .
<beuno> jml, At the same time, and only because I know lp won't have been getting
<beuno> people to stack as there was only a 'mirrored' copy, it is migrating
<beuno> directly to --development-rich-roots.
<beuno> er
<beuno> fail
<beuno> http://paste.pocoo.org/show/117145/
<beuno> that's what I get for selecting textg when reading
<beuno> and linux clipboard stupidness
<jam> beuno: I replied to you message, btw
<jam> There is a bit of LP renaming trickery that you don't really need
<beuno> jam, I saw
<beuno> jam, part of the renaming
<beuno> is to keep merge proposals and bugs linkage
<jam> I suppose you might have to do something to avoid the recursive stacking problem
 * beuno hasn't replied because he wants to vreify first
<jam> beuno: oh, so you want bugs linked to .../trunk to now be linked to .../trunk-rich ?
<beuno> jam, yeap
<beuno> merge proposals, more importantly
<beuno> subscriptions, etc as well
<Peng_> jam: Pushing to +junk avoids the default stacking policy; that's the workaround I used.
 * Peng_ fires up an email client
<lifeless> Peng_: except renaming is about to be disabled ;)
<lifeless> jml: ^ :P
<jml> lifeless: yes.
<jml> it'd be nice if bzr had an option to ignore the default stacking policy
<lifeless> thumper: btw, lp:pqm was already 1.6 branch and repo; stackable.
<lifeless> thumper: its because trunk wasn't hosted.
<thumper> lifeless: that shouldn't matter
<lifeless> thumper: ok
<lifeless> thumper: mirrored branches don't have a private copy though
<thumper> lifeless: I know
<lifeless> thumper: so bzr+ssh can't stack locally
<thumper> lifeless: trust me on this, it is tested
<thumper> lifeless: we have custom transports
<lifeless> ok
<lifeless> question; how can I change https://code.edge.launchpad.net/%7Elifeless/pqm/trunk/+edit to be hosted
<thumper> you can't
<lifeless> I deleted the (optional) Branch URL
<jam> lifeless: delete it and push ?
<lifeless> jam: that deletes all the active merge proposals
<lifeless> and bug links
<jam> lifeless: shiny
<lifeless> the former is valuable, the latter would be nice but is less valuable
<lifeless> jam: in fact, I'm not even sure one can delete it with active merge proposals
<jam> So it sounds like it falls back to "you can't"
<lifeless> thumper: please advise
<jam> Since I don't think there is any way to promote a mirrored branch to a hosted branch without deleting it
 * lifeless tries just pushing anyway
<jam> lifeless: you could rename it out of the way
<jam> then everything ends up linked to the wrong thing
<jam> but at least they are still there
<lifeless> ah, readonly transport
<james_w> Stacked on:  	 lp:ubuntu/karmic/asio
<james_w> jml: I'm sorry I ever doubted you :-)
 * thumper on a call
<james_w> jml: https://code.edge.launchpad.net/~ubuntu-branches/ <- I'm going to kick of a big run tonight if that looks good to you
<Peng_> jam: BTW, I tried having a team +junk branch; it was rejected.
<jam> jml: ^^ what happened with that?
<jam> Only on the staging server?
<Peng_> That's entirely possible.
<james_w> team's aren't allowed junk branches are they?
<jml> they have been recently
<james_w> ah
<jam> Peng_, jml: http://code.mumak.net/2009/03/team-junk-branches.html
<jml> but our branch creation policy code is in a few too many places.
<Peng_> Well, I ran into that wall on the branch description page where I renamed it.
<jam> btw jml, I want my bubble domes
<Peng_> Bubble domes?
<jml> Peng_: yeah, that makes a *lot* of sense.
<jml> Peng_: the edit form had completely different set of logic.
<jam> Peng_: read ^^, but it refers to a Simpson's episode, and talks about "not all designs are good ones"
<jam> Such as "Separate Bubble Domes" on a vehicle
<lifeless> oh yes
<lifeless> it was hilarious episode
<Peng_> I see.
<Peng_> Not that there's anything wrong with it, but I've only seen a couple episodes of The Simpsons.
<Peng_> jml: The Wikipedia image link in that post is broken.
<mwhudson> Peng_: when did you upgrade your bzr.mattnordhoff.com branches?
<poolie> hello all
<poolie> jam, still around?
<Peng_> mwhudson: Um. 20:55 -- ~1h45m ago.
<Peng_> mwhudson: (Which is a few minutes after I upgraded lp:loggerhead.)
<mwhudson> Peng_: ok
<mwhudson> Peng_: this is really odd
<mwhudson> Peng_: some of your branches are ok
<mwhudson> e.g. https://code.edge.launchpad.net/~mnordhoff/loggerhead/new-style-classes
<Peng_> mwhudson: Huh. You're right, that is bizarre.
<Peng_> It looks like that branch was last mirrored right after I made the change.
 * Peng_ shrugs.
<Peng_> Maybe things'll work out in a few hours?
<Peng_> mwhudson: Maybe some of my branches got caught in between the upgrade and lp:loggerhead getting renamed or something.
<mwhudson> Peng_: yeah, that's my theory (hope!)
<Peng_> Heh, right.
<mwhudson> jelmer: please stop registering huge mirrored branches on launchpad for the moment
<gutworth> how can I change my working copy back to an old version?
<mwhudson> jelmer: it won't work and causes us problems
<mwhudson> jelmer: (i'll fix it soonish)
<mwhudson> gutworth: bzr revert -r -3
<gutworth> ah
<gutworth> I was messing around with checkout and switch
<mwhudson> checkout and switch are to do with the relationship of working tree and branch
<mwhudson> revert is a pure wt think
<mwhudson> *thing
<Peng_> mwhudson: One branch was remirrored just now, and it went correctly.
<mwhudson> Peng_: ah, that was the one i hit try again on
<mwhudson> Peng_: phew!
<Peng_> Oh, heh.
<mwhudson> i was really confused there
<Peng_> I guess you can give up the crying, then? :D
<mwhudson> somewhat
<Peng_> Mind if I hit retry on the rest of the branches?
<mwhudson> Peng_: go ahead
<Peng_> Oh, good, there were only 3 left.
<gutworth> is there a command line way to disable lazy import?
<jelmer> mwhudson: ok
<Peng_> gutworth: I don't know of one.
<mwhudson> jelmer: thanks
<mwhudson> gutworth: no
<jelmer> mwhudson: feel free to remove whatever mirrored branches are there now from me if you have some automated way of doing so
<Peng_> beuno: So, is the t-shirt thing still on? :D
<beuno> Peng_, of course!
<beuno> send me your address!
<jelmer> mwhudson: (I have a plugin that automatically registers stuff if I push it to samba.org, have disabled that now)
<mwhudson> jelmer: nah, they'll get disabled after a few tries
<mwhudson> jelmer: thanks
<mwhudson> jelmer: i'll let you know when it's safe again :)
<Peng_> beuno: Are they shipped from somewhere in the U.S.?
<beuno> Peng_, or the UK, not sure
#bzr 2009-05-14
<Peng_> Cool, I've never had anything destroyed by customs before. :D
<beuno> Peng_, I'll make sure to not send any live animals in it
<mwhudson> canonical t-shirts have successfully got past nz biosecurity
<mwhudson> which is probably about the strictest border control going
<jelmer> mwhudson: which one was problematic ? I don't recall having pushed anything large recently
<mwhudson> jelmer: not sure, perhaps i'm being over the top
<mwhudson> jelmer: the openoffice ones certainly did, but they're disabled now
<Peng_> What sizes are the t-shirts? Some strange, foreign measurement system that I've never heard of?
<jelmer> mwhudson: I think the second largest one I've pushed so far would be samba, which is ~50k
<Peng_> (Hey, I may not know anything about foreign countries, but at least I know they exist! :P )
<mwhudson> jelmer: hm, i'd hope that would work
<mwhudson> jelmer: ah, maybe not on prod actually
<beuno> Peng_, they're measured en em's
<Peng_> I wonder what my waist size is in ems?
<Peng_> ...I wonder what it is in inches or centimeters?
<beuno> Peng_, of course, I was kidding
<beuno> s/m/l/xl?
<servilio> hi! I have a working dir that I started from scratch and now I'd like make its history look like if it would have been started off from another branch
<beuno> Peng_, http://shop.canonical.com/product_info.php?products_id=399&osCsid=deb8dc669413edbef04a27d04685add7
<beuno> see size charts
<servilio> I've tried bzr-rebase, but only to have the other pulled and completely overwriting the new one
<servilio> any suggestions?
 * servilio notes that it is his first time using rebase, so it might easily be that he's used it wrongly
<Peng_> Cue Firefox freezing. Argh.
<Peng_> beuno: XL, I guess. Can you steal my address from my Canonical Store account?
<Peng_> (Actually, if you could, that'd probably be a huge privacy violation... :P )
<lifeless> Peng_: beuno can't. A sysadmin could; you should file a question asking them to give him the address :)
<lifeless> Peng_: or... you could just tell beuno
<Peng_> :D
<Peng_> Hmm, which of those is less typing? If the question was really terse...
<lifeless> yo, give bueno moi address
<Peng_> beuno: Normal lp:~beuno email address?
<Peng_> You can't see the sizing chart without logging in. :\
<beuno> Peng_, got it, thanks
<Peng_> beuno: ok :)
<igc> hi all
 * igc off to the dentist - bbl
<lifeless> jam: let me know when you pass the token
<lifeless> jam: ping
<jelmer> mwhudson: btw, is it right that the API doesn't support removing branches yet?
<jelmer> mwhudson: (I'm interested in cleaning up all those broken mirrored branches at some point)
<thumper> jelmer: yes, the api doesn't yet support removing branches
<thumper> jelmer: file a bug please :)
<thumper> jelmer: tag with "api", kthxbye
<thumper> poolie: I can hack if you need me to try something
<lifeless> jelmer: what are the urls for samba, both git an dbzr ?
<igc> back
<lifeless> jelmer: jeeeeelmer
<BasicOSX> This branch may be out of date, as Launchpad was not able to access it 21 minutes ago. (Not a branch: "http://bazaar-vcs.org/bzr/bzr.1.15/".) Launchpad will try again shortly.
<lifeless> BasicOSX: I don't think it has been created
<lifeless> BasicOSX: poolie asked in a company channel a couple of weeks back, I think noone actioned.
<BasicOSX> ok, I'll wait, just anxious to work on it
<lifeless> poolie: btw, when asking for a branch; if you don't get an ACK from a LOSA, the process is - file an RT
<poolie> i know
<poolie> i thought i did
<lifeless> BasicOSX: we'll look at getting 1.15 on lp natively; that will need losa support, and I've started the discussion now.
<poolie> it may be just a typo, hold on
<poolie> hello BasicOSX
<BasicOSX> hello poolie
<poolie> lifeless: could this just be the quirk that it doesn't push til the first commit?
<poolie> spm^^ does the pqm 1.15 branch exist?
<lifeless> poolie: the instructions for making a branch for pqm include a manual push
<lifeless> poolie: it has been made actually
<lifeless> poolie: but it will be very out of date
<poolie> i don't see it in http://bazaar-vcs.org/bzr/
<lifeless> yah
<lifeless> do you want it made this far ahead of the rc?
<poolie> 2 days? sure
<poolie> especially considering for spm there's only 1.5 working days until the rc
<poolie> even less depending on travel
<lifeless> spm: might like to update the docs, insofar as its make, setup config, and push once ;)
<spm> updating docs is good. doing.
<lifeless> spm: its a manual push as there isn't a default push location
<lifeless> e.g.
<lifeless> bzr info ../1.14
<lifeless> copy, paste, change 1.14->1.15, bzr push
<lifeless> (which I've just done)
<spm> ta
<lifeless> BasicOSX: its all there
<lifeless> we'll do native lp for 1.16/2.0
<BasicOSX> Should be able to get via lp or http?
<lifeless> lp will need to try again
<lifeless> http://bazaar-vcs.org/bzr/bzr.1.15 for now
<spm> lifeless: that push was to escu I assume. verifying.
<lifeless> spm: look in pqm's bash history
<lifeless> spm: it was litteraly
<lifeless> bzr info ../1.14
<lifeless> bzr push (copied and adjusted url)
<spm> awesome. perfect, ta.
<poolie> thanks spm
<thumper> lifeless: so is my bug a dupe? and being fixed?
<lifeless> thumper: have you donethe test ?
<thumper> lifeless: yes, and added comments to the bug
<thumper> lifeless: bug mail is delayed...
<thumper> lifeless: I thought it would have gone out by now
<thumper> :-|
<poolie1> thumper: which?
<thumper> poolie1: which what? which bug? bug 376287
<ubottu> Launchpad bug 376287 in bzr "branch fails with "bzr: ERROR: The branch ... has no revision None."" [High,New] https://launchpad.net/bugs/376287
<lifeless> bug 376255
<ubottu> Launchpad bug 376255 in bzr "smart server, new branch, ghosts, boom." [Critical,Confirmed] https://launchpad.net/bugs/376255
<lifeless> is what I think it may be a dup of
<lifeless> or at least very close
<thumper> lifeless: but the smart server isn't being used between two local directories is it?
<lifeless> thumper: same code path can be
<thumper> ok
<lifeless> jam: ping
<jam> hey lifeless, I just saw your earlier request.
<jam> I'm sorry to say I didn't get to presentations.
<jam> We had the power go out last night
<lifeless> ok
<jam> and I didn't have internet for half the day
<lifeless> I'll carry on then
<lifeless> jam: was just blocked until I got the token back
<jam> Please push them up somewhere and I'll be happy to focus on them tomorrow
<jam> And if you sent me an email... I didn't get it
<lifeless> jam: I did; its in mail to you from yesterday
<jam> problem with hosting your own...
<lifeless> I'll send another one when I finish up with them today
<jam> lifeless: yeah, no mail from 12am => 6am
<jam> and then down again 9:30 => 12
<lifeless> jam: it'll be queued somewhere. I sent to jam@c.c
<jam> lifeless: right, my queue hasn't all flushed yet
<lifeless> jam: anyhow, look for a mail from me tomorrow; as I'm grabbing the lock now :)
<jam> Yeah, the power going out was pretty flukish, but it really messed up the day
<jam> of course, it didn't help that when the internet went out it took them 1.5 hours to realize it was an site-wide effect
 * igc lunch
<bob2> does bzr use "pyftpdlib"?
<lifeless> we use the stdlib ftp client
<lifeless> and medusa as a test servere
<bob2> bugs.debian.org/528602
<lifeless> :!grep -n pyftp bzrlib/transport/ftp/* /dev/null 2>&1| tee /tmp/v308109/0
<lifeless>  
<lifeless> I'd query it
<jfroy> bah
<jfroy> bzr takes way
<jfroy> too much memory when adding large files
<jfroy> or rather when committing large files for the first time
<jfroy> Keeps biting me since I tend to work with large media files on a regular basis (1 GB + HD files)
<jfroy> :(
<lifeless> jfroy: :(
<jfroy> it's at 2 GB real ATM
<jfroy> >.>
<jfroy> is there any hope of addressing that in the future?
<lifeless> yes
<jfroy> or it is a design necessity and someone need to slap me for versioning large binary files?
<lifeless> but for a trivial answer, split and join your files yourself ;)
<jfroy> yeah well if I split those files they won't work anymore :p
<lifeless> 'and join' :)
<AfC> jfroy: you didn't ask if there was any hope of $whatever being addressed in the _near_ future...
<jfroy> thought: could use a fancy content filter to auto-split and auto-unsplit stuff
<lifeless> content filter api is probably not powerful enough
<lifeless> but yes, broadly; and patches to make such a thing would be good
<jfroy> :(
<jfroy> I wouldn't even know where to start looking :|
<lifeless> thumper: try lp:~lifeless/bzr/repo-source
<thumper> lifeless: do I need to build extensions?
<lifeless> no
<thumper> lifeless: just branch and try?
<lifeless> but you should
<thumper> how?
<lifeless> yah
<lifeless> make
<lifeless> you need python-dev and zlib1g-dev packages installed
<thumper> pyrex?
<lifeless> python-pyrex
<lifeless> bbs, caving in and having a pastry
<vila> hi all
<thumper> lifeless: branch that with 1.15dev I got AbsentContentFactory :(
<lifeless> branching from it ?
<thumper> lifeless: object has no attribute get_bytes_as
<thumper> yes
<thumper> well, cbranch, but yes
<lifeless> so pushing worked but the result is broken ?
<thumper> lifeless: I got the error getting your bzr branch from launchpad :(
<lifeless> thumper: very interesting
<lifeless> thumper: you have a broken bzr in production, is what that means
<thumper> lifeless: it is 1.14.1 + patches that you got mwhudson to do
<lifeless> yes
<thumper> so...
<thumper> now what?
<lifeless> clearly thats not quite enough
<thumper> clearly
<lifeless> it would be nice if my bundle was not deleted when I send to merge@...
<thumper> lifeless: it isn't
<lifeless> its not in the mail that gets sent out
<thumper> lifeless: it is in the librarian
<lifeless> well
<lifeless> branch bzr.dev
<thumper> all incoming email is stored
<lifeless> and pull from the bundle
<lifeless> and you'll have a working bzr to test with
<thumper> the email is stored, but not really accessible
<lifeless> so
<thumper> I'm updating my trunk
<lifeless> I mean 'people should get the bundle I send'
<lifeless> to be precise
<thumper> and I'll try again to see if it matters
<thumper> lifeless: interesting idea
<lifeless> with BB I would mail the list
<lifeless> and people get my original signed email
<lifeless> BB then send out additional data
<lifeless> I quite liked that
<lifeless> really fooding now
<lifeless> https://code.edge.launchpad.net/~lifeless/+junk/bbctest
<bob2> bbc = brisbane something core?
<bob2> hah, poor lp doesn't like that branch
<lifeless> yes
<lifeless> https://bugs.edge.launchpad.net/launchpad-code/+bug/376255
<ubottu> Ubuntu bug 376255 in bzr "CHK stream source doesn't handle ghosts." [Critical,Confirmed]
<lifeless> mwhudson: ^
<lifeless> poolie: can you review my patch for bug 376255
<ubottu> Launchpad bug 376255 in bzr "CHK stream source doesn't handle ghosts." [Critical,Confirmed] https://launchpad.net/bugs/376255
<lifeless> poolie: I'll send it in tonight if you do, if looks sane to you
<poolie> lifeless: i'll try
<poolie> lifeless: are you talking in barcelona?
<poolie> more than usual i mean :)
<lifeless> poolie: 3 times
<poolie> of course you are, you told me you're preparing them
<lifeless> poolie: I did:)
<lifeless> poolie: /wave, done for day modulo adhoc chats and submitting that branch if you ok it
<poolie> i'll looknow
<poolie> was talking to vila
<vila> bob2: BBC == BrisBane Core
<vila> bob2: BC was already taken
<poolie> i kind of wish you'd just spell it out
<poolie> having one name was meant to avoid confusion, not invite new names
<lifeless> poolie: when creating a test branch, abbreviations will be used, by nearly everyone
<lifeless> I do use brisbane-core for tags and other things ;)
<poolie> yeah, the branch name that provoked bob's question was not a good example
<lifeless> :)
<poolie> lifeless: review done, effectively a 'tweak'
<poolie> and i already filed last week the bug asking for a 'tweak' status
 * igc dinner
<poolie> hi igc
<poolie> night
<igc> hi poolie. first cut at smarter upgrades just pushed to lp btw
<igc> hope to clean-up & submit for review tonight or tomorrow
<igc> poolie: also, branch making commit FILE 4x faster on dev6-rr pushed for review last night
<poolie> nice one
<poolie> ones :)
 * igc ready heads for dinner now
<igc> really
<flo_hns> hello everyone. For one of my project, instead of having one branch for the whole thing, I split it into a branch per component, figuring that would be smarter.
<lifeless> igc: one thing that would be really useful would be a pack() after an upgrade to rr6
<flo_hns> I have by now concluded that it's not so smart after all, and would like to unify all those branches into one ? Are there tools/ways to do that, without losing the history ?
<flo_hns> So, to summarize, what I'm looking for is a way or tool, to go from many branches with no common ancestor to one branch, without losing the history. So kinda of a "repo merge" operation.
<flo_hns> anyone knows of such a thing ? :)
<bob2> branch, not repo
<flo_hns> bob2: well, I didn't want someone to tell to go for "bzr merge" :) so i figured branch might be confusing.
<lifeless> flo_hns: merge-into
<flo_hns> lifeless: ah awesome, looks like what I need. thanks!
<jelmer> lifeless: man, that pack is taking long
<vds> I have a problem trying to pqm-submit a branch on launchpad, after asking for the gpg passphrase bzr just hangs
<lifeless> jelmer: you're doing it local right ?
<lifeless> jelmer: do you have the C extensions build ?
<jelmer> lifeless: yes; no
<jelmer> lifeless: no python-dev on target machine
<jelmer> lifeless: done
<lifeless> jelmer: It would be nice to get it repacked with the C extensions
<lifeless> jelmer: I'm pulling a copy myself to test
<lifeless> jam: fetch from a non-optimal-packed bbc branch over VFS is _painful_. Something we might want to address before 2.0
<lifeless> jam: one readv per revision painful
<jam> lifeless: well, given that it is what, 2-40x larger?
<jam> lifeless: so I've written code to "batch up" groups
<jam> it is just the eternal question between
<jam> how much do you batch
<jam> and when do you issue the request
<lifeless> sure
<jam> by *not* batching, we avoid holding the whole repo in memory
<jelmer> lifeless: this branch is also on launchpad, but disabled I think because of size issues
<lifeless> we have reasonable asnwers though
<lifeless> e.g. 64KB
<jam> lifeless: actually, the batching was a large win for stuff like 'bzr ls' because it had to hit a lot of tiny groups
<lifeless> jelmer: yes, it was 1.5GB :P
<lifeless> jam: I must sleep, was just finishing off a little personal hacking when you happened by ;)
<lifeless> 23:40 here
<jam> sure
<jam> sleep well
<jelmer> g'night lifeless
<jam> lifeless: argh.... 'bzr push lp:...' AttributeError: 'AbsentContentFactory' object has no attribute 'get_bytes_as'
<lifeless> I sent you a couple of mails too, largely content free :P
<jelmer> when should I be using str.decode("utf-8") and when osutils.decode_utf8() ?
<jam> pushing up a non-stacked branch, as the project doesn't have any development focus yet
<lifeless> jam: it has ghosts
<lifeless> jam: updated your bzr
 * lifeless is gone
<jam> well, this is 4359
<jelmer> jam: ^
<lifeless> way to old you need 4362 or so
<jam> jelmer: my copy of osutils doesn't have decode_utf8
<jelmer> jam: sorry, I mean cache_utf8.decode
<jam> jelmer: I would generally use .decode('utf-8'). cache_utf8.decode will shove the unicode and str objects into dicts
<jam> so as to 'de-dupe' them later
<lifeless> jam: https://code.edge.launchpad.net/~lifeless/bzr/repo-source.
 * lifeless is gone
<LarstiQ> hah, the maintenance of http://bazaar-vcs.org/ is returning html when bzr looks for the bzrdir format on http://bazaar-vcs.org/bzr/bzr.dev
<jam> LarstiQ: yep, just ran into that myself
<jam> It seems bzr is about 3 revs old in Launchpad
<jam> Fortunately, I get to cheat
<jam> and I can connect directly to the host via bzr+ssh :)
<LarstiQ> tsk :)
<jam> that said, even with Robert's fix, 'bzr push' fails for this branch unless I do 'nosmart+'
<LarstiQ> is the most recent bzr.dev available via a smart protocol?
<LarstiQ> for the general public
<bialix> jam: hi
<jam> hey bialix
<jam> LarstiQ: no, I just have SSH access to that machine
<bialix> does merging through pqm still the same as year ago?
<jam> bialix: yep
<jam> I can submit if you prefer
<jam> I know there is also some maintenance going on, though I don't think it effects pqm right now
<bialix> jam: please do
<bialix> jam: I think your latest note should be tweak
<bialix> if you'll send merge request, can you tweak, please?
<jam> sure
<bialix> jone more question
<bialix> s/jone/one/
<Tak> bialix meant: one more question
<jam> well, it depended on whether we actually wanted to do the change or not, I left it open for you to decide
<bialix> jam: it was premature optimisation
<LarstiQ> Tak: are you a bot?
<LarstiQ> s/you/running/
<Tak> LarstiQ meant: Tak: are running a bot?
<bialix> nice
<bialix> Tak: teach me English please
<LarstiQ> s/s/&/
<LarstiQ> hmm, I hope that didn't cause an infinite loop
<bialix> jam: my patch for unicode cmdline: it will be in next bzr 1.16?
<jam> bialix: well, 1.15, yes
<bialix> ah, even so
<bialix> that's nice to have in rc1. more people will test it
<bialix> today we have a question in ru-bzr about diff headers and non-ascii filenames
<bialix> the problem is: diff headers encode filenames as utf-8
<bialix> this is very bad for windows console
<bialix> I remember we discussed it in the past
<bialix> there is no right choice here
<bialix> I'm thinking about adding special command-line option, e.g. --header-encoding, to force diff header show filenames in other encoding (oher than utf-8)
<bialix> jam: ^
<jam> bialix: so the code to fix that sort of thing is rather involved
<jam> It required changing 3-4 layers to pass around a 'path_encoding' parameter
<bialix> wdym?
<bialix> oops
<bialix> does it will affect merge directives?
<jam> The place where we would know the output encoding
<bialix> is it will be major API break?
<Tak> argh
<jam> then has to pass that down through about 4 layers to actually get that value set to the code that writes to the screen
<jam> Tak: ??
<Tak> sorry, I didn't mean for the regex script to be running in this channel
<jam> LarstiQ: what is s/s/&?
<jam> or is it just that you were regexing a regex?
<bialix> :-D
<jam> bialix: It isn't a "major" break, but a minor one, and tracking down all the cases was ugly enough I didn't continue to persue it a while ago
<LarstiQ> jam: s/prefix/& append/
<LarstiQ> jam: and indeed, the s was an attempt to regex the regex :)
<bialix> jam: and this change also affects log -p IIUC
<bialix> I'm not sure about merge directoves
<bialix> directives
<jam> bialix: if we had support to pass a value for path encoding
<jam> we can just make sure that merge directives pass utf-8 there
<bialix> one thing that bothers me is behavior of GNU diff (from gnuwin32.sf.net). It emits filenames in user_encoding
<jam> bialix: I'm pretty sure GNU diff emits everything in OEM encoding
<jam> so Unicode names aren't guaranteed to work
<bialix> jam: no
<jam> what do you get for: "diff Ð¢ÐµÑÑ Ø¬ÙØ¬Ù" ?
<jam> My very strong guess is that 'GNU diff' thinks of filenames as pure 8-bit octets
<jam> and if OEM encoding can't handle a given Unicode filename
<jam> it just fails
<jam> since it can't *read* the file
<jam> (on my platform, both of those would show up as ???? ????, and I don't have a filename named ????)
<jam> I could certainly be wrong
<bialix> jam: I've got nothing
<bialix> I'll try to create Arabic filename first
<jam> bialix: Explorer should handle it fine
<bialix> C:\Temp\2>diff -u Ð¢ÐµÑÑ Ø¬ÙØ¬Ù.txt
<bialix> diff: ????.txt: Invalid argument
<jam> bialix: yep
<bialix> GNU diff does not handle pure unicode
<jam> bialix: right, so if you don't deal with unicode ,then you just write the 8-bit string that you read, back onto the wire
<jam> which is generally OEM encoding
<jam> IIRC
<jam> it doesn't specifically matter what it is
<bialix> but
<bialix> C:\Temp\2>diff -u Ð¢ÐµÑÑ Ð¢ÐµÑÑ2
<bialix> --- Ð¢ÐµÑÑ        2009-05-14 18:44:25.953125000 +0300
<bialix> +++ Ð¢ÐµÑÑ2       2009-05-14 18:44:38.734375000 +0300
<bialix> @@ -1 +1 @@
<bialix> -foo
<bialix> +bar
<bialix> filenames in cp1251
<jam> bialix: Is this on Russian windows?
<bialix> no
<bialix> it's on English netbook
<Tak> LarstiQ: it disallows that :-P
<bialix> but with Russian settings
<jam> bialix: http://www.eggheadcafe.com/conversation.aspx?messageid=33050149&threadid=33050144
<jam>  If an application is compiled for ANSI API, then the filenames will be recoded to/from current codepage.
<jam> Which means, try doing "chcp 437"
<jam> and see if 'diff' continues to work
<bialix> yes, it works
<bialix> C:\Temp\2>diff -u Ð¢ÐµÑÑ Ð¢ÐµÑÑ2
<bialix> --- â¥ÏÂ±â¥        2009-05-14 18:44:25.953125000 +0300
<bialix> +++ â¥ÏÂ±â¥2       2009-05-14 18:44:38.734375000 +0300
<bialix> @@ -1 +1 @@
<bialix> -foo
<bialix> +bar
<bialix> but filenames still in cp1251 as you could see
<jam> bialix: well, I see them as horribly horribly broken
<jam> at least in your paste
<bialix> them? GNU diff?
<jam> bialix: in the paste you just generated, I get very bad characters shown
<jam> --- [] [sigma] [+/-] [>=]
<bialix> C:\Temp\2>chcp 866
<jam> bialix: and when I do "diff Ð¢ÐµÑÑ.txt Ð¢ÐµÑÑ.txt"
<bialix> Active code page: 866
<jam> I get:
<bialix> C:\Temp\2>diff -u Ð¢ÐµÑÑ Ð¢ÐµÑÑ2
<bialix> --- â¥ÑÑÐ        2009-05-14 18:44:25.953125000 +0300
<bialix> +++ â¥ÑÑÐ2       2009-05-14 18:44:38.734375000 +0300
<bialix> @@ -1 +1 @@
<bialix> -foo
<jam> diff: ????.txt: No such file or directory
<jam> diff: ????.txt: No such file or directory
<bialix> +bar
<bialix> I've created my files first
<bialix> C:\Temp\2>diff --version
<bialix> diff (GNU diffutils) 2.8.7
<bialix> Written by Paul Eggert, Mike Haertel, David Hayes,
<bialix> Richard Stallman, and Len Tower.
<bialix> Copyright (C) 2004 Free Software Foundation, Inc.
<bialix> This is free software; see the source for copying conditions.  There is NO
<bialix> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE
<jam> bialix: i created them as well
<bialix> jam: as I could see diff emits simply characters in cp1251 encoding
<jam> bialix: not according to your paste
<bialix> regardless of real console encoding
<jam> it emits them as 8-bit filenames
<jam> which then get interpreted by the consoles' code page
<jam> now, I'm not sure how these are stored *on disk* exactl
<jam> but the fact that Arabic didn't work hints that more might be going on
<jam> bialix: anyway, what *I* would do in bzr, is to take the Unicode name, and try to encode it into the sys.stdout.encoding (with replace=True). And if sys.stdout is a file, then do something like always utf-8
<bialix> bear in mind recent patch for unicode cmdline it seems GNU diff using filenames "as is" without encoding them to unicode
<jam> I think technically it is supposed to be locale.getpreferredencoding at that point
<bialix> bbiab
<jam> jelmer: I'm not sure what you are doing, but I see: Thu May 14 16:38:46 2009 UTC: Jelmer Vernooij <jelmer@samba.org>, Request for non-PQM managed branch.
<jam> on http://pqm.bazaar-vcs.org/
<jam> I'm guessing you have your submit branch set up incorrectly
<jelmer> jam: oh
<jelmer> jam: pqm-submit was spitting out HTML so I send in a merge request manually
<jelmer> jam: still is, btw - is anything up with it?
<jam> jelmer: bazaar-vcs.org is undergoing maintenance
<jam> and yielding HTML when you try to read .bzr/branch/format
<jam> (It yields the main page, IIRC)
<jam> Though I thought 'pqm-submit' only checked that your public branch was valid
<jam> so I don't have any idea why it would be checking bazaar-vcs.org
<jelmer> jam: it asks the submit branch for its public location apparently
<jam> jelmer: right, so that you can have a local mirror, and not have to hit the remote location
<jam> to determine what revisions to send
<jam> well, that is why we have it for 'bzr send', and the 'merge target' gets reused for pqm-submit
<Kissaki> using bzr on windows. On "bzr ignore <file>" a versioned file, it will warn me that it's versioned. On "bzr status" it will still list it as modified (as before) and worse, the ignored .bzrignore file is displayed as well. "bzr revert .bzrignore" will even tell me "removed" but the file itself is still on the hdd.
<Kissaki> maybe I should submit a bug ticket
<Kissaki> ...
<jam> Kissaki: after 'bzr revert .bzrignore' Isn't the file renamed to .bzrignore.~1~ ?
<jam> The property of being "versioned" supersedes the property of being ignored
<Kissaki> no
<jam> so if you want to remove and ignore you need to do that
<Kissaki> so there's no way to ignore a versioned file?
<Kissaki> but still, it's broken
<jam> Kissaki: "bzr ignore X; bzr rm X
<jam> Kissaki: I just checked, we never delete newly added files via revert
<Kissaki> it won't fetch it then again?
<jam> so if you do:
<jam> bzr add somefile
<jam> bzr revert
<Kissaki> ah ok
<jam> It will leave 'somefile' alone
<jam> you may want "bzr rm --keep X"
<jam> depending on whether you want the file actually deleted from disk, or not
<Kissaki> thx
<Kissaki> wtf, now after adding another, unversioned file it's displayed as added again, the .bzrignore
<KX> Does anyone use bzr with redmine?
<jam> Kissaki: we generally version .bzrignore, so that your ignore list gets transmitted
<jam> I belivee 'bzr ignore X' automatically creates it and versions it.
<Kissaki> but it did seem to work before... Maybe I did delete it from repo, but it was kept on hdd...
<Kissaki> so I thought it would work without commiting it
<Kissaki> but if I specifically ignore .bzrignore, shouldn't it be ignored then?
<Kissaki> after all, if I want it versioned, I won't ignore it
<Youssef> Hello guys!
<Youssef> i just have a question
<Youssef> I would like to know what's the difference between "Create a checkout" and "Make a local copy of the branch" please
<Youssef> in the tortoisebzr gui
<KX> well
<KX> since the site is down and I can't access the docs, would someone mind helping me set up my ssh key on windows?
<KX> I used puttygen.exe on my pc, saved id_rsa and id_rsa.pub in Docs & Settings/Me/.ssh and then on the server in ~/.ssh I made authorized_keys with my public key all on one line and the "run bzr in cmd shell" still asks me for an SSH password when I do e.g. bzr update
<jam> Kissaki: you could try doing echo "./.bzrignore" > .bzrignore
<jam> but doing "bzr ignore .bzrignore" wouldn't do what you want, as it would then add the file
<jam> KX: I would usually use pageant, if you have putty
<jam> Start/Programs/Putty/Pageant
<KX> I have it, just not sure hwat to do
<jam> adds an icon to your systray
<jam> then right click on the icon, Add Key
<KX> I've efound out that apparently putty uses a different format to openssh
<jam> KX: just for the key file format
<KX> so I'm going to try doing export as openssh key real quick
<jam> but the Public/Private key stuff is the same
<jam> If you use Pageant, then you *want* putty's format
<KX> mmm, well is it not possible without pageant?
<jam> It *is* possible, but I still think pageant is *easier*
<KX> I guess I'll do it that way if it works
<KX> Ok I've opened it
<jam> So there should be an icon of a computer with a hat in your systray
<KX> so I save the private key as id_rsa.ppk in .ssh and then click on the icon anadd key and locate that file
<jam> yep
<KX> ok
<jam> If pageant is running, and your key has been added, then we can access it without promptingyou
<jam> though you still need to get the public key line from puttygen so that you can upload your key to the remote machine
<KX> oh, so that's it? I'll try it now then
<KX> I've already done that
<KX> authentication publickey failed
<KX> it should be called id_rsa.pub in .ssh right?
<jam> KX: so the key format from puttygen doesn't match 'id_rsa.pub' format.
<jam> however, if you added the key to pageant, we don't care what files are around
<jam> we talk to pageant *first* (and then look for files)
<KX> well the format looks like
<jam> so if you are getting failed
<jam> that means there is a problem elsewhere
<KX> ---- BEGIN SSH2 PUBLIC KEY ----
<jam> can you paste the connection output?
<KX> and an END block, with data in between
<KX> Well all it says after I run bzr update is
<jam> It is possible you are running openssh which doesn't know how to connect to pageant, versus using paramiko internally
<jam> try:
<jam> set BZR_SSH=paramiko
<jam> bzr update
<KX> Connection (version 2.0, OpenSSH_4.3)
<KX> Authentication (publickey) failed.
<KX> SSH password:
<jam> well, if it is printing out "Connection (version...)" then it is using paramiko
<KX> but it says openssh there :s
<jam> so I'm guessing you don't have the public key uploaded to the other side correctly.
<jam> KX: That is the *remote*
<vxnick> can anyone tell me how I can ignore all subdirectories except a certain one? I've tried expanding on the one provided by 'bzr help ignore', but I get "event not found" when trying "RE:(?!modules/babble/).*"
<jam> openssh locally doesn't print a Connection line :)
<jam> vxnick: "bzr ignore *; bzr add subdir"
<jam> the add will supersede the ignore
<KX> on the remote, it is in ~/.ssh/authorized_keys and it looks like ssh-rsa SPACE lots of junk ending with == SPACE rsa-key-.....
<jam> or you could do
<jam> bzr ignore ./*
<vxnick> jam: thanks :)
<jam> to just ignore top-level dirs automatically
<KX> anything wrong with that?
<jam> KX: well, that *sounds* correct. Of course, you have to check things like
<jam> perms on ~/.ssh
<jam> and ~/.ssh/authorized_keys
<KX> what should they be?
<jam> IIRC if they arent 700 and 600 then openssh refuses to connect
<jam> let me check here
<KX> thanks
<jam> KX: chmod 0700 .ssh; chmod 0644 .ssh/authorized_keys
<jam> is what I have
<jam> If you have 'root' access on the remote machine, I think it gives warnings about this in /var/log/secure
<KX> I can access /var/log but not secure
<KX> I'll try now I changed the file modes
<jam> you might check /var/log/messages, but yeah, usually only root can read the logs
<jam> just in case
<KX> thank you very much
<vxnick> jam: ignore * then bzr add sub/dir didn't exactly work, as it re-added the parent 'modules' directory in order to add modules/babble
<KX> jam it works lovely now, thanks I've been trying to do this for 2 days ... who'd have thought it was file permissions ...
<jam> vxnick: that is required
<jam> if you did "bzr init ."
<jam> you can't just add "foo/bar" without adding "foo/"
<jam> if you prefer, you could
<jam> cd foo
<jam> bzr init
<jam> or cd foo/bar; bzr init
<vxnick> well this is a checkout you see
<KX> vxnick, what are you trying to do with our dirs? :P
<vxnick> it's not a problem, just wanted to let you know
<davidstrauss> What's up with the bzr site?
<LarstiQ> davidstrauss: hrmph, this is silly now
<davidstrauss> LarstiQ: ?
<LarstiQ> jam: can you/should I raise the topic of bazaar-vcs.org
<LarstiQ> davidstrauss: this is no longer 'shortly'
<davidstrauss> LarstiQ: please explain
 * LarstiQ counters with a question
<LarstiQ> davidstrauss: when you said "what's up with the bzr site", what did you have in mind?
<LarstiQ> maybe we're talking about different things
<davidstrauss> LarstiQ: When will the wiki be back online
<LarstiQ> davidstrauss: right. I don't know. I'm surprised it isn't back already.
 * beuno asks
<LarstiQ> beuno: if it really still needs to be down, could they at least make `bzr pull http://bazaar-vcs.org/bzr/bzr.dev` not bork on bzrdir format query getting html back?
<beuno> LarstiQ, asking  :)
<LarstiQ> beuno: kiitos :)
<jam> LarstiQ: I already asked in canonical #is, it seems that moin upgrade was having real problems
<jam> beuno: argy was the one working on it
<jam> well, that was ~3 hours ago
<LarstiQ> oops
<LarstiQ> is this my fault? :)
<jam> LarstiQ: no
 * LarstiQ asked for a moin upgrade
<jam> LarstiQ: AFAIK they upgraded the machine to Hardy, which "comes with" an upgrade to moin
<jam> Apparently moin upgrades aren't very perfect ...
<LarstiQ> jam: ah ok
<jam> beuno: sorry, 'agy' not 'argy'
<beuno> jam, yeah, guessed it  :)
<beuno> nobody's answering though
<jam> well, given London time, it is ~ 8pm there
<jam> it is possible he stopped, though it would be nice to have *something* before he leaves
<jam> I guess we have the Maintenance warning, rather than utter failure
<jam> (in the morning it was ConnectionError)
<LarstiQ> ah
<luke-jr__> jelmer: btw, the svn+http syntax is basically required for password-locked repositories it seems
<jelmer> luke-jr__: That's caused by bzr sending a POST request to see if there's a bzr smart server running
<jelmer> luke-jr__: that triggers a "auth required" error on a lot of servers
<luke-jr__> no doubt
<luke-jr__> the "svn+ is obsolete" message just gets annoying while it's still required
<jelmer> luke-jr__: that's no longer printed in newer bzr-svn's
<luke-jr__> i c
<fbond> bzr missing shows I have an extra revision and so does my parent, but `bzr rebase` does nothing.  Any good reason for this?
<fbond> bzr rebase says "Rebasing on file:///...", but then nothing happens.
<LarstiQ> fbond: rebasing on a different branch than missing checked?
<LarstiQ> are you sure you want to rebase btw?
<fbond> LarstiQ: Yes, I'm sure, and yes, both are going to the parent implicitly.
<fbond> Or at least, both are claiming to go to the same branch (the parent).
<LarstiQ> fbond: if they print out the same branch url, then yes.
<LarstiQ> fbond: oh, wait.
<LarstiQ> fbond: if you have one extra, and no missing, there is nothing to do for rebase.
<LarstiQ> fbond: by definition the rebase result is the same as prior to the rebase.
<fbond> LarstiQ: I have one extra, and the parent has one extra, too.
<fbond> bzr missing lists a total of two revisions, one on my side, one on the parent's side.
<LarstiQ> fbond: ok.
<LarstiQ> in that case, no idea.
<LarstiQ> fbond: anything in ~/.bzr.log?
<fbond> Only what I would expect; no trace backs or anything.
<jelmer> fbond: rebase rebases on the push location by default, not on the parent location
<LarstiQ> jelmer: fbond mentioned the branch urls are both the parent
<fbond> jelmer: bzr help rebase says it uses the parent...
<jam> fbond: I'm pretty sure you want 'replay' but I'm not positive
<jelmer> fbond: Sorry, never mind me. It is the parent actually.
<fbond> jelmer: No problem.
<fbond> Anyway, rebase has certainly worked for me in the past.
<LarstiQ> fbond: I would indeed expect something to happen.
<LarstiQ> fbond: does -r help?
<jam> LarstiQ: bazaar-vcs.org seems to be working...
<fbond> Yeah, I think it's a bug...
<fbond> LarstiQ: I'll try using -r.
<LarstiQ> jam: yay!
<LarstiQ> jam: thanks to whomever fixed it.
<LarstiQ> davidstrauss: ^^
<fbond> LarstiQ: Ouch, weird.
<davidstrauss> LarstiQ: cool
<beuno> LarstiQ, server should be up again
<LarstiQ> beuno: pull worked, thanks
<fbond> LarstiQ: bzr rebase -r XXX caused *my* XXX to be replaced by *parent's* XXX.
<jelmer> fbond: any merge revisions involved?
<fbond> (and my XXX has disappeared)
<fbond> No big deal, this was a merge from another branch, anyway.
<fbond> But that was not expected.
<jelmer> fbond: rebase ignores merges, there's an open bug about that
<fbond> jelmer: Ignores merges?
<fbond> There was content from this merge, FWIW.
<fbond> jelmer: Do you have a bug #?
<jelmer> fbond: it's the highest listed one in the bzr-rebase bugs page iirc
<fbond> jelmer: Looks about right.
<jam> fbond: cd trunk; bzr merge ../my branch; bzr revert --forget-merges
<jam> should be ~equivalent to 'bzr rebase'
<jam> Note that you'll lose the merge parent of 'my branch'
<jam> you could get it back if you want to be extra creative
<fbond> jam: Thanks; it's easy enough to recreate the merge revision.
<fbond> I was just surprised to see rebase fail.
<jam> LarstiQ: well, it looks like the new Moin engine changed {{{ verbatim }}} display a bit
<jam> If you have a multi-line verbatim
<jam> you have to start it with an empty line
<jam> or it doesn't think it is verbatim
<jam> see the change to http://bazaar-vcs.org/Roadmap/BrisbaneCore/Details
<jam> just in case we run into that elsewhere, I want someone else to know about it :)
 * LarstiQ looks at Download
<LarstiQ> jam: ah, I see
<LarstiQ> it seems the wiki comments do work now
<jam> comments?
<jam>  ### lines ?
<LarstiQ> {{{#! wiki comment
<LarstiQ> or /* */
<jam> ah, k
<jelmer> jam: I'm now getting 1.35s to extract all bzr.dev revs using the XML serializer
<jelmer> jam: and 0.91 with the RIO one
<LarstiQ> jam: which I had attempted for the list of older releases on /Download
<jam> LarstiQ: so {{{#! => <!- ?
<jam> or whatever the HTML comments were
<LarstiQ> jam: no, a <div> which is not visible by default, but you can toggle comments to be visible
<jam> ah, interesting
<jam> I guess that makes it logical for the download stuff
<jam> since a screen-scraper will always see the div
<jam> and probably won't apply the CSS
<LarstiQ> jam: exactly, I gleaned the idea from the TurboGears (pypi listed) download location, which easy_install knew how to handle
<dirkD> is it possible to let bzr not ignore *.so files?
<dirkD> (without using bzr add .......................so al the time)
<jelmer> dirkD: remove the *.so pattern from the .bzrignore file
<dirkD> jelmer: it's not there
<dirkD> it seems like bzr ignores *.so by default
<jelmer> dirkD: perhaps ~/.bazaar/ignore ?
<dirkD> yes, there it is
<dirkD> is it possible to make an exception for that (in the tree)?
<dirkD> otherwise every developer has to change his ~/.baazaar/ignore file
<jelmer> I think I've seen something like that, I'm not sure how exceptions work though
<beuno> lifeless, VFS calls have gone away on a few operations when interacting with Launchpad. Did LP get upgraeded os is the client getting smarter?
<vxnick> hi guys - is there a way that I can bzr ignore ONLY the root index.php file, and not the same in sub-dirs?
<dirkD> vxnick: bzr ignore ./index.php i think
<dirkD> (i'm not sure)
<vxnick> thanks dirkD I'll give it a go
<vxnick> that looks like it worked, thanks :)
<dirkD> np vxnick
<lifeless> beuno: neither
<lifeless> beuno: you're not using enough bits in your mask for determining'same operation'
<beuno> lifeless, uhm...  what?
<lifeless> beuno: push with the same format is vfs free except on new branches
<lifeless> same for pull
<lifeless> differing formats will trigger vfs
<lifeless> new branches will trigger vfs
<lifeless> moin
<lifeless> btw
<beuno> mornin  :)
<jelmer> ah, moin is working again \o/
<jam> dirkD: If you 'bzr add foo.so' it will always be versioned
<jam> There isn't a way to specify you want to 'undo' an ignore otherwise
<dirkD> yes, but then i have to ass 130 .so files manually
<jam> so people creating new .so files won't see them
<dirkD> s/ass/add
<jam> dirkD: find . -name *.so -print0 | xargs bzr add
<jam> dirkD: find . -name *.so -print0 | xargs -0 bzr add
<jam> takes... 2s ?
<lifeless> bzr ls --ignored | xargs bzr add
<dirkD> that's an option, but it has to be used by some people who will forget this
<beuno> lifeless, btw, bling: https://code.edge.launchpad.net/bzr
<beuno> (I know you like bling)
<dirkD> jam: giving them a new ~/.bazaa/ignore is more easy then
<lifeless> beuno: the graph?
<lifeless> beuno: is the word 'ago' meant to be below the ..... line ?
<beuno> lifeless, it's suppose to be on the same line
<lifeless> beuno: its on the same row as lp:bzr/1.15
<beuno> lifeless, ah. shouldn't be. Got a screenshot handy?
<lifeless> beuno: unmaximaise your browser
<lifeless> :)
<lifeless> mines about 800px wide
<beuno> lifeless, borwser size doesn't break it
<beuno> font size does, though
<beuno> but I have to increase it 4 times
<jam> hey lifeless
<lifeless> also, perhaps it would read better as "124 commits in 90 days. Last 3 hours ago."
<lifeless> cause I don't know what 'max' means
<beuno> right
<beuno> that's the problem
<lifeless> beuno: I'm using epiphany
<beuno> 124 is the max number of commits per day
<jam> lifeless: do you have a min-font size set?
<beuno> in 90 days
<beuno> not super-clear
<lifeless> jam: no
<lifeless> I have my DPI set accurately
<lifeless> and 10 point document font in font-appearances
<lifeless> beuno: peak daily
 * beuno tries epiphany
<lifeless> beuno: 90 day activity, 124/day peak, last 3 hours ago
<lifeless> 90 day view, peaked at 124/day, idle for 3 hours
<lifeless> hi jam
<beuno> lifeless, thanks for the feedback, will look into it
<beuno> lifeless, right, in epiphany it does wrap
<beuno> I'll look into that as well
<lifeless> beuno: its cute; its likely also broken :)
<lifeless> beuno: I bet that 124 is 'a big merge'
<beuno> lifeless, yes, i
<beuno> it's not mainline commits
<beuno> I decided that explicitely
<lifeless> I think it will be confusing if that graph doesn't line up with bzr log
<beuno> why wouldn't it?
<beuno> because of it not showing merges now?
<lifeless> bzr log by default now only shows mainline commits
<lifeless> I'm not advocating either position btw
<lifeless> I'm just advocating keeping the theme the same across the platform
<lifeless> lp's branch view only shows mainline commits
<beuno> yeah, it's a tough choice
<beuno> because merges, in many ways, show more work
<lifeless> I don't think its that tough ;) confuse users? [Yes] [no]
<lifeless> oh yes; FWIW I argued for keeping log showing all commits not just mainline
<lifeless> which would be consistent with the bling
<beuno> if only performance hadn't been so bad, I would of agreed  :)
<lifeless> beuno: we have to revisit revnos; either to get better code to assign or to change it to one we can write fast code for
<jam> lifeless: for the groupcompress talk, should I start with the graphs (to give "wow" factor) or should it come after discussion of the design?
<jam> It feels like I'm starting "wow" and then just sort of talking without ending with a bang
<jam> lifeless: we also need to consider the merge-sorted indenting
<jam> *just* revnos isn't enough
<jam> you can approximately do what we have with set-difference operations, and a smart difference that doesn't walk the whole ancestry
<lifeless> jam: yes; well revnos were enough in the first round of dotted revnos, I think. anyway, its moot- until someone has it as top of pile
<lifeless> but I do feel we should decide sooner rather than later the plan so users don't get flummoxed again, later.
<lifeless> jam: the gc talk, IIRC was a big gc and a bit chk
<lifeless> so we could do two separate sets of graphs
<jam> lifeless: so far the GC talk has no chk
<lifeless> or we could use some summary numbers, and then graphs at the end
<jam> new compression backend 'group-compress'. John and I present the internals of this exciting compressor, its genesis, design and performance details.
<lifeless> oh right
<lifeless> no chk for us
<lifeless> we can obviously cheat
<lifeless> anyhow
<jam> well, I can move the "text extraction" performance slides to the end
<lifeless> I think waking the audienc eup is good
<jam> and leave the "compressed size" to the front
<lifeless> we could even spread them around
<lifeless> bzr vs git at the front
<lifeless> wow we sucked
<lifeless> <details>
<lifeless> bzr v git now
<lifeless> [I know that more than gc is in there, but we could compare just compressors]
<lifeless> or perhaps hg would be more entertaining
<lifeless> btw we're still slightly larger than git for samba
<lifeless> not sure why
<jam> lifeless: we are larger than git for launchpad, too
<jam> 95 => 105 or so
<jam> w/ lzma we are ~=
<lifeless> that overall or .pacj
<jam> lifeless: du -ksh .bzr .git
<jam> so including indices
<lifeless> I haven't got an overall for samba yet
<lifeless> hmm, still need to make finding revisions faster
<lifeless> we need 'empty' to come back from the smart server
<jam> lifeless: so for 'time get_record_stream(all_texts)' I get a peak of about 330MiB/s if I do 1 pass, and 570MiB/s if I put it under timeit
<jam> thoughts?
<luke-jr__> git has about 3 minor things better than bzr
<lifeless> jam: you mean for record in stream:record.get_bytes_as() ?
<luke-jr__> IMO
<jam> ah, gc.disable => 461MB/s
<jam> lifeless: right
<jelmer> luke-jr__: well, what are they ? :-)
<luke-jr__> jelmer: it tracks copies, to some small degree
<jam> I'm just trying to present things 'faithfully' though I know that 'peak' is almost 2x more than 'standard'
<lifeless> jelmer: I recompressed samba, a 169MB pack
<jam> lifeless: down from 1.5GiB?
<lifeless> jam: yes
<lifeless> jam: actually, 1.7 or so
<luke-jr__> jelmer: I kinda like the "git add everything to commit" thing
<luke-jr__> and cherry picking
<jelmer> luke-jr__: Git doesn't track copies any more than bzr does, but the UI can infer where a copy was done
<luke-jr__> jelmer: the UI is part of git
<jam> lifeless: could be the de-duping
<jam> (for lp in git)
<jelmer> luke-jr__: yeah, but tracking implies it's stored somewhere
<lifeless> jam: of same sha files?
<jam> IIRC, we have about 50% dupe texts, 70% of which are the empty text
<jam> lifeless: right
<luke-jr__> jelmer: what git does is slightly better than bzr
<lifeless> jam: would be good to make the file graph really separate
<jam> lifeless: yep
<jelmer> luke-jr__: I'm not disagreeing there :-)
<luke-jr__> jelmer: I still think bzr needs to add copy support ;)
<jelmer> luke-jr__: What do you mean with "git add everything to commit" exactly ?
<lifeless> jelmer: the index
<luke-jr__> jelmer: git doesn't commit changes unless you add them explicitly
<jelmer> luke-jr__: It's planned, but not one of the highest priority features
<jelmer> luke-jr__: ah, ok
<luke-jr__> just because fileA changes doesn't mean you want to commit t
<luke-jr__> it*
<jelmer> luke-jr__: What's better about git's cherrypicking?
<luke-jr__> jelmer: it works?
<lifeless> jelmer: it has a one-shot command
<luke-jr__> bzr's cherrypicking is just a diff patch
<jelmer> luke-jr__: gits is a diff patch too
<lifeless> luke-jr__: so is gits
<luke-jr__> really? :/
<lifeless> really
<luke-jr__> it doesn't update the tree?;
<lifeless> they record the revid it came from
<lifeless> thats all
<jelmer> luke-jr__: it adds to the commit message a note saying what was cherrypicked
<luke-jr__> and copy that revid and its dependencies into the repo?
<lifeless> no
<luke-jr__> :/
<luke-jr__> ok, 2 things then :p
<luke-jr__> oh
<luke-jr__> git does appear to be OK with cross-merges
<luke-jr__> merge A into B, then B into A, etc
<jam> lifeless: token is yours, push just finished
<lifeless> thanks
<jelmer> luke-jr__: bzr handles that too, although you have to specify --lca to merge to get it to deal with them properly
<lifeless> where are we up to
<jelmer> lifeless: it'll actually tell you if it sees a cross merge
<jelmer> s/lifeless/luke-jr__/
<luke-jr__> jelmer: does --lca actually work reliably?
<luke-jr__> --weave sure doesn't
<bob2> is --lca going to become the default sometime?
<jelmer> luke-jr__: I've never had trouble with --lca
<jelmer> I think we scared Aaron by talking about merge algorithms
<luke-jr__> jelmer: inferred renames would be a nice thing too
<jelmer> luke-jr__: see "bzr rename --auto"
<jelmer> or at least I think that was what the name was
<luke-jr__> ah
<luke-jr__> ok, so really just 2 :)
<luke-jr__> 1. explicit adding to commits (very minor, especially since I can uncommit after making a mistake)
<luke-jr__> 2. copying
<luke-jr__> IMO, there needs to be 3 new kind of copying
<luke-jr__> 1. template (changes in original need to be merged into the copy; not sure how this would apply correctly outside of merges)
<luke-jr__> 2. history-only (new file, but retaining history of original file at time of copy)
<luke-jr__> 3. unknown copy (always causes conflicts in ambiguous cases)
<jelmer> luke-jr__: what about files that are being split?
<luke-jr__> jelmer: that's more of a block-copy, unrelated but nice to add
<jelmer> luke-jr__: I think copy tracking and how it should be implemented is perhaps better left until the moment people start working on it, it's a complex beast
<luke-jr__> eg, splitting a file is on par with moving a funciton from a.c to (pre-existing) b.c
#bzr 2009-05-15
<AfC> lifeless: where did you upload your GPG key? It's still not on any of the public keyservers.
<lifeless> subkeys
<igc> morning
<lifeless> hi
<mwhudson> hi igc, lifeless, AfC
<igc> hi guys
<distatica> Let's say I made two revisions a moment ago, the last one I want to keep, the first one I made changes that I don't want anymore. What options do I have now? I don't want to revert back two revisions and lose the changes I made, but I'm not sure how to handle that.
<distatica> I'm a bzr / programming newbie, for what it's worth.
<lifeless> distatica: the easiest thing is just to undo the changes you don't want
<lifeless> and commit
<distatica> you mean manually? Just go in and remove those and then make a new commit?
<distatica> Or do you mean there's a way to undo a revision?
<lifeless> you can undo a revision
<lifeless> but as you're new to bzr I suggest not doing that until you've got some more experience
<distatica> ok
<lifeless> just edit your files and make them the way you want, and do a commit
<distatica> could I make the last commit a patch, revert back and apply that patch? Or am I just getting too complicated?
<distatica> For the record, I can undo these changes in about 20 minutes of work, so it's not a major critical issue, I was just going to learn how to do it while I'm here, unless I don't have the knowledge yet to perform it.
<lifeless> so
<lifeless> if you've shared the branch with someone you can't really ever delete the fact that you /did X/
<lifeless> think of bzr as a journal
<distatica> ok
<lifeless> once shared with people they have the journal
<lifeless> you can't erase from their copy
<lifeless> if you haven't shared it with people you can rip the most recent page  in your journal out
<lifeless> and then write on a new page
<lifeless> the way you'd pop two commits off is:
<lifeless> bzr uncommit
<lifeless> bzr shelve --all
<lifeless> bzr uncommit
<lifeless> bzr shelve --all
<lifeless> now, bzr unshelve
<distatica> so, if I make 3 commits, revert back 1, and then share the repo, the log will only show 2 commits?
<distatica> ok
<lifeless> will put the most recent shelved changes up ready for editing
<lifeless> yes, though 'revert' doesn't affect the journal at all; 'bzr uncommit' does
<distatica> oh I see
<lifeless> (the shelve --all, unshelve pair is a no-op, you could just do uncommit, shelve --all, uncommit to get to the same state)
<distatica> this is an issue I've been having, being a non-programmer some of my commits are... well pointless. :) It's just me screwing around with one thing, doesn't work, go back, try another.
<lifeless> anyhow, at this point in my example, you'd change things so they are you want, the commit
<lifeless> bzr unshelve
<lifeless> and bzr commit again
<distatica> ok
<lifeless> and you're back nearly-where-you-started but with the commit 2 back changed
<lifeless> so back to the journal analogy
<lifeless> if someone has been reading your journal
<lifeless> its not pointless ;)
<lifeless> if they haven't, if its private notes, then its fine to just change your mind
<distatica> ok, that's great news actually -- I had asked this question from someone a while back and got the impression (most likely due to my own ignorance) that once it was there it was set in stone and that was that.
<lifeless> the key thing is sharing
<distatica> yeah, once it's gone then it's stone.
<lifeless> once you've done that its more tricky :)
<distatica> great, thank you.
<igc> lifeless: does that mean that stacked branches are implicitly standalone?
<lifeless> igc: not sure what you mean by that
<igc> lifeless: when you said "we explicitly don't stack in shared repos"
<igc> what did you mean exactly?
<lifeless> so
<lifeless> in principle a branch can be stacked, while in a shared repo
<lifeless> but our ui code says 'oh, you have a shared repo, we won't stack'
<lifeless> so it should be unusual, but its not impossible, to encounter a stacked branch in a shared repo
<lifeless> I think we'll probably make it very common when we overhaul how we manage branches
<igc> ok
<lifeless> but thats a different discussion
<igc> right
<igc> lifeless: on another topic, that commit file patch has been reworked as we discussed
<igc> I know you're really busy ...
<lifeless> thanks
<igc> but if you're happy with it, I'll land it fro 1.15 today
<lifeless> I appreciate the ping
<lifeless> my day is:
<lifeless> 1) slides, deadline is today
<lifeless> 2) final prep for trip
<lifeless> 3) all other stuff
<AfC> lifeless: ah, there it is now.
<AfC> mwhudson: morning :)
<jml> poolie: you know how you say you use the register-branch API -- how exactly do you authenticate with that?
<jml> bzr alias snt="snt"
 * jml corrects the typo and tweetoblags.
<poolie> jml: i think it uses https auth
<poolie> hello all
<poolie> i'm basically getting ready to go and doing slides today
<poolie> lifeless: i approved your patch as you probably saw
<jml> poolie: yes.
<jml> poolie: and it prompts you for your Launchpad password?
<poolie> i think so
<poolie> it's so 2006 :)
<poolie> also, saying "it's so x" is so 2006 :)
<lifeless> poolie: I landed it as you may have seen :)
<jml> poolie: I'm actually waiting for a revival of "c'mon, it's the nineties!"
<jml> poolie: I may be waiting a while.
<spm> jml: so long as we skip the 80's revival. there are some places that should be left in the past.
<lifeless> spm: when doves fly
<spm> lifeless: ha! 'twas more the vison of the 80's "BIG" hair and warrick kapper style shorts that terrifies
<jml> lifeless: also when they cry.
<lifeless> it a myth
<bob2> shudder
<fullermd> jelmer: ping
<jelmer> fullermd: pong
<fullermd> Is there some reason you chose malloc.h rather than just using stdlib.h in the pyrex rio stuff?
<lifeless> igc: ping
<lifeless> igc: I didn't see a new merge request for that branch; did you simply push up changes?
<igc> lifeless: I did push the changes and ...
<igc> I tried to tell lp that it needs a new review
<igc> but the latter didn't seem to do much :-(
<lifeless> I've filed a bug
<lifeless> one thing I've seen already
<lifeless> the def check inner function
<lifeless> thats very opaque style
<lifeless> it would be clearer to either just do self.assertEqual(x,  ...) 3 times
<igc> I just copied what was there from memory
<lifeless> I realise this is kindof trivial, but we had 100 line tests that looked like that once
<lifeless> and it was fugly
<fullermd> jelmer: FreeBSD malloc.h has been #error'ing since 2001 (and #warning'ing since 1994) and pointing grumpily at stdlib.  Builds fine for me with that change.
<jelmer> fullermd: I've sent a merge req
<fullermd> Rox.  jelmer++
 * jelmer longs back to the days when statements had to be terminated with semicolons and malloc lived in malloc.h
<fullermd> When men were real men, women were real women, and small furry creatures from Alpha Centauri were real small furry creatures from Alpha Centauri?
<lifeless> igc: ok reviewed
<igc> lifeless: thanks
<lifeless> igc: I'mvery glad you factored it out, because now I'm sure there was something really wrong earlier ;)
<lifeless> igc: and yes, I've just checked your older code
<lifeless> so the problem is, you don't actually force include missing parents
<lifeless> they aren't being generated from iter_changes
<lifeless> so you'll have to iter_changes the *entire tree* if the user uses specific files
<lifeless> igc: If you want to chat about this, I'm happy to do so
<igc> lifeless: thanks. I'll take a look soon
<lifeless> igc: I'm going to nose down on presentations
<lifeless> igc: you may need to ring me :P
<igc> ok
 * igc lunch
<lifeless> so the good news is we saturate my link very happily branching bbc over the smart server
<lifeless> igc: did my review make sense?
<igc> lifeless: just got back from lunch - I'll take a look now
<igc> lifeless: so, I might be stupid but I still don't see the problem ...
<lifeless> ok
<igc> iter_changes only needs to return changed parents, not all of them
<lifeless> right, but unless its looking at parents it won't return them, because iter_changes has a bug
<igc> i.e. if a parent isn't in iter_changes, then it isn't needed in apply_delta IIUIC
<igc> lifeless: but it *is* looking at parent right now
<lifeless> how?
<igc> it looks at the whole tree, then post-filters
<lifeless> ow
<lifeless> I'm really torn
<igc> nad osutils.parent_directories doesn't need to return the root
<igc> at the os level, '' doesn't make sense
<lifeless> well, other code would be cleaner if it does - as you are making sure you have [''] always
<igc> also, my change to when record_titer_changes was deliberate ...
<igc> and the comment still hold exactly as is btw
<igc> I benchmarked to decide when it was the right thing fwiw
<lifeless> why the (len(self.parents) < 2 and not self.specific_files and not self.exclude)
<lifeless> clause?
<igc> because for non-chk formats, ...
<igc> it's slower than the current code otherwise
<igc> at least on Emacs
<igc> I'm happy to extend the comment along those lines
<lifeless> So this means tha the self.specific_files and self.exclude processing with record_iter_changes is _slower_ than the old full-tree code path
<lifeless> and that its only faster with record_iter_changes on chk repositoreis because the chk code is able to compensate
<lifeless> I appreciate that you've got it going faster
<igc> yes, according to my measurements
<lifeless> I'm really worried that the other changes, such as the reinstance of files_across_trees are going to make it harder for someone to come bacj and fix bug 347649 properly
<ubottu> Launchpad bug 347649 in bzr "iter_changes missing support needed for commit" [High,Confirmed] https://launchpad.net/bugs/347649
<igc> it was consistently slower - 08. vs 04 or something like that
<lifeless> as they will have to basically undo this patch to fix it
<lifeless> on the other hand I don't want to block performance improvements
<igc> lifeless: I did look at trying to remove the file_across_trees bit but ...
<igc> it broke the test suite cos ...
<lifeless> do you have any suggestion about how we can do both things?
<igc> we trap for bogus include paths
<igc> and iter_changes doesn't see those
<lifeless> file_across_trees is a problem because it upcassts the dirstate to an inventory - its spectcularly slow
<lifeless> emacs is what 20K files?
<igc> just checking, we're talking about the _set_specific_file_ids() method yes?
<lifeless> yes
<igc> emacs is 8K from memory
<igc> 100K revisions but ...
<igc> that doesn't matter myuch here
<lifeless> ok, so 16K inventory entries
<lifeless> I don't feel good about this code
<lifeless> so I'm going to recuse my self as a review at this point; I don't want to block you, and I haven't managed to open your eyes to why the layering is a problem or matters so much
<lifeless> I'll be effectively offline for 2 weeks, and I don't like the idea of you being blocked for that long.
<igc> I see and agree with the desire for one iter_changes call covering ...
<igc> legal filename checking, strict checking and collecting results
<igc> but I don't see it being necessary to get there in a single step
<lifeless> I bet you cold cache specific file commits will be way slower with your patch
<lifeless> particularly on the large trees I've been working up to - 50K and 100K files
<igc> slower than now or slower than possible?
<lifeless> slower than now
<lifeless> I could be wrong
<lifeless> but what you trade off is some unoptimised code (CHKRepository.add_inventory) for some optimised code that does a lot of IO (WT.iter_changes of everything)
<igc> I'll throw together the OOo tree and benchmark on it
<lifeless> cold cache will be key to see the disk IO impact
<lifeless> I can suggest a completely different approach if you just want to make it faster in the interim
<igc> lifeless: design wise, I have a question ...
<igc> if we delegate specific_file prcoessing to iter_changes ...
<lifeless> (an approach I wouldn't feel unhappy about)
<igc> how we we accurately insert the parents after the fact?
<igc> s/we/can/
<igc> we don't have all the info?
<lifeless> igc: iter_changes is allowed to jump around
<lifeless> igc: it already does this for renames
<lifeless> iter_changes has built into it the logic of find_ids_across_trees
<lifeless> anyway
<lifeless> if you want something easy
<lifeless> add a parameter to finish_inventory called 'basis_inventory'
<lifeless> and if use_record_iter_changes is False in commit
<lifeless> pass self.basis_inventory to finish_inventory
<lifeless> and in finish_inventory do:
<lifeless> if self.repository._format._commit_inv_deltas
<lifeless> delta = self.new_inventory._make_delta(basis_inventory)
<lifeless> self.repository.add_inventory_by_delta(basis_inventory, basis_inventory.revision_id)
<lifeless> ^
<lifeless> this will work around finish_inventory being overly slow in CHK repositories when not using record_iter_changes
<lifeless> and as you'll already have a basis_inventory it should be nigh free
<igc> lifeless: ok, I'll play with that next week and try it on some larger data sets
<lifeless> igc: I would expect that to be ~= to what you have today, and deal with cold cache and other situations much better
<lifeless> no where near as fast as fixing iter_changes
<lifeless> I would expect a fixed iter_changes to smoke everything
<lifeless> as for what to do in iter_changes to handle parent dirs
<lifeless> I would keep a minimal set of directory items output
<lifeless> and a 'we need a parent of X' queue
<mtaylor> morning lifeless
<lifeless> at the end of the normal loop, if there 'we need a parent of X' is non-empty
<lifeless> we do the normal loop on just the missing parents
<lifeless> without recursion
<lifeless> hi mtaylor
<lifeless> 25 minutes to branch samba with bzr
<lifeless> 16 with git :(
<lifeless> I think the difference is entirely size
<lifeless> as both saturated my link
<mtaylor> lifeless: I had to use hg ove the past few days for something - hated every second
<lifeless> mtaylor: :)
<igc> lifeless: right, and it's the lack of recursion support that makes it hard to tack these on now
<igc> lifeless: btw, there is a genuine use case for filter_iter_changes_by_paths() beyond commit: post processing the output from Inventory.iter_changes()
<igc> and anything else that looks the same but doesn't take the specific_files parameter
<lifeless> igc: Sure, I wouldn't have suggested a generic function if I didn't think it could be useful generically ;)
<lifeless> igc: that said, I think Inventory.iter_changes should take specific_files :)
<igc> with chk_maps, I'm pretty sure we get the lot and post-filter much like this
<igc> lifeless: anyhow, thanks for the feedback & have fun at uds/allhands
<lifeless> I'd like to have a toolkit of iter_changes iterator filters
<lifeless> quite separately from making commit awesome
<igc> lifeless: I was thinking along those lines too
<lifeless> but the only way to avoid excess IO is for iter_changes to know that it should skip over things
<lifeless> which the sepecific + exclude params are needed or
<lifeless> *for*
<igc> when dirstate.iter_changes() supports exclude as a parameter, I'll be far more interested :-)
<lifeless> I'd like it if someone other than John and I did that
<lifeless> we've got a bunch of talented people
<igc> we do
<igc> and it's a talent knowing which bits of code to leave to the experts :-) :-)
 * lifeless snorts
 * lifeless looks around for that beaker of expert-juice
<igc> I've read the dirstate code multiple times and it still makes my head spin :-(
<lifeless> the C version is a lot clearer
<lifeless> we got to use functions
<lifeless> they help ;)
<igc> yes :-)
<lifeless> If you want to poke at iterchanges a bit and send mail asking for clarification please do
<lifeless> it will be an asset to have you understand it
<lifeless> though, does our medical cover self inflicted insanity?
<lifeless> igc: I have another hidden motivation
<lifeless> I want to make the commit code radically simpler
<igc> lifeless: I'm all for that
<lifeless> by having it be _just_ policy on top of iter_changes + CommitBuilder
<lifeless> policy+ui
<igc> though it's pretty good but one particular bit now
<igc> and that bit is around the pointless-commit checking
<lifeless> yes
<igc> I think some of check_pointless() ought to be pushed down into builder.any_changes()
<lifeless> yes, or removed
<lifeless> uhm
<lifeless> any_changes is kindof pure
<lifeless>  I don't think it should be saying 'no' if there are changes
<lifeless> also
<lifeless> check_pointless should also catch pointless merge commits
<lifeless> if you know what I mean
<igc> that "initial commit is just a root directory" stuff seems to look way too much into the builder for my liking (was my point)
<igc> anyhow, back to other stuff
<lifeless> sure
<lifeless> I agree
<vila> hi all
<lifeless> hi
<jml> lifeless: how go the talks?
<lifeless> good
<lifeless> gc one nailed I think
<lifeless> bvg one nearly full-draft
<knielsen> is there an algorithm that given a bzr revision number will provide the revision number of the parent (leftmost parent in case of merge changeset) ?
<Peng_> beuno or mwhudson: ping
<knielsen> ie. N -> (N-1), but what about composite revision numbers?
<lifeless> knielsen: X.Y.Z->X.Y.(Z-1) forall Z > 0
<lifeless> knielsen: X-1 for all X.Y.Z, Z=0
<lifeless> If I remember correctly ;)
<fullermd> Sounds like an XY problem question, though.
 * lifeless looks around for the muzzle
<fullermd> I told you, wait 'till she leaves town.
<lifeless> :P
<knielsen> lifeless: hm, thanks, but doesn't that sound too simplistic?
 * knielsen thinking
<lifeless> knielsen: if you want it to be complex, I can come up with some extra stuff
<vila> X.Y.Z->X.Y.(Z-1) forall Z > 1 X-1 otherwise (we don't have Z=0 AFAIK)
<Youssef> Hi all!
<Youssef> is there an admin?
<vila> knielsen: but relying on revnos is fragile, why don't you just access the revision map and take the first parent /
<vila> s!/!?!
<Peng_> I hate time zones.
 * vila talking perl again :(
<knielsen> vila: yeah, just wondering
<Peng_> Whoever invented time zones had no respect for programmers. :(
<vila> Peng: go to North Pole and turn around if you don't like the current TZ
<knielsen> vila: I prefer revid:'s myself, but most of the world seems to be using revision numbers without considering that they can change at each merge
<Youssef> please guys respond me!
<Peng_> Youssef: I admin things, but probably not what you're interested in.
<Youssef> lol
<Youssef> okauy
<Youssef> yesterday i asked what is the difference between
<Youssef> create a checkout and make a local copy of the branch
<vila> knielsen: there are not supposed to change in a given branch, not even a trunk one where other branches are merged into if you use append_revisions_only
<fullermd> Time zones are an artifact of diurnal slavery.  Liberate thyself!
<knielsen> vila: well, if two people branch from revision N, and each commit revision N+1, then at least one of the commits will change the revision number when you merge ;-)
<lifeless> vila: you're wrong ;)
<lifeless> vila: the parent of the first commit on a branch is a mainline rev
<Youssef> Peng_:
<Youssef> ???
<Peng_> fullermd: I did, but the rest of the planet hasn't followed along, so I still have to deal with it.
<Peng_> Youssef: Probably the difference between "bzr checkout' and "bzr branch". See ToirtoiseBZR's docs and "bzr help".
<fullermd> Peng_: Their fault then.  Apply beatings until behavior is modified.  Making bail is left as an exercise for the reader.
<Youssef> Mmhhhh... okay thanks
<Peng_> fullermd: I can't beat up everyone.
<vila> knielsen: not inside a given branch, on trunk the first to push will even keep the same revno as his local branch
<Peng_> Wait, I only have to beat up all Bazaar users. That's significantly easier, but still impractical.
<vila> lifeless: wrong about Z=1 or about revno stability ?
<lifeless> vila: Z=1
<knielsen> vila: didn't know about append_revisions_only, want to check that ... but what I mean is if I eg. branch from an old revision of lauchpad directory, commit locally, merge tip of the launchpad branch, and finally push the result to the launchpad branch, all intervening revision numbers will change
<knielsen> right?
<lifeless> knielsen: yes
<vila> knielsen: yes
<lifeless> knielsen: this is used to control presentation of history
<vila> knielsen: either your manage history presentation from trunk or you force your local history upon others
<vila> the later doesn't scale very well
<knielsen> well, actually I prefer to always use revid: when sending revision references to others (or tags of course) ...
<knielsen> but I don't understand what you mean with "manage history presentation from trunk" ?
<knielsen> sounds like there is some documentation somewhere that I would like to read to learn about this ;-)
<vila> knielsen: you mean you're voluntering to write it ? Great ! :-)
<knielsen> lifeless: right, just did a simple example of multiple branching/merging, and I got 1.1.2 as the parent of 1.2.1, so the issue _is_ a bit more complex (as it must necessarily be)
<knielsen> vila: I might actually, but I will have to learn it first ;-)
<vila> knielsen: the left-hand side history for a given branch is shown by 'bzr log -n1'
<knielsen> probably I will check into the source code
<vila> i.e. you get the commit messages for the commits done on that branch only, not the commit messages for the merged revisions
<vila> managing history presentation from trunk then means that you chose proper commit messages when merging and generally do only commits for merges in trunk
<vila> *but* if you push on trunk, you end up with series of commits for each feature or bugfixes, not a synthetic view, but a detailed one
<knielsen> vila: yes. Exactly
<vila> it's a highly subjective matter
<knielsen> vila: well, the underlying problem is an automatic tool that monitors a public branch for changes, and eg. builds and tests each new revision, or does some other action
<knielsen> vila: and often I see the tools or people providing notifications in the form of the revision number of the new revision
<vila> knielsen: we call that a gatekeeper
<lifeless> knielsen: huh?
<lifeless> 1.2.1 descending from 1.1.2 ?
<lifeless> oh, its the newer form, the original had the drop-2 items property
<knielsen> vila: but the revision number is actually not suitable for this in the general case. Just knowing the revision number does not allow you to do anything really reliably, as when you look at the branch that revision number may rever so something else entirely
<knielsen> vila: so the solution is to use revision id's, of course...
<lifeless> knielsen: long lived branches often set the append only flag
<lifeless> which means the revnos are stable
<knielsen> lifeless: yes, I want to check up on that flag, wasn't aware of it. sounds useful
<lifeless> bzr help configuration, I believe
<knielsen> I guess I will look into the source to learn more at some point
<fullermd> To be precise, it's not so much that the flag keeps the revnos stable, as that it prevents you from doing the things that make them change.
<vila> fullermd: right
<knielsen> lifeless, vila: anyway, thanks a lot for you comments, quite useful
 * igc dinner
<bialix> jelmer: I have a couple questions about bzr-git
<bialix> 1) does it can work with github? at least for branch/pull
<bialix> 2) why you has marked it as incompatible with Windows?
<jelmer> bialix: it works with github
<jelmer> bialix: it's not been tested on Windows yet, and I'm aware of some places where we should be converting / to \
<bialix> jelmer: re Dulwich: does C-extensions (_object.c and _pack.c) is used now?
<jelmer> bialix: they're optional
<jelmer> bialix: patches to fix the windows issues are very much welcome btw
<bialix> I've fixed setup.py to compile them, but _pack.c cannot be compiled with MSVC right now (MSVC lacks stdint.h)
<bialix> jelmer: I have interest in bzr-git
<jelmer> bialix: you can steal the stdint.h replacement from bzr-svn
<bialix> perhaps I need to work with some github projects, so
<bialix> ok, I'll look to bzr-svn then
<bialix> jelmer: how you prefer to get patches: by mail or via LP merge requests?
<jelmer> bialix: by email
<bialix> ok
<awilkins> lifeless: Did you speak to me earlier? I have an alert but my scrollback doesn't contain it
<awilkins> lifeless: I either had an obscure bug or suffered from an MD5 collision in my packs... I think the bug is far more likely
<lifeless> awilkins: bug, windows specific
<lifeless> fail during inserting a pack
<lifeless> then do the same pull again
<lifeless> fail the second time because we can't rename over the file
<awilkins> lifeless: Aha, yes, I got that
<lifeless> can you file a bug:)
<awilkins> Definitely, I was watching with a FS traceer
<awilkins> I think the fail may either have been a permissions thing or a result of that jailbreak bug
<awilkins> Although it recurred after I fixed the jailbreak, move the repo, made a new one, and pushed all the branches into it
<awilkins> 'twas always a particular pack, I recognised the MD5 each time
<lifeless> yes
<lifeless> odd to have it happen again ><
<lifeless> reproducible?
<lifeless> [and have you filed a bug for the rename handling of it on windows? :)]
<awilkins> Gimme a chance...
<lifeless> :P
<awilkins> I saw it write the pack and then write it again in the same session
<lifeless> oh? depends on what you mean by that
<lifeless> older clients write to packs by doing append many times
<awilkins> I still have the nagging thought that it could have been an MD5 collision but that would be rather silly
<awilkins> This was a 14.1 client writing to a 14.1 server over HTTP HPSS
<lifeless> so that does a single post
<lifeless> if it was an md5 collision a different error
<lifeless> would have been reported
<lifeless> one that says 'lucky you' in essence
<awilkins> Does it even check?
<lifeless> yes
<lifeless> welllll
<lifeless> there are checks about this
<awilkins> The trace (which I didn't save, sorry) had the offending pack created and written in "packs" then in upload, then it tries to rename it from upload to packs and fails
<awilkins> Maybe I'll do it again when I'm back in the office
<awilkins> Right now I have an annoying deadline I'm going to miss
<lifeless> oh
<lifeless> might be a suspend/resume bug
<awilkins> Of the session?
<lifeless> yeah, stateless server - saves in progress pack as <hash>.pack in uplaods
<lifeless> then does the final rename to ../packs in a separate hpss call
<awilkins> That rename is the bit that fails - shouldn't it be doing all the pack writing like that and not creating files in "packs"
<awilkins> Hmmph, I can't branch 1.14 from lp
<awilkins> Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'get_bytes_as'")
<awilkins> I've been getting that for 3 days now
<lifeless> try with sftp
<lifeless> if that works we need to repair the branch
<lifeless> smart server wants more data in stacked branches
<lifeless> repair is a bit wrong; just push a tad more data into it
<awilkins> Looks like a missing bit of API
<lifeless> bzr branch nosmart+bzr+ssh://b.l.n/~bzr/bzr/bzr.dev
<awilkins> Got a 'str' object has no attribute 'get' trying sftp
<awilkins> I think that might be bzr-svn though
<jelmer> awilkins: yeah, that's a known issue fixed in 0.6
<awilkins> Ok, the problem occurs in the finish() method of NewPack
<jelmer> vila: are you aware of the python-webdav module?
<vila> jelmer: never heard about it
<jelmer> vila: python-based webdav server implementation
<jelmer> vila: I'm looking at it for bzr-svn server side testing
<bialix> jelmer: ping
<jelmer> bialix: pong
<bialix> jelmer: if you don't like my test command I'll keep it for myself in my own branch
<bialix> so other patches I'll prepare in another branch
<bialix> what I should do?
<jelmer> bialix: Please keep it separate
<bialix> ok
<bialix> jelmer: are you ok to put test files into temp subdir?
<mxpxpod> jelmer: around?
<jelmer> mxpxpod: hi
<mxpxpod> I'm getting an error trying to push to a branch using bzr-svn
<mxpxpod> SubversionException: ("'/svn/support/!svn/bc/5/branches/1.0' path not found", 160013)
<jelmer> bialix: ideally check for TEMPDIR environment variable and if that doesn't exist, tempdir subdir
<jelmer> mxpxpod: can you give a bit more context?
<mxpxpod> jelmer: do you want my .bzr.log?
<jelmer> mxpxpod: yeah, can you mail that perhaps?
<bialix> jelmer: on Windows there are $TEMP and $TMP. Also I can use tempdir python std lib
<mxpxpod> jelmer: yup, where would you like it emailed to?
<jelmer> mxpxpod: jelmer@samba.org
<jelmer> bialix: ah, yeah, python std lib tempdir sounds like a good idea
<bialix> ok
<mxpxpod> jelmer: sent
<bialix> jelmer: do you did rebase of my forst patch?
<mxpxpod> jelmer: let me know what you figure out...
<bialix> s/forst/first/
<jelmer> bialix: yeah, I dpushed it
<jelmer> bialix: dulwich is maintainer in parallel in both git and bzr
<bialix> :-(
<jelmer> mxpxpod: no email yet
<jelmer> s/maintainer/maintained/
<mxpxpod> jelmer: check your spam... it's from bryan@reigndropsfall.net
<bialix> jelmer: even file-ids are not preserved :-(
<bialix> should I send to you plain diffs then?
<jelmer> bialix: no, please by all means do send bundles
<jelmer> bialix: dpush will preserve whatever it can in git
<jelmer> bialix:
<jelmer> bialix: it will retain author/committer, commit message and multiple commits and the merge graph
<bialix> I have a lot of coinflicts
<jelmer> sorry about that
<jelmer> it would've been the same with a plain diff though
<bialix> :-/
<jelmer> at some point bzr-git will start supporting push
 * bialix need to figure out how to best handle this in the future
<jelmer> mxpxpod: still nothing, can you try jelmer@ubuntu.com ?
<mxpxpod> jelmer: yeah
 * jelmer dinner
<mxpxpod> jelmer: sent
 * bialix waves
<jelmer> mxpxpod: that worked
<jelmer> mxpxpod: please file a bug
<jelmer> mxpxpod: there is one somewhere there
<jelmer> mxpxpod: 0.6 ?
<mxpxpod> jelmer: 0.5.4
<awilkins> jelmer: Do you still have to use svn-push or can you just use push for new branches that don't exist in the target repo?
<awilkins> (for 0.5.4)
<SamB> awilkins: I don't think svn-push still exists ?
 * awilkins reads the help and answers his own question
<awilkins> SamB: It's there, but the help says it just tells you to use push
<awilkins> It's going to be a long push anyway, many MB of data over a rather slow upstream
<awilkins> I do find myself wishing it was a bit more chatty
<awilkins> It's just sitting there eating bandwidth and some feedback would be nice :-)
<awilkins> If only so I can tell when I've hit my ISP cap and it's throttled me :-)
<SamB> doesn't it show you the progress ?
<SamB> and transfer rate ?
<awilkins> SamB: The other transports do, but this one isn't
<jam> mneptok: I heard you were looking for me
<awilkins> Yegods I hate having a slow upstream
<mneptok> jam: i am!
<mneptok> jam: got time to look into a bug that's blocking some MariaDB work?
<mneptok> jam: https://bugs.launchpad.net/bzr/+bug/375898
<ubottu> Ubuntu bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [Undecided,New]
<mneptok> !botsnack
<ubottu> Yum! Err, I mean, APT!
<jam> mneptok: I have not specifically looked at that yet, if you give me a bit I'll have a peek
<mneptok> jam: at your leisure, sir.
<mneptok> jam: thanks for the mental bandwidth :)
<jam> mneptok: so is re-doing the merge of pbxt an option?
<knielsen> jam: that's certainly an option. The merge described in the bug was just a test, and since there were problems it has been put on hold
<jam> because I'm guessing that doing something like "bzr merge-into/bzr join" is going to be a lot easier
<knielsen> jam: we were not aware of the bzr join functionality, but it looks interesting (and what is bzr merge-into?)
<jam> knielsen: 'lp:bzr-merge-into' is a plugin that merges a project into a subdirectory of another project
<jam> 'bzr join' is a built-in command to do the same thing, but as written has specific requirements as to repo formats, etc
<knielsen> jam: sounds like this would be better, using a supported way to merge a subproject rather than the hackish/abusish approach from the bug...
<jam> knielsen: so from what I could see, you are merging everything in, but you get some filename conflicts, so you move them out of the way, do the global merge, then merge them back in
<jam> sorry,
<jam> rename them to where you really want them
<knielsen> yes, sounds right
<jam> let me give it a poke, since I should have what you need here
<knielsen> hm, bzr docs says `bzr join` requires that the tree to be joined be first split out with `bzr split`... but won't that prevent commits from the original subproject tree to be pullable into the new joined tree?
<knielsen> well, I should try it and see
<jam> knielsen: well, I've used 'merge-into' before to maintain a nested structure
<knielsen> jam: ok, I'll look into that as well
<jam> the only known issue is that newly added files in the root of the subproject
<jam> will show up in the root of the outer project
<jam> rather than in the subdir
<jam> otherwise, things should flow fine
<jam> knielsen: what rev of maria should I try to use?
<jam> (just before the pbxt merge)
<jam> ah, I think I found it
<knielsen> jam: you can use the revid:paul.mccullagh@primebase.org-20090407105746-tolv5dita1d3eavm of lp:maria
<jam> k, i used -r'revid:paul.mccullagh@primebase.org-20090407105746-tolv5dita1d3eavm' since that was in the bug report
<jam> looks about the same :)
<knielsen> jam: just out of curiosity, do you think the "ERROR: No final name for trans_id 'new-1'" is a bzr bug, or caused by user abuse?
<jam> (At first glance Pidgin decided to turn : Paul into a smiley face, so it wasn't obvious)
<knielsen> heh
<jam> knielsen: it *is* a bug, but whether it was introduced at the 'combine' step, or at the new merge time...
<knielsen> jam: right...
<knielsen> jam: there is a _lot_ of add/rename/modify going on on top of each other on the same files, so lots of potential for borner case bugs.
<knielsen> s/borner/corner/
<Tak> is there a way to explicitly close a branch? (bzrlib)
<jam> Tak: del branch
<jam> knielsen: I'll post my approximate steps
<Tak> aha, thanks
<knielsen> jam: cool, thanks
<Tak> hmm, how does that work when I have a tree and/or a revisiontree that I've obtained from that branch?
<Tak> do I need to del them all?
<jam> Tak: well, you need to get rid of all references to the branch
<jam> I'm not sure how you got a "tree" from the branch, though certainly a revtree via repository
<jam> I doubt the revtree references the branch, but it would reference the repository
<jam> knielsen: update posted to 375898
<Tak> ok, so I need to nuke everything that might reference the branch
 * knielsen looking
<Tak> I suppose Branch.close() wouldn't be considered in the future? ;-)
<jam> knielsen: I can say that after doing the recipe I mentioned
<jam> I can do: "bzr merge lp:pbxt"
<jam> and the files changed are in storage/pbxt/... and mysql-test/suite/pbxt/...
<knielsen> jam: right, that's cool
<knielsen> jam: I'll definitely try it out and see how it works
<knielsen> jam: With the original merge I did, the but shows up when merging a single changeset from lp:pbxt, but merging all of lp:pbxt worked like you tested on the new merge. So will be interesting to compare
<jam> knielsen: can you give the cherrypick you want me to try?
<jam> (note that I won't have applied your individual patches yet)
<jam> but we still shouldn't get 'no name for new-1' sort of stuff
<jam> we could give conflicts, etc, but that error is an internal bug
<knielsen> jam: I did `bzr branch -rrevid:paul.mccullagh@primebase.org-20090403100843-wrwq5hjzvnigsx69 lp:pbxt to-be-merged and then merged from the to-be-merged branch.
<jam> knielsen: that would be a complete merge, not a cherrypick, at least as far as I can see
<jam> you aren't specifying an explicit base
<jam> what you just mentioned should be equivalent to:
<jam> bzr merge -r revid::paul.mccullagh@primebase.org-20090403100843-wrwq5hjzvnigsx69 lp:pbxt
<knielsen> jam: that might be the same as cherry-picking revid:revid:paul.mccullagh@primebase.org-20090402202852-wa2fbcmrdy7gda2f..revid:paul.mccullagh@primebase.org-20090403100843-wrwq5hjzvnigsx69 - I'm not sufficiently knowledable with bzr to know (it's a single commit)
<jam> and at least here, I get:
<jam> $ bzr merge -r revid:paul.mccullagh@primebase.org-20090403100843-wrwq5hjzvnigsx69 ../pbxt
<jam>  M  mysql-test/suite/pbxt/r/type_varchar.result
<jam>  M  mysql-test/suite/pbxt/t/type_varchar.test
<jam>  M  storage/pbxt/src/ha_pbxt.cc
<jam> All changes applied successfully.
<knielsen> jam: basically, I'm merging the next single commit on lp:pbxt ...
<knielsen> jam: right, so it works!
<jam> knielsen: with the range you gave, I get the same result "All changes applied successfully"
<jam> and it doesn't count as a cherrypick
<knielsen> jam: right, so in the merge in the bug report, the two first files are actually deleted in the merged mariadb tree ...
<jam> because evid:paul.mccullagh@primebase.org-20090402202852-wa2fbcmrdy7gda2f is in your ancestry already
<knielsen> jam: and bzr says something strange: +N mysql-test/suite/pbxt/r/type_varchar.result.OTHER
<knielsen>     +N mysql-test/suite/pbxt/t/type_varchar.test.OTHER
<jam> knielsen: well "Contents conflict in ...." is "You deleted X, but OTHER modified it, Conflict"
<jam> so we version the latest version of the OTHER (as .OTHER)
<jam> since you can "bzr revert .....OTHER" if you want to preserve your delete
<jam> or you can "mv x.OTHER x" if you want to restore the file
<knielsen> jam: right. In any case the conflicts are correct
<jam> [I'm not particularly fond of versioning foo.OTHER, but I understand why it was chosen.]
<jam> that said, the "No final name for trans_id 'new-1'" is still a bug
<knielsen> of course
<jam> I don't know how it thinks it wants to version a file, with no real file-id
<jam> and obviously no filesystem path
<jam> knielsen: anyway, I can probe directly into the bug, or I can say "use merge-into" to do this sort of thing, and we can punt for now
<jam> I'd like to get back to working on my presentation for next week, if that is ok
<knielsen> jam: yes, agree. Using merge-into is in any case much better, thanks a lot for that hint.
<knielsen> jam: so I will look into merge-into to solve our problem. And then later when you or someone else get back to look at the bug, I hope you will have the necessary information to debug it
<knielsen> jam: I gave the 3-step sequence to reproduce from public launchpad trees, with revid:s to make sure they stay stable, so hopefully that will be sufficient
<knielsen> jam: in any case, thanks a lot for your time and help!
<vxnick> hi all - I'm trying to bzr push a branch to a remote server via sftp, but I get the message "This transport does not update the working tree of: <repo location>"
<Tak> that's just a warning
<vxnick> Tak: it doesn't push anything though - it says "no new revisions to push" even when I bzr add them
<vxnick> do I need to commit before I push or something?
<knielsen> vxnick: yes, you need to commit before you push. push transfers only committed changes.
<vxnick> knielsen: ah ok - I was under the impression that checkout/commit were distinct from pull/push
<kfogel> I'm running bleeding-edge bzr.  I'm initting a new repository (new project); I'm tempted to use format 1.14 or 1.14-rich-root -- I would use brisbane-core, but apparently it's not in trunk yet?  So, anyone advise for/against 1.14?
<xnox> bzr: ERROR: Must end write group before releasing write lock on CHKInventoryRepository
<xnox> Please help. This is on bzr pull from svn
<xnox> it seems to me there is a race condition between pull and repacking of revisions on rich-root svn repo's with regards to write lock. That's on bzr 15
<jfroy> hello
#bzr 2009-05-16
<xiaohui> how to  change the parent branch of bzr?
<jelmer> xiaohui: bzr pull --remember
<xiaohui> jelmer, thank you
<rockstar> abentley, around?
<rockstar> jelmer, do you know much about bzr hooks?
<jelmer> rockstar: hi
<jelmer> rockstar: a bit
<rockstar> jelmer, so, I've got a class that inherits from bzrlib.hooks.Hook, and it registers two hook points.  How do I fire those two hook points?
<jelmer> rockstar: the hook points are iterables over the registered hooks
<jelmer> so you can just do something like:
<jelmer> for hook in myhooks_instance['hook_name']:
<jelmer>    hook(42)
<rockstar> bzrlib.hooks.HookPoint has a hook method, but not an fire method.
<rockstar> jelmer, you would think that the HookPoint would know how to fire itself.  :/
<jelmer> rockstar: no, you have to call the individually registered entries yourself
<jelmer> although I guess it would indeed make sense for HookPoint to have such a method
<rockstar> jelmer, yea.  Something like HookPoint.fire(*args)
<rockstar> jelmer, I'll implement create a subclass of HookPoint in Tarmac, try it out, and if it works, I'll create a patch for Bazaar.
<rockstar> Is there a simple way to add revisions to a branch created with BzrDir.create_branch_convenience ?
<BasicOSX> Attempting 1.15rc1 release and I keep getting "bzr: ERROR: socket.error: (104, 'Connection reset by peer') " several network, all peered differently, even 1 network from a large hosting provider in the midwest (US). Something wrong with LP tonight?
<rockstar> BasicOSX, on push?
<BasicOSX> or branch or pull
<rockstar> BasicOSX, hm, I haven't had any problems, and I've been using it steadily tonight.
<lifeless> rockstar: what do you mean by add revisions
<lifeless> rockstar: is this test code or real code
<rockstar> lifeless, test code.
<lifeless> BasicOSX: what aare you getting that from
<BasicOSX> bzr  branch http://code.launchpad.net/~bzr/bzr/bzr.1.15
<BasicOSX> gives that to me
<lifeless> rockstar: and what do you mean by add revisions
<rockstar> lifeless, basically, I want to test that two branches are merged.  I was planning on going to find the merge tests in bzrlib and see how they work.
<rockstar> lifeless, if I create two branches with BzrDir.create_branch_convenience and try to merge them, it throws NoCommits (which makes sense)
<lifeless> A and B are merged if len(heads(a.tip, b.tip)) == 1
<BasicOSX> lifeless:  attempting  ~/projects/bzr/bzr.1.14/bzr  branch http://code.launchpad.net/~bzr/bzr/bzr.1.15 to see if it's a problem(?) in bzr.dev (revision: 4369)
<lifeless> rockstar: tree1 = self.make_branch_and_tree('1'); tree1.commit(''); tree2 = tree1.branch.push('2')
<lifeless> tree1.commit('next')
<rockstar> lifeless, yes, so I want to add some revisions b so that I can actually make a merge (but not necessarily commit)
<lifeless> tree2.commit('next in 2')
<lifeless> tree2.merge_from_branch(tree1)
<rockstar> lifeless, I'm not using the bzr test suite.
<lifeless> rockstar: oh; any reason preventing you?
<BasicOSX> bzr: ERROR: Connection error: Couldn't resolve host 'bazaar.launchpad.net' (-2, 'Name or service not known') things keep getting stranger
<rockstar> lifeless, um, mostly because I'm too lazy to go try it out, and I probably don't need most of it.
<BasicOSX> I did just recently upgrade to 2.6.24-24-server on my hardy system, but that's the only change
<rockstar> lifeless, but mostly lazy.  :)
<lifeless> rockstar: from bzrlib.tests import TestCaseWithTransport
<lifeless> thats all thats needed :)
<rockstar> lifeless, I am stealing the Hook/HookPoint stuff though.
<rockstar> Well, not stealing, but using.
<lifeless> rockstar: to add revisions you need to do commits or pull/push from another branch
<lifeless> rockstar: by far the easiest way is using the bzr test harness
<rockstar> lifeless, okay, that's simple enough.
<lifeless> BasicOSX: anything I can do, let me know
<lifeless> BasicOSX: but I think you have some local trouble ;P
<BasicOSX> I'd like to think so, but 4 different computers on 4 different network on 4 different ISPs?
<BasicOSX> Comcast, UUnet, Qwest, and Sprint all having problems? could be, heck google went down the other day :-)
<BasicOSX> lifeless:  373455 when from Fix Released to Fix Committed, that normal?
<BasicOSX> bug 373455 that is
<ubottu> Launchpad bug 373455 in bzr "brisbane-core doesn't support stacking but should" [High,Fix committed] https://launchpad.net/bugs/373455
<lifeless> BasicOSX: no
<lifeless> BasicOSX: fix committed means 'it has landed in bzr.dev'
<Peng_> But bzr uses "Fix Released" for that.
<lifeless> oh yes, I'm explaining badly
<lifeless> what I mean is, if its not ix released, its not in trunk
<lifeless> I don't think we've finished fixing stacking
<lifeless> I could be wrong
* BasicOSX changed the topic of #bzr to: Bazaar version control system | 1.15rc1 released 15 May, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
<Peng_> Congrats. :)
<BasicOSX> Now the scary part.. merge back into trunk :-P
<alsuren> is there a way to tell bzr to ignore changes in permissions? I just copied everything to a fat32 usb stick, and it's telling me that the entire repo has been changed
<lifeless> alsuren: the only permission bzr tracks is the executable bit
<lifeless> alsuren: are you using bzr under windows?
<alsuren> no, I'm on ubuntu. Problem is that I made *some* changes
<alsuren> oh, I just read the bit on status-flags. I reckon I could hack something together with grep to work out which files I *actually* modified
<alsuren> yeah, so parsing the output of status -S is actually really easy. Why isn't this the default?
<alsuren> actually, I'm quite glad that it's not
<alsuren> ignore me
<Peng_> :D
<alsuren> okay, so actually I still need help
<alsuren> $ bzr revert
<alsuren> bzr: ERROR: [Errno 1] Operation not permitted
<alsuren> there is a bug in launchpad about it
<alsuren> https://bugs.launchpad.net/bzr/+bug/190725
<ubottu> Ubuntu bug 190725 in bzr "Bzr can't init branch on ntfs-3g filesystem" [Medium,Triaged]
<alsuren> (for reference, I used cp -R proj/.bzr /media/disk to do the copy)
<alsuren> does anyone know a way around this, or am I just screwed?
<lifeless> alsuren: well the bzr metadata should be just fine
<lifeless> alsuren: you could try branching fresh
<alsuren> *bets he'll run out of space if he does that, but tries it anyway*
<alsuren> no. still operation not permitted
<alsuren> oh, ololol: it's symlink that's throwing
<alsuren> okay, so removing the symlinks from the repo makes revert work, but I still need some way to stop bzr from trying to track the execute bit
<Peng_> Hmm, content filters? :D
<alsuren> Peng_: https://bugs.launchpad.net/bzr/+bug/190725/comments/8 suggests a plugin. how do I need to change it?
<ubottu> Ubuntu bug 190725 in bzr "Bzr can't init branch on ntfs-3g filesystem" [Medium,Triaged]
<alsuren> (I'm thinking that the real solution would probably be retro-fitting permissions to FAT at the operating system layer, but we all know that's not going to happen
<alsuren> hrrrm... I guess I could monkey-patch os.stat to clear the execute bit, but that's *really* horrible
<lifeless> o
<Odd_Bloke> jelmer: I just hit http://dpaste.com/44691/ when trying to push to Debian SVN.
<lifeless> so the basic problem is, fat is returning garbage data, and we assume when the platform is unix that all fs's track X reasonably well
<lifeless> we have code to work around no X tracking but only activate it on windows
<lifeless> file a bug please
<lifeless> I suggest we add a a config setting/environment variable to force that workaround code on in this sort of situation
<Peng_> What about explicitly checking if the fs supports it?
<Peng_> Same way you do the CIFS checks?
<lifeless> Peng_: what CIFS checks
<lifeless> Peng_: do you mean the case insensitive ones?
<Peng_> Yeah.
<lifeless> we need either reference data or to write
<lifeless> its possible in principle
<alsuren> lifeless: should I paste this conversation to the bottom of my bug report?
<alsuren> lifeless: where is this no-X-tracking magic, and can I enable it with a plugin in the short-term?
<awilkins> Offtopic : Is there an ability in the SFTP protocol to just get a hash or crc of a file, not the file?
<awilkins> Thinking about it, is tracking x-bit a security risk, and should it be done at all?
<alsuren> awilkins: where did you get that idea from?
<alsuren> bzr is used for pushing source code around, which is compiled and executed on the user's system. There are far more dangerous things that you can do than twiddling an X bit
<awilkins> alsuren: Yes, put that way it does seem less significant
<lifeless> alsuren: its mainly in workingtree*.py
<lifeless> awilkins: don't think so
<lifeless> [to both SFTP and x-bit security]
<lifeless> bzr doesn't run the users code
<lifeless> its why we don't have in-tree plugins, for instance
<awilkins> Fairy snuff.
<lifeless> as long as bzr doesn't run code from a branch, there isn't a risk that is bzr's fault ;)
<lifeless> now,if bzr tracked owners
<lifeless> or setuid
<luks> bzr actually can try to run some python code :)
<lifeless> that would be different
<lifeless> luks: from the users branch?
<luks> yes
<lifeless> how?!
<luks> via imports
<lifeless> thats the system python path
<lifeless> outside bzr's control; file a bug on your OS/python install :)
<luks> sure, but it can happen :)
<lifeless> same as bash can run some code from there
<luks> but bash is expected to do so
<lifeless> no
<lifeless> having '.' in your path is widely recognised as a security law
<lifeless> *flaw*
<lifeless> same goes for . in your python path
<luks> except that's the default setting for python
<alsuren> luks: well if you fancy porting bzr to python3 and using "from . import whatever" all over the place, then go for it
<luks> I'm not saying anything except that it's possible for bzr to run user's code right now
<luks> I know about it and I can live with it
<alsuren> that's actually something I'd never thought about before.
<luks> I can't even reproduce it right now, so maybe there was something done to fix it
<luks> I've seen a few people to have that problem on the ML in the past
<alsuren> luks: reading the tut, that's not how it works
<alsuren> "Actually, modules are searched in the list of directories given by the variable sys.path which is initialized from the directory containing the input script (or the current directory)"
<alsuren> so . isn't actually in your path, only $ dirname `which bzr`
<luks> can't really find the posts
<lifeless> alsuren: that doesn't protect against it :P
<jelmer> Odd_Bloke: hi
<jelmer> Odd_Bloke: that's the no 1 bug for bzr-svn, should be fixed before 1.15
<Odd_Bloke> jelmer: Is there any way I can work around it?
<jelmer> Odd_Bloke: you can comment out the assertion
<jelmer> it should generally be harmless
<Odd_Bloke> jelmer: Cool, thanks.
<alsuren> lifeless: if . isn't in your path, then surely you're pretty safe (sorry, went to lunch)
<alsuren> https://bugs.launchpad.net/bzr/+bug/377243
<ubottu> Ubuntu bug 377243 in bzr "bzr (linux) doesn't handle FAT's limitations (X-bit and symlinks) well. Should behave like on windows." [Undecided,New]
<alsuren> lifeless: can't find the win32 hacks you speak of
<knielsen> I have a --no-trees shared repo (bzr init --no-trees). Is there an option to `bzr branch` to override the --no-trees, eg. the opposite of `bzr branch --no-tree` ? `bzr brancj --tree` doesn't complain about the not documented --tree option, but it also doesn't create a tree?
<knielsen> (I know I can just bzr co afterwards, so not big deal, just wondering if I missed the option)
<jelmer> knielsen: I don't think there is anything like that atm, but I agree it makes sense
<knielsen> ok
<knielsen> Maybe an oversight, since the --tree option is there somehow but seems to do nothing
<knielsen> might be a good starter project to get into the code ;-)
<jelmer> knielsen: Yeah, this might be a trivial one to fix
<pst555> i wonder how i could accomplish something like repo1/lib where lib being a link to repo2
<pst555> is a bzr co lib inside repo1 and then a bzr link-tree the right thing to do?
<rocky> jelmer: care to elaborate on "dpush" ? :)
<jelmer> rocky: what about it?
<rocky> just trying to understand it
<jelmer> rocky: it just pushes into a foreign vcs (such as svn) losslessly (i.e. what can't be represented in that VCS is lost)
<rocky> ah metadata can be loss
<LarstiQ> hmmmm
 * LarstiQ wonders about a /dev/null foreign vcs
<Jesse> good evening london
<Jesse> hi?
<jesse_1> hi
<luks> hi
<jesse_1> is it possible to configure bazaar to use a username for ssh to certain hosts?
<jesse_1> i tried authenticantion.conf
<jesse_1> but bzr still uses the $USER value
<luks> I don't know, but on unix with openssh you can use ~/.ssh/config
<jesse_1> aha
<jesse_1> dumb me, i thought everything's configured in bzr
<jesse_1> i am still confused why authentication.conf didn't work
<jesse_1> i am using private key for sftp, but am tired of typing my username in the url
<jesse_1> so i put a section in my auth conf
<jesse_1> with scheme, user & host
<darkhole> Hi everybody...
<darkhole> I need some help, about Eclipse+Bzr
<darkhole> ??
#bzr 2009-05-17
<AfC> Wow. Running `bzr viz` results in Bazaar crashing with a DBus error. That's great.
<lifeless> meep
<AfC> I didn't know bzr-gtk needed DBus to operate. {shrug}
<AfC> DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 0
<AfC> Ah
<AfC> from bzrlib.plugins.gtk import seahorse
<AfC> thence
<AfC> crypto = dbus.Interface(bus.get_object(BUS_NAME, CRYPTO_PATH), ...
<AfC> "neat"
 * AfC wonders what to do about it.
<AfC> If I had to guess, I'd speculate it's ongoing wreckage from the Python 2.5 to 2.6 upgrade.
<AfC> but we'll see
<AfC> Bug filed
<luke-jr> AfC: dbus is considered a standard component of any desktop system
<luke-jr> I don't think you'll get much progress trying to break that dependency unless you do it yourself
<AfC> luke-jr: I wasn't implying I don't have DBus present
<AfC> (I'm a GNOME hacker)
<AfC> luke-jr: I was merely expressing a bit of surprise that bzr-gtk was doing something that goes down that particular rabbit hole.
<luke-jr> shrug
<luke-jr> as far as I'm concerned, GTK sucks and has no place on my systems, so I can't say I'm surprised
<luke-jr> KDE 4 sucks too, so here's hoping GNOME 3 is Qt4
 * luke-jr ponders trying to make C bindings for Qt to encourage such a road.
<jelmer> AfC: bzr-gtk doesn't need DBus, it will use it if it's available though (to communicate with seahorse)
<AfC> jelmer: sure
<AfC> jelmer: that's what I'm inferring
<AfC> jelmer: the stack trace is at https://bugs.launchpad.net/bzr/+bug/377476 if you're interested
<ubottu> Ubuntu bug 377476 in bzr "bzr visualize crashed with DBus error" [Undecided,New]
<AfC> what puzzles me a bit is that after (fake) merging that branch to another the crash doesn't happen
<AfC> so I'm really at a loss to say what's up. I also largely expect that it's something inconsistent and transient on my system, but again, no idea what
<jelmer> AfC: fwiw I can't reproduce it with either but I'm on Debian (still python2.5)
<AfC> jelmer: ok
<AfC> jelmer: that's useful to know. I'll assume it's something local for now
<AfC> jelmer: thanks
 * AfC goes to find a coffee
 * jelmer goes to find more beer
<mwhudson> Peng_: you have quite a few loggerhead branches on the go
<mwhudson> Peng_: how many of them are aimed at being merged into trunk in the end?
<Peng_> mwhudson: Yeah, I know. The "cheezum" ones are the branch I run on my website, which isn't intended to be merged.
<Peng_> mwhudson: The others, ehh.
<Peng_> mwhudson: Want me to make a list? :D
<mwhudson> well, just curious really
<Peng_> mwhudson: FWIW, here's a list explaining them: http://paste.pocoo.org/show/7dCXpn7r0mCOoKejNiRM/
<Peng_> And I'll land that branch in a second.
<mwhudson> Peng_: thanks
<mwhudson> Peng_: i'd say, just fix the pep8 stuff as you go
<Peng_> I feel bad about spamming "bzr log -n 1" with it.
<GPHemsley> Bazaar is good with branches and tags, right, (allegedly) unlike Mercurial?
<Peng_> Um.
<Peng_> I wouldn't say one is better than the other, just different.
<Peng_> Mercurial versions the tags (just dumping them in a ".hgtags" file in the working tree), while Bazaar doesn't. There are advantages and disadvantages to both.
<GPHemsley> Peng_: Well, I've heard a lot that Mercurial is bad at branches and tags, and that they shouldn't be used.
<GPHemsley> Perhaps moreso with branches than tags.
<Peng_> Regarding branches, with both bzr and hg, people usually make a new clone for a new branch, instead of supporting git's multiple-branches-per-directory thingy. Hg has some support for that, but it's not perfect; bzr doesn't at all.
<GPHemsley> what about with regard to CVS/SVN?
<Peng_> Who cares about cvs and svn? :D
<GPHemsley> well, I want to replicate CVS's method... minus the politics ;)
<GPHemsley> method of branching and tagging, that is
<GPHemsley> I should probably elaborate
<Peng_> Ah. I have just about zero experience with CVS.
<GPHemsley> oh
<GPHemsley> well
<GPHemsley> I can explain what I want, and you can tell me if Bazaar does that
<Peng_> OK, probably.
<GPHemsley> FIrst off, I'll be using the centralized repository method
<GPHemsley> I want to be able to branch at a point of release (0.1.0) to continue the latest development on the main branch, while still being able to make maintenance releases on the side branch (0.1.1, etc.)
<GPHemsley> I'd also like to be able to tag each release as it happens
<GPHemsley> on whatever branch it happens on
<GPHemsley> Peng_: It seems fairly straightforward, and it's easy on CVS, because there's no distributed part to worry about. Can it work with Bazaar?
<Peng_> GPHemsley: Sure, or hg. That's pretty basic stff.
<GPHemsley> Peng_: Well, I'm not considering Hg for this. I'm just trying to make sure switching to Bazaar is a safe thing to do for what I want.
<GPHemsley> I'd much prefer to use Bazaar. I just want to make sure it does what I want.
<Peng_> Okay. It does.
<GPHemsley> Oh, and, if it matters, I'll be stuck with 1.10.
<Peng_> One thing to note is that cherrypciking between branches isn't very easy to do.
<GPHemsley> Meaning what?
<Peng_> Well, I mean, you *can* do it, but it won't reflect the history.
<Peng_> GPHemsley: Branch A has revisions 1, 2, and 3. Then you branch off branch B, and commit revisions 4 and 5. Then you want to merge revision 5 back into branch A.
<GPHemsley> so branch A would lose 4 and 5 history?
<Peng_> GPHemsley: Err, revisions 4 and 5 were supposed to be on branch B, but I guess it works either way.
<GPHemsley> right, that's what you said. I'm just trying to figure out what gets lost.
<Peng_> GPHemsley: Nothing is /lost/ on the original branch, but the branch you cherrypick into won't automatically get the commit message and whatnot.
<Peng_> Ehh, I suck at explaining things.
<Peng_> Anyway! What you want is possible in bzr.
<GPHemsley> heh, no problem
<GPHemsley> So, can you merge in just a single changeset?
<GPHemsley> or revision? or whatever they're called here?
<Peng_> GPHemsley: Yes, but it won't be as smooth as merging in everything. It's basically equivalent to doing a diff, patch and making a new commit.
<GPHemsley> right
<GPHemsley> so no worse than CVS
<GPHemsley> but better in the sense that you *don't* have to do three commands ;)
<fullermd> To say nothing of actually using CVS  ;)
<GPHemsley> fullermd: Heh. Well, I switched from CVS to SVN, but I really don't like SVN. And I've been finding myself yearning for Bazaar commands.
<GPHemsley> So who would like to volunteer to walk me through the conversion process? :)
<GPHemsley> Oh, and I'm doing all of this on Sourceforge, BTW
<GPHemsley> fullermd: You up for the challenge? I know you've been helpful to me in the past. :)
<Peng_> cvs to bzr or svn to bzr?
<GPHemsley> SVN
<Peng_> bzr-svn.
<GPHemsley> I already did CVS to SVN a while back
<GPHemsley> link?
<Peng_> GPHemsley: http://bazaar-vcs.org/BzrForeignBranches/Subversion
<GPHemsley> k, thanks
<GPHemsley> So, will I have to use the version specifically for 1.10, or can I use the latest version?
<Peng_> GPHemsley: You'll have to use an older release of bzr-svn.
<Peng_> Upgrading bzr would really be better.
<GPHemsley> Do you know why that is? It seems silly.
<GPHemsley> And I can't upgrade. Like I said, I'm using SourceForge.
<mwhudson> GPHemsley: you can use a newer bzr to do the conversion
<mwhudson> then push it to sf just fine
<GPHemsley> mwhudson: Oh, OK, so it's for the version that I have on my computer?
<mwhudson> right
<GPHemsley> oh, then that's easy
<Peng_> FYI (since I don't want my grepping to go to waste!), the last version compatible with bzr 1.10 is 0.5rc1.
<GPHemsley> heh, thanks
<GPHemsley> it's on the page, though ;)
<Peng_> Oooh. I skipped that section of the page. I'd put my foot in my mouth, but it isn't very clean.
<GPHemsley> heh, I wouldn't recommend that then
<Peng_> Oh well, it was still fun to figure out. :)
<GPHemsley> was that in the source code or something?
<Peng_> Yeah.
<GPHemsley> cool
<lifeless> Peng_: you should try washing your mouth sometime; then it will be clean
 * fullermd has never done svn -> bzr.
<fullermd> Facing up to the time to move to svn was what made me choose bzr in the first place   :p
<GPHemsley> heh
<Peng_> lifeless: I know. My dentist is going to murder me. Or she'll charge me a lot of money and be happy, I guess.
<fullermd> To say nothing of your podiatrist.
<GPHemsley> Alright, so I need subvertpy for this
<GPHemsley> I try to install with via MacPorts and it tells me it doesn't know where my svn development files are
<GPHemsley> And, well, neither do I
<Peng_> They might not be installed.
<GPHemsley> where do I get them?
<lifeless> presumably via macports
<lifeless> I believe we have .dmg installers for bzr which include bzr-svn though
<GPHemsley> lifeless: Kindly point
<GPHemsley> mwhudson: What format will bzr-svn use? Will it be compatible with the server's 1.10?
<Peng_> GPHemsley: Yes.
<GPHemsley> OK... but I'm still having trouble with subvertpy
<GPHemsley> where would the SVN development files be?
<GPHemsley> could the problem have to do with what I used to install SVN?
<GPHemsley> ugh... I can't set the environmental variable for some reason...
<GPHemsley> (I found the files)
<AfC> Why does it say "bzr+ssh" but "<bzrlib"? (ie, what's with the extra '<' ?)
<AfC> [actually, I'd like to know why it bothers to say this at all, but whatever]
 * GPHemsley wonders what AfC is talking about
<AfC> GPHemsley: bzr's current iteration of text presented while network operations are underway
<GPHemsley> ah
 * fullermd doesn't recall any bzrlib in the output.
<Peng_> AfC: It displays < and > to show if it's currently reading from or writing to the network.
<GPHemsley> Any idea why the subvertpy script is not picking up my environmental variables?
<GPHemsley> the install script, that is
<GPHemsley> (via MacPorts' port command)
<GPHemsley> Peng_: Any idea?
<lifeless> GPHemsley: http://bazaar-vcs.org/Download
<GPHemsley> that's what I use
<GPHemsley> bzr-svn is not included
<lifeless> oh, ok
<AfC> Peng_: no, that '<' and '>' are separate, also appearing on the line
<AfC> Which is why I'm asking
<lifeless> AfC: pastebin :P
<davidstrauss> The date in NEWS.html for 1.15rc1 is wrong.
<davidstrauss> Simple copy/paste error.
 * davidstrauss goes to bed now.
<AfC> lifeless: I'll try.
<AfC> [/                  ] <bzrlib <      1KB     0KB/s |
<GPHemsley> ugh.... I can't even compile subvertpy by hand because it fails with a different error...
<GPHemsley> collect2: ld returned 1 exit status
<GPHemsley> lipo: can't open input file: /var/tmp//ccJpbdpb.out (No such file or directory)
<GPHemsley> error: command 'gcc' failed with exit status 1
<GPHemsley> oh, hmm...
<GPHemsley> looks like there's a bigger problem
<GPHemsley> ugh, I don't know what to do
<GPHemsley> everything I try errors out one way or another
<crisb> any loggerheads around?
<Peng_> crisb: At least 0.2. Sometimes. Why?
<crisb> just trying to do serve --http on the trunk - it blows up because BranchesFromTransportRoot has an arg missing, added that arg in and now it just says no such option --http!
<Peng_> crisb: What's the missing arg?
<Peng_> crisb: Oh, I see. Hmm.
<crisb> peng_: a config object.  used the serve-branches code as a copy
<Peng_> crisb: Right.
<Peng_> Darn. Now not only do I have to test start-loggerhead, but plugin mode as well.
<crisb> peng_: dont think LoggerheadConfig() works in this situation which is what I did
<Peng_> crisb: The problem is that the config object parses the command line arguments, but it doesn't know what to do with "serve --http".
<crisb> ahah
<Peng_> So now I've accidentally broken both start-loggerhead and "serve --http". Nice! :D
<crisb> ;)
<crisb> shall I file it?
<Peng_> crisb: Sure.
<crisb> peng_: number 377551 is born
<Peng_> crisb: Thanks.
<pmezard> what's the best way to detect lightweight checkouts programmatically, with maximum compatibility across bzrlib versions? is it what bzr info does?
<Peng_> crisb: I have a fix up in a branch at http://bzr.mattnordhoff.com/bzr/loggerhead/serve-http-config -- does it work for you?
<crisb> Peng_: sorted, yep looking great.
<Peng_> crisb: It works? Really? Awesome. :)
<crisb> ;) handy now I can package it for mandriva as a plugin
<max_r> hi all. I have a question: I saw that you are developing new serialization format to replace XML called RIO. Why aren't you using something already implemented/stable/fast like google protocol buffers?
<jelmer> max_r: Extra dependency in Bazaar, extra build complexity (need to compile .proto files)
<jelmer> max_r: Also, RIO is already used in other places in Bazaar
<jelmer> max_r: It just wasn't fast enough yet
<Laney> is there a way to "merge" a commit with the current one without doing uncommit/commit?
<amanica> Laney: you can't change a commit
<Laney> ok
<max_r> jelmer: I see thanks
<alefteris> hi all! lets say I want to create a new branch but bring only a single file, together with its history, is it possible? Or I have to branch the usual way and then delete the files I don't need?
<davidstrauss> alefteris: Are you on bzr 1.14?
<alefteris> yes
<davidstrauss> alefteris: make a new directory, move the file there, and then bzr split that directory
<davidstrauss> alefteris: This new directory should be in your existing tree
<davidstrauss> alefteris: (and added)
<davidstrauss> alefteris: That will turn the new directory into a distinct bzr tree that keeps all history for that file.
<davidstrauss> alefteris: You may want to branch before doing the moving and splitting, just to avoid messing up your current branch.
<alefteris> so make a new dir, add it, move the file in there, then bzr split this dir, correct?
<davidstrauss> alefteris: Yes.
<alefteris> davidstrauss, move the file manualy or through bzr?
<davidstrauss> alefteris: And the split dir will be its own tree/branch with all history for that file pulled in.
<davidstrauss> alefteris: through bzr
<alefteris> ok thanks a lot
<alefteris> all those different branch formats are meant to provide different options for different needs or newer ones are supposed to replace the previous ones?
<alefteris> davidstrauss, I get a branch format error when doing the split, whats the required format that i should upgrade to?
<davidstrauss> alefteris: you need a rich root format
<alefteris> 1.14?
<davidstrauss> alefteris: any rich root format will work
<davidstrauss> alefteris: bzr upgrade --1.9-rich-root
<davidstrauss> alefteris: I'm still wary of 1.14's format
<davidstrauss> alefteris: There are issues with it being fixed in 1.15+
<alefteris> davidstrauss, can you tell me anything about the previous question or there is any doc, explaning the various bzr formats?
<davidstrauss> alefteris: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#upgrade
<davidstrauss> alefteris: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#split
<davidstrauss> "This command will produce a target tree in a format that supports rich roots, like 'rich-root' or 'rich-root-pack'."
<alefteris> davidstrauss, I mean this one: all those different branch formats are meant to provide different options for different needs or newer ones are supposed to replace the previous ones?
<davidstrauss> alefteris: The newer ones replace the older ones
<davidstrauss> alefteris: Eventually old ones are obsoleted
<davidstrauss> alefteris: The current default format is 0.92
<davidstrauss> alefteris: Details are all here: http://doc.bazaar-vcs.org/latest/developers/development-repo.html
<alefteris> davidstrauss, how come then that the default format is still so old? the newer ones are not so stable/tryed yet?
<davidstrauss> alefteris: 0.92 is compatible with bzr >=0.92. Other versions require newer releases.
<davidstrauss> alefteris: We're waiting for newer releases to become more widespread before upping the default version. It's not a question of stability.
<alefteris> so it's basicaly in order to have branches compatible with older version of bzr in servers etc?
<davidstrauss> alefteris: yes
<alefteris> cool thanks a lot david for your answers :)
<davidstrauss> alefteris: sure
<dlee> I do net admin for a small office of Windows users, but since I write a number of utilities in Perl/Python that use Unix-like tools, I have set up a central way of running such tools under Cygwin without having to install Cygwin on each workstation.
<dlee> Question:  Is there anything different in the Windows (stand-alone I suppose) Bazaar build, versus building from the tar, that would make it better than running the source Bazaar under Cygwin Python 2.5?
<dlee> I'm mostly thinking of filename casing and EOL...
<lifeless> I'm not aware of any patches in the code
<lifeless> we do check platform forsome stuff, and IIRC cygwin shows up as a unix platform in python
<dlee> I had problems in older Bazaar versions when, say, trying to version file sets on Windows machines when people saved with inconsistent name casing, but I think that even happened under Windows bzr stand-alone back then.
<dlee> sys.platform == 'cygwin'
<cr3> bzr is returning an assertion error for a file which was removed and later added again: bzr: ERROR: exceptions.AssertionError: name u'system_manager.py' already in parent
<cr3> this is kinda preventing me from committing or doing anything else with my branch :(
<cr3> meh, I just killed my other branch and rebranched
<lifeless> dlee: yes, we should handle that better now
<dlee> lifeless:  Wonderful!  Now just deciding whether to jump to 1.14.1 or wait for 1.15.
<Peng_> beuno: ping
<Peng_> cr3: fwiw, worst case, you probably just have to kill .bzr/checkout and run "bzr checkout" again. You don't even have to lose the files in the working tree.
<cr3> Peng_: cheers
<Peng_> beuno: unping. I sent an email instead.
#bzr 2010-05-17
<igc> morning
 * fullermd waves at igc.
<igc> fullermd: hi
<thumper> igc: hey
<thumper> igc: how are you feeling today?
<igc> hi thumper
<igc> thumper: I'm feeling good today thanks
<thumper> cool
<thumper> igc: I'm getting closer to announcing 0.1 of wikkid
<thumper> igc: but hit a line ending snag
<thumper> igc: how much do you know about the bzr line ending magic?
<igc> thumper: a fair amount
<thumper> it seems that http posts send '\r\n'
<thumper> and I want to normalise the http post to whatever the current file is using
<thumper> is there bzrlib magic that could help?
<igc> thumper: probably not
<thumper> hmm.. ok
<thumper> I'll work on it tonight I think
<igc> thumper: we don't support branch-specific rules yet so ...
<thumper> igc: where in bzrlib is the line ending work?
<igc> newline handling is defined by each user in their ~/.bazaar/rules file
<thumper> I may nick some code
<igc> thumper: bzrlib/filters may help?
<thumper> thanks, I'll look later
<thumper> hi lifeless
<thumper> lifeless: home?
<lifeless> thumper: yes
<lifeless> just walked in ze door
<thumper> and straight onto irc?
<lifeless> well, it is a work day
<lifeless> clothes into laundry pile
<lifeless> laptop on charger, fire up the standard work env
<lifeless> I doubt I'll get all that much done 'today' though
<igc> hi lifeless
<lifeless> hiya
<lifeless> igc: are you home now?
<igc> lifeless: yes indeed
<igc> lifeless: and back at work at last
<lifeless> cool
<lifeless> is it just me, or is the emacs-editor-locking thread a little high in the handwavy, little low in the read-whats-been-written-about-the-guts stakes?
<spiv> lifeless: it's not just you
<spiv> I think my main work for the day will be making sure I take cold & flu pills regularly...
<igc> hi spiv
<spiv> Hey igc
<lifeless> spiv: ubuflued?
<spiv> lifeless: mildly, I hope.
<spiv> It feels like something that a good night's sleep might fix.
<Peng_> With bzr-search indexing committers and stuff, does that mean we have to delete and recreate the indexes or something?
<Peng_> Or run "bzr index" again or...?
<Peng_> (Although, with bug #580534, that might not work anyway...)
<ubottu> Launchpad bug 580534 in bzr-search "ValueError indexing with 2a and bzr.dev trunk" [Critical,Triaged] https://launchpad.net/bugs/580534
 * igc lunch
<mwhudson> igc: great to see you back online again!
<lifeless> Peng_: delete the index
<Peng_> lifeless: Do you know where #580534 fits in? I don't want to delete everything and then discover I can't recreate it.
<lifeless> bug 580534
<ubottu> Launchpad bug 580534 in bzr-search "ValueError indexing with 2a and bzr.dev trunk" [Critical,Triaged] https://launchpad.net/bugs/580534
<lifeless> bah caches
<lifeless> its fixed
<lifeless> it was broken by the index reordering stuff in trunk
<Peng_> Oh, awesome.
<igc> hi mwhudson: thanks!
<lifeless> ok, halt(); am naffed
<igc> bbl
<vila> hi all
<vila> fullermd: ping
<vila> fullermd: gmp conflict while trying to upgrade freebsd8 (gmp-5.0.1 with libgmp-4.3.2 involved for py-pycrypto and bazaar-ng)
<vila> fullermd: nm, pkg_delete -f libwhatver ; pkgdb -F ; portupgrade py-pycrypto appears to do the trick, sanity check welcome though
<guijemont> hi
<guijemont> are there bzr-gtk people here?
<jelmer> guijemont: hi
<jelmer> yep
<guijemont> cool
<guijemont> I've been scratching an itch lately
<guijemont> that is, I want bzr viz to have the history graph "collapsed"
<guijemont> like qlog does
<guijemont> am starting to have something working
<guijemont> though not finished yet
<guijemont> dunno if you would be interested in integrating such a patch when it's finished
<jelmer> Yeah, we'd definitely be interested in something like that
<guijemont> I found myself refactoring things quite a bit in the TreeModel
<jelmer> though I would encourage you to move the logic to determine those graphs from qbzr into bzrlib
<jelmer> and then use that logic from both qbzr and bzr-gtk
<guijemont> yeah, would probably be clever
<guijemont> do you know how the graph is generated in qbzr?
<jelmer> you might also want to talk to garvdm
<jelmer> he is the author of that code in qbzr and is also interested in moving the qbzr logic up
<guijemont> haven't lkooked at the code, but it's much faster to start: does it generate the graph on the fly when expanding a node ?
<guijemont> oh, and also, are there code standards to respect in bzr-gtk?
<guijemont> would that be the same as the ones for bzr?
<mgz> vila: did we mess something up with babune? because it looks like everything *but* windows is deadlocking in bt.per_repository now
<mgz> hey gary.
<jelmer> guijemont: basically the coding standard would be the same
<vila> mgz: no idea, I'm currently upgrading a lot of various things and haven't investigated yet
<jelmer> speaking ofthe devil...
<vila> mgz: and congrats for your new and shiny and easy to recognize nick :-P
<mgz> ehehe :)
<GaryvdM> Hi mgz  (are you Martin GZ?)
<mgz> yeah, vila made me get a non-ridiculous nick
<GaryvdM> Oh - ok
<GaryvdM> Hi vila, jelmer
<vila> mgz: but to answer to your first question, I don't think we've messed up anything, most probably an unfortuante coincidence
<jelmer> hi vila, GaryvdM, mgz
<vila> hey jelmer, GaryvdM  :)
<vila> mgz: but if you feel otherwise, I'm all ears
<mgz> ehehe
<guijemont> yeah, hi .*
<guijemont> GaryvdM: so, are you the one who knows about the visual graph generation stuff in qbzr?
<mgz> I looked at the history and didn't see anything likely, but yell if you want me to try poking anything here
<vila> guijemont: wow, yeah, there is definetly interest for that and GaryvdM's brain is the one you want to suck from :)
<GaryvdM> guijemont: I wrote the code...
<vila> mgz: I'd like to setup debug-windows to a branch of yours so you and modify it so you can add a test.this file with the tests you're interested in instead
<guijemont> if ppl want to play with where I'm at (quite functional) for collapsing in bzr viz, it's at lp:~guijemont/bzr-gtk/collapsed-merges
<GaryvdM> vila: If I want to run some test code in a subprocess, should I create a hidden command, and have a blackbox test, or is there an easier way.
<vila> mgz: AIUI we now have ~260 new failures we didn't see before
<guijemont> GaryvdM: does it generate the graph info on the fly, or is it just better than bzr viz to precompute that?
<mgz> yeah, I put a message in a bug about that. fixing the reporting stuff means we're now seeing them all.
<vila> GaryvdM: ECONTEXT, don't you enough support in qbzr with qrun or something ?
<mgz> vast majority are thread-leak related, makes me wonder if your chunking of tests into small groups workaround has slipped?
<GaryvdM> guijemont: Will respond in a sec
<vila> guijemont: I think GaryvdM tested qlog with some mysql branch, you should try and see if you get comparable results
<mgz> put up branches for some of the others that I can repo here.
<vila> mgz: leaks coming back is what I fear the most
<GaryvdM> vila: no. qrun is a dialog for running a arbertery bzr command,
<GaryvdM> vila: qlog is to big
<guijemont> vila: well, for now, my changes in viz are purely graphical, it's still as slow (or maybe slower) as before
<vila> mgz: but thinking about hudson hanging on zombies made me realized I should file a bug there as that's clearly a blocking one
<GaryvdM> vila: I want a test for the threading infrastructure, not the threading infrastructure and qlog. :-)
<vila> mgz: (not that I suspect zombies right now, but you never know with those undeads...)
<GaryvdM> guijemont: When I wrote qlog, I refactored the code so that the logic could easily be reused in bzr-gtk, and others.
<vila> GaryvdM: hmm, but do you still need to use bzr to launch your main then ?
<GaryvdM> vila: yes, because it needs to know how to import qbzr
 * vila hugs GaryvdM for thinking about reuse
<vila> GaryvdM: ouch, ok, I see
<guijemont> GaryvdM: yeah, jelmer was talking about the idea of merging it in bzrlib
<guijemont> GaryvdM: do you know what still needs to be done to make that happen?
<GaryvdM> guijemont: I plan to move this logic into bzrlib, but I'm going to need a better test suit.
<vila> GaryvdM: then an hidden command is probably your best bet.... can you lazy register a test command ?
<vila> GaryvdM: do you start to see why you may want to address the root bug instead of going with a work-around :-} :-/
<mgz> vila: I'm going to do a complete test run on my machinary just to confirm that nothing on trunk has affected thread-problems
<guijemont> GaryvdM: ok. I think I will have a look at that code and try to make bzr-gtk work with it in the meantime
<GaryvdM> vila: Yes - but fixing the root bug is hard
<GaryvdM> guijemont: The relevant code it the qbzr branch is lib/loggraphprovider.py
<GaryvdM> *in the
<guijemont> ok
<vila> GaryvdM: may be you can register the command just before launching the test subprocess and avoid polluting the name space ?
<vila> vila: Did I really just suggest such an idiotic idea ?
<GaryvdM> vila: but that would need to happen in the subprocess,
<guijemont> is qbzr at lp:qbzr?
<guijemont> I guess so, seems to work
<GaryvdM> guijemont: yes
<GaryvdM> guijemont: There are 2 qbzr imports in that file that we would need to do something about.
<GaryvdM> LogGraphProvider is a base class, and there is a specific qbzr LogGraphProvider in lib/logmodel.py
 * GaryvdM looks at lp:~guijemont/bzr-gtk/collapsed-merges
<guijemont> GaryvdM: I barely touched the graph generation stuff  though
<guijemont> the code didn't look like it wanted to be changed (it's basically one huge function)
<mgz> I do wonder whether it might not be easier to just rewrite all client-server tests to use a subprocess server, which can just be killed on teardown
<vila> guijemont, GaryvdM : If you manage to share the exact some code, there will be a strong case to include it in the core
<guijemont> I think I'll try to go in that direction
<vila> mgz: easier, may be (there are a few tests that directly talk to the server though) but the performance will surely suffer
<guijemont> might find bugs in the process, who knows
<mgz> can't perform worse than a hang ;)
<vila> mgz: hehe, hangs are generally due to uncaught exceptions which is the first thing I want to address
<mgz> selftest-freebsd looks stuck to me, probably needs killing.
<vila> mgz: yeah, as soon as I get a free hand :)
<vila> mgz: it was my last hope for a blue icon :-/
<GaryvdM> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~guijemont/bzr-gtk/collapsed-merges/". :-(
<vila> mgz: I'm about to upgrade to lucid and will come back later
<guijemont> hmm, did I mistype it?
<guijemont>     push branch: bzr+ssh://bazaar.launchpad.net/~guijemont/bzr-gtk/collapsed_merges/
<guijemont> haha
<guijemont> _ not -
<guijemont> sorry
<GaryvdM> ok - np
<jelmer> vila: quickest upgrade ever!
<GaryvdM> jelmer: vila is offline
<vila> hehe, isn't it ? lucid rocks !
<GaryvdM> Oh wow back allready!!!!
<vila> GaryvdM: I rejoined from my laptop while upgrading the desktopn :)
<GaryvdM> Oh - very pro...
<vila> ...and will soon update babune too
<vila> GaryvdM: hehe, the joy of versioned setups :)
<mgz> dammit, testtools change has borked my setup again.
<mgz> now seems like there's no way at all of getting a stack from an expected failure
<GaryvdM> guijemont: fyi qbzr/lib/loggraphprovider.py was derived from bzr-gtk/branchview/linegraph.py, but has change substantially.
<guijemont> ok
<guijemont> to be honest, I don't like much the code in bzr-gtk/branchview/linegraph.py though
<vila> mgz: are you sure stack backtraces are available to testtools ? I would have tought that only the tests themselves could get them, and even that...
<guijemont> a huge function with tuples everywhere, and variable names that tend to look like each other
<vila> wow, first time ever I'm able to get gdm working on gentoo...
<GaryvdM> guijemont: Sorry - I'm partially to blame for that. loggraphprovider.py is better at that.
<mgz> they're not really, I've had to add hacks to get them back unmangled
<mgz> there's a 'wishlist' bug on testtools to restore things to how they were before
<GaryvdM> guijemont: LogGraphProvider loads a lot of data at load and caches it. Each time you colapse and expand in qlog, the whole graph layout is recomputed, but because of the caches, that is very fast.
<guijemont> ok, that is the secret
<GaryvdM> guijemont: These are the entry points for LogGraphProvider:
<GaryvdM> open_branch or open_locations
<GaryvdM> load_graph_all_revisions or load_graph_all_revisions_for_annotate
<GaryvdM> Those are called on load^
<vila> mgz: an old or a recent bug ?
<GaryvdM> compute_graph_lines is call each time you collapse or expand.
<GaryvdM> guijemont: ^
<mgz> vila: old, from r4920 when testtools was merged and broke a bunch of things for me
<mgz> I still have bugs to file on other issues too.
<vila> mgz: ok, may be you should start with that then ? :-/
<guijemont> GaryvdM: ok
<guijemont> will try playing a bit with it
<guijemont> after having cleaned the flat, that is...
<GaryvdM> guijemont: Good luck. Fell free to bug me when I am on irc, or mail me on either the bzr, bzr-gtk or qbzr mailing lists
<guijemont> ok, thanks
<GaryvdM> guijemont: Btw qlog is missing 2 features that bzr-gtk has:
<GaryvdM> guijemont: a Progress bar
<GaryvdM> guijemont: and filtering revisions from the command line.
<mgz> selftest related - am I mad, or does --strict do absolutely nothing?
<mgz> I want to see a real traceback for this expected failure, and can't work out a way to make bzr let me
<nessita> hello everyone! I need help on the following: I have a branch of a project X where I need to moved out a subfolder to another subfolder in project Y. I've tried bzr split but I can't push the splitted folder into a branch subfolder. Any ideas how can I workaround this? (I need to preserve the history from the source project)
<nessita> this is basically what I need to do https://pastebin.canonical.com/32341/
<nessita> oops, that link is not open to everyone, this is public: http://nessita.pastebin.com/nmRpjHXa
<vila> mgz: sry to have missed that earlier, but why do you want to see a traceback on an expected failure ? The test pass (its failure is expected) so nothing should be output
<vila> mgz: may be you *had* tracebacks when *trying* to handle the expected failure and things are now working correctly ?
<mgz> ha, you ask just as I have bent testtools to my will
<jelmer_> :-)
<mgz> I want it because there's some useful information in there, particularly what the failure is exactly and what line it came from
<mgz> so, the code I needed was:
<mgz> if _post_testtools_apocalypse:
<mgz> 	test.addOnException(self._set_real_exc_info)
<mgz> and:
<mgz> def addExpectedFailure(self, test, err=None, details=None):
<mgz> 	if err is None:
<mgz> 		err = getattr(self, "_real_exc_info", None)
<mgz> 		olderr = err[1].args[0]
<mgz> 		if isinstance(olderr, tuple) and len(olderr) == 3:
<mgz> 			# This is the knock-on ExpectedFailure, but it's passed the
<mgz> 			# original exc_info for some reason, so get that back
<mgz> 			err = olderr[0], olderr[1], err[2]
<vila> mgz: hmm, this is really ugly, it may be correct though, I have no idea :D
<vila> what is post_testtools_apocalypse ?
<mgz> well, with a few more pokes looks like I've finally got full test run going
<mgz> will give result when I get back in an hour and a half
<mgz> ^just a check to see if we're post r4920 or not, my tests for this code run it against multiple bzrlib versions to make sure I don't regress
<vila> ho, ok
<vila> mgz: I may not be there anymore in far less than an hour :) But if you post to the list, I will certainly read
<mgz> will do if I find anything interesting, otherwise I'll just file bugs
<mgz> (my aborted run earlier got thread leaks as normal, but no "failed to start thread" stuff, so I think we've not regressed that, so probably an environment change causing it rather than code)
<mgz> right, gotta go.
<fullermd> vila: Yes, gmp rename.
<vila> fullermd: wait... were you *sleeping* ???? :-P
<vila> fullermd: thanks for the confirmation ;)
<vila> err, the *explanation*
<vila> fullermd: as you can guess, I shot in the dark hoping for the best :)
<fullermd> I wasn't sleeping.  I was just resting my eyes.
<vila> an thinking so deeply you were making some weird noise, yeah, I do that too, I don't understand why they call it snoring...
<fullermd> I know!  My, uh, engine is just a little imbalanced when it's running that hard!
 * fullermd nods at himself.
<Lor> Is there a simple way to make a merged-in branch the mainline?
<Lor> The non-simple way would be to just merge in the other direction, but this might require setting up another branch locally.
<GaryvdM> Lor
<GaryvdM> Lor: Unfortunatly not.
<GaryvdM> Lor: There has been talk of a "land" command though.
<Lor> Right. The problem is how to merge stuff into the true mainline from a feature branch. A merge + push will turn the feature branch into the new mainline.
<Lor> A pqm would of course solve this, but it's pretty heavyweight.
<maxb> Yes. It's rather annoying. You'll have to have another branch locally
<Lor> It's not really a big deal, of course.
<Lor> Branches are conceptually a bit heavyweight, though.
<Lor> I'm not sure if it's a good idea to require them all to have a separate directory with its own .bzr.
<Lor> I'd appreciate fuller support for lightweight heads (after all, a branch is really just a head) like the ones loom uses.
<GaryvdM> sigh - I have way to many in progress qbzr branches ...
<nessita> anyone around with knowledge in bzr-fastimport plugin?
<mgz> oooh, good news, I got the hang, and the thread problems
<mgz> and Alexander's diff problems with newlines
<mgz> hang in bt.test_lockable_files.TestLockableFiles_RemoteLockDir.test_break_lock but that's probably just going to be any unlucky smartmedium using test
<mgz> okay, the only revs between my last good full run and this in the blame for bzrlib/tests/test_smart.py are r5223 and r5232
<mgz> hm... both look reasonably innocent. will try backing out Robert's change and see if that helps.
<jelmer> nessita: you probably want to talk to igc when he's around
<nessita> jelmer: thanks! I'll try ping him
<mgz> hey Alexander.
<mgz> I think I understand those test failures you were getting with merges
<mgz> they were all (diff3) paramatised ones right? I see them now, so will file a bug and patch later.
<bialix> hey mister
<bialix> will be nice, thanks
<bialix> how's your trip back to home?
<bialix> mgz: ^
<mgz> a lot less stressful than the one over :)
<bialix> :-)
<bialix> you finally found the right nick ;-)
<mgz> blame vila!
<bialix> :-D
<bialix> my home internet is sooooooo sloooooooooooow after uds one :-(
<mgz> my home internet is very fast compared to UDS. terrible latency there, had to wait till someone had left their laptop unattended ;)
<bialix> :-)
<GaryvdM> bialix: Hi
<GaryvdM> mgz: lol
<bialix> heya
<bialix> GaryvdM: I've missed a good joke?
<GaryvdM> internet was slow for mgz...
<GaryvdM> bialix: ^
<bialix> ah, yes
<bialix> terribly slow
<bialix> GaryvdM: it was true about my hangover
<bialix> I'm trying to talk in English with people here in Ukraine. crazy
<GaryvdM> bialix: Made some progress with the threads branch. Error reporting better, got tests passing, and have push branch to lp.
<GaryvdM> bialix: lol...
<bialix> wow
<Lor> What is the easiest way to get rid of a big file that was accidentally added to a branch and takes inordinate amounts of space in a repository?
<Lor> I know that it is in principle possible to rewrite history and alter the commit that added the file, and then replay everything back.
<LeoNerd> Heh... fun
<LeoNerd> You'll change the commit IDs, and anyone who's branched from you since then will shoot you
<Lor> This is for private development, so that's not a huge problem.
<LeoNerd> search for "bzr obliterate"
<Lor> But still, it would be even better if it was just possible to tell the repository to get rid of the text of that file.
 * LeoNerd runs away
<mgz> okay, not r5222 at fault, will probably just do 5222 + (5222-5200)/2 next
<mgz> *r5223
<prkos> Hi! How do I get just the source of an application every once in a while but so it's fast to download, I only need it to compile, I won't do dev work on it so I don't need history
<bialix> try `bzr checkout --lightweight`
<prkos> bialix: thanx, what's the workflow with that, I always do it in the same folder, and compile somewhere else?
<bialix> I don't understand\
<bialix> it's like doing `cvs checkout
<prkos> I tried it one before but it compile with some features missing
<prkos> I've read about the lightweight option but it's not easy to understand from a non-dev point of view
<bialix> what is `source of an application`?
<prkos> source code
<prkos> so I can compile the application
<prkos> I'm not sure if that's the tree in bzr?
<prkos> working tree?
<bialix> so you'd better download tarball with the sources
<bialix> working tree, yes, -- it's the files under version control
<bialix> lightweight checkout creates working tree without history
<prkos> is there a bzr command for the tarball source for an application on lp?
<bialix> `bzr export` but I'm not sure about lp
<bialix> there was feature request for loggerhead to add the option: download sources as tarball
<bialix> hey loggerhead devs, are you here?
<prkos> once I do a lightweight checkout, how do I update to get the new code - bzr update?
<prkos> will it only download the source without history as the first time?
<bialix> yep
<bialix> ~~~
<MvG> jam: Are you this week's patch pilot, as the wiki claims?
 * jelmer waves
 * MvG notices the away state of jam
<MvG> jam: Now that you seem to be back from away: are you this week's patch pilot? If so, shouldn't the topic reflect this fact?
* jam 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 | bzr 2.1.1 is out
<MvG> :-)
<jam> MvG: yeah, I'm this weeks pp
<jam> I'm mostly recovering from traveling today, but I'll certainly be giving it some attention this week
<MvG> Happy to hear that.
<MvG> I'll particularly appreciate any comments on my outstanding merge requests.
<MvG> Those about bash_completion plugin.
<MvG> https://code.launchpad.net/~gagern/bzr/bug560030-include-bash-completion-plugin/+merge/23912 was already approved by vila, but will need a second opinion.
<MvG> https://code.launchpad.net/~gagern/bzr/bash_completion-ExecutableFeature/+merge/24951 depends on the former, and might benefit tests beside those for bash_completion.
#bzr 2010-05-18
 * spiv waits for the cold&flu pills to kick in fully
<lifeless> ugh
<spiv> I'm definitely doing much better than yesterday.  I don't seem to actually have a fever anymore, and I got a proper night's sleep.
<spiv> Hooray for ubuflu :/
<mgz> lifeless: re "Where is test_dir being set?", two instances of `self.test_dir = ` in bzrlib.tests both of which are old
<mgz> so I presume the change is something to do with how test methods are put on instances in testtools
<spiv> mgz: oh wow, that's a shorter nick!
<mgz> blame vila!
<igc> morning
<lifeless> hmmm
<mgz> I presume the code was wrong before, but happened to work because no one was checking if the attribute they'd put the directory name in was still a string or whatever
<mgz> didn't look too closely once I'd worked out how easy the fix was
<lifeless> mgz: yeah
 * igc lunch
<nilg> I'm having problems with launchpad since yesterday, anyone else?
<Croepha> can bzr diff compressed files? like can it give intelegable changes between revisions of a docx file?
<spiv> Croepha: not as a builtin feature
<spiv> Croepha: I think it would be possible to write a plugin to do that, or perhaps you could try "bzr diff --using=..." if you already have a tool for producing readable diffs for that file type.
<lifeless> nilg: some details please
<lifeless> Croepha: you can write a plugin to the diff code that examines specific files in a different way
<nilg> lifeless: sorry I works actually
<vila> hi all
<bialix> heya
<igc> night all
<GaryvdM> Hi and Night igc.
<bialix> night igc
<gour> morning
<gour> night igc
<igc> hi GaryvdM, gour (and night)
<gour> #541626 makes bzr-fastimprt unusuable for me
<gour> is it just fastimport's problem or affects bzr aswell?
<bialix> you should say bug #541626
<ubottu> Launchpad bug 541626 in bzr-fastimport "'BTreeBuilder' object has no attribute '_find_ancestors'" [Undecided,Confirmed] https://launchpad.net/bugs/541626
<gour> bialix: thanks
<bialix> our pet bot, good ubottu, take a cookie
 * gour would like to to darcs <---> bzr and use LP
<gour> s/to to/to do
<bialix> tailor?
<gour> i'm not sure it can do incremental import and believe fastimport should be better supported...igc takes care for it
<bialix> perhaps not today
<gour> vmiklos (who wrote darcs part) recommends it over tailor as well
<GaryvdM> bialix: Nudge https://code.launchpad.net/~garyvdm/bzr-explorer/better_tree_filter/+merge/20519
<bialix> at evening, sorry, have to work
<GaryvdM> bialix: Ok
 * GaryvdM looks at 2 qbzr mps
<MvG> Hi there! When will 2.1.2 be released? https://launchpad.net/bzr/+milestone/2.1.2 expects it 2010-04-22, and bug #572098 is really annoying. Yes I could work from a snapshot, but I prefer releases for my production work.
<ubot5> Launchpad bug 572098 in Bazaar "`bzr clean-tree` should not blindly delete nested branch/tree/repo (affected: 1, heat: 6)" [High,Fix released] https://launchpad.net/bugs/572098
<MvG> Got the wrong bug, it's #559436 that's annyoing me personally, but seeing a list of 5 high priority fixes looks like a release might be a good thing.
<Peng_> bug 559436?
<ubot5> Launchpad bug 559436 in Bazaar "AttributeError: 'NoneType' object has no attribute 'get_config' (affected: 4, heat: 30)" [High,Fix released] https://launchpad.net/bugs/559436
<Peng_> Oh.
<MvG> Means whenever I switch a branch with local modifications, I get a backtrace... :-(
<MvG> s/branch/tree/
<GaryvdM> vila: Who is the rm for 2.1.* ?
<vila> GaryvdM: hmm, I've lost track here, was it igc or poolie ?
<GaryvdM> vila: jam did 2.1.0. I can't find the release announcement for 2.1.1
<vila> GaryvdM: yeah, so poolie was RM for 2.1.1, where are you searching for the annoucement ? lp ?
<GaryvdM> vila: yes
<vila> GaryvdM: hmm, he presumably forgot this bit then
<GaryvdM> MvG: Out of the people who could be the rm, none of them are online right now, so it may be a good idea to send a mail to the mailing list.
<MvG> GaryvdM: OK, will do so.
<vila> GaryvdM: do you remember which toolkit was used for diffamation ? qt ?
<vila> GaryvdM: or was it osx specific ?
<GaryvdM> vila: It was written in java. I'm not sure which toolkit
<vila> wow, who said java was slow ? :-P
<vila> for those that couldn't attend UDS,  the video is here: http://ubuntudevelopers.blip.tv/file/3617079/
<bialix> does somebody really said that java is slow? he should look at python first
<Peng_> Heh.
<vila> bialix: some people explained me that they switched from java to python for web apps because python was faster :-P
<bialix> ah
<bialix> maybe
<bialix> but diffamation is desktop thing
<guijemont> doesn't java have a reputation of slowness just because a lot of people programming in java don't know what they're doing?
<vila> yup, so the key is to focus on the relevant part that needs to be animated, things like shortest edit paths (mentioned in the above presentation) are certainly needed to reduce the data set to process
<guijemont> (me? feeding the trolls?)
<vila> the same apllies to python really :)
<guijemont> certainly
<guijemont> that's where the virtue of brainfuck is
<guijemont> bad programmers don't go there
<guijemont> good programmers don't either though
<GaryvdM> vila: http://www.aviz.fr/diffamation/
<guijemont> indeed diffamation looks cool
<vila> GaryvdM: ecellent, thanks for the url
<jml> did anyone take notes for the "Bazaar/Launchpad healthcheck" session at the recent UDS? I can't find it on gobby
<vila> jml: ouch, ping poolie ? :-/
<jml> vila: I'll send him an email.
<vila> mgz: in case you're wondering, I've found the problem with babune
<vila> jml: I should have known...
<vila> mgz: the selftest -x option can't be used twice (AFAICS) so TestBreakin and its zombies was back...
<vila> mgz: I've just finished upgrading babune to lucid and relaunch a full set of runs, gentoo has already succeeded
<spiv> jml: bazaar-m-healthcheck?
<jml> spiv, ahh, thanks. I was looking for it under the community track
<spiv> jml: that would have been logical :P
<vila> jml: pfff, I'm so disappointed :-P
 * vila runs (not only to avoid jml's great vengeance :)
<jml> :D
<spiv> vila: Huh, I thought selftest -x could be used twice?
<spiv> vila: btw, if you feel inclined, maybe set up a builder for bzr on python2.7?
<spiv> (It'll fail to even start tests atm, though, I filed a bug)
<bialix> yep, some pages gone from gobby
<bialix> jml: that page still there
<bialix> titled bazaar-m-healthcheck
<jml> bialix: thanks.
<bialix> I guess we should put those pages to wiki
<jml> bialix, yeah. that'd be good.
<jml> bialix, I'm collecting all of the Launchpad-related notes, putting them onto our wiki, then blogging a summary.
<jml> I'm not going to do that for Bazaar though.
<bialix> ok
<bialix> I'll do that for bzr
<guijemont> I've named some of you there, hope you don't mind: http://guij.emont.org/blog/2010/05/18/scratching-an-itch-make-bzr-gtk-collapse/
<guijemont> GaryvdM, jelmer and vila
<nessita> vila: ping
<vila> nessita: pong
<nessita> vila: hi there! I added a comment on https://bugs.launchpad.net/bzr/+bug/581751
<ubot5> 'Error: Could not parse data returned by Launchpad: HTTP Error 401: Unauthorized\nResponse headers:\n---\ncontent-length: 21\ncontent-type: text/plain\ndate: Tue, 18 May 2010 13:05:13 GMT\nserver: zope.server.http (HTTP)\nstatus: 401\nvia: 1.1 wildcard.edge.launchpad.net\nx-powered-by: Zope (www.zope.org), Python (www.python.org)\n---\nResponse body:\n---\nBug 581751 is private\n---\n (https://launchpad.net/bugs/581751)'
<nessita> vila: lifeless suggested me to ping you, is there any debug we can do together?
<vila> wow, ubottu can't authenticate ? That's weird...
<nessita> any extra info I can add? I can reproduce it consistently
<vila> nessita: just sec, let me page in the context
<nessita> vila: sure, thanks
<vila> hmm, looks like the nightly hasn't been updated since 2010-03-24, so I'm pretty sure it doesn't have the fix
<vila> nessita: what do you mean by 'split' the bzr command ?
<nessita> vila: yes
<vila> nessita: nice host name by the way :)
<nessita> heh :-)
<vila> nessita: sorry for the delay, I've just updated to lucid and my setup is not fully functional yet
<vila> GaryvdM: did you merge annotate_find to trunk ? It seems that branch doesn't work anymore on lucid
<nessita> vila: no problem. Just ping me using my nickname and I'll be happy to help debugging
<GaryvdM> vila: I have not yet merge annotate_find to trunk, but I have merge trunk in to annotate_find, so annotate_find should work on trunk.
<GaryvdM> *should work on lucid
<vila> ok, first I'd like to check if the nightly includes the fix I mentioned
<vila> GaryvdM: Oh, right, you told me that, let me check
<vila> GaryvdM: thanks, that fixed it :)
<vila> nessita: right, the fix is revno 5160 on trunk while the nightly seems to be 5106, right numbers, wrong order
<nessita> vila: ok, so, is there any way of getting a newer bzr other that branching trunk?
<vila> nessita: can you run bzr from sources ?
<nessita> vila: I guess so :-)
 * nessita branches
<vila> nessita: none of the ppas seems to contain better than nightly, this fix should be in the next releases (2.0.6, 2.1.2, 2.2xxx)
<vila> spiv: (surely too late but anyway) I thought -x could be used twice too, regression ? (-s can ! :)
<vila> nessita: don't forget to run make after branching (hmm, you may need to install some dependencies too, pyrex for one...)
<nessita> vila: is there any howto?
<nessita> I mean, a list of deps so I install them at once
 * vila looks at the package def
<nessita> jeje
<nessita> that's cheating!
<vila> :)
<vila> I know we don't have TestDepends but I'm pretty sure we have DevDepends (or whatever the name is)
 * nessita is still branching
<vila> argh, one more regression, can\t switch virtual desktops anymore
<vila> nessita: hmm, first branch ever ?
<nessita> yeap
 * nessita sings like a virgin, branching for the very first time
<vila> shift+ctrl+alt+left instead of ctrl+meta-left .... did the design team infected by emacs viruses ?
<vila> nessita: :-)
<vila> argh, keyboard layout bug :(
<nessita> vila: how big is a bzr branch?
<vila> history or working tree ?
<nessita> history
<nessita> vila: it doesn't matter, I was just curious
<nessita> this thing is still branching :-)
<vila> nessita: my .bzr shared repo is ~62
<vila> ghaa 63M
<vila> that should be an upper bound as it contains many revisions that were never (or are not yet :) merged to trunk
<vila> nessita: lag/bandwidth ?
<nessita> max download rate is 1M for me
<nessita> and the branch is using ti all
<nessita> it*
<nessita> \  78155kB   107kB/s | Fetching revisions:Inserting stream and counting
<vila> hmm, 78M already, something weird is going on here :-/
<nessita> not relly?
<nessita> nessita@dali:~$ du -sh src/bzr.trunk/
<nessita> 35M	src/bzr.trunk/
<nessita> finished!
<vila> nessita: so you used twice the volume of the final branch: something weird happened, can file a bug with these numbers please ?
<vila> nessita: then you can ping lifeless :-)
<nessita> ok
<nessita> vila: make completed successfully
<vila> nessita: so, run 'make' in the bzr branch
<nessita> done
<vila> wow, you rock :)
<nessita> heh
<vila> no weird messages about extensions nor zlib ?
<nessita> nopes, it failed because of the lack of pyrex, which I installed and re run make
<vila> nessita: just do './bzr info -v' there
<vila> ok, so you should have the other ones already installed (I vaguely remember zlib-dev was required at some point)
<nessita> vila: https://pastebin.canonical.com/32382/
<vila> nessita: cool
<nessita> vila: this worried me though https://pastebin.canonical.com/32383/
<nessita> vila: note bzr vs ./bzr
<nessita> but versions match?
<vila> nessita: try using this bzr for your previously failing ... let me look ta this pate
<vila> nessita: yes, versions are bumped for release only, nightly are not your usual beast
<nessita> ohhhh ok
<nessita> vila: shall I redo the splits with the newer bzr?
<vila> but the full output should mention the revno
<vila> nessita: not if the fix apply to your case
<nessita> perfect
<vila> nessita: bah, no
<vila> sorry for the convoluted answer
<nessita> no problem
<nessita> I can do the split again
<nessita> shall I branch using newer bzr too?
<vila> nessita: no, just try the failing command with the new bzr
<nessita> ok
<vila> either it's fixed or it's a whole new bug anyway
<vila> mgz: babune back in blue, expect for the windows run !!
<nessita> it didn't fail!
<nessita> vila: nice :-)
<vila> nessita: pfew, I'm so glad about that ! This fix was a real pain :)
<nessita> vila: thank you very much for your help!
<vila> nessita: I was afraid you were hitting the same kind of problem only different, luckily it looks to be the *same* :)
<vila> nessita: my pleasure
<nessita> seems like it
<nessita> vila: have a few more minutes for a follow up question?
<vila> nessita: sure
<nessita> vila: so, the merged worked (yey!) but, when applied, it removes some files (because the source branch has those removes in it). Is there any way to avoid/undo certain changes?
<vila> nessita: if the merge remove 'filea', doing 'bzr revert filea' should restore it, you can then commit and the following merges shouldn't delete it again
<nessita> vila: yey, you're right
<nessita> thanks again!
<vila> nessita: I'll mark the bug as a duplicate then
<nessita> vila: please do
<nilg`> bzr repo on launchpad is nearly impossible to get from china, any knowledge about that issue?
<vila> guijemont: marmitians anonymous, really, you know there are free certificate providers these days ? :-P
<vila> guijemont: and, of course, no problem with your citations :)
<guijemont> vila: yeah, should handle that one day
<guijemont> but the big issue is it's a shared server
<vila> ha, yeah, technical problems are so much easier to handle when humans are not involved :-D
<GaryvdM> vila: I know you us synergy. Are you aware of this: http://code.google.com/p/synergy-plus/
<GaryvdM> *use
<GaryvdM> vila: The old synergy segfaults for me. synergy-plus is more stable for me, but the clipboard is broken.
<vila> GaryvdM: good to see this nice software resurrected, I'll track it to see how it evolve.
<vila> GaryvdM: it's mission critical for me so unless it works better I'll stick with the working one :)
<GaryvdM> vila: I see.
<vila> GaryvdM: also, I try to minimize installs from source, so unless it's packaged for lucid... I will wait (if someone proposes it as a ppa though.... I will gladly test it ;-)
<vila> GaryvdM: Oh, and I have a pending bug against virtualbox about the bad interactions between vbox, synergy and the apple magic mouse...
<kfogel> On a Debian GNU/Linux system, ever bzr command gets this warning:
<kfogel> /usr/lib/python2.5/site-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases.  See http://www.pycrypto.org/randpool-broken
<kfogel>   RandomPool_DeprecationWarning)
<kfogel> But python-paramiko package is up-to-date.  Googling does not reveal any obvious fixes, and the URL given in the warning is a 404.
<kfogel> Any ideas?
<IslandUsurper> Isn't Crypto a separate download from paramiko?
<cbz> what happens when a pack file size gets to the system filesize limit?
<IslandUsurper> kfogel, the source install docs list http://www.python.org/pypi/pycrypto/ as the place to get pyCrypto
<kfogel> IslandUsurper: thanks
<IslandUsurper> kfogel, I would guess there's a different package for it instead of python-paramiko
<nessita> hey all, me again with weird issues. Anyone has a hint how to solve this conflicts? https://pastebin.canonical.com/32393/
<maxb> You know that that's a pastebin most people can't see?
<nessita> duh, sorry, pastebin was disabled a few hours ago :)
<nessita> oops, still is
<nessita> public paste: http://paste.ubuntu.com/435609/
<nessita> maxb: thanks for pointing this out!
<maxb> I guess this is a private branch?
<nessita> maxb: yes, I split a subtree from a branch and I merged it against another branch in another project
<nessita> (using bzr split and bzr merge)
<maxb> that sounds... complicated :-)
<nessita> yeah
<nessita> I'm so frustrated
<nessita> but I have to do this, and maintain history
<bialix> GaryvdM: still here?
<bialix> GaryvdM: maybe I simply should dogfood your bzr-explorer patch? I'm not really wise to easily review your changes
<bialix> about duplication: maybe it's worth to require in explorer trunk compatibility with newer qbzr? and keep explorer 1.0.x as compatible with qbzr 0.18?
 * bialix going to home, will read irclogs later
<bialix> ~~~
<mgz> vila: good to know the nix hang problems are not related, was coming to that conclusion here
<mgz> I've got some interesting results on the thread leak regression I'll probably post to the mailinglist
<pheller> can anyone tell me what provides XMLSerializer ?
<pheller> nevermind.  I see it's part of bzrlib now
<vila> mgz: (passing around) regression ? The leaks have been there for... a very long time, what are you comparing to ?
<mtaylor> abentley: bug in lp-submit in pipelines:  I just got this error: bzr: ERROR: There is already a branch merge proposal: https://code.edge.launchpad.net/1.0/~mordred/drizzle/pandora-build/+merge/14733
<mtaylor> abentley: too bad the 1.0 doesn't really belong in that url...
<vila> mgz: the bug itself is very stealth and I have never been able to reproduce it on demand...
<abentley> mtaylor, funny, I thought I'd fixed that one.
<mgz> vila, that's just it, yes, the leaks have always been there, but they were never fatal for *me* before
<mgz> and now I can reliably repo.
<mtaylor> abentley: it's possible I'm running an old version
<mgz> vila: I've got a couple of things I'd like you to check if you can
<abentley> mtaylor, just testing now.  It's possible I only fixed lp-propose.
<mgz> 1) make really-really sure you're chop-test-run-into-several-smaller-subprocesses workaround is still working, as that should make leaks harmless
<mgz> 2) do a full babune test run on r4919 and r4920
<abentley> mtaylor, yeah, that's it.  On 2.1, lp-submit will give you that error.  On 2.2, you get lp-propose through its lp-submit alias.
<mtaylor> abentley: ok. cool
<mtaylor> abentley: I'll just deal with it then
<mtaylor> it's certainly not borking me :)
<abentley> mtaylor, I'll fix it, just not right now.
<GaryvdM> bialix: If you read this in the log, I've replied to your questions in the mp. Thanks
<vila> mgz: 1) is demonstrated by babune being almost blue (including some hacks for some slaves to increase BZR_CONCURRENCY *above* the number of available processors)
<fullermd> For god's sake, let it BREATHE!
<vila> mgz: what do you call a full run ? All slaves ?
<vila> fullermd: funnily enough it's the freebsd8 that needs the hack has running it under vbox with more than two cores lead to far too much crashes :-/
<vila> s/freebsd8/freebsd8 slave/ and to avoid any misunderstandings, I blame vbox not freebsd (remember the time skew problems I was encountering ? Still there, even worse maybe)
<vila> and babune's fans have been changed for more silent, yet still efficient, ones, so it can breathe and I don't hear it complain anyway
<fullermd> Obviously, the answer is to make freebsd8 the host rather than the emulated one   ;p
<vila> fullermd: all tests are run in slaves, not on host :-P Host is for *my* tests :-)
<vila> so I'll still need to have a freebsd slave ;)
<fullermd> Daemons don't take well to chains.  You're liable to wake up one day to a trident at your throat.
<GaryvdM> If you interrupt a bzr-git fetch, will it resume, or restart?
<vila> one more reason to give it only two cores, I may be able to put my neck between the two teeth of the bident :)
<vila> fullermd: and stop complaining, now you can blame the lower number of cores to explain why freebsd is the slowest nix on http://babune.ladeuil.net:24842 :-P
<fullermd> Ah, yes.  Core limits for VM's should be called the Skynet Prevention Program.
<vila> You said the name !!!!
<fullermd> jaunty isn't a nix?  ;p
<vila> hehe, I was waiting for that, check again in a couple of days or drill down for the trend, jaunty and karmic last run are atypical :-P
<fullermd> Doesn't much matter anyway, since Windows does it in 2 minutes  ;p
<vila> no no, 55mins, note the debug :) This one is running only a small subset :)
 * fullermd snorts.
 * vila dinner :)
<fullermd> You've got a pathetic career as a benchmarker ahead of you if you're gonna get bogged down in irrelevant details like that   ;p
<mgz> <vila> mgz: what do you call a full run ? All slaves ? <- windows only, but all tests (minus bb.test_breakin)
<mgz> I'll get my write-up done later, then things might start making more sense
<mgz> essenstially, I think things have got worse on the threads-leaked-alive front.
<mgz> and it's the fault of testtools, which is becoming something of a mantra for me
<fullermd> Well, consistency is a virtue, right?
<eydaimon> can I create a branch on remote host? say I have a bunch of files in a dir. I want to create a branch on the remote host, and check them in there. how would I do it?
<beuno> eydaimon, create teh branch locally and push to it
<beuno> it will create it
<eydaimon> bzr init . ?
<eydaimon> then bzr push pathname?
<beuno> bzr init .
<beuno> bzr add
<beuno> bzr commit -m
<beuno> bzr commit -m'Some message'
<beuno> bzr push pathname
<eydaimon> thanks :)
<eydaimon> will the local branch work as a checkout or as a branch?
<beuno> youz welcome
<beuno> a branch
<eydaimon> can I make it a checkout?
<eydaimon> so Id on't have to keep pushing
<beuno> yes, but you will need to checkout from $path
<eydaimon> so first push, then checkout
<eydaimon> bzr doesn't seem to like writing to a dir which already exists
<beuno> yeah, it's fussy about that
<GaryvdM> eydaimon: You can make your local branch a check out by running bzr bind :push
<eydaimon> cool. thank you
<vila> mgz: hmm, re-trying old revisions on windows with the bug fixes in testtools and subunit may be worth a try, but I won't bet a lot on testtools making things worse
<vila> mgz: keep in mind that the root cause is that transport objects don't close their socket, for http that means keeping the connection alive. The servers have to keep their own connections open. At some point python's gc will finally collect the transports and close the client sockets triggering the server sockets close.
<vila> mgz: But since that take too long, we finally reach the socket/file handle/thread limit
<vila> mgz: now, to fix that, we need to close the socket in either the client or the server, that's where I encountered weird behaviors (uncaught exceptions in the server threads leading to hang threads for once)
<vila> mgz: I have some branches where the servers where almost good and where there were almost no more leaked threads and... get interrupted
<vila> mgz: It's high n my TODO list now so expect some results soon (for handwaved values of soon of course :)
<kojiro> There's something I really don't understand about bzr-svn: If I do a merge/commit/push, it puts back changes that were already on the svn repo, but makes it look like I just made those changes
<kojiro> is that really what I should be doing?
<vila> fullermd: benchmarker... OMG what a scary thought...
 * fullermd . o O ( Vilacraft... )
<jam> vila: shouldn't you be ... not in IRC... by now :)
<fullermd> Wow, you haven't even started benchmarking, and people are already trying to get rid of you!
<GaryvdM> jam :-p
<vila> jam: hey ! Indeed :)
<jam> hi GaryvdM
<vila> Proceed as if I wasn't there :)
<jam> vila: I'm seeing an awful lot of blue on babune :). Though I wonder why selftest-windows isn't, seeing as you worked with Martin all week on it...
<jam> Are there patches pending?
<jam> (At least, I thought you said you got Win32 to pass...)
<vila> jam: AFAIUI, most of them are now due to the infamous "Can't start new thread"
<vila> I thought we add, but for some reasons, not all tests were running and we based our countdown on that.
 * mgz reads log
<vila> mgz had landed further patches I believe so the remaining ones should be fixed when the leaks will
<vila> oh, he's there (mgz) so he can comment :)
<mgz> yup, I'm aiming to splat everything that's not a leak
<jam> vila: you know, if you gave that vm 2 cpu's, you're troubles would probably go away...
<mgz> including a couple of things I see but babune doesn't
<vila> jam: I can't make XP recognize several cores...
<jam> *your*
<mgz> on the leak-as-regression thing, something has gone seriously bad in the past 300 revisions
<jam> vila: my wife runs xp-pro on 2-core
<jam> (business machine)
<mgz> leaks are harmless provided there's enough memory to spare for the stack space required by lingering threads
<vila> ha, pro, that should explain it :)
<jam> maybe
<vila> mgz: could be, I can try increasing the memory allocated to the vm
<jam> xp was based on 2k's kernel, IIRC. So maybe xp-home has an explicit deficit, but xp generally can definitely handle multi-core
<mgz> between r4919 and r4937 (which is the first post-testtools rev that doesn't corrupt memory), the working set increased two or three fold
<vila> now waitaminute, I'm pretty sure I'm using a pro version...
<mgz> and the tests start hanging.
<vila> mgz: working set ?
<vila> corrupt memory ?
<mgz> sorry, yes, this is complicated by lots of unrelated things
<mgz> hence easier in a big email than on IRC
<vila> ok
<jam> mgz: working set => active memory consumption?
<mgz> right, it's one of the measures I get from windows, also, pagefile usage, and I'm not sure how they overlap
<mgz> (is the combined value the total memory usage?)
<bialix> how to configure pqm plugin to send merge request for 2.1 branch?
<GaryvdM> bialix: Change the submit branch in branch.conf.
<bialix> e.g.?
<GaryvdM> bialix: you probably will not have permissions though.
<bialix> boom
<GaryvdM> bialix:    submit_branch = bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/
<GaryvdM> or just
<GaryvdM> bzr pqm-submit bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/2.1/
<mgz> vila: so, I ran the whole testsuite against a bunch of different revisions, summary of the results at <http://float.endofinternet.org/temp/bzr_selftest_result_summary.log>
 * bialix rambling on out-of-date hacking.txt instruction re pqm
<mgz> the first rev I can test without the crash from r4920 has massive memory usage, and hangs in a threaded test, as does each revision after that
<mgz> more recent revisions still have massive memory usage, but run faster (there was a rev aiming to speed up the test suite, right?) and now get various thread-related failures but hang less reliably.
<vila> mgz: yes, lifeless optimized a bunch of tests
<mgz> I'm going to run some revs between 4945 and 5200 but it seems to me like the regression is between r4919 (which is fine for me) and r4937 (which is the first post-testtools that I can run)
<mgz> hence the request for you to try r4919 on babune, if you can
<mgz> I expect zero thread problems.
<mgz> (the full results are on my server, but are giant xml files that might hurt unsuspecting webbrowsers)
<vila> mgz: now running
<vila> mgz: that was fast :-/
<vila> hmm, the qbzr guys are gone for some more vodka I suspect...
<mgz> bah, dodgy unicode handling in error messages is historical...
<mgz> don't suppose you have python 2.4 on that box?
<vila> mgz: 2.4 2.5 2.6
<mgz> AttributeError: 'BzrAutoTimingTestResultDecorator' object has no attribute '_call_maybe' <- and I got this from subunit, and didn't know what the hell it was
<vila> pretty old bug
<mgz> in bzr? that was fixed?
<vila> err wait, you got that *now*
<mgz> I might have been trying to test an old revision at the time.
<vila> no, I'd say in testtools
<mgz> I can run the testsuite back to at least ~4000 cleanly
<vila> they try to preserve backwards compatibility with that (IIRC), they may lack 2.4 testers though
<mgz> but I have less in-tree infrastructure I'm relying on
<mgz> r4919 is before testtools
<vila> bite the bullet man, testtools is the future and the sky is the limit ! :-D
<mgz> okay, so this probably isn't going to be easy to prove with babune
<mgz> but, here's my 4919 run: http://float.endofinternet.org/bzrcst/clasfull/4919
<vila> mgz: just try to exclude all http server related tests (add a skip in the server setup if you want) and just focus on the rest
<mgz> and 4920: http://float.endofinternet.org/bzrcst/clasfull/4920 (early crash)
<mgz> and 4937: http://float.endofinternet.org/bzrcst/clasfull/4937 (crash bug fixed, late hang)
<vila> argh, poisoned url, kill firefox, kill firefox ! ;)
<mgz> yeah, sorry ;)
<mgz> I did load one of those even on your laptop, so it should survive
<vila> this bug drove me crazy for a long while, there is really no way to predict when something will fail, hece the --parallel=fork trick
<mgz> but that trick seems currently to be insufficent
<mgz> and looking at my local test runs, things have got *much worse* with leaks in the past 300 revs
<vila> mgz: sure, I knew since the beginning we were on thin ice
<vila> it stoppped working for OSX long ago and get rid of the slaves for this reason
<mgz> the number of leaks is about the same, but they're causing deadlocks, OOM testfailures, thread handle test failures, and huuuuge memory usage
<mgz> so, something changed.
<vila> I've seen it appearing on OSX and I could precisely point the revision,
<vila> it was totally unrelated :)
<mgz> ehhehe
<mgz> there is a symptom vs. cause problem with this, too big a problem to isolate
<vila> thread scheduling is not... damn, what's the word
<mgz> the memory usage is causing the failures, or the leaking is causing the memory usage, or...?
<mgz> deterministic?
<vila> yeah, thanks, deterministic
<mgz> okay, I think I'll do two more things before moving onto another problem for the moment
<vila> not closing the sockets is causing the leaks, increasing memory usage (but not all I think)
<mgz> #1 cherrypick my r4937 fix back on top of r4920 to see if I can squarely blame testtools for the change in mem usage
<vila> more memory usage certainly leads to memory fragmentation, => increasing time => different scheduling => may be more leaks
<mgz> #2 run some revs before and after robert's test-speedup (know what number that was?)
<vila> at one point it's useless to try to understand what happens
<vila> mgz: I think there was several commits for several improvements
<vila> I'd say around 2.1 release
<mgz> testtools did change some teardown/other details in pretty subtle ways
<vila> mgz: don't rely on teardown, use addCleanup, you can't mix both
<lifeless> moin
<mgz> sure, but were the thread-related tests ever audited for that kind of thing after r4920?
<vila> mgz: yes, there was some changes there.... speaking of the devil !
<lifeless> vila: you can mix them, they have a defined order
<mgz> it's pure fluke that the bb.test_non_ascii problem went on to cause a reliable crash to annoy me into finding and fixing it
<mgz> okay, set r4290+4937 running, time for a break.
<vila> lifeless: I'm falling asleep right now, but I think I remember cases where you could easily shoot yourself in the foot by mixing them
<lifeless> yes, we had a list discussion
<lifeless> we want to transition entirely to cleanups
<lifeless> go to sleep though :)
<vila> right, that was the idea I was trying to convey: use addCleanup, not tearDown
<vila> yeah, 22:22 is a good hour for that
<mgz> vila: check the diff of r4937 ;)
<mgz> the point is it happened 17 revs after the breakage, and there may be similar as-yet-uncaught issues related to threading
<vila> mgz: :-D
 * vila zzzz.... cmfdinjd bou8rh7m
<jam> lifeless: /wave
<lifeless> jam: hai
<lifeless> jam: did you have a chance to look at dirstate2?
<jam> lifeless: I grabbed a copy of it, but haven't poked at it yet
<lifeless> ok
<lifeless> jam: whats the time for you now ?
<jam> 4pm, 1hr before EOD
<lifeless> so, between mountain view and montreal. doh, my clock is running out of zones
<fullermd> Heck, I just lookit my watch, it tells me what jam's time is   ;p
<RumblePure> I'm in utter panic. I've checked out from my main branch to my laptop. I did bzr update on my laptop after having worked on my code, and that created a real mess. Original files got screwed up, and tons of files that end with .THIS and .OTHER have been created.
<RumblePure> How can safely revert to latest commit on laptop?
<RumblePure> That's all I care about now.
<beuno> so
<beuno> you had uncommited changes?
<RumblePure> beuno: not on the laptop no. I had commited locally
<beuno> I don't think I follow
<RumblePure> 1. I checked out from my main branch to my laptop.
<RumblePure> 2. I worked on my code on the laptop, doing local commits on the laptop's branch multiple times.
<RumblePure> 3. Satisified with my work, I wanted to commit back to main branch on stationary.
<lifeless> what bzr version?
<RumblePure> 4. Bzr said I have to do bzr update before I can do that. After I did bzr update, everything got messed up.
<lifeless> we made update much better recently, I thought.
<RumblePure> lifeless: we've been over this man, last time this happened I followed your advice and updated to latest version.
<RumblePure> 2.1.1
<RumblePure> Oh no I think I'm gonna have to throw up.
<RumblePure> My local commits are no longer even showing when I do bzr log on the laptop.
<lifeless> RumblePure: calm down
<lifeless> RumblePure: its all there, there is no data loss
<lifeless> RumblePure: do you have bzrtools installed ?
<RumblePure> lifeless: then why wont bzr log show my previous local commits?
<RumblePure> lifeless: no i dont. what does it do?
<lifeless> because they are sitting staged until you commit
<lifeless> if you run bzr st
<lifeless> and look at the pending merges section of the output
<lifeless> your most recent commit before you ran update will be there.
<RumblePure> lifeless: they aren't shown when i do bzr st. only the status.
<RumblePure> but never mind that.
<RumblePure> All I wanna do know is to get things to the way they were before i did bzr update on laptop.
<lifeless> RumblePure: 'bzr st' ? not 'bzr st .' or anything else ?
<RumblePure> bzr st only
<lifeless> ok
<lifeless> anyhow
<lifeless> if you could install the bzrtools plugin
<lifeless> if you're on Debian or Ubuntu, apt-get install bzrtools
<RumblePure> i already have it, or so it seems
<lifeless> great
<lifeless> run 'bzr heads --dead'
<RumblePure> ... what does it do?
<lifeless> queries your repository
<RumblePure> Ok this is good, I think I see my last commit.
<jam> lifeless: looking at your dirstate2 branch, I see that you don't handle a failure in "rename current NEW.check". Are you looking for more of a 'logically, this sequence seems correct' check, or a code check?
<lifeless> jam: well I know its a sketch, but all feedback is good
<lifeless> jam: I think the thing to answer at the moment is 'is this the right approach/what needs to be done to plug conceptual holes in it'
<lifeless> RumblePure: now, you'll have something like:
<lifeless> HEAD: revision-id: robertc@robertcollins.net-20091220080322-7cx34xsdvkzm1x0p
<RumblePure> lifeless: I should say that I just realized that I did have uncommited data on the laptop. So this was data that had not even been locally commited. This was the state before I tried bzr update.
<lifeless> RumblePure: ok, so you *did* have uncommitted changes.
<lifeless> that makes it trickier.
<RumblePure> lifeless: but you can scratch it.
<RumblePure> lifeless: not that important right now.
<lifeless> RumblePure: you sure ?
<RumblePure> lifeless: I'm more forced to than sure, but yeah.
<lifeless> ok.
<RumblePure> HEAD: revision-id: purerumble@puremainframe-20100518210143-n03lz2rtfa1tspx2 (dead)
<lifeless> copy that string from the email bit on. E.g. for me it would be robertc@robertcollins.net-20091220080322-7cx34xsdvkzm1x0p
<lifeless> without the (dead) bit
<jam> lifeless: so I have some "this bit is hard to understand" stuff. and I still need to go through it step-by-step logically to make sure things fail correctly
<lifeless> now first we reset your working tree:
<RumblePure> purerumble@puremainframe-20100518210143-n03lz2rtfa1tspx2
<jam> first bit is that it seems ok
<lifeless> bzr revert
<lifeless> secondly, we restore your local state
<[1]reggie> hey bzr experts -- we have a commit mailer that is failing to work with a SSL server on port 465
<lifeless> 'bzr pull --local . -r revid:purerumble@puremainframe-20100518210143-n03lz2rtfa1tspx2'
<[1]reggie> any chance I"m just missing some config option?
<jam> [1]reggie: I don't think smtplib trivially supports SSL, if you can, use TLS on the standard ports
<RumblePure> lifeless: ok it says on revision 89, this was better than when bzr log showed only up to 83.
<[1]reggie> jam, alas this is not an option (other than just setting up a local smtp server)
<lifeless> RumblePure: now that you've encountered this with bzr 2.1.1, we know that we haven't fixed the issue as well as we thought we had. Is your code open source?
<RumblePure> lifeless: no, super really sorry man.
<lifeless> no problem
<lifeless> however, would you be willing to run some queries for us - that would return metadata only ?
<RumblePure> lifeless: I remember your buddy at this channel asked the same question. Trust me I wanna help you to 105% to catch this bug, but can't give you the code. :-/
<lifeless> thats ok, I understand completely.
<jam> [1]reggie: it could probably be updated to do so, looking here: http://docs.python.org/library/smtplib.html
<RumblePure> lifeless: affirmitive. but do it quickly
<jam> you have to use a different class
<jam> SMTP_SSL
<lifeless> RumblePure: bzr heads --all
<jam> but otherwise should be the same
<jam> Not sure how you would indicate that in the config file
<RumblePure> lifeless: One question first, is the local branch on my laptop healthy now?
<lifeless> RumblePure: should be, yes.
<[1]reggie> right. I saw that.  I'm using a binary insatll of windows.  I guess I could use a python install
<RumblePure> lifeless: I still got some *.THIS and *.OTHER files laying around. Should I just get rid of them?
<lifeless> RumblePure: yes
<RumblePure> lifeless: will it bother your inqueries that you want me to run if i just clean up first and do a local commit?
<jam> [1]reggie: how are you generating emails then? This is failing for 'bzr send'?
<RumblePure> *inquiry
<lifeless> RumblePure: it will yes
<jam> you can always 'bzr send -o filename' and then send that with another mailer
<lifeless> RumblePure: I want you to run
<jam> If it is from 'bzr-email', that isn't bundled with the installer anyway
<RumblePure> lifeless: ok, lemme at least make a hard copy of the folder.
<lifeless> bzr find-merge-base . [the master branch you checked out]
<lifeless> that will print a revid
<jam> also, on Windows, I think the default is to have "bzr send" spawn whatever MAPI mailer is present
<jam> which means we aren't the ones sending to SMTP anyway.
<lifeless> I then want you to look in 'bzr log --show-ids' for that revid, and print the revno that it has there
<lifeless> On 04/08/2010 03:34 PM, Francis J. Lacoste wrote:
<lifeless> > Stuart Metcalf announced that they should be rolling out an OpenID-enabled
<lifeless> > Mumble at the end of next week. That will save us from registering 38
<jam> anyway, more details needed... :), I might be around later
<lifeless> bah sorry, paste error
<lifeless> ignore the email :)
<mgz> are the email address for third party packagers written down anywhere? I know at least some of them subcribe to the bzr list
<RumblePure> lifeless: I reach the master branch through bzr+ssh and a dynamic ip-number that has changed. Will go with new ip-number
<lifeless> mgz: they were on the wiki at one point
<mgz> I shall poke around.
<RumblePure> lifeless: It says it requires argument OTHER
<RumblePure> lifeless: oh wait
<RumblePure> lifeless: never mind
<mgz> hm, DistroDownloads wikipage currently does not seem to have contact points
<mgz> or rather, it has general links and things but no email addresses. CCing people on a short email I can do, filing upstream bugs and so on is too much for a teeny change
<lifeless> mgz: which change are we talking about ? the dep one? no need to bother there as I said ;)
<lifeless> just a courtesy if you feel like it
<RumblePure> lifeless: It has revno 83
<mgz> well, if I could find email addresses, courtesy would be easy, just post a short message to list with CCs.
<RumblePure> lifeless: the revision id that matches what bzr find-merge-base gave.
<lifeless> RumblePure: can you look at bzr log <master branch> --show-ids, and get the revno that the base revisionid has there ?
<lifeless> RumblePure: it may be 83 as well, just want to be sure
<RumblePure> lifeless: affirmitive, it is 83 that has that revid
<lifeless> RumblePure: finally, I need to know if you had new files involved in your branch
<lifeless> bzr st -r 83..
<lifeless> have a look in that, and tell me if there are new files
<RumblePure> lifeless: yes i remember and just checked, there were new files involved
<lifeless> were those files the ones that went really messy?
<lifeless> (I don't know) is an ok answer.
<RumblePure> lifeless: other files went messy too, but yeah those files that were new at the time went messy.
<lifeless> ok
<RumblePure> lifeless: with new, I mean they show up under "added:"
<lifeless> I think this gives me enough to try to reproduce
<lifeless> thank you
<lifeless> now, to get your changes into your master
<RumblePure> lifeless: no problem. Just grab me anytime at ArashU@gmail.com and I'll see what I can do more.
<lifeless> as you've only added stuff - doing the following should work:
<lifeless> bzr unbind
<lifeless> bzr push <master url>
<lifeless> bzr bind
<RumblePure> lifeless: Can we try that some other time? I really need to get to bed. Just wanna cleanup (remove *.THIS and *.OTHER files) and commit locally. Will that be OK for now?
<lifeless> sure
<lifeless> thanks for your help
<RumblePure> lifeless: Ok, now I've fixed the stuff I lost and commited *breathing out*. Thx for the help lifeless. You saved my day again. You got my email ArashU@gmail.com? Just grab if you want help to track that bug.
<lifeless> sure thing, thanks
<bignose> when I âbzr merge ; bzr revert --forget-mergesâ I understand that the working tree remains with the changes, but the merged revisions are gone.
<bignose> but what about âbzr merge ; bzr revertâ? do the merged revisions remain, waiting for a commit?
<lifeless> no
<lifeless> 'bzr revert' discards all changes
<lifeless> 'bzr revert .' discards only path changes
<lifeless> 'bzr revert -forget-merges' discards only pending merges
<lifeless> its a bit magic; sorry.
<bignose> ah. so why would I have seen advice elsewhere to do both âbzr revert ; bzr revert --forget-mergesâ to be sure?
<lifeless> no idea
<bignose> is it a behaviour that's been different in the past?
<lifeless> nope
<lifeless> 'bzr revert' has, ever since creation, been a Big Hammer
<bignose> what does âonly path changesâ mean?
<lifeless> files, directories, symlinks that have changed
<lifeless> 'things that are paths'
<bignose> but not contents?
<lifeless> yes their contents
<bignose> ah. so what's excluded?
<lifeless> pending merges
<bignose> heh.
<bignose> okay, maybe that's what I'm remembering. âbzr revert . ; bzr revert --forget-mergesâ
<bignose> maybe from a person who kept them as distinct operations in their mind
<lifeless> I would guess a git user
<bignose> righto.
<lifeless> as git requires . for basically everything
<lifeless> but . is an explicit path for us, rather than nothing which is 'find the root and do the default'
<bignose> so, it can be useful to âbzr merge ../foo-feature/ ; bzr revert . ; bzr revert ../bar-feature/ ; bzr commitâ
<bignose> because that allows a single commit of all the merges
<bignose> right?
<bignose> hmm, no.
<bignose> is there a way to get a bunch of revisions from various places, apply them all, and only then commit?
<lifeless> bzr merge foo; bzr merge bar --force; bzr merge gam --force; bzr commit
<bignose> okay, just read the help on that. perfect, thanks.
<bignose> so lifeless, you're no longer living in oz?
<RumblePure> lifeless: hey lifeless. I told you I cleaned up, made some changes and then made two or three more local commits. Well guess what. After that I ran bzr update again and it all went smoothly.
<RumblePure> lifeless: after the update i commited back to master, no problems!
<RumblePure> lifeless: and .bzr/branch/branch.conf still had the new ip-number. Maybe this wasn't related to the changing ip?
<RumblePure> lifeless: and I've checked the code. All my latest changes are there.
<lifeless> RumblePure: I'm not sure
<lifeless> I'll try and reproduce
<lifeless> bignose: yah, moved back to NZ
<RumblePure> lifeless: but remember when the problem showed up I had some locally uncommited changes when I tried to commit back to master? you think that caused it all?
<lifeless> at this point, yes
<RumblePure> lifeless: Well I'll try to pin it down some other day, try to find out what's really causing this.
<mgz> okay, that's shiny.
<mgz> not only did sourceforge let me use my launchpad openid to post a bug report (as I've long forgotten my login), but launchpad understood the concept of an upstream bug at sourceforge and it's easy to make pretty linky.
<mgz> it's almost like the days of free software balkanisation are over
<lifeless> almsot ;)
<ciss_> if i try to revert to revision 1, bazaar tells me: "bzr: ERROR: Path(s) are not versioned" - i suppose this is due to some files been unrecoverably deleted. can i tell bzr to ignore missing files and do the revert anyway?
<ciss_> ah, sorry, found my error
#bzr 2010-05-19
<igc> morning
<mgz> morning Ian.
<mgz> request: could you look at https://code.launchpad.net/~simon-kersey/bzr-explorer/568728-fix/+merge/24306 at some point?
<mgz> I did a drive-by comment on in a while back, and don't want the guy thinking I'm ignoring him (I just don't know if the code is right)
<bignose> mgz: it would be churlish of me to chime in on the subject of Launchpad as an OpenID consumer, wouldn't it? :-)
<bignose> anyway, I'm given to understand that wheels are in motion to get a proper OpenID consumer in Launchpad, so that makes me optimistic.
<igc> mgz: I hope to get back to code reviews today
<bignose> igc: glad to see you back in the saddle
<igc> thanks bignose!
<mgz> great, thanks.
<rysiek|pl> hi guys
<rysiek|pl> anybody care to help a bit?
<rysiek|pl> I just nuked my bzr repo
<rysiek|pl> but I have a crapload of checkouts (not branches, checkouts) here and there - what would be the best way to get the newest revisions in the new repo?
<rysiek|pl> 1. restore a backup (40 revisions back), and in checouts do bzr up; resolve conflicts, bzr ci?
<rysiek|pl> 2. just ignore the backups and move a checkout as the new repo?
<rysiek|pl> 3. do bzr pull IN the backup-restored repo FROM the checkout?
<lifeless> 3 sounds plausible to me
<rysiek|pl> 4. bzr push the checkoput INTO the backup-restored repo
<lifeless> as long as you hav heavyweight checkouts, not lightweight (the default is heavy)
<lifeless> 3 and 4 are equivalent
<rysiek|pl> heavy, heavy
<rysiek|pl> okay, great
<rysiek|pl> so, restore a backup, bzr push/pull
<rysiek|pl> trying.
<lifeless> spiv: hi
<lifeless> mwhudson: also ping
<mwhudson> lifeless: hello
<lifeless> bzr smart server in lp
<lifeless> what diagnostics can I get on that ?
<mwhudson> not terribly much easily :/
<lifeless> also, is it still running as a subprocess; and what happens to its stdin/stdout - are they connected to twisted ?
<mwhudson> i think unhandled exceptions should go into oops reports
<mwhudson> yes and yes
<lifeless> trying to figure out why we only get 21KB/s from lp; gathering data as first step
<mwhudson> it's running bzr lp-serve user-id --inet
<lifeless> shoving this under udd as 'slow checkouts hurt distro users'
<mwhudson> ish ayway
<lifeless> ok
<lifeless> do we have statistics / info gathering on the twisted master
<lifeless> I'm particularly interested in socket windows (raw and ssh wrapped), packet delays and so on
<spiv> lifeless: morning.
<lifeless> spiv: python-dev, antoine's message 'Summing up' may be of interest to us and the smart server in standalone mode
<mwhudson> lifeless: not in any very structured way
<lifeless> mwhudson: is that yes if I ask nicely? or 'no, but I didn't want to say that' ? :)
<spiv> lifeless: ta, will look
<mwhudson> lifeless: it's 'conch dumps some crap into a log file about this sort of thing, but i doubt it's of any use'
 * mwhudson sucks a 50 meg file off launchpad over bzr+ssh using hitchiker and watches the network in system monitor
<mwhudson> it's quite surprising
<lifeless> do tell
<mwhudson> lifeless: http://people.canonical.com/~mwh/sm.png
<lifeless> yes
<lifeless> there is something wrong ;)
<mwhudson> it ramps up slowly to a decent rate, then drops right down and slowly ramps up again
<mwhudson> it's a bit odd
<lifeless> I would expect this as a buffering interaction
<lifeless> if a pipe somewhere fills
<lifeless> process swaps/stops getting time slices
<lifeless> the tcp window may not open enough, and can take time to recover
<mwhudson> http grab of the same file is also behaving a bit strangely, but very differently
<mwhudson> http://people.canonical.com/~mwh/sm2.png
<rysiek|pl> lifeless: worked like a charm, thanks
<rysiek|pl> guys, maybe it would be a good idea to estimate, what's the average bandwidth in both situations?
<rysiek|pl> I mean, the graphs show completely different behaviour, true, but maybe the overall average bandwidth at the end of the downloading is more or less the same?
<lamalex> Hey, does anyone know if there's already a bzr equivalent of the git-version-gen autoconf script?
<lamalex> I know I can adapt that to be for bzr, but I figured I'd see if someone had already done it
<rysiek|pl> if so, maybe it would be a good idea to try wgtetting or whatever with a fixed max rate, just below that average
<rysiek|pl> to see if anything strange happens, or not
<lifeless> lamalex: not that I know of
<lifeless> lamalex: I've done something similar for setup.py
<lifeless> lamalex: and drizzle does something similar too
<lifeless> mtaylor: ^ show lamalex the bzr version stuff for drizzle
<mtaylor> lifeless: aroo?
<lifeless> mtaylor: so http peaks at 1mb
<lifeless> bah
<mtaylor> lifeless: oh - gotcha
<lifeless> mwhudson: so http peaks at 1MB
<lifeless> and bzr+ssh at 512KB
<mtaylor> lamalex: it's all in pandora-build ... (which you should use for your autoconf needs anyway) ... but specifically
<mwhudson> lifeless: yeah, after the initial fast burst though http followed a vaguely similar pattern to bzr+ssh
<mtaylor> lamalex: http://bazaar.launchpad.net/~mordred/pandora-build/devel/annotate/head:/m4/pandora_vc_build.m4
<mtaylor> lamalex: I've got to run at the  moment - are you going to be around in 5 hours?
<lifeless> spm: whats that darn tool you swear by
<mwhudson> less of a sawtooth i guess
<spm> lifeless: 'find'
<lifeless> spm: not swear at
 * mwhudson was going for 'awk'
<lamalex> mtaylor, no probably not
<lamalex> but maybe
<spm> lifeless: a hammer?
<spm> context may help - what are you trying to do :-)
<lifeless> spm: for network window / efficiency / analysis
<mtaylor> lamalex: ok. well, I can certainly help you out on this if you still need it when I get back or tomorrow
<spm> AHhhhhh! tcptrace + xplot
<lamalex> mtaylor, thanks
<mtaylor> lamalex: sure!
<bignose> yikes, m4.
<bignose> isn't there a better templating solution that's dependably installed?
<spm> http://www.tcptrace.org/ and http://www.tcptrace.org/manual/node12_mn.html specifically. sheer gold.
<lifeless> mwhudson: what file were you testing with
<mtaylor> bignose: well, not that's integrated with autoconf, no
<bignose> s/better/more human-maintainable/
<mwhudson> lifeless: http://bazaar.launchpad.net/~vcs-imports/linux/trunk/.bzr/repository/packs/7590053cc142a5cb7ca8d0e33022ce2a.pack
<mtaylor> lamalex: that particular macro encodes YYYY.MM.BZR-REVNO into the version ... as we're the only user of that particular function, I haven't generalized it yet.
<mtaylor> ok. I'm off. have fun all
<joerg_> hi
<joerg_> how can I move everything in the root dir of my branch to a subdir?
<joerg_> like:
<joerg_> bzr mkdir src
<joerg_> bzr mv . src/myproject
<joerg_> which of couse does not work ;)
<lifeless> bzr mv $(ls | grep -v src) src/myproject
<joerg_> hmm....that will fail because of some files that aren't under version control
<lifeless> well, adjust appropriately
<lifeless> perhaps bzr ls --versioned
<fullermd> Need a bzr pivot_root...
<lifeless> fullermd: wouldn't address this case
<lifeless> fullermd: (and we have it)
<joerg_> lifeless, well, thx....that works ;)
<joerg_> only .bzignore shouldn't be moved I guess ;)
<lifeless> right
<joerg_> but I will simply bzr revert it
<lifeless> you'll want to mv that back :)
<lifeless> or that, sure
<fullermd> We do?  Where?
<lifeless> tree transform
<lifeless> it can handle a merge that moves the root
<lifeless> we don't have a userspace command for it, yet.
<fullermd> Yeah, but that's not much of a UI  ;)
<lifeless> mwhudson: what ISP do you have?
<mwhudson> lifeless: vodafone
<mwhudson> but my local connection is through a telecom 'cabinet'
<lifeless> for ADSL ?
<mwhudson> yar
<lifeless> I'm peaking at ~ 128K
<lifeless> which is, frankly, sucky.
<mwhudson> oof
<mwhudson> what does your modem think you're synced at?
<lifeless> dunno, don't have the admin password for it
<mwhudson> are you still in the short term rental place?
<lifeless> yes
<lifeless> 3 months 1 week to go
<fullermd> Not that he's counting down or anything.
<mwhudson> i'm not too surprised that your internet sucks then
<lifeless> hah
<lifeless> its a private residence the owner is on sabbatical, as opposed to a serial rent environment
<mwhudson> ah ok
<lifeless> we've taken over the phone account etc
<lifeless> I suspect a call to telecom is in order
<mwhudson> maybe the owner was on an old, capped plan?
<lifeless> 128K is 1Mbit
<mwhudson> noone seems to bother with that any more though
<lifeless> I changed the plan to the upsized one
<lifeless> one possibility is an adsl1 modem
<lifeless> another is bad wiring
<mwhudson> distance to the exchange?
<lifeless> who knows
<lifeless> telecome knows
<lifeless> thats who knows
<lifeless> spm: is ParseOptions: packet 41290 TCPOPT_SACK option truncated, skipping other options
<lifeless> spm: a meaningful worry - just use a longer snaplen and repeat?
<spm> lifeless: not sure. I usually grab the entire snaplen - debugging http so you want to see the data.
 * igc lunch
<lifeless> heh, in this case the data is just a pack so 'meh'
<lifeless> or ssh, so equally
<lifeless> though
<lifeless> we may want to write a ssh analyzer
<lifeless> if we can get the session key out of twisted ?
<lifeless> mwhudson: ^
<lifeless> mwhudson: would that be a lot of work, do you think?
<mwhudson> lifeless: no idea at all
<mwhudson> it would be at least a moderate amount of work
<spm> mwhudson: try suggesting it's impossible perhaps?
<lifeless> spm: -s doesn't seem to give me a graph
<spm> lifeless: -S      create time sequence graph[s]
<spm> wrong case.
<spm> the stock xplot via apt, *may* not be able to deal with the output generated tho. on just about every other system I've used, I've had to manually compile 'his' version to have it work.
<lifeless> also, for nuisance value, the microwave here is on the same freq as the ap
<spm> \o/
<lifeless> so dinner time is no-internets-time
<spm> awesomely awesome!
<spm> I know my wireless mouse used to get horribly laggy when the wireless was busy.
<lifeless> hmm, it decided a2b was empty
<lifeless> but b2a has dome something
<spm> that sounds ... vaugely right. a2b would be likely just acks.
<spm> tcptrace -l, to get a view?
<spm> summary text view as in.
<lifeless> otp
<spm> err - not summary. whatever. :-)
<lifeless> turns out to be wifi fail
<lifeless> however, am now getting 800KB/s to melbourne
<spm> sweet
<lifeless> still a bit bursty
<lifeless> drops down to 200 every now and then
<lifeless> going to be interesting to debug on top of :P
<lifeless> verra noisy
<lifeless> I wonder if I'm going to need a local ping background measurement ;P
<lifeless> 700K to b.l.n
<lifeless> \o/
<lifeless> 800
<lifeless> 850... you can do it
<lifeless> 100 :(
<lifeless> sawtooth
<mwhudson> lifeless: i guess doing a regular bzr+ssh transfer off say devpad would be an interesting comparison
<lifeless> does hitchhiker have a non interactive mode ?
<lifeless> echo 'get /~vcs-imports/linux/trunk/.bzr/repository/packs/7590053cc142a5cb7ca8d0e33022ce2a.pack' | hitchhiker bzr+ssh://bazaar.launchpad.net :P
<lifeless> boom
<lifeless> I saw the same massive dropoff you did
<lifeless> spm: take pity on me; give me a sample session with tcptrace + xplot
<lifeless> I hav a trace
<lifeless> tcptrace -l shows sensible things
<spm> :-)
<spm> sure.
<spm> have you the trace somewhere I can munge at the same data?
<lifeless> sure
<lifeless> let me shove it on devpad
<spm> ta
<lifeless> the files ssh and http on devpad:~robertc - copying now
<lifeless> done
<lifeless> or thereabouts
<spm> ta, grabbing
<spm> You don't have permission to access /~robertc on this server. haha
<lifeless> I don't?
<lifeless> I beg to differ
<spm> oh wait. nm. I was using http access. lemme just scp it.
<lifeless> yah, not in ~public_html
<spm> righto. so looking at http. tcptrace -l http ;; on a bigger more complex snarf, i'd start with -b (brief) to get an idea of which streams to look at, but here is easy.
<spm> so no supriose that all the data is coming from crowberry; a is just acking.
<lifeless> right, I tried to capture just one file
<lifeless> well, there is the initial request ;)
<spm> :-)
<spm> tcptrace -G http <== builds *all* the graphs
<spm> xplot -x b2a_tsg.xpl a2b_tsg.xpl &
<spm> the -x and specifying both will allow you to zoom in on 1, and see the same zoom on the other at the same time. way cool.
<spm> I find it useful to not touch the vertical adjust, but stretch the two graphs fully horizontally. ymmv.
<lifeless> bad flag argument -x
<spm> right. you need his version of xplot then.
<lifeless> grah
<lifeless> ok
<lifeless> has he considered getting his patches upstream ?
<spm> no idea :-)
<spm> gawd dammit. one day I will remember that right click exits.
<lifeless> I wonder if tim sheppard even knows about this patchset
<spm> possibly not
<lifeless> shep at xplot.org
<lifeless> ^ go, mail him.
<spm> will do
<spm> but first... :-)
<lifeless> hmm, C code needs a little love
 * spm starts to play spot the yak ;-)
<lifeless> ok, much better
<lifeless> it could use a window bitmap cache
<spm> if you stretch horiz, you'll be able to better zoom. vert if really useful imho.
<lifeless> so flat bits are stalls ?
<spm> so here we're basically looking for 1 main thing; other maybes. is the tcp window full. which - apparently is sure as hell isn't.
<spm> slowdowsn of some sort, yeah
<spm> aroud 12:54:20 "something" happened
<lifeless> hah! it does tmiezones
<spm> oh wow. zoom on ~ 12:54:19 window full.
<spiv> And around 13:22, lunch happened.
 * spiv makes it so
<spm> :-)
<lifeless> 14:54:19 you mean :P
<spm> lifeless: whatever :-D
<spm> but note also the large numbers of '1's and '2's.
<lifeless> chatty
<spm> looks like a fail for acks to be received
<lifeless> how do you you zoom out
<spm> left click
<spm> zoom by selecting; then left click
<lifeless> so whats a 1 and a 2 - or should I e reading at this point
<spm> rtfm, resends, once, twice of the same packet istr.
<lifeless> so you're thinking massive packet loss ?
<lifeless> the yellow band is the window size, right ?
<spm> actually - 1/2 I think are duplictae acking.
<spm> the delta between the horizonatal lines is the window
<spm> yellow and green
<lifeless> 53:24.5 has a similar region
<lifeless> hah, is one green?!
<spm> yeah. a couple of window fulls, imho, isn't bad. not great, but not bad. keeping in mind this is *your* window (aiui), not crowberrys.
<lifeless> sorry, I'm unclar
<spm> if you zoom in on the start, you can see the scaling take off.
<lifeless> is the gap 'data in the window' or 'amount that can be in the window'
<spm> amount that can be in the window.
<lifeless> ok
<lifeless> and can we tell amount in flight/in the receiver buffer
<spm> each white cross, is in fact a line with 2 arrows, zoom right in on one. that's a data packet.
<lifeless> I see black lines with arrows
<spm> http://www.tcptrace.org/manual/node12_mn.html <== check the 2nd diagram by way of example
<spm> based on that - it *looks* to me like crowberry isn't hammering you as hard as it could; or your pipe is full. ??
<spm> tho the backoff from ~ 3/5ths to end is... odd
 * spm checks throughput...
<spm> hrm. ~ 500kps. not too shabby.
<lifeless> avg
<lifeless> peaked at 880 or so
<lifeless> so lots of room for improvement
<spm> which, assuming default tcpwindow sizings on crowberry is about max for london to AU given latency.
<lifeless> I'm in nz ;)
<spm> so slightly closer eh? ;-)
<lifeless> no, sadly, no
<lifeless> can/should we tweak the window settings up ?
<lifeless> 350ms 64 bytes from crowberry.canonical.com (91.189.90.11): icmp_seq=5 ttl=42 time=328 ms
<spm> we can, trivially. I'd advise yes. but would want to cross check 1. what they actually are.
<lifeless> bah
<lifeless> 64 bytes from crowberry.canonical.com (91.189.90.11): icmp_seq=5 ttl=42 time=328 ms
<lifeless> and ask why the defaults aren't large enough to handle the earth.
<spm> 2. watch carefully JIC of funkies (I doubt we'd see any)
<spm> nfi. that's the default that linux kernels come with aiui.
<lifeless> yeah
<lifeless> the aarnet mirror admin
<bignose> ho, Bazaar folk. what is the preferred pastebin?
<lifeless> swears that everyone should up their window settings
<spm> yeah. that supersize macca's theirs
<spm> they*
<spm> nod
<lifeless> bignose: one that works. And not pastie.
<lifeless> me, I use pastebinit
<lifeless> spm: thanks for this; I think there is more to nut out here
<bignose> my favourite, <URL:http://paste.ca/>, has been responding 500 errors for weeks.
<lifeless> spm: I need to do a couple of 'new country' chores before shops close.
<spm> lifeless: np. i suspect there is, but it's all clues.
<bignose> I'll try that one, lifeless
<spm> shoo
<lifeless> spm: but I might grab a little more of your time to look at the ssh trace after, if thats ok with you
<spm> surely
<bignose> lifeless: what URL?
<lifeless> its been .... some time, since I did this sort of analysis myself
<lifeless> bignose: apt-get install pastebinit
<spm> eek. crowberry is the, small, default.
<lifeless> spm: I can has RT ticket for 'we run servers please' ?
<bignose> ooh! naughty Ubuntu worker, everyone knows âaptitudeâ is the command to recommend :-)
<lifeless> spm: I mean, should I file an RT saying all our servers facing the net might need stuff ?
<spm> if you create said RT, I don't see why not ;-)
<spm> lifeless: sure. it'll help us track it at least.
<spm> fwiw. the *best* way to do these is get two sniffs at the same time. in this case, one on your machine, and one on crowberry. and display the sender from crowberry (b2a) and receiver at yours. you get a better view of the packet flows with times and whats missing etc.
<bignose> I've had a crash on âbzr shelveâ, with a âMalformedTransformâ exception <URL:http://pastebin.com/yk6ziW8V>
<bignose> there appear to be some bug reports with that same error, but different use cases
<bignose> Launchpad is not displaying bug reports properly for me. can someone check whether the crash I'm getting is already reported, and/or submit that traceback to the report?
<bignose> it's reproducible (I've pasted the version where I used â--no-pluginsâ), and I can make the repository available if it would help diagnosis.
<lifeless> spm: that would be awesome. I can has packet capture privs on crowberry ? :)
<spm> hahaha. no. *I* wouldn't even ask for that. :-)
<lifeless> mwhudson: how do I get that linux pack onto the staging bazaar.launchpad.net ?
<lifeless> mwhudson: /win 67
<mwhudson> spm: um, no quick idea, i guess you can sftp it up...
<bignose> it seems to be because the shelve involves undoing a rename
<bignose> but meanwhile the original filename is occupied by a new file, that isn't versioned.
<bignose> so I'm not sure what I expect âshelveâ to do in that case. no crash, of course, but I don't know the right behaviour.
<lifeless> what bzr version?
<lifeless> also is there a bug about the rendering for you ?
<bignose> <URL:http://pastebin.com/yk6ziW8V>
<bignose> no, I don't have a Launchpad account and it's not working well for me in any case :-)
<bignose> Bazaar version 2.1.1
<lifeless> bignose: ok, we'll need to open a bug for you for that
<lifeless> bignose: you say there isn't a bug open about launchpad rendering badly?
<lifeless> bignose: could you put an email together, to me, with screen shots and so on that shows lp behaving badly, and I'll make a bug report out of it
<PainBank> any upload anything to sourceforge using bzr?
<PainBank> should I create a seperate trunk and branches directory (I am more familiar with doing this in svn) or just push it all up to SF?
<parthm> PainBank: I haven't uses sf in a long time but bzr doesn't require specific directories like trunk and branches. You can probably push it all up as long as the project devs agree to treat dir x as trunk / mainline.
 * fullermd eep!'s at broken dirstate code   :(
<parthm> PainBank: this article seems to be doing what you want http://sina.salek.ws/content/migrating-subversion-bazaar-including-special-guide-sourceforge-projects
<lifeless> fullermd: ?
<fullermd> lifeless: https://bugs.launchpad.net/bugs/582656   :(
<ubot5> Launchpad bug 582656 in Bazaar "Compiled _dirstate_helpers causes crash with specified file commands (affected: 1, heat: 6)" [Critical,Confirmed]
<bignose> lifeless: shelve crash reported in Debian BTS now, <URL:http://bugs.debian.org/bug=582210>
<bignose> lifeless: the Launchpad rendering problems seem to be a strange interaction between Iceweasel and my proxy; change either of those and it's alright.
<bignose> lifeless: shelve crash reported in Debian BTS now, <URL:http://bugs.debian.org/582210>  (fixed the URL)
<lifeless> bignose: what proxy are you using ?
<lifeless> launchpad is on https generally, so I wouldn't expect anything in it except -perhaps- css files to hit your proxy
<lifeless> nevertheless, there is a problem :)
<vila_> hi all
<vila> vila_: Sorry for using your nick, I'll leave
<vila> tsk tsk
<parthm> vila: hi
<parthm> vila: i noticed you have claimed the reivew https://code.launchpad.net/~parthm/bzr/538868-message-for-heavy-checkout/+merge/25336 ... i could land it if it looks ok it you
<vila> parthm: hi !
<parthm> vila: or if i can get another reviewer :)
<vila> parthm: I didn't claim it, I suspect jam assigned me instead, I plan to review it soon
<fullermd> Maybe vila_ claimed it for you.
<parthm> vila: ah. ok :) .. no hurry. was just wondering.
<parthm> fullermd: ha :)
<vila> annoying squatter this vila_ ...
<fullermd> lifeless: I can't trivially run selftest, lacking testtools   :|
<fullermd> lifeless: Won't have time the next few days to try and fudge it into place; got a week of stuff to do before I leave town Friday.
<vila> fullermd, lifeless : babune has a freebsd8 slave, can I help ?
<fullermd> Mmm.  Building the bzr-2.1.1 tag in my 2.1 branch seems to die too, though the installed 2.1.1 doesn't
<fullermd> It was rebuilt since my last OS/python upgrade though, so it's not that...
<fullermd> Holy crow it takes a long time to branch bzr.dev on local disk.
<vila> die ? How ?
<lifeless> gnight
<fullermd> Hm.  It seems to work on my server, which is fbsd8/i386/py2.6.4.  Failing on my workstation, fbsd-current/amd64/py2.6.5.  So, if everything's different, the result is different   :p
<fullermd> Oh, pyrex 0.9.8.6 vs 0.9.9 too.  Hm.
<fullermd> Maybe I can test that switch quick-like...
<fullermd> That could explain why the system-wide 2.1.1 works, but hand-building it doesn't; the system-wide has the generated files from the tarball.
<fullermd> In fact...
 * vila holds his breath and hopes fullermd will finish his sentence soon enough
<fullermd> Yes, if I build from the 2.1.1 tarball, it works.  If I build from the bzr-2.1.1 tag it blows chunks.  diff shows only the generated .c/.h files as different between the trees.
<fullermd> So it sounds like pyrex 0.9.9.
<vila> hmm, pyrex 0.9.9 here, but maybe the .c files has not been modified since I upgraded....
<vila> err, the .pyx files of course
<vila> one more hole in babune setup....
<vila> a lucky one this time\
<fullermd> Oh, that should be quick to test with that repro script (or manually)
<fullermd> Actually, don't even need a modified file in the tree.
<fullermd> So just 'bzr stat bzrlib' in the bzr.dev tree should tell you.
<vila> tell me what ? what repro script ?
<fullermd> https://bugs.launchpad.net/bzr/+bug/582656
<ubot5> Launchpad bug 582656 in Bazaar "Compiled _dirstate_helpers causes crash with specified file commands (affected: 1, heat: 6)" [Critical,Confirmed]
<fullermd> Or just 'bzr stat bzrlib'; I get the crash (with 0.9.9-built stuff) there too.
 * vila branching (don't ouch the babune working one !!!)
<vila> yeah, ouch, exactly, not a typo !
<fullermd> Pfft.  Wimp.
<vila> boom
<vila> KeyError: ''
<fullermd> Oh, good.  I've successfully ruined your day; now I can go sleep in peace   8-}
<vila> fullermd: hehe, I'll check which pyrex version were used to generate my files and add a comment
<fullermd> (which I'm about 3 hours overdue for at the moment, so  *bamf*)
<fullermd> It leaves a comment right on the first line.  Handy.
<vila> I thought so
<vila> Generated by Pyrex 0.9.8.6 on Thu Apr  1 17:19:38 2010
<vila> haha, so funny
<vila> not
<fullermd> Just confirms my long-held suspicion that dirstate is a conspiracy against me.
<vila> 656 diffs...
<fullermd> Between the generated files?
<fullermd> Yeah, I think the diffs are big even between runs of the same version.  Suckage   :|
 * vila searches the magic incantation to ignore the comment lines mentioning the source file
<fullermd> Well, at least we could build with cython instead...  except [last time I tried] that yields stuff that doesn't work at ALL.
<fullermd> But that would fix THIS bug.  Sorta   ;)
<vila> urgh, you're right, bunch of moved around code or added "registers" .... go figure the problem :-/
<vila> wow __Pyx_AddTraceback call added 8-{
<vila> err, no, calls deleted in fact (/me switches the windows to a sane order)
<vila> lucid is still using 0.9.8.5, yeah for responsible distro maintainers using well tested versions :-P
<fullermd> Figures.  CD I ordered last week showed up in my mailbox today, so obviously something UNpleasant had to happen to counterbalance and leave the day centered.
<vila> ok, got the failure in the test suite, that should narrow down the problem
<vila> bah of course it's a blackbox test :-/
<vila> 7 failing tests already
<fullermd> Oh well.  I'll still have the CD after the bug is fixed.  Nya nya nya, Fate!
<vila> lol
 * fullermd quickly hides.
 * vila setup a dedicated babune job :)
<vila> 32^W41^W53 failures so far, one of them ought to be easier to debug than the others
<fullermd> Actually, I'd WAG that tracking it would be easier by just dumping some debug printf's around where it crashes to see what unexpected structure (or lack thereof) the pyx is giving back, and dig down from that direction.
 * vila goes back to fixing its keyboard layout before turning insane
<fullermd> ... of course, just using the phrase "debugging printf" probably shows I'm not qualified to deal with python in the first place   :p
<vila> fullermd: except a pdb.set_trace() with a simplified context may be even more handy, I'll look into it when the run finish
<vila> fullermd: same concept, different tool )
<vila> :)
<fullermd> Well, I require_feature(zzz), so I'll leave it in your hands for the next fartoofew hours.
<vila> I would probably wait for jam to turn up anyway he knows pyrex far better than me
<vila> fullermd: sleep well
<vila> and thanks for the heads-up !
 * fullermd  <---  canary in the bzr-mines.
<vila> hmm, I was about to joke about sending some gas and thought better :)
<bialix> bonjour vila
<vila> hello Sacha :)
<bialix> my patch for backslashes landed to 2.1 last night, thanks jam
<bialix> I think I should provide a patch for bzr.dev to merge it cleanly now?
<bialix> because that was for 2.1 only
<bialix> and 2.2 has different command-line parser
<bialix> or the person who will do merge simply ignore my changes?
<bialix> vila: ^
<spiv> bialix: a patch to merge it cleanly would be good, I think
<bialix> that's my understanding as well
<vila> bialix: it would be better if you merge 2.1 to trunk to ensure the conflicts are properly resolved
<bialix> I'm just double checking
<bialix> ok, so maybe I can adapt some my new tests
<vila> but if you propose a patch including your 2.1 merge in its ancestry everything should be fine
<vila> grr damn xmodmap bug !
<mgz> morning all.
<mgz> vila: just posted thingy about leak experiements, basically what I said yesterday evening
<vila> mgz: Hi ! I haven't checked my mail yet :-/
<mgz> am now going to try and do some actually-useful things.
<mgz> I mean just, like, that second.
<bialix> heya mgz
<gour> igc: hello, is bug #541626 bzr or fastimport's stuff?
<ubot5> Launchpad bug 541626 in Bazaar Fast Import "'BTreeBuilder' object has no attribute '_find_ancestors' (affected: 2, heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/541626
<asabil> jelmer: ping ?
<jelmer> asabil: hi
<asabil> hey jelmer, I just wanted to know if you would have an idea about this assertion error failing:
<asabil> File "/home/asabil/.local/lib/python2.6/site-packages/dulwich-0.5.1-py2.6-linux-i686.egg/dulwich/pack.py", line 926, in iterentries
<asabil>      assert isinstance(offset, int)
<asabil>  AssertionError
<jelmer> asabil: not without context...
<asabil> I am trying to clone an internal git repo, and it fails with that error
<asabil> I can paste the crash file somewhere
<jelmer> what versions of bzr-git/dulwich ?
<asabil> from source
<asabil> freshly installed
<asabil> the crash trace is here: http://pastebin.com/SkbAkPeE
<jelmer> asabil: from the tarballs, from bzr ?
<asabil> from bzr
<maxb> Is there any good reason why bzrtools releases are strictly bound to bzr releases?
<jelmer> asabil: can you check what the type of offset is ?
<asabil> yep, give me few minutes please
<asabil> it takes a lot of time to clone a 6Gb repo
<jelmer> oh, if it's a 6gb repo I suspect the type might be a long
<jelmer> I don't think we support repositories that big yet
<asabil> is there a way I can help fixing this ?
<jam> maxb: by request of the author
<maxb> ...?
<jam> abentley prefers that the plugin aborts early rather than claims to work and fails late
<jelmer> asabil: we'd need support for larger pack files in dulwich first I think
<jelmer> asabil: do you have any pack files > 2Gb?
<asabil> let me check
<jam> vila: I'm awake, but not officially working yet
<asabil> jelmer, yes I think there is a 6Gb pack file
<jelmer> asabil: in that case, you'd really need to patch dulwich first
<jelmer> at the moment it doesn't support index files for pack files larger than 2Gb
<asabil> ok, I will start there then
<jelmer> you might also want to check nobody else is working on that support yet, I think one of the Google folks was interested in it as well
<asabil> jelmer, on the mailing list ?
<jelmer> asabil: yep
<asabil> ok I will, thanks
<mok0> I'd like to access the revno from inside a program running out of a bzr repo. Does anyone have a code snippet that can show me how to do that?
<mok0> I've been browsing bzrlib for a function, but not been lucky
<bialix> branch.last_revision()
<mok0> bialix, what's the path to "branch" ?
<bialix> branch is the instance of bzrlib.branch.Branch
<bialix> e.g. br = bzrlib.branch.Branch.open('path')
<bialix> print br.last_revision()
<bialix> or maybe br.last_revision_info()
<bialix> check the API
<mok0> bialix: got it working, thanks a bunch!
<bialix> np
<mok0> Now I need to figure out how best to include that in my django site
<bialix> http://wiki.bazaar.canonical.com/Integrating_with_Bazaar can be useful
<mok0> bialix: indeed
<vila> jam: ok, back from shopping (a *real* chair for my desk :)
<parthm> jml: hi
<parthm> jml: .. sorry. i meant to ping jam.
<parthm> jam: hi
<ovnicraft> hi folks, when i push in lp i give the message, pgrade the repositories to the same format for better performance.
<ovnicraft> i found in the web this command: bzr upgrade --2a
<ovnicraft> so i want confirm this before to do it
<ovnicraft> its ok?
<jelmer> ovnicraft: yep
<ovnicraft> jelmer, thx
<jelmer> ovnicraft: it might also be that the remote branch is out of date while the local one is newer
<jelmer> ovnicraft: in that case you might want to upgrade the branch on lp
<ovnicraft> in lp has format 7
<ovnicraft> jelmer, i get that is 2a
<maxb> format 7 sounds like a branch format
<maxb> Bazaar formats can get confusing, because there's a repository, a branch, and a working tree, all with independent formats
<jelmer> it is, but I think it's probably the branch format that's part of 2a
<jelmer> maxb: yeah
<maxb> bzr info -v tells all
<jelmer> launchpad displays the long names
<ovnicraft> sorry, branch format 7, repo format 2a
<jelmer> ovnicraft: did the upgrade help?
<ovnicraft> that info from lp, i am upgrading the repo
<fullermd> jam: Latest bug comment is as far as I can take it.
<jam> fullermd: that's the "its a really big diff that is hard to understand" ? :)
<jam> can you email me the output?
<fullermd> No, just tracked to one line that's differing in whether it succeeds or not.
<jam> ah, didn't get that one yet
<fullermd> Hmph.  I just rm'd the dir   :p
<jam> you still have 0.9.9 pyrex installed, right?
<fullermd> Yah, regenning.
<jam> thanks
<[1]reggie> jam (or anyone else) -- how would I setup bazaar.conf to use sendmail to send mail?
<[1]reggie> I'm on windows but have a sendmail binary
<[1]reggie> just setting the config line in bazaar.conf doesn't appear to do it
<jam> [1]reggie: first off, "to send mail"
<jam> Under what circumstances?
<[1]reggie> bzr commit
<fullermd> Mailed.
<jam> fullermd: thx
<jam> [1]reggie: I presume you are then using 'bzr-email' ?
<[1]reggie> let me check
<jam> fullermd: I think you mentioned that cython doesn't work for you. Can you give a bit more detail? (I use it here)
<jam> and I've at least reproduced the failure with your test script.
<jam> Interestingly you do have to pass a path, which may be a decent hint
<[1]reggie> jam, we have a emailer.py that is in our mysql_plugins folder.  if post_commit_mailer = smtplib then it tries to use that.  otherwise it uses whatever post_commit_mailed is set to
<[1]reggie> I have mine set to my sendmail instance
<[1]reggie> I just ran a test commit and got no error and no error in .bzr.log but also no email
<[1]reggie> very frustrating that smtplib doesn't support SSL 465
<jam> [1]reggie: k. I'd start by saying I don't have a copy of, nor access to the mysql plugin
<jam> so there isn't a huge amount of support I can do on it
<[1]reggie> I know
<jam> I will point out that bzrlib.smtp_connection.SMTPConnection *can* take an optional "_smtp_factory" parameter (originally designed for the test framework). And you could pass SMTP_SSL in there instead.
<jam> If mysql cribbed the email sending from bzr-email
<jam> that also has a "_smtplib_implementation" attribute, which instantiates an SMTPConnection
<jam> which would be another way to inject your own SMTP_SSL object
<TresEquis> jelmer: re https://bugs.launchpad.net/bzr/+bug/480102, the only thing odd about the last-imported revision for lp:karl3 is that it includes a change to an svn:eol-type property
<ubot5> Launchpad bug 480102 in Launchpad Bazaar Integration "assert len(tview) == tview_len (affected: 5, heat: 48)" [High,Triaged]
<jam> [1]reggie: another option is too look at how bzrlib/mail_client.py works
<jam> which is where 'bzr send' hooks into sending notifications to your existing mail client
<jam> so that you have an opportunity to write messages to it.
<jam> probably not exactly what you want for the mysql post-commit effect, though
<TresEquis> that change shows up here:  svn diff -c 5140 http://osi.agendaless.com/bfgsvn
<TresEquis> bug not here:  bzr log -p --limit=1 lp:karl3
<jelmer> TresEquis: bzr-svn doesn't import changes to svn:eol-type properties
<TresEquis> OK, but would that explain the checksum issues on the next revision?
<TresEquis> it also added 'svn:keywords' property, with 'Id' as the value
<TresEquis> that might cause SVN to believe something different about the content of the file than bzr, maybe?
<fullermd> jam: Don't remember offhand, it was a couple months ago.  But it just flat didn't work at all for anything.
<fullermd> jam: Yes, need the path.  Don't need changes though; I found I could just 'bzr stat bzrlib' in a pristine tree to bring it up.
<jam> so my immediate guess is that pyrex is leaving an exception on the stack, and then accidentally checking the exception state as part of the "x == y" statement
<fullermd> Mmm.  The object comparison does that?
<fullermd> My fiddling fingered that one specific line of the C.
<TresEquis> jelmer: the next commit on the karl/trunk branch (the one which fails to import) is svn r5144, which touches (only) the file whose properties got changed in svn r5140
<jam> fullermd: adding a "PyErr_Clear()" just before that line makes everything just peachy
<jam> *ugh*
<fullermd> Wacky.
<jam> Looking at: http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/CHANGES.txt
<jam>   - Exceptions caught by an except clause are no longer put into the thread     state and cannot be retrieved using sys.exc_info(). To access the caught     exception, it must be bound to a name in the except clause. A third name     can be supplied to capture the traceback.
<jam> So I have another thought, we'll see
<jam> looks like I got it
<jam> change the bare "except KeyError:" to "except KeyError, e:"
<jam> and things are happy again
<jam> can you try it on your system? (line 1241)
<fullermd> Hm.  Well, that makes 'bzr stat bzrlib' work.  The test script still fails, though, as does stat bzrlib/_dirstate_helpers_pyx.pyx
<fullermd> (it's 1239 in my bzr.dev)
<jam> fullermd: my guess is that we just have to trap all of these bare exceptions, because pyrex is fubar without it
<jam> we use it in a fair number of other places
<jam> basically, look for "except[^,]*:"
<fullermd> Changing the one at 1222 as well fixes it.
<jam> a) This is definitely a bug in pyrex, and I'm trying to write a simple test case to show it
<jam> b) we can probably work around it for now
<fullermd> (well, fixes this incarnation of it anyway; who knows what evil lurks in the hearts and minds of any other except's in there)
<jelmer> TresEquis: hmm
<jelmer> TresEquis: *looking*
<jam> fullermd: reproduced
<jam> I'll file a bug on pyrex
<fullermd> I guess this just shows how version control systems can help you find bugs   :p
<TresEquis> svn collapses the $Id: ...$ string in its internal representation when that svn:keyword is set, I think
<TresEquis> a stupid CVS compatibility hack
<jelmer> TresEquis: bzr doesn't touch that, it shouldn't really affect it
<TresEquis> it wouldn't cause bzr and svn to have different ideas about the payload for that file?
<jam> fullermd: as near as I can tell, dirstate_helpers is the only extension that uses exceptions without objects, I'll put up a patch
<TresEquis> jelmer: I'm trying now to check out the karl/trunk stuff from a copy of 'bzr' with a pdb.set_trace() just before the call to main()
<TresEquis> so that I can look at the stack when the exception happens
<TresEquis> crap, bzrlib is bailing out without giving me a shot at the traceback / stack frame
<jam> fullermd, vila, lifeless: https://code.edge.launchpad.net/~jameinel/bzr/pyrex_099_bug_582656/+merge/25625
<fullermd> Purdy.
 * fullermd thanks jam.
<mgz> amusing pyrex bug, well tracked down jam.
<fullermd> Oh, right, "amusing" was totally the first word that came to my mind last night   :p
<mgz> maybe it's one of those things that's only funny after the fact ;)
<fullermd> It'll give us something to chuckle over in the rest home, anyway.
<vila> jam: setting a run on babune
<vila> jam, fullermd : http://babune.ladeuil.net:24842/job/debug-freebsd/2/
 * vila dinner, will check later
<vila> rhymes :)
<lfaraone> I'm on a selow connection, and I want to only make changes to a branch then push them up somewhere on launchpad, how can I minimize the data transfer? (I don't really care about full history)
<TresEquis> jelmer: sigh, the traceback is no help, as the caller (who has computed the window) is implemented in C
<jam> vila: I'm not sure what in that sentence rhymed... but maybe in french? Anyway, thanks for the run. I'm pretty confident, having used pyrex 0.9.9 here.
<vila> jam: dinner with later ?
<jam> I've never pronounced "later" as "linner" but maybe you do :)
<vila> damn, for once there was no typo :)
<jam> Now if you said "date: will check late"
<fullermd> That would doubly rhyme, since late dates cause strife with the wife.
<vila> talking about wife.... see you later :-P
<mgz> Hm, should I file a new bug for my three hashcache-related test failures, or should I piggyback on bug 70272 from 2006
<ubot5> Launchpad bug 70272 in Bazaar "test failure (TestHashCache) (affected: 0, heat: 0)" [Medium,Confirmed] https://launchpad.net/bugs/70272
<mgz> changing the three tests not to sleep for four seconds each would be nice as well, can't they be utimed into the past?
<mgz> ...think I'll file a new one, mine's certainly FAT related, just tried unsetting TMP and they pass
<cbz> what is eclipse doing constantly running bzr in the background?
<jelmer> TresEquis: :-(I
<cbz> because it keeps ending up running out of heapspace - and complains about Decorators
<fullermd> Calculating missile trajectories for when it becomes self aware and takes over.
<TresEquis> jelmer: the offending svn revision is actually 5147, not 5140
<TresEquis> and the oddity is that the 'tview' string looks like a real revision of the file
<TresEquis> but it corresponds to neither the prior version (5146) nor the updated one (5147)
<TresEquis> the tview_len value is the actual length of the file in r5147
<TresEquis> so I have no idea where the bogus version comes from
<TresEquis> jelmer: OK, the 'view' string is *not* a valid revision:  it contains a Python syntax error, at least
<jelmer> TresEquis: it doesn't occur anywhere in history?
<TresEquis> jelmer: nope
<MTecknology> In bzr explorer, is there any way to run 'bzr pull' a lot of branches at once?
<TresEquis> jelmer: it looks like a partial / intermediate change between the version of the file svn r4908 and the version in svn r5090
<TresEquis> but it also includes text which wasn't added until 5147
<TresEquis> the developer who committed 5147 maybe was using bzr-svn?
<TresEquis> I don't know if there is any way to see "fingerprints" left by such a commit, assuming bzr-svn made it
<ree> hi jelmer TresEquis
<TresEquis> ah, ree is the developer I spoke of
<ree> ze one who messed up things, right :)
<TresEquis> ree:  do you think you might have committed svn r5147 via bzr?
<ree> not sure.
<ree> or bzr, or merge from our imagedrawer branch... which was also bzr'd
<ree> so this may well be the root of the problem but I don't know how to be sure
<ree> merge from our imagedrawer branch = with pure svn, that is
<TresEquis> I do see a bunch of bzr: properties on the svn r5090 dump
<TresEquis> which is the one where you merged the imagedrawer branch
<ree> yes. I am not even sure if that one was merged with bzr or with svn
<TresEquis> bzr:revision-info, bzr:ancestry, bzr:file-ids, bzr:revision-id, bzr:text-parents, bzr:text-revisions
<TresEquis> plus svn:mergeinfo and svk:merge ;(
<ree> how nice
<ree> the svk bit was someone else ;)
<ree> TresEquis, in fact it is possible that I done that one with svn
<ree> sorry, usage history longer then memory
<ree> jelmer, would it not be possible, in theory, that bzr-svn just ignores the wrong info, and misses "something" but not the whole lot?
<ree> 'cause it may have been my fault, but if I could do it others will do it I can guarantee
<ree> so that's maybe something bzr-svn should be prepared of
<ree> ^
<TresEquis> I think it may be possible to scrub out the bzr: revision properties
<TresEquis> I will want to try on a scratch repo first
<ree> TresEquis, that would solve it
<TresEquis> ree: those bzr: properties are not "revision properties" (which are unversioned, and can be changed later), but "tree properties"
<TresEquis> which are revisioned
<ree> d'oh
<ree> does this prove that it was me with svn? or it could have been bzr?
<TresEquis> I don't see how svn would have been adding bzr: properties
<TresEquis> but using svn to merge a branch to which those properties had been added earlier via bzr-svn would be plausible
<TresEquis> I also have no evidence that those properties have anything to do with the error
<TresEquis> none of those properties are on the affected file, or its parents
<jelmer> TresEquis: but they mention the affected file perhaps?
<jelmer> TresEquis: what version of bzr-svn are you testing with?
<TresEquis> 2.1.1
<ree> jelmer TresEquis it was definitely the case, that the properties were on the branch being merged
<jelmer> TresEquis: of bzr-svn I mean?
<ree> but, what buggers me is that there is no evidence that those properties have anything to do with the error
<TresEquis> jelmer: http://paste.ubuntu.com/436359/
<ree> jelmer, I have the issue with 1.0.2
<jelmer> ree: Have you tried bzr-svn trunk ?
<ree> no, but I can
<jelmer> please do
<TresEquis> jelmer bzr plugins says 1.0.2
<jelmer> TresEquis: can you please also try with trunk ?
<TresEquis> the file which blows up the checkout / import is karl/trunk/karl/content/views/blog.py
<TresEquis> jelmer: like so?  $ bzr co lp:bzr-svn ~/.bazaar/plugins/svn
<jelmer> TresEquis: yep
<hno> How do I temporarily go back to a specific revision? Neither update or switch seem to take revision specifiers.
<ree> TresEquis, tx
<hno> I can do a checkout, but that seems a bit overkill..
<TresEquis> hno: bzr up takes a -r / --revision arg
<hno> TresEquis: Maybe by bzr on this box is too old then.. 1.18.1.
<hno> long overdue for upgrade anyway.
<TresEquis> hno: I really like the new "shared revisions" repo format
<ree> jelmer, checkout of our project will take some time, cc 10 min
 * ree doing with trunk
 * TresEquis as well
<TresEquis> and halfway there
<hno> TresEquis: "shared revisions"? Is this part of the 2a format?
<TresEquis> "Shared repository with trees"
<TresEquis> right, 2a
<TresEquis> I misremembered
<lifeless> hno: no, we've supported shared repos since 1.0
<lifeless> (actually a bit older still, but meh)
<ree> I just wish joining worked solidly with svn. (to overcome externals)
<ree> we had a project (kss) that we could never switch to bzr for this reason, mainly
<TresEquis> jelmer:  I'm back at the pdb.set_trace I added in bzrlib
<hno> lifeless: I know.
<lifeless> jam: land that pyrex patch; its like coding on top of a sea
<TresEquis> jelmer:  same crash
<jelmer> 'morning lifeless
<TresEquis> same busted not-really-a-revision ;(
<jelmer> TresEquis: :-(
 * ree still just at 488/1089
<lifeless> hi jelmer
<TresEquis> jelmer: the 'window' tuple has the bits which cause the borked file version in the 'new_data' field
<jelmer> TresEquis: I suspect the base text is invalid and that's causing the problems
<TresEquis> is that the 'sview'?
<lifeless> hno: yes, -r on update is new
<lifeless> hno: or you can use revert -r
<lifeless> which has been around for ages.
<hno> lifeless: I do not want to revert, just switch to that revision..
<TresEquis> jelmer: the 'sview' has the same text as svn r4908
<ree> TresEquis, why was it so much faster for you? Working from a server or something?
<TresEquis> ree: dunno -- I started earlier, maybe
<ree> TresEquis, did you do a bzr get, or a bzr co?
<ree> or that shouldn't matter.
<TresEquis> so, it is trying to apply the patch from r5090 - r5147 against the base from r4908
<TresEquis> ree: I did 'bzr co'
<lifeless> hno: yes, so using your version of bzr: bzr shelve --all; bzr revert -r X; bzr unshelve
<lifeless> hno: will get you onto that revision the same as update -r
<TresEquis> jelmer: the 'apply_txdelta_window' curried 'apply_window' has a value for 'sbuf' which is from the wrong source revision
<TresEquis> but I can't see who called that code in the first place
<jelmer> TresEquis: it's called from fetch.py
<TresEquis> jelmer: does that mean that the checksum matched before the currried bit was returned?
<jelmer> TresEquis: the base text is wrong
<jelmer> TresEquis: so yes
<jelmer> I mean no
<jelmer> sorry :)
<hno> lifeless: Think I prefer checkout -r then...
 * hno starts a 60 seconds countdown of the remaining lifetime of this install. Time for a complete system update.
<lifeless> hno: why?
<TresEquis> ugh
<hno> lifeless: Because I like to? And the distro release used becomes end-of-life in some weeks..
<lifeless> hno: I meant 'why do you prefer checkout -r'
<lifeless> I am very happy that you're upgrading :)
<hno> Because I do not want to accidently commit that revert.
<lifeless> k
<TresEquis> hno:  just figured out I knew you from Squid list
<lifeless> :)
<hno> TresEquis: Thanks
<lifeless> free software is a small small world
<hno> indeed. And hi lifeless ;-)
<lifeless> :)
<hno> Ok, countdown ended. Time for system update. See you later and meanwhile let #bzr return to normal high squid developers presence level.
<lifeless> ciao
<TresEquis> ack , curried functinos are a pain to debug
<TresEquis> curried functions called by C code are even worse
<jelmer> TresEquis: that's not really the problem here though, the issue is before the curried code
<TresEquis> jelmer: yeah, but the curried code is the only place I can detect the problem ;(
<jelmer> TresEquis: look at SvnEditor.apply_textdelta
<TresEquis> the currying gives me no way to get back to the 'self' of the think which created it
<jelmer> TresEquis: if you go up in pdb?
<TresEquis> up lands in 'report_inventory_contents'
<jelmer> TresEquis: but down from that there is apply_textdelta?
<TresEquis> no
<TresEquis> down from there is the curried 'apply_window'
<jelmer> ah, right
<jelmer> have you tried setting a breakpoint in apply_window when the problematic file is processed?
<TresEquis> I have the breakpoint in the apply_txdelta_window function, right before the failing assert
<TresEquis> that is the bottom of the traceback
<jelmer> that's too late though
<jelmer> you need the place where the base text is retrieved
<TresEquis> yep
<NightNord> Greeting, everyone. Is there any kind of UTF-8 to native encoding when commiting/pulling to/from remote repository in bazaar, as it is done in subversion?
<jelmer> NightNord: for paths, commit messages, etc - yes
<jelmer> NightNord: not for file contents (similar to subversion)
<TresEquis> jelmer: I have added yet-another-layer-of-indirection in fetch.py
<NightNord> Too bad, it seems that none of git,hg,bzr capable of this feature. Curious, that CRLF/LF conversion is done in bazaar...
<NightNord> jelmer: thanks
<TresEquis> currying the curry with a method, to get me access to self
<lifeless> vila: around ?
<lifeless> NightNord: what do you mean ?
<NightNord> lifeless: any known for me DVCS incapabable for switching text-file encodings, despite of that eol conversion could be done without marking all converted files as 'changed'-ones
<NightNord> In theory, same trick could be used for encoding conversion
<MTecknology> where is .bazaar/plugins/ in windows?
<lifeless> NightNord: sure, you could write a plugin to do that for bzr
<lifeless> MTecknology: bzr --version should show you
<MTecknology> lifeless: thanks
<NightNord> lifeless: if plugin is something the same as for git are 'hooks', I suppose it's quite hacky operation... At least if not checking bzr code =)
<guijemont> jelmer: how do you run bzr-gtk's unit tests?
<jelmer> "bzr selftest bzrlib.plugins.gtk"
<lifeless> guijemont: bzr selftest plugins.gtk
<lifeless> NightNord: filters to do changes like that are a supported feature, not hacky at all.
<NightNord> Hm... That's could done a trick. I'll dig in, thanks, lifeless
<guijemont> aha, didn't know about that command
<lifeless> NightNord: if you're new to python you'll probably find the learning curve a little steep; folk here or on the mailing list will be happy to help, I'm sure.
<TresEquis> jelmer: ok, different stab:  I'll make 'self.chunks' on the FileRevisionBuildEditor an instance of a class derived from list, but which holds onto a reference to the editor
<guijemont> time to see how many tests I broke
<TresEquis> Waiting 10 minutes between tries is not good for staying in the flow ;(
<NightNord> lifeless: Actually, I'll need to run single very simple shell command (find -name '*.cpp' -exec enca -x KOI8-R '{}' \;), so, I hope, my knowledge in python and some working plugin as example are sufficient. But thanks for invite, anyway =)
<lifeless> NightNord: you'll need to do the reverse as well, for the input filter
<lifeless> otherwise you'll commit in your local encoding
<NightNord> Yes, I know, I just simplified description to write less ;)
<lifeless> ok
<NightNord> I found checkeol plugin, I suppose it will serve as good base
<TresEquis> jelmer: ok, that hack gets me to the editor instance
<TresEquis> only I lost my pdb prompt, gotta run again ;(
<ree> TresEquis, got to go, good luck!
<ree> jelmer, thanks!
<TresEquis> jelmer: what information is interesting from the editor?  base_ie?
<NightNord> lifeless: hah, looks like plugins are actually like git hooks. And I see no plugins that actually 'change' data without marking it as changed
<lifeless> NightNord: The eol plugin
<NightNord> Ah, you mean embedded one...
<NightNord> Now I finally got your point. There is a special type of plug-ins, called 'filters', which are exactly what I need
<lifeless> yes, we hope
<TresEquis> jelmer: the base_ie shows that it bzr-svn does think that the parent revision for svn r5147 is svn r4908, instead of r5090
<lifeless> not widely used, but if it doesn't fit file a bug and we'll fix.
<TresEquis> now trying to figure out why
<jelmer> TresEquis: please note that this is the per-file base, not the per-revision base
<jelmer> and it's the revision against which the diff is sent, that's also not necessarily the base
<jelmer> s/the revision/the file revision/
<TresEquis> jelmer: (Pdb) parent.base_ie.revision
<TresEquis> 'svn-v4:4f889dee-8c54-0410-98c1-98789d956ae4:karl/trunk:4908'
<TresEquis> doesn't that mean that we think the base version of the file is from svn r4908?
<NightNord> lifeless: simple hack over eol.py show that it fit well. It's even simplier then I thought initially. Thanks again.
<TresEquis> because svn thinks that the base revision is 5090
<MTecknology> is there any installer package for tortoisebzr on windows?
<jelmer> TresEquis: it only means we expect svn to send the delta against the base text in that revision
<jelmer> TresEquis: how can you tell svn thinks the base revision is 5090?
<jelmer> is that the base revision of the overall revision or of this particular file revision?
<TresEquis> svnlog shows 4098, followed by 5090, followed by 5147 (the last is the one which blows up)
<jelmer> is the file changed at all in r5090?
<lifeless> NightNord: cool
<NightNord> lifeless: Actually, quick googling "git content filter" told me, that git supports just the same feature as well. But I will probably stick with bzr on this project, as folks at #git didn't know an answer for same question =)
<TresEquis> jelmer: svn log of this particular file
<TresEquis> the diff is a diff against 5090
<TresEquis> 5090 was, however, a revision which involved merging a branch
<TresEquis> so maybe we are deceived by the metadata about the merge?
<TresEquis> yes
<TresEquis> jelmer: I set a conditional pdb.set_trace() inside FileRevisionBuildEditor.__init__
<TresEquis> the first time it hits, it is being called from open_file with base_revnum=5089
<mwhudson> is there any way of doing what bzr replay does that works on paths rather than fileids?
<TresEquis> jelmer: the second time, the base_revnum of the caller is 5146
<TresEquis> jelmer: interesting, the 'len' attribute of the base_ie object matches the len of the r5090 version of the file, but its revision is still 4098
<jelmer> so it looks like we're storing the wrong file under the r4098 revid
<TresEquis> or mapping to it inappropriately?
<TresEquis> the file's text matches the 4098 revid
<TresEquis> but not its length
<TresEquis> anything you's like me to look at about the editor?
<TresEquis> its parent_trees are both tied to svn r5146
<TresEquis> as its base_tree
<TresEquis> its revid is svn r5147
<TresEquis> in the call to _open_file, the file_id and base_file_id are the same
<jelmer> TresEquis: sorry, don't have time to help debug this at the moment :-/
<TresEquis> jelmer: ok, thanks
<mwhudson> hm
<mwhudson> is there any way i can cherry pick changes to just one file?
<lifeless> yes
<lifeless> mwhudson: merge filename
<mwhudson> lifeless: ah right
<mwhudson> thanks
<lifeless> jam: tsk, you skipped mentioning pyrex in your fix ;P
<lifeless> in NEWS, I mean.
<mgz> mentioning slash blaming?
<lifeless> oh blaming, most definitely
<lifeless> doing 2.0->2.1
<lifeless> to propogate the pyrex fix
<lifeless> hmm, I want a health checker for our branches
<poolie> hi all
<mgz> hello!
<poolie> martin?
<mgz> yup, vila made me get a nick that doesn't take half an hour to type ;)
<bignose> bah. let them eat tab completion.
<TresEquis> jelmer: I tried to summarize my findings on the LP issue
#bzr 2010-05-20
<igc> morning
<spiv> Good morning.
<igc> morning spiv
<lifeless> spiv: feeling better ?
<spiv> lifeless: yes, thankfully.
<spiv> I can't guarantee I won't brainfade in the afternoon again... but so far so good, and without cold&flu pills!
<cody-somerville> ugh
<cody-somerville> I just did a merge of two trees of the same codebase that have no revision ancestry. There are very little differences between the two trees but bzr conflicts on all the files because the year in the copyright statement at the top of the files were all updated.
<cody-somerville> will trying a different merge method help or bzr just won't be able to figure this out on its own?
<lifeless> you could write/adapt/improve jams copyright plugin
<lifeless> spiv: would like to talk gil stuff with you at some point
<lifeless> ok, really popping out for these chores/lunch
<spiv> lifeless: ok
<spiv> We're starting to get on top of the review backlog from the sprint :)
<lifeless> \o/
<lifeless> losa ping
<spm> yo
<lifeless> can you check balleny's bzr 2.1 branch
<spm> lifeless: sure, in what sense check tho?
<lifeless> I think the xmlrpc server fell down went boom just as pqm went to do the 2nd-phase push
<spm> ahh. right.
<lifeless> so there will be another commit in that branch vs lp
<spm> manually push the sucker?
<spm> lifeless: https://pastebin.canonical.com/32485/ so yeah, looks to me like '42 missed
<lifeless> please sir may I have another
<spm> lifeless: Pushed up to revision 4842.
<lifeless> thanks a lot
<spm> np
<lifeless> now I can do -> bzr.dev
<lifeless> :)
<spm> heh
<lifeless> garh, bzr-search not-quite-fixified.
<lifeless> spiv: does bzr merge --weave still call NEWS helper ?
<cody-somerville> ugh
<cody-somerville> lets say I have two branches
<cody-somerville> the second branch is a branch of the first branch
<cody-somerville> in the second branch, I've moved files using bzr move
 * lifeless waits for launchpad
<lifeless> 6 ppm
<lifeless> :<
<cody-somerville> why is that if I make modifications to those files I moved under the original name in the first branch that when I merge the first branch into the second branch I get a text conflict for the original filenames?
<spiv> lifeless: I don't recall, I *think* so
<lifeless> cody-somerville: you shouldn't
<lifeless> cody-somerville: please file a bug
<spiv> cody-somerville: in the situation you just described, you shouldn't.  Either there's a bug, or the situation isn't as you described.
<cody-somerville> lifeless, I can only assume that maybe I didn't use bzr move when I thought I did?
<spiv> You can look at the file-ids
<lifeless> have a look at bzr log filename
<cody-somerville> how do I do?
<lifeless> in branch2
<spiv> e.g. "bzr file-id FILENAME"
<lifeless> with -v
<lifeless> if it shows the rename, you used bzr mv
<cody-somerville> sighs
<cody-somerville> wasn't moved
<cody-somerville> because I merged the first branch into another branch to initial create the 'second branch' and that was a bzr-git import and it shows the files were deleted and then added with new name.
<cody-somerville> *initially
<cody-somerville> Any way I can give bzr the extra meta-data?
<lifeless> no, this is a hole.
 * cody-somerville sobs.
<lifeless> or rather, not trivially.
<lifeless> you can probably rebase, if you hit things hard enough
<lifeless> there is a file id mapping feature in that plugin
<lifeless> damned if I know how to use it though :()
<cody-somerville> I'm trying to manage two series of a codebase
<cody-somerville> but upstream decided to create a new git branch (or w/e its called in git) for the new series.
<lifeless> jam: bzr in C ? I've got a few libraries you might want
<lifeless> jam: that are slowly building up towards that
<lifeless> e.g. libvfs
<lifeless> anyone want to keep CHK1/CHK2 formats around?
<spiv> I wouldn't think so
<spiv> There are always old releases if someone does.
<lifeless> bleh
<lifeless> Ran 24411 tests in 1013.377s
<lifeless> FAILED (failures=1, errors=72, known_failure_count=47)
<echo-area> hello, I got error "Invalid url supplied to transport" when doing bzr checkout svn+http://url
<echo-area> what's the problem?
<echo-area> thanks
<spiv> echo-area: do you have the bzr-svn plugin installed?  (check the output of 'bzr plugins')
<echo-area> spiv: yes, if I do bzr checkout svn+ssh://other-url, I am prompted to input the password.  But I can't, since the subversion repository is not accessible by ssh for me
<spiv> echo-area: odd.  pastebin the entire error?
<echo-area> ok
<echo-area> spiv: http://pastebin.com/khtwepfF
<lifeless> back soon
<echo-area> does somebody have an explaination to my bzr-svn problem?
<spiv> echo-area: I don't, sorry
<echo-area> spiv: no problem, thank you
<echo-area> does bzr-svn require pycurl?  I found it mentioned here: https://answers.launchpad.net/bzr-svn/+question/11299
<lifeless> bzr bzr plugins
<lifeless> sorry
<lifeless> check the output of 'bzr plugins'
<lifeless> I suspect its not loading, and the error will be in bzr.log
<echo-area> (to support svn+http)
<vila> echo-area: It's not *required* AFAIK, but used if available
<echo-area> lifeless: http://pastebin.com/khtwepfF  <--  output of bzr plugins is pasted here
<lifeless> vila: bzr-svn uses the svn http core, can't use anything else
<lifeless> echo-area: and is svn in the list ?
<vila> lifeless: the current run on pqm says (lifeless) Merge 2.1 into 2.0, you meant 2.0 into 2.1 right ?
<lifeless> blah 2.1 to trunk
<echo-area> lifeless: yes, it is "16.svn 1.0.2"
<lifeless> ok
<lifeless> check your .bzr.log just in case there is an error there
<vila> lifeless: it still uses any available bzr client for some operations (can't remember which but at least OPTION is involved and jelmer asked me to support that directly far too long ago)
<lifeless> sure
<vila> " blah 2.1 to trunk" cool !
<echo-area> I've updated the pastebin content.  An exception is thrown when the plugin tries to connect the server
<echo-area> http://pastebin.com/xsj7q0Ca
<echo-area> it's here
<echo-area> I guess the problem is in subvertpy, let me check
<vila> echo-area: try using 'bzr plugins -v' the paths used will displayed and may help you detect a problem in your setup, and as lifeless mentioned, check your .bzr.log ('bzr version' will tell you where it is located))
<echo-area> vila: done; the content of .bzr.log reflected the error has been pasted.  Btw, when bzr-svn calls subvertpy functions, is the "svn+" part of url stripped off?  I.e., at line 249 of transport.py of bzr-svn, does the url parameter begin with "http://" or "svn+http://"?
<spiv> I'd expect stripped.
<spiv> But ICBW.
<echo-area> I don't have experience using python before, and I want to change subvertpy's code, so I need help: in this expression _ra.RemoteAccess(url, *args, **kwargs), which field of the definition in the C code of _ra.RemoteAccess is the function gets called?
<vila> echo-area: before modifying code, have you tried using -Dtransport as an additional parameter to the command ?
<vila> it should output more debug stuff to .bzr.log
<echo-area> vila: no, let me try now.  Do you mean bzr co -Dtransport svn+http://...?
<vila> yup, it may give you what you are after with this code modification with a bit of luck
<echo-area> vila: sadly there's no more output I've not seen.
<spiv> echo-area: that Python expression will invoke ra_new in subvertpy/_ra.c (via a little bit of indirection)
<echo-area> spiv: yes, and I've located the PyTypeObject "_ra.RemoteAccess" in _ra.c, but that definition does not give me any clue which function to look further
<spiv> echo-area: see around line 2071, PyTypeObject RemoteAccess_Type = {
<spiv> echo-area: which defines various builtin operations that can be done with a Type object, and also defines the methods and members of that type.
<spiv> echo-area: specifically, the constructor for that type roughly corresponds to the tp_new slot (right at the bottom of that struct definition)
<spiv> echo-area: and arrays like ra_methods defines the methods instances of that type will have
<spiv> echo-area: so _ra.RemoteAccess(...) is calling the _ra.RemoteAccess constructor, which as I said before will mean the ra_new function in that file.
<spiv> echo-area: does that help?
<echo-area> spiv: yes, that's enough knowledge for me to dig deeper.  Thank you!
<spiv> echo-area: great :)
<spiv> echo-area: any luck?
<echo-area> spiv: no, I was interrupted and am doing other things now.  I expect myself solving this problem before the weekend
<echo-area> s/solving/explaining/
<Lor> Hi. If I have a directory hierarchy with several branches under it, synchronizable across machines easily with multi-pull or repo-push, is there any way to easily synchronize changes to the actual hierarchy layout?
<Lor> Before nested trees are production quality, that is.
<Lor> Also, why must the shared repository of a branch always be located in a parent directory?
<Lor> Seems like it wouldn't be very complicated to simply record the location of the repository in branch.conf
<jjann> Hi. Is there some way to colorize bzr diff output? (similar to what git and hg offer)
<bialix> jjann: look at cdiff command from bzrtools
<jjann> bialix: that's perfect, thanks
<guijemont> jelmer_: vila: ping
<guijemont> I have a bzr-gtk branch that implements collapsing with which I am quite happy now
<guijemont> should I do a merge request through launchpad?
<guijemont> or a bzr send to the ml?
<guijemont> or something else?
<vila> guijemont: a merge request with a cover lettter explaining if and how you share code with qbzr would be the best
<vila> guijemont: did you tested it with a mysql or emacs branch ?
<guijemont> vila: my branch still uses ye olde linegraph()
<guijemont> hmm, i didn't, good idea
<guijemont> I tested it with itself, and with lp:elisa
<vila> trying with bigger branches may help unless you're into adding automated tests (which are painfully lacking so far)
<guijemont> I think it will make sense to add some automated tests when the code is refactored to use the qbzr graph generation stuff
<vila> guijemont: hehe, TDD is about doing it the other way around i.e. write tests first :-)
<vila> guijemont: but it's harder to do TDD with an existing code base and no tests
<guijemont> vila: yeah, and with a code base that doesn't separate things well
<fullermd> Oh, no, it's much easier.  Your changes never break tests   :p
<vila> fullermd: you're on the right path young jedi, the next step is to realize that the only that should be written is one that fix a test :)
<vila> s/only/& code/ mandatory typo...
<cbz> when i access a svn repo with bzr can it track renames?
<cbz> as it seems to stop displaying history for a file at the point at which it was renamed
<fullermd> Ergo, bzr-gtk is already perfect.  QED   :)
<vila> haaaaa, that's why it's so hard to ehance code without tests, I should have think about that sooner :)
<vila> wow, time travel again... I see files created in the future... (5mins and 1.5hours)
<fullermd> Maybe you're just slow   :p
<vila> the really weeird thing is that 'date' displayed value seems correct
<guijemont> reminds me of today's smbc
<guijemont> (or was it yesterday?)
<vila> nope, all on the *same* system, no mounted fs involved (that would be too easy :)
<guijemont> yeah, today
<guijemont> http://www.smbc-comics.com/comics/20100520.gif
<vila> arf, no samba there :)
<vila> guijemont: :)
<guijemont> hmm, I have a few "maximum recursion depth exceeded"
<guijemont> the code looked good when using recursion :/
<jelmer_> guijemont: what do you recurse on?
<guijemont> don't remember
<guijemont> I might do that in more than one place
<guijemont> I'll have a look at the backtraces in more detail
<guijemont> hmm, actually, the place where I get this is weird
<guijemont> i think i need a break before plunging into that
<GaryvdM> Hi bialix
<GaryvdM> Just landed stable scroll for qannotate \o/
<vila> GaryvdM: Really ? Is it really what I think it is ?
<GaryvdM> Hi vila, I think it is what you think it is.
<vila> GaryvdM: that's awesome !
<vila> GaryvdM: you rock :)
<mgz> But is it what I think you think he thinks it is?
<GaryvdM> lol
 * GaryvdM thinks about landing lp:~garyvdm/qbzr/annotate_find. Does it really matter if the ui is inconsistent for a while?
<vila> GaryvdM: doesn't matter to me :)
<vila> mgz: I think I see what you mean...
<vila> boom, maximum recursion depth exceeded in discussion
<vila> GaryvdM: what matters though, is that some bindings should be defined there :-P
<GaryvdM> vila: I don't understand
<vila> return should be bound to next by default
<jam> hi vila and GaryvdM
<Lor> Is there a recommended way to put multiple branches under a single working directory?
<Lor> (With the intention that the working directory is used to switch between the branches)
<vila> when I enter text the 'Find:' field, I'd like 'return' to give me the next match without touching my mouse
<GaryvdM> vila: ok
<GaryvdM> vila: You and Craig both gave me some feed back. I will go through that first.
<vila> Lor: I don't use that setup myself, but AIUI, lightweight checkouts and the switch command OR the bzr-colo plugin are different ways to achive that today
<Lor> Ah, didn't know about bzr-colo.
<Lor> Is it some sort of a hack to simulate nested trees until they are fully supported by the core?
<Lor> Ah, no.
<Lor> Right.
<GaryvdM> Lor: Not nested trees. Rather collocated branches.
<GaryvdM> Lor: Like git
<Lor> Right, I'm reading the docs now.
<Lor> It's just an alternative directory layout convention for lightweight checkouts?
<Lor> Does it work with bzr-pipeline?
<GaryvdM> Going out for a bit. bbl
<cbz> jelmer_: are you there?
<Lor> Is there really a performance overhead for storing multiple unrelated projects in the same shared repository?
<jelmer_> cbz: hi
<cbz> jelmer_: does bzr-svn track renames? it appears that it's history of files i renmamed stops at the point i renamed them
<jam> Lor: "bzr init-repo --no-trees project; cd project; bzr init branch1; bzr co --lightweight branch1 work
<jam> Lor: from there you can do: 'bzr branch --switch ../branch1 ../branch2"
<jam> or
<jam> "bzr switch -b branch2"
<Lor> I was asking about how to put branches under a _working directory_.
<Lor> bzr-colo seems to provide a sensible convention and tools to make its usage easier
<jam> Lor: well, you can do:
<jam> touch work
<jam> cd work
<jam> bzr init-repo --no-trees .
<jam> bzr init _a_branch
<jam> bzr co --lightweight _a_branch .
<jam> It is a bit weird to put the branches in the same dir as the working tree
<jam> so aside from that, bzr-colo
<Lor> Yes, that's one convention.
<Lor> But it's a bit funny to have the branch directly under the root of the working directory, since there's then nothing to immediately distinguish between a branch directory and a workingtree subdirectory.
<Lor> .bzr/branches seems like a more sensible place to put the branches
<Lor> It also seems to work ok with bzr-pipeline.
<Lor> So I'm all good.
<Lor> Actually, pipeline+colo=loom?
<jelmer_> cbz: yes, it can track renames
<jelmer_> cbz: but it won't infer renames from copy + delete in svn
<jelmer_> cbz: so it will only work for revisions pushed from bzr into svn
<cbz> okay
<cbz> can't it use whatever information svn uses to work out what has been renamed?
<LeoNerd> SVN doesn't store renames.
<LeoNerd> SVN stores a revision that deletes a file, but adds a new file by copying history from the old one.
<LeoNerd> That isn't quite a "rename"
<mgz> ugh, setuptools makes me feel unclean
<cbz> but it stores enough meta information for tortoisesvn to work out that a rename/copy has taken place
<idnar> the mismatch is that bzr doesn't support copies
<cbz> oh
<Lor> Suppose I have a network connection available only for a limited while. I want to get new revisions from upstream, but my working directory is currently a mess so I don't want to merge right away. What's the best way to do this?
<Lor> The obvious solution is just to branch upstream into a local copy and then merge that local copy into my working branch later on.
<Lor> But I'm wondering if there is a way that doesn't require creation of a temporary local branch.
<jelmer_> Lor: not that I can think of
<Lor> Well, in principle it's possible to do a merge, then revert before committing. This does bring in all the revisions into the local repository. But after the revert there is just pointer to them so it's not trivial to redo the merge.
<Lor> just _no_ pointer to them
<Lor> But a branch is a cheap thing.
<Lor> Actually, one of the reasons why the colocated branch convention is good is that you always get a shared repository so branches are always cheap.
<Lor> Incidentally, could someone explain the point of shelves?
<Lor> It seems kind of silly that when we have full version control available, a separate system is used to store temporary changes.
<TresEquis> Lor: back out a part of the uncommitted changes in the working directory
<TresEquis> to make it possible to to more focused commits
<TresEquis> e.g., with simple commit messages
<Lor> If you want to back out some changes that you want to later bring back, why not commit, then revert those changes, then do what you want, then merge rest of the stuff from the commit?
<TresEquis> Because I don't want them in the "public" history yet
<Lor> "public"?
<Lor> It's your own branch!
<TresEquis> but I'm going to push it somewhere public
<TresEquis> e.g., if I'm evaluating a patch which supplies both a testcase and a fix
<Lor> That seems like a problem with your workflow.
<TresEquis> I apply the patch, shelve the fix, and ensure that the testcase fails
<TresEquis> (note I haven't committed anything)
<TresEquis> then unshelve the fix and commit both together
<TresEquis> or if I have made "janitorial" changes to one part of a file while making substantive changes to another part
<Lor> I forgot: after the commit, uncommit back to the previous revision but revert the working tree only partly (those parts you don't want to shelve).
<TresEquis> I want to commit the two parts separately
<Lor> bzr-pipeline seems like the right tool for that.
<Lor> (or loom)
<TresEquis> no, those are too complex
<Lor> Only if you think that a branch is a big thing.
<TresEquis> no
<TresEquis> I'm done trying to explain how I use it -- I don't need to defend it
<Lor> I'm not saying there's necessarily anything wrong with shelves, they just seem orthogonal and redundant.
<elmo> aborting commit write group: OSError(24, 'open: Too many open files')
<elmo> bzr: ERROR: [Errno 24] open: Too many open files: '.'
<elmo> seriously?
<Lor> Sorry, _un_-orthogonal.
<GaryvdM> elmo: On what os?
<elmo> GaryvdM: Ubuntu, Lucid
<jam> elmo: I've only seen that when using bzr-svn
<jam> the code that actually reads the content does have a try/finally:f.close()
<jam> so we shouldn't be leaking from there
<elmo> jam: this is straight bzr, managing /etc
<elmo> root@carpobrotus:/etc# bzr st | tr -d @ | grep -v "^[a-z]" | grep -v " postgresql/8" | grep -v /hook | awk '{print $1}'| wc -l
<elmo> 1268
<elmo> ^-- that's the number of files I'm trying to commit
<elmo> I'm basically doing bzr ci -m "commit message" $(<the bzr st horror above>)
<elmo> (without the wc, obviously)
<jam> elmo: hmm... I still haven't seen us have a problem with that, but we can certainly try to investigate
<jam> I assume it is perfectly reproducible for you?
<jam> and 'bzr --version' is?
<elmo> jam: yes, reproducible
<elmo> jam: 2.1.1
<elmo> 2.1.1-1 to be precise
<elmo> I suspect I can reproduce with a dumb testcase and that the trigger is listing files on the command line
<elmo> I'm sure I've commited trees with more changes before but I don't often specify the files on the command line
<elmo> but I'm guessing
<elmo> yeah
<elmo> I'll file a bug, it's got a trivial test case
<jam> elmo: thanks, I'm trying to reproduce now
<elmo> jam: http://paste.ubuntu.com/436872/
<jam> elmo: so, I can reproduce something weird with "bzr st `cat big_list.txt`"
<elmo> reported as https://bugs.launchpad.net/bzr/+bug/583468
<ubot5> Launchpad bug 583468 in Bazaar "bzr commit will break when given too many files as arguments (affected: 1, heat: 0)" [Undecided,New]
<elmo> jamnice
<elmo> jam: nice - even
<elmo> jam: that looks like a related/similar problem
<jam> elmo: seems like it is actually a problem with the command line being too long
<jam> and that is getting masked somehow
<elmo> jam: I don't think so?
<elmo> 'ls *' works, for example
<elmo> so 'bzr st *' should too
<jam> elmo: now i'm seeing "permission denied"...
<jam> elmo: so I'm pretty sure it isn't the commit code, but actually the "what has changed" code that is at fault, still investigating
<elmo> jam: ok, thanks for looking.  FWIW, it's not urgent though I do appreciate you looking into it
<jam> elmo: Yeah, if you "mv  _readdir_pyx.so _readdir_pyx_old.so" it works
<jam> the issue is something in there is opening file descriptors and not closing them
<jam> I know we do "open(directory)" so we can do "chdir(old_dir_id)" but we seem to properly (close(old_dir_id))
<jam> elmo: any chance you can test on something other than lucid?
<elmo> jam: like what?
<elmo> something newer?
<jam> or older
<jam> something different
<elmo> sure, I can test hardy trivially
<jam> in case it is something like OS not actually releasing handles on open(directory) or a problem with opendir()/closedir() etc
<jam> thanks
<jam> I've only got a Lucid VM here
<jam> so you don't need commit, 'bzr st *' should trigger it just fine
<jam> but it probably has to be a bunch of files and not their containing dirs
<jam> because the code filters (if you supply dir/ and dir/foo, we only use dir/)
<elmo> jam: hardy with 2.0.4 exhibits the same behaviour
<jam> elmo: thx
<jam> elmo: submitting a bug, hopefully I can track it down
<jam> bug #583486
<ubot5> Launchpad bug 583486 in Bazaar "_readdir_pyx.so leaks file descriptors (affected: 1, heat: 0)" [High,Confirmed] https://launchpad.net/bugs/583486
<elmo> jam: ah, I guess I should dupe my bug into that then?
<elmo> jam: (done)
<cr3> is there a way to either revert to a tag or determine the revision corresponding to a tag?
<mgz> launchpad-bugs-owner@lists.canonical.com "Your message was rejected" huh?
<mgz> that's surely not expected behaviour from submitting a merge proposal, sending me email complaining about it.
<Lor> Wait, what? Are plugins allowed to store data into bazaar.conf?
<GaryvdM> Lor: yes
<Lor> Then it's not really a configuration file?
<jpds> cr3: bzr tags ?
<cr3> jpds: yep
<Lor> (In the unix sense, meaning: managed only by the user, can be set read-only)
<jpds> cr3: Err, that was the answer to the latter part of your question.
<GaryvdM> Lor: What plugin are you looking at ?
<Lor> bzr-bookmark
<GaryvdM> Lor: Well, the user *configures* their bookmarks
<Lor> Arguably, yes.
<luks> bzr itself modifies bazaar.conf
<Lor> I'm not saying this is wrong, but it is confusing not to have a clear idea exactly where bzr will touch, and where the user is in control.
<luks> I think providing UI for configuration files is nothing special
<Lor> hm, when I do bzr co bm:foo, the bound_location gets the _expanded_ bookmark location, instead of just bm:foo
<Lor> I was hoping to use bookmarks as a layer of indirection so that if the upstream location moves someplace else, I just need to do a single reconfiguration and everything will keep on working.
<lifeless> moin
<Lor> (Basically I'm wondering whether I should use bookmark locations as part of something I'm doing, or cook my own thing, even though it would be slightly similar)
<Lor> bazaar.conf doesn't support include directives?
<Lor> I'd like to use the same configuration on multiple machines, except for some site-specific bits.
<jam> elmo: found the bug
<jam> when you pass in a path
<jam> we open() the current directory so that we can chdir() back to it
<jam> but if it is a file and the 'chdir(path)' fails, we were not closing the descriptor
<jam> simple one-line fix
<lifeless> grah
<lifeless> +1
<elmo> jam: awesome, ta
<jam> lifeless: do you want me to clean up the code a bit, I get some warnings under pyrex. Otherwise I can just do the minimal one-line fix
<lifeless> jam: we want to land in 2.0
<jam> lifeless: sure
<jam> I'll start small :)
<lifeless> jam: so - one liner, for SRU niceness. Cleanup in trunk after mergnig forward.
<jam> elmo, lifeless: Theres the one-line fix
<jam> http://paste.ubuntu.com/436938/
<lifeless> yeah, doit
<mtaylor> it would be great if I could say bzr push $parent
<mtaylor> except without the $parent part
<mtaylor> I mean - if it was something good and not $parent
 * mtaylor is babbling
<mtaylor> bzr push `bzr info | grep parent | awk '{print $3}'`
<mtaylor> is what I'm trying to say
<jam> mtaylor: bzr push :parent ?
<mtaylor> jam: wow. is that a thing?
<jam> mtaylor: yes
<mtaylor> jam: see... you anticipate my needs before I even know them :)
<jam> mtaylor: bzr help location-alias lists 6 shortcuts
<TresEquis> borrowing guido's time machine, are we?
<mtaylor> woot
<AfC> Bazaar for dapper in the PPA doesn't install "bzr: Depends: python-configobj but it is not installable"
<AfC> (yes, dapper. I need Bazaar there to get *off* of that system, heh)
<AfC> So should I... install Bazaar manually?
<jelmer_> AfC: uhm
<AfC> jelmer_: that's what I said :)
<jelmer_> AfC: Or perhaps just run it unpacked from your home directory?
<AfC> jelmer_: as in from tarball?
<AfC> [if so, that's kinda what I was thinking, actually; I realize that's not what I said]
<jelmer_> AfC: well, unpack the tarball first, but yeah :-)
<TresEquis> $ sudo python setup.py install --root=/opt/bazaar
<jelmer_> bzr will also work fine without installation though
<AfC> Weill it work, or will I need this python-configobj thing manually? too
<jelmer_> AfC: no, you won't need to install python-configobj in that case
<jelmer_> we just remove that for the debian packages because we'd like to avoid duplication on the system
<AfC> jelmer_: if I don't "install" it, should I still `make` (or whatever) to build the C stuff? Presumably!
<jelmer_> AfC: it's not necessary but it will help with performance
<TresEquis> AfC:  setup.py build_ext --in-place, I think
<AfC> this is horrid. Pyrex not in dapper.
<jelmer_> AfC: you can use bzr without the extensions, it'll just be slower
<jelmer_> is the repository you're trying to use very large?
<AfC> jelmer_: 250 MB, 4500 files
<jelmer_> so I guess the question is whether it will take more time to install pyrex first or to just use the slower bazaar :-)
<AfC> yeah, I'm trying it now
<jam> AfC: If you are extracting the tarball, you shouldn't need pyrex, the extensions shoul dbe there
<jam> should be
<AfC> jam: that's what I thought, but `make` failed with horrible errors
<jam> AfC: care to pastebin?
<jam> and 'python setup.py build_ext -i' is correct
<AfC> just working through it
<AfC> hm
<AfC> bzrlib/_annotator_pyx.c:4:20: error: Python.h: No such file or directory
<AfC> let me guess. a build-dep
<jam> AfC: python-dev IIRC
<jam> and zlib1g-dev
<mgz> you... can just, not build the extensions
<jam> I think thats about it
<jam> mgz: yes, he can skip it, and it will "work". But for a 250MB repo, he may be quite a bit happier with the extensions built
<mgz> hm, yeah, depends on what he means by "get *off* of that system"
<mgz> just pushing a branch to somewhere else is generally network-bound
<AfC> mgz: of course
<AfC> mgz: but in this case I need to capture the changes that have happened out there first
<AfC> jam: built ok
<AfC> thank you
<jam> glad it worked
<AfC> and if I'm being rude to this system, just ./setup.py install --root=/usr ?
<lifeless> jam: hi
<lifeless> dirstate stuff
<AfC> or, failing that, what's the option to specify the remote bzr location?
 * AfC is RTFM, honest :)
<lifeless> bzr help env-variables
<lifeless> found via bzr help topics | grep env
<donri> Best way to uncommit a pushed commit?
<jam> AfC: "INSTALL" says "python setup.py install --home=~"
<jelmer_> lifeless: it's not mentioned in the man page, while most of the other variables are
<jam> donri: Aside from "bzr uncommit" ?
<donri> Duno, is uncommit good enough?
<lifeless> jelmer_: it would be nice for the man page to pull it from the help
<jam> (and potentially push --overwrite, but I would probably use 'bzr uncommit" on the remote site as well)
<jelmer_> lifeless: I agree
<jelmer_> lifeless: this is the moment where one of us tells the other to write a patch.
<AfC> lifeless: ah, duh, I didn't think of an environment variable. Thanks
<jelmer_> :-P
<donri> jam: Don't I want to make a new commit that reverses the changes?
<jam> donri: depends what you need to do
<lifeless> jelmer_: actually, I was going to say file a bug ;)
<jam> you *can* just uncommit, and push that around
<jam> but people tracking you may get confused
<lifeless> donri: if you want to pretend it never happened, uncommit
<donri> lifeless: Even if pushed?
<lifeless> donri: if other people have it already, commit something that reverses it
<donri> I'd like that if someone pulls, they don't have the effects of that commit.
<jam> the alternative is: bzr merge -r X..X-1; bzr commit -m "Reverse what happened in X"
<donri> Regardless of the log.
<jam> well
<jam> bzr merge . -r X..X-1
<lifeless> donri: how long ago did you push it ?
<lifeless> donri: minutes/hours/days ?
<donri> I use Bazaar to deploy so the production server pulls from Launchpad
<donri> Which is automated, so, yea.
<lifeless> so, someone will have it already : you need to commit the reverse change
<donri> Thanks, merge worked wonderfully.
<AfC> jam, mgz, jelmer_, lifeless: thanks for your help
<jam> lifeless: I'll try to respond to your dirstate email tonight or tomorrow, I'm off for now
<lifeless> jam: oh, I wasn't prompting for an email
<lifeless> if you're back later, we could chat
<poolie> hi all
<lifeless> hi
#bzr 2010-05-21
<Lor> Is there some estimate of when nested (by-reference) trees will become a supported feature?
<fryguy_> is there any way to get a list of files that would be applied in a merge without applying it? `bzr merge --preview` shows a diff, but I'd like to see the files (more like a --pretend?)
<idnar> as a quick fix, you could pipe the diff through diffstat
<fryguy_> is that a unix command?
<fryguy_> i ended up just applying the merge and piping stderr to a file, and then reverting it
<AfC> fryguy_: yes, it's in a package you can install. The "diffstat" package, as it happens.
<fryguy_> i'm on windows :(
<Kilroo> I feel your pain
<fryguy_> well, I do like developing on windows. c# is a lot of fun.. so it's not all bad
<Kilroo> I did like C# okay.
<idnar> ah, might be harder to get diffstat on windows
<Kilroo> Didn't much care for codebehind, but C# was good.
<igc> morning
<Kilroo> Random thought of the moment: I think the decentralized-but-not-quite-distributed development model is far more easily supported by bzr than by any other vcs I've encountered.
<Kilroo> Or to put it another way, I like bound branches.
<mneptok> take up bonsai as a hobby.
<mneptok> ;)
<Kilroo> Lulz.
<poolie> Kilroo, it's true
<spiv> lifeless: yeah, I saw that GIL message.  My guess is it doesn't have much relevance for us
<spiv> lifeless: because our common case atm is pull from bzr+ssh, which shouldn't involve any threads.
<lifeless> beep, wrong
<lifeless> or perhaps
<lifeless> I was thinking paramiko for a second
<lifeless> but then I remembered that paramiko isn't used for bzr+ssh
<lifeless> however
<spiv> Right.
<lifeless> we do have a threading handshake-thunk in the server streaming and client streaming code
<lifeless> don't we ?
<lifeless> converting reads to generators
<spiv> We do use threads for insert
<lifeless> and generators to writes
<spiv> And for builtin TCP serve.
<lifeless> right, TCP serve very obviously has threads
<spiv> No thread for get_stream*, just insert_stream*
<lifeless> so
<lifeless> if the client doesn't read its buffer enough
<lifeless> client side buffer fills up
<spiv> But we've been observing apparent oddness with get_stream
<lifeless> os socket buffer is full - network will back off
<lifeless> yes, oddness to
<lifeless> too
<lifeless> I filed a couple of bugs I want to chase down, as branch time is hurting the distro
<spiv> Even in the inserter case, there's no fixed size buffer.
<spiv> As the network thread receives bytes it unwraps them from the HPSS layer and pushes them onto a Queue.Queue
<spiv> Which "should" be fast, assuming the other thread(s) aren't starving the network thread of CPU time.
<spiv> Yeah, I saw the bugs, they are marked Critical after all ;)
<lifeless> oh good, for some reason I thought we had a fixedish queue
<lifeless> the reason the GIL thing stood out to me was that it describes networking threads getting starved out of proportion to the cpu load - AIUI
<spiv> Well, from reading from a pipe, we are a bit pessimistic, lots of small reads to avoid blocking.
<spiv> When reading from a socket we just always grab 4k or something.
<lifeless> is bzr+ssh considered to be a pipe or socket ?
<spiv> A pipe.
<spiv> Anyway, for the bugs you filed, they are streaming from LP, so no threads in the server bzr involved.
<lifeless> argh
<lifeless> maybe I should fix
<lifeless> Conflict: can't delete bzrlib/plugins/bash_completion because it is not empty.  Not deleting.
<lifeless> first
<lifeless> as its breaking the workflow for 2.0->2.1->trunk merges
<spiv> lifeless: you would make many people happy
 * lifeless gets out the economy sized yak shaver
<spiv> lifeless: I suggest "moving bzrlib/plugins/bash_completion to lost+found/" ;)
<nDuff> Hmm. I have a project where I'm interested in determining if any files in a large tree revert to prior states, and being able to scan said directory for changes quickly/efficiently; however, I _don't_ need to be able to retrieve content associated with said former states, just enough metadata to identify them.
 * nDuff is pondering whether bzrlib can be pervented to the purpose. :)
<lifeless> so, you're happy with a lost+found directory approach ?
<lifeless> perhaps bzr-lost+found, so as not to collide with the fs one
<lifeless> nDuff: sure, you could use the dirstate module, or perhaps even working tree 4, directly.
<lifeless> you may find some areas where we are a bit fuzzy on layers - but we'd be delighted to sharpen them up to serve your purpose
<mkanat> lifeless: You could just do .saved or something, too.
<mkanat> lifeless: Somewhat like rpm does.
<spiv> lifeless: I'm happy with any improvement
<nDuff> lifeless, thanks for the encouragement -- I was already reading through the pydoc for bzrlib.dirstate, and will look into the API to the working tree code as well.
<spiv> lifeless: I think in practice most people will routinely delete everything in lost+found, and maybe rarely rescue one or two files from it
<lifeless> mkanat: are there docs on precisely what rpm does ?
<mkanat> lifeless: Good question.
<spiv> lifeless: but "rm -r lost+found" is a much easier way to recover a sane tree than the current situation
<mkanat> lifeless: Brief search finds an email mention briefly: http://www.redhat.com/archives/rpm-list/2001-July/msg00213.html
<spiv> So, I guess I am happy with the lost+found approach :)
<spiv> mkanat: that doesn't seem to address this situation (that a managed directory is being deleted; what should happen if there are unmanaged files in it?)
<lifeless> mkanat: so, we do ok on single files
<thumper> hey
<mkanat> lifeless: Yeah.
<thumper> I just noticed that kdiff3 is back
<thumper> how can I use it to resolve merge conflicts?
<lifeless> mkanat: we're talking about the case where we want to delete a directory X containing a file X/Y that is not versioned
<thumper> is it easy?
<lifeless> mkanat: or is versioned and is modified
<lifeless> mkanat: the proposal is to move the entire path under a top level bzr-lost+found directory
<mkanat> lifeless: Well, if it only contains unversioned files and is being deleted, then it's fairly easy to just say "make it .moved or .saved" or something.
<lifeless> mkanat: and say that we've done that
<mkanat> lifeless: I imagine that's the most common case--that's the one I've hit.
<lifeless> mkanat: 99% of the time [NotAMetric statistic] its just a .pyc file so the entire thing should be deleted
<lifeless> at the moment though, we leave the directory in place, and it gets in the way when you switch back
<mkanat> lifeless: Unless it's some configuration file that's important to the functioning of some customization on a branch that you're merging into, or something like that.
<lifeless> mkanat: which is why moving it under a different directory is better - the common case is to nuke all the things; the uncommon case is to want to add the containing directory again and put the file back
<lifeless> mkanat: sure thats why we can't delete the file outright
<mkanat> lifeless: Okay. Might want to call it bzr-deleted or something like that, for clarity.
<mkanat> Or -removed.
<mkanat> lifeless: I think it will be somewhat surprising behavior, though.
<lifeless> I'm not sure thats more or less clear
<lifeless> mkanat: the current behaviour sucks :)
<mkanat> lifeless: I think lost+found definitely won't be clear to people who don't have that on their OS.
<mkanat> lifeless: I think I'd find it somewhat more intuitive to rename the directory in place.
<lifeless> what do you mean ?
<mkanat> lifeless: I mean, if I were looking for where my files went, and I actually needed them.
<mkanat> lifeless: I could also nuke them with clean-tree, which is how I nuke things now anyhow.
<lifeless> so we print out whats happening
<mkanat> lifeless: But bzr prints out so much stuff when merging, it might get lost.
<lifeless> mkanat: it doesn't on switch, IME
<mkanat> lifeless: Oh, that's true.
<lifeless> mkanat: this is primarily an issue for switch, because you're often changing between radically different code bases.
<mkanat> lifeless: I think I encountered it with "up" once, maybe, when I was updating with local commits.
<lifeless> we could introduce the concept of precious files and say 'ignored files can be deleted willynilly', and treat unversioned unignored files as precious [thereby avoiding an initial config file], but we'd still have an issue with that config file story, for intance.
<mkanat> lifeless: Yeah.
<mkanat> lifeless: I'm just thinking about the case where, let's say I have two or three of those directories, I switch, and then I do "bzr status", and I see only one directory that I never added.
<mkanat> lifeless: I think treating it like a contents conflict and making it .moved would be more in line with what I normally expect bzr to do.
<lifeless> do this
<lifeless> sit in bzr.dev
<lifeless> bzr switch 2.1
<lifeless> bzr switch 2.0
<lifeless> [using whatever layout you want :)]
<lifeless> oh, but dp a 'bzr selftest nothingtodo' at each step, to compile pyc files
<mkanat> Okay.
<lifeless> spiv: the 2.0->2.1 merge could use a NEWS merge magic to move the new items in 2.0.unreleased to 2.1.unreleased
<lifeless> spiv: any ideas how? file a bug ?
<lifeless> we should squelch /usr/lib/pymodules/python2.6/lazr/uri/__init__.py:19: UserWarning: Module launchpadlib was already imported from /usr/lib/pymodules/python2.6/launchpadlib/__init__.py, but /usr/lib/pymodules/python2.6 is being added to sys.path
<lifeless>   import pkg_resources
<lifeless>  too
<lifeless> actualy, lazr should
<spiv> lifeless: that would be good, file a bug
<lifeless> I did already, weeks back
<lifeless> now to find it
<mkanat> lifeless: Ah, okay.
<mkanat> lifeless: (I just went through the process.)
<spiv> lifeless: there's the related case of "new item in feature branch, when merged to trunk (or stable branch) move to right place"
<mkanat> lifeless: See, I think that if there were anything important in there, and they were in a deep directory structure, trying to sync them back into the right place from a lost+found directory would be difficult.
<lifeless> mkanat: cp -r lost+found/foo ./ would do it quite well
<spiv> lifeless: you're possibly thinking of bug 517490?
<lifeless> mkanat: where foo is a top level dir there, not the whole path
<ubot5> Launchpad bug 517490 in Bazaar "news_merge confused by added sections (affected: 1, heat: 6)" [Low,In progress] https://launchpad.net/bugs/517490
<mkanat> lifeless: On *nix, if you're familiar enough with the command line.
<lifeless> mkanat: explorer will permit copying to merge things too
<mkanat> lifeless: True. Does the OS X interface, also?
<lifeless> mkanat: I believe so
<mkanat> lifeless: Okay.
<mkanat> lifeless: Well, why not just not consider them conflicts?
<mkanat> lifeless: That is, just leave them where they are, unversioned, and don't add a conflict.
<lifeless> mkanat: thats what we do at the moment, and that is annoying us
<lifeless> spiv: no
<mkanat> lifeless: Is that new since 2.0? (I see conflicts in bzr status.)
<lifeless> spiv: grab 2.1 from lp, merge in 2.0. there is a small conflict - resolve that [its not what I'm talking about]. Then compare the result to what I committed in lifeless/bzr/2.1
<mkanat> lifeless: I see how it gets annoying when you move back to bzr.dev.
<mkanat> lifeless: Renaming them to .moved or .saved would work too, though, wouldn't it? You could do .saved.1 if there was already a .saved there.
<spiv> lifeless: I agree that isn't 517490
<spiv> lifeless: just that it's the closest I remember you filing
<lifeless> mkanat: so if we renamed them to .moved or .saved, (the dir that is), we'd have less issues with successive switching back
<lifeless> but we'd still clock up an impressive amount of cruft
<mkanat> lifeless: Yeah, true.
<mkanat> lifeless: And in the switch case, you probably don't want that stuff sticking around, usually.
<mkanat> lifeless: What if switching puts that directory in .bzrignore though?
<lifeless> ideally we'd just delete the dir - but that needs more info than we have [today], or a change in the definition of 'what bzr does to ignored files'
<lifeless> mkanat: so in branch A its versioned and B its unversioned and ignored ? we still promise not to delete files we can't recreate
<mkanat> Okay.
<mkanat> So we use the versioning status of it in branch B to decide whether it goes in lost+found?
<mkanat> I understand the convenience of it. I still think that it will be surprising to people who don't know the rationale, though.
<spiv> mkanat: I think some surprise is inevitable, given the constraints.
<lifeless> so the current concept I have in my head is:
<lifeless> when a directory is deleted by a transform and it has children we can't dispose of gracefully, we move the directory <somewhere>
<lifeless> unlike files *most* conflicts of this nature will be because of build products / editor temporary files (including ones bzr makes) and so on.
<lifeless> e.g. __init__.py~1~
<lifeless> I think Tom may have had it right when he had precious files, in arch.
<lifeless> so a question here is, is it better to do this now, or do precious files first, or just one of the two things
<lifeless> if we just do precious files (or junk files - they are symmetrical enough), we could gracefully dispose of more directories.
<lifeless> and the thing wouldn't be as fantastically annoying
<lifeless> if we just move directories we can't dispose of further than we do today, we won't get conflicts switching back and forth, but we will still pile up the cruft
<lifeless> if we do both, we won't get conflicts, and we won't pile up as much cruft
<spiv> Avoiding cruft is less important than avoiding conflicts.
<lifeless> so, I think, I'm going to just make these conflicts a little harsher - to dir.deleted
<lifeless> if thats not enough we can go for a single place to move the cruft, and-or junk|precious file categorisation
<lifeless> mkanat: thanks for asking all those questions
<mkanat> lifeless: Thanks for having the conversation with me. :-)
<spiv> If you do dir.deleted, make sure it still solves the problem with multiple levels of deleted dir, each with unmanaged files.
<lifeless> spiv: naturally - I already had that on my mental tests to write list
<lifeless> spiv: so - did you see what I mean with the 2.0->2.1 merge?
<spiv> lifeless: I haven't yet run those commands, but the description made sense.
<lifeless> spiv: so, I should file a bug ? Basically I want to copy upwards new things to show where they arrive in the series
<spiv> lifeless: yes
<lifeless> is there a tag for this
<spiv> I thought there was, but it doesn't seem to exist anymore.
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/583630
<ubot5> Launchpad bug 583630 in Bazaar "Support the news mangling we do when merging up across series in newsmerge (affected: 1, heat: 0)" [Wishlist,Confirmed]
<lifeless> spiv: https://bugs.edge.launchpad.net/launchpadlib/+bug/552419 is the warning to squelch bug
<ubot5> Launchpad bug 552419 in python-launchpadlib (Ubuntu) "Multiple module import warning from ubuntu-bug (affected: 5, heat: 30)" [Undecided,Confirmed]
<spiv> lifeless: ?
<lifeless> spiv: the launchpadlib already imported thing I was saying we should suppress
<lifeless> just FYI - gary closed it as invalid, need to find out why
<spiv> I'm still lacking context, I don't recall noticing that bug myself.
<lifeless> oh
<lifeless> are you running lucid ?
<spiv> Yes.
<lifeless> can you please run feed-pqm bzr (from trunk)
<lifeless> I see this:
<spiv> When would I notice it?  Using hydrazine?  Or just lp:... lookups?
<lifeless> ./feed-pqm bzr
<lifeless> /usr/lib/pymodules/python2.6/lazr/restfulclient/__init__.py:19: UserWarning: Module launchpadlib was already imported from /usr/lib/pymodules/python2.6/launchpadlib/__init__.py, but /usr/lib/pymodules/python2.6 is being added to sys.path
<lifeless>   import pkg_resources
<lifeless> loaded existing credentials
<lifeless> bzr lp-propose
<lifeless> etc
<lifeless> lp: lookup doesn't use launchpad apis.
<lifeless> ./feed-pqm bzr
<spiv> Yeah, that's what I thought.
<lifeless> /usr/lib/pymodules/python2.6/lazr/restfulclient/__init__.py:19: UserWarning: Module launchpadlib was already imported from /usr/lib/pymodules/python2.6/launchpadlib/__init__.py, but /usr/lib/pymodules/python2.6 is being added to sys.path
<lifeless>   import pkg_resources
<lifeless> bah pastefail
<lifeless> loaded existing credentials
<spiv> I don't see that with hydrazine trunk.
<lifeless> ok, thats *interesting*
<lifeless> fresh lucid install ?
<lifeless> what version of setuptools? do you have the launchpad ppa ?
<spiv> Depends on what you mean by fresh ;)
<spiv> Recently upgraded to lucid (< 1 month), but the system as a whole was originally installed >3 years ago, IIRC.
<lifeless> ok, not fresh :)
<lifeless> well, will need to dig deeper
<spiv> python-setuptools 0.6.10-4ubuntu1
<spiv> I don't think I have the launchpad PPA
<lifeless> and pkg-resources?
<lifeless> hmm
<lifeless> possibly pycentral or whatever to blame to
<lifeless> too
<spiv> Same version of pkg-resources
<lifeless> ok
<lifeless> something to track down later
<lifeless> for now; time to go pickup bank card, fuel the car - do the stuff that got truncated before
<lifeless> won't be long
 * igc lunch
<lifeless> I need a teddy bear
<lifeless> spiv: got a minute
<lifeless> actually scratch that, XXX time.
<lifeless> spiv: so we might want to move to 64K reads on pipes and sockets when we're in streaming mode
<lifeless> keep the buffers as empty as possible
<lifeless> or for cleverness value, figure out the current buffer size regularly and start reading in that size
<lifeless> can scale up quite large
<spiv> Yeah.
<lifeless> MBs
<spiv> Although at some point large reads may start hitting perf issues in our code
<spm> ziggy bytes!
<spiv> Due to relatively naÃ¯ve string splitting, etc.
<lifeless> \o/ partial branch fail -> uploading entire bzr now.
<lifeless> spiv: yeah. OTOH if we find those we can fix em
<spiv> Right.  Just something we should be aware of.
<lifeless> :(
<lifeless> :!bzr push lp://staging/~lifeless/bzr/propose-accepted
<lifeless> 119387kB    74kB/s | Fetching revisions:Inserting stream
<lifeless> spiv: another data point, we're doing many small writes in that push ^
<lifeless> write(7, "b\0\0\f\346B3289\ntexts\n\ngroupcompress-"..., 3307) = 3307
<spiv> lifeless: Hmm :(
<spiv> I thought we'd fixed that :(
<lifeless> - 207016kB     0kB/s | Fetching revisions:Inserting stream
<lifeless> a tad excessive, methinks
<spiv> For bzr.dev?  Oof.
<lifeless> yeas
<lifeless> now I get to test my patch
<lifeless> YAK SHAVING
<spiv> I hear you have particularly woolly yaks in NZ.
<lifeless> hmm, trunk is unhappy for lp-propose
<lifeless> however, dinner, then digging.
<lifeless> NotFound: Object: <canonical.launchpad.systemhomes.WebServiceApplication object at 0x6d90d90>, name: u'1.0'
<lifeless>  <>
<lifeless> back
<lifeless> ok, so lp-propose in trunk is failing to get an OAuth token
<lifeless> mgz: did you do the edge->production mass change?
 * lifeless needs to find it again
<mgz> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5244/bzrlib/plugins/launchpad/lp_propose.py
<mgz> revert that, see if it magically fixes it
<lifeless> mgz: it does
<lifeless> mgz: or rather, reverting the entire patch fixed it
<mgz> okay, so, either I didn't know what I was doing and broke something, or a change is needed elsewhere as well
<lifeless> mgz: possibly/probably the latter. Or cached credentials may be at fault.
<lifeless> mgz: I propose to:
<lifeless>  - back it out now [so dailies don't get broken etc]
<mgz> can you see if just backing out that line is sufficient?
<lifeless> sure
<mgz> narrows down what needs looking at. if it's just that, nix it.
<lifeless> yeah, that makes it work for me
<lifeless> https://code.edge.launchpad.net/~lifeless/bzr/propose-accepted/+merge/25747
<lifeless> mgz: so, roll back that one change and you'll inwestigate ?
<mgz> yeah, revert that file then, and maybe someone who knows launchpadlib can say what was wrong
<lifeless> I think its probably something to do with the beta->1.0 change. Or something.
<mgz> or yeah, I can poke further
<lifeless> so, I think the key elements are:
<lifeless> lets open a bug on this
<lifeless> so we can close the one about xmlrpc
<mgz> right, makes sense.
<lifeless> I'll do that
<mgz> are there any elements not done for the current bug? it's filed against three projects.
<lifeless> whats the current bug # ?
<lifeless> 581670
<mgz> ...I just spent fifteen seconds failing to copy that from my address bar >_<
<mgz> mouse/keyboard coordination lacking
<lifeless> :)
<lifeless> https://bugs.edge.launchpad.net/bzr/+bug/583667
<ubot5> Launchpad bug 583667 in Bazaar "bzr talks to edge API servers to propose merges etc (affected: 1, heat: 0)" [Wishlist,Confirmed]
 * mgz unedges the url to subscribe
<lifeless> also, naughty, the 581760 change didn't have NEWS entry.
<lifeless> please always put stuff in NEWS if it is going to matter to anyone.
<mgz> didn't really seem user-facing to me, but maybe it is
<lifeless> new cached credentials
<lifeless> every user having to re-auth against lp is fairly user facing :)
<mgz> ah.
<lifeless> now, arguably we should use the same token file on edge and prod
<lifeless> I'll file a bug on that in a sec.
<lifeless> mgz: https://code.edge.launchpad.net/~lifeless/bzr/lp-propose-host/+merge/25749 review kplease
<mgz> done.
<lifeless> oh also - for judging whether to put something in NEWS
<lifeless> we have a programming userbase too; so 'user facing' really means 'end user or plugin/api consumer or devs-should-know'
<lifeless> if that makes sense
<mgz> hm, sure.
<spiv> We even have an "Internals" section in NEWS
<spiv> For changes likely to be significant for other bzrlib devs, I guess, even if it's not strictly meant to affect end users or 3rd party code.
<lifeless> mgz: anyhow, enough said about it - I think you need to dial up the 'tell people about it' sensitivity a bit and its all good.
<igc> night all
<lifeless> gnight
<mgz> hmpf, need to get some of my harder stuff to a landable state, not just doing these ten-minute changes
<lifeless> true
<lifeless> and I'm going to encourage you on the testtools exception encoding thing too.
<lifeless> though I think its temporarily under control
<mgz> I'm struggling to write that in a non-black magic way
<lifeless> if you want a teddy bear, tell me your thoughts
<lifeless> I'm utterly failing to do $fridaynight
<mgz> well, to change how testtools formats the traceback, I'm adding a method _exc_info_to_unicode to TestResult
<mgz> which is basically just _exc_info_to_str but with traceback.format_exception swapped out
<mgz> but means I need to to do one of 1) duplicate the function, 2) monkey-patch, 3) crazy low level stuff
<mgz> and it only gets more squiggly from there
<mgz> the bits that need to be change are scattered across unittest, traceback, and linecache and not in any coherant manner
<lifeless> ok
<lifeless> so lets start at the bottom
<lifeless> we know we want a fixed linecache ?
<lifeless> lets say we have a fixed_linecache module
<lifeless> which we use and wraps linecache
<lifeless> ignoring how we choose to use it, it can be tested well there, yes ?
<mgz> hm, yeah, the other option I was considering there was giving it promoted tuples, which also store the file encoding
<lifeless> sure, that seems orthogonal to where you put the adaption stuff
<lifeless> somewhere we need the code that fixes linecache
<lifeless> so lets get that solid with tests.
<lifeless> then a fixed traceback, with tests. We could use mocking or dependency injection, or just integration tests for that.
<mgz> was it selftest you suggested as a template for whole-source-module tests?
<mgz> test_selftest that is
<lifeless> oh
<lifeless> bzrlib's test_plugins does something like that
<lifeless> as does testrepository
<lifeless> testrepository uses testresources... hmm
<mgz> a, testrepository, that was it
<lifeless> jml: how would you feel about testtools growing a make check dep on testresources?
<mgz> but yeah, the test_plugins way makes sense to me
<jml> lifeless: fine by me.
<mgz> this is going to be 90% corner cases, but should all end up making sense, and cover the common(ish) case of locale'd os messages
<jml> lifeless: I kind of half-think they should be one project anyway
<lifeless> mgz: ok, so you could use either - have a look at both. If you want to use testresources, I'll happily have the generic resources from testrepository lifted up into testresources in a new resources package, or something.
<lifeless> jml: possibly
<lifeless> man, today was a bug filing day
<mgz> I see you've done an impressive number
<mgz> five or so just from lp-propose investigations
<lifeless> GaryvdM: actually bzr-search wasn't quite fixed; Its fixed now.
<GaryvdM> lifeless: cool
<lifeless> spiv: apparently resolve --take-other will delete the dir and its contents
<lifeless> this is tolerable but still ... icky, I think
 * lifeless pops up a level
<lifeless> jam: gmorning
<GaryvdM> amanica: Mow about hacking together this Sunday?
<GaryvdM> amanica: Is your wife busy?
<bialix> mow?
<GaryvdM> Hi bialix
<bialix> hey Gary :-)
<jam> morning lifeless
<jam> Peng__: history-db just landed in trunk, if you want to check it out :)
<amanica> hi GaryvdM :-) , I'll have to check with her, but I'm keen to get some things done this weekend. will have to let you know
<bialix> hey amanica! how's your trip back?
<GaryvdM> amanica: Ack
<amanica> hi bialix, I slept like a baby in the plane. it still took me a couple of days to recover
<amanica> bialix, I used some of the russian you tought me today
<bialix> yep, the same here
<bialix> oh, nice
<amanica> good to here
<bialix> you make your coleage shy?
<amanica> no :-) , but she said she "isn't lazy!"
<bialix> work hard, don't be lazy!
<amanica> yep :)
<bialix> lol
<bialix> and what you said?
<amanica> I told her the story about why I thought about learning that in russian
<amanica> her russian is a bit rusted though.
<amanica> bialix, you never tought me how to say goodbye
<bialix> bye == poka
<amanica> wow
<bialix> or even paka
<amanica> cool
<bialix> goodbye is longer
<bialix> do svidanya
<bialix> direct translation: for next meeting
<amanica> cool thanks
<GaryvdM> bialix, amanica: qannotate now has Stable ScrollÂ®
<amanica> GaryvdM sweet!
<GaryvdM> bialix, amanica : It also trys to keep the selection stable, but is a bit iffy if the selection is inside a modified hunk
<bialix> Stable Scroll?
<GaryvdM> bialix: If you change revision/refresh/change encoding, it keeps you scroll position.
<GaryvdM> *your
<bialix> COOOOOOOOOL!
<beuno> removed:
<beuno>  loggerhead/wholehistory.py
<beuno> \o/
 * GaryvdM must take a look at history-db to see if it can be used in qlog
<GaryvdM> jam: You said earlier that history-db landed in trunk. Is that in loggerhead?
<jam> GaryvdM: yes
<nigelb> If I want to import a cvs repository to bzr to dissect commits, how do I go about it?
<jam> nigelb: cvs2bzr would be my suggestion
<jam> in the cvs2svn project
<nigelb> jam: is there documentation somwhere I can refer to while it installs??
<jam> Not sure offhand
<nigelb> no problem,s I'll look at man :)
<jam> also, you probably want bzr-fastimport
<nigelb> well, now the problem is cvs2bzr fails because I dont' have a cvsroot directory, sigh
<jam> it expects you have the raw repo, I believe
<nigelb> great.  I only have an annonymous checkout
<nigelb> Nothing I can do in that case?
<jam> ask launchpad to import it for you?
<nigelb> just for dissecting a commit, wouldn't that be abuse? ;)
<jam> how much history do you want?
<jam> lp doesn't really mind
<jam> the project might even already be there :)
<nigelb> there is a bug fixed between 1.2.2 and 1.2.3 release and cvs isn't friendly enough to examine the thing
<nigelb> the project uses source forge
<nigelb> jam: as you said, there is a project
<nigelb> and I just requested code import. :)
<bialix>   File "C:\Python25\lib\site-packages\testtools\content.py", line 91, in <lambda>
<bialix>     content_type, lambda: [value.encode("utf8")])
<bialix> UnicodeDecodeError: 'ascii' codec can't decode byte 0xd2 in position 425: ordinal not in range(128)
<bialix> and what I should do?
<jelmer> bialix: it looks like value is a plain string and not a unicode string
<vila> bialix: ping mgz ;-)
<bialix> yes, it is
<bialix> I'm trying to write test for diff
<bialix> there is only plain strings
<bialix> but with non-ascii characters
<bialix> mgz: ping!
<bialix> vila: what I can do about this problem?
<bialix> I'm sure my test is correct now, but I can't go further
<vila> bialix: use pdb to identify the string
<bialix> which string?
<vila> I think there is an env variable to make selftest call pdb on execptions
<vila> bialix: value
<vila> bialix: the one that is failing
<bialix> just print was enough
<bialix> found
 * mtaylor thinks bzr launchpad-login should grab info from launchpad and set bzr whoami... would make getting set up on a new box quicker
<jelmer> mtaylor: or the other way around perhaps
<jelmer> mtaylor: it could just ask launchpad for the credentials associated with the current users id
<jelmer> not the credentials but the username
<jelmer> having launchpad provide your credentials for you is probably not such a good idea :-)
<mtaylor> good point
<GaryvdM> jam: Hi
<GaryvdM> jam: I'm trying to grork history-db
<jam> hi GaryvdM
<GaryvdM> jam: Is there a README?
<GaryvdM> jam: I have some questions, I don't want bug you if there are docs I should read first. The only doc I could find is dotted_revno_caching.txt
<jam> GaryvdM: that's the only doc I know of :). What are you looking for?
<jam> Querier is what you are going to want to be using
<GaryvdM> jam: How do I get it to create and populate a db?
<GaryvdM> jam: Does it update on tip change or read?
<GaryvdM> jam: or revision fetch?
<jam> GaryvdM: history-db has hooks to auto-update on tip changed
<jam> however, anytime you use Querier, it also ensures that the data has been imported
<jam> (Querier.ensure_branch_tip() will import if it hasn't already)
<jam> You might want to use "bzrlib.plugins.history_db._get_querier" which will cache a Querier object on the Branch object
<GaryvdM> jam: Cool, so if you do a tip change with out the plugin, things will be ok.
<jam> yep
<GaryvdM> jam: How do I get it to create and populate a db?
<jam> The way the plugin is written, it will manage a db if you set "history_db_path=XXX"
<jam> If you want qbzr to depend on it existing, then we can look at having a custom field (loggerhead does this)
<GaryvdM> jam: enviroment var, or config?
<jam> config
<nigelb> ok, so LP cannot import from sourcforge? running into issues because anonoymous access still requires a password :/
<GaryvdM> jam: I plan to make qlog use it if availible, else work the old way
<jam> nigelb: I'm pretty sure you can import from the https:// anon access
<jam> At least, google shows other projects being imported from there
<jam> GaryvdM: so one option is to use Branch apis that history-db interacts with
<jam> such as Branch.iter_merged_revisions()
<nigelb> jam: hm, I'll read that up
<jam> (iter_merge_sorted() ?)
<GaryvdM> jam: ack
<GaryvdM> jam: can history db's be shared accross branches and repos?
<nigelb> jam: um, ok I can't find anything for that :(
<jam> GaryvdM: yes, and it is intended to be used that way
<jam> (it was intentionally designed to share history between branches)
<GaryvdM> jam: You have a cmd_history_db_create, but it's not registered.
<jam> GaryvdM: it should be, as I use it
<jam> hmm. I wonder if I deleted the registration by accident when I removed some other stuff
<jam> probably
<lifeless> <early> moin
<GaryvdM> Hi lifeless, wow, very early.
<jam> GaryvdM: restored
<GaryvdM> jam: I'll check for you
<GaryvdM> oh - og
<GaryvdM> *ok
<jam> I got rid of a bunch of them, accidentally included this one
<lifeless> GaryvdM: yes, sleep fail.
<lifeless> tail end of jetlag getting its revenge, I think.
<GaryvdM> ~/bzr/bzr.dev $ bzr history-db-create
<GaryvdM> bzr: ERROR: sqlite3.OperationalError: unable to open database file
<GaryvdM> jam: Must I create it my self with sqlite?
<GaryvdM> lifeless: sorry to hear that
<jam> GaryvdM: no, it should create it itself, but you have to tell it where with --db or by setting history_db_path=XXX
<GaryvdM> I'm like jelmer - no fail once I get to bed, but I fail alot in getting to bed
<GaryvdM> jam: I did
<jam> bzr history-db-create --db=test.db -d .
<jam> try that
<GaryvdM> jam: global config in ~/.bazaar/bazaar.conf
<jelmer> GaryvdM: lol :-)
<GaryvdM> ok
<jelmer> that's a nice way of putting it
<jam> hmm... still should have worked
<jam> does the *directory* where you wanted to create the db exist?
<jam> I only create the db itself
<GaryvdM> jam: command worke
<GaryvdM> jam: let me check
<GaryvdM> jam: sorry - I had a typo in my .conf
<jam> :)
<lifeless> jam: the brain in 2 days ;P
<jam> lifeless: nice. I should have mentioned that a lot of the mobs don't see a lot of use.
<lifeless> :>
<jam> At high level, it tends to be ichi swarm because of all the towers
<jam> and fast rebuild time
<jam> and 2 ichi == 1 crabatron, but they build in <1/2 the time
<lifeless> ah
<lifeless> designing games is hard
<lifeless> designing is hard
 * GaryvdM curses backyard monsters..... (I'm addicted...)
<lifeless> thats it, friend request for you.
<jam> I'm just waiting for Robert to come out of protection so I can raise his town :)
<lifeless> raise or raze :P
<GaryvdM> dam - just got the trogen, and ackpected...
<GaryvdM> *accepted
<GaryvdM> lifeless: Your yard is very neat - I wish I could restart...
<lifeless> GaryvdM: you can move things
<lifeless> GaryvdM: long click on something
<GaryvdM> Ah - that is very cool
<lifeless> my yard is probably sillyly laid out and jam will toast me
<lifeless> but perhaps not
<jam> lifeless: well, it depends what level your towers are :)
<lifeless> 5 ?
<jam> but generally, you need overlapping fire on towers
<jam> or i can send 20+ mobs to take the towers down one-at-a-time
<lifeless> I wish the fire zone showed
<lifeless> I *think* my snipes are all overlapping
<jam> absolutely, I really miss that from DD
<jam> snipers are excellent at taking out non tower attackers
<jam> usually only 1-shot 1-kill
<Meths> Which game is this?
<jam> but it takes 4 shots to kill an ichi with a level 5 tower
<jam> Meths: Backyard Monsters, (a facebook game)
<jam> and I can build something like 40 ichis for one go
<jam> oh, and upgrading the flinger should take low priority
<jam> you can fling multiple times
<jam> lifeless: on the flip side, a full aoe tower takes 20 hits, but can kill all 40 ichis at once
<jam> anyway, nothing really stands against multiple waves
<GaryvdM> jam: Could we add a branch lines table, or is there an easy to query for it?
<jam> doesn't that only matter when you have them expanded?
<GaryvdM> jam: If the rev no in dotted_revno in 3 fields, we could SELECT UNIQUE on the first 2. Would that be fast?
<GaryvdM> jam: hmm - intresting point
<jam> so certainly we should think about what you need
<jam> But if you expand, and see that there is 1.2.100, you can certainly send another query for 1.2.1-99
<jam> which should be pretty cheap given the existing apis
<jam> they can all be done in parallel
<GaryvdM> jam: could I query for 1.2.* ?
<jam> not going through Querier
<jam> probably could from an SQL perspective, would have to think about it
<jam> I think so
<jam> but until you expand, you don't know if you want 1.2 or 10.50
<GaryvdM> jam: with current schema a LIKE, but 3 fields would be cheaper
<GaryvdM> ^ query for 1.2.*
<GaryvdM> jam: logic would be like this:
<jam> GaryvdM: the cost is going to be in walking the mainline, since you need to exclude other branches, etc.
<jam> I don't think SELECT UNIQUE vs LIKE is going to be a big deal
<GaryvdM> jam: I was thinking of to queries: select unique was to get a list of branch lines (which I might not need)
<GaryvdM> like was for getting the revisions in a branch line.
<GaryvdM> and LIKE would not be needed for that if the rev no was stored as 3 fields
<GaryvdM> I'm trying to think about what we load in to mem, and when....
<jam> GaryvdM: so we can certainly discuss how qbzr could look
<jam> like just grabbing the mainline to fill a page to start
<jam> and then using 'iter_merge_sorted' when expanding a node
<jam> to get just what was merged into that rev
<jam> and possibly filling out the rest of the branch line
<jam> I'm not sure if the latter is needed or not
<jam> vs just having a 'tail' pointer that could be expanded
<GaryvdM> jam: yes - was just about to say that
<GaryvdM> for branches like emacs and OOo
<jam> And iter_merge_sorted() is available on Branch and optimized today by bzr-history-db
<jam> so it would allow you not to directly think about bzr-history-db
<jam> branch already caches its merge sorted result
<jam> so it will be cheaper if you have it, but okay if you don't
<jam> ok== no worse than today I tihnk
<jam> loggerhead couldn't because it doesn't hold onto a branch between requests
<GaryvdM> jam: I create a fake merge rev for viewing multiple branches, and branches with pending merges. Could we add a revision and its merge sort, with the revid a hash of the parnent ids?
<jam> GaryvdM: you could certainly do something like that
<jam> not sure how to inject that into Importer
<jam> but i'm sure we could find a way
<GaryvdM> jam: Cool - I think this could work well.....
<exarkun> Are repositories safe for concurrent access?
<lifeless> yes
<exarkun> Hooray.  Thanks.
<lifeless> why do you ask?
<exarkun> Coz I'm about to have a repo shared between multiple mostly-uncoordinated actors doing checkouts of various things
<exarkun> So I'd like for the repo to not end up corrupted by this. :)
<exarkun> Do you know if the same goes for the stuff in ~/.cache/bazaar/svn?  Coz I'm checking out from an svn repo.
 * exarkun waits ages for the initial 'bzr checkout' to complete so he can see what happens next
<lifeless> less so but enough
<lifeless> one particular bit that isn't safe is ~/.bazaar/locations.conf
<lifeless> which bzr-svn writes to (once per repo I think)
<lifeless> there is a bug on this
<exarkun> yea, I filed that one
<exarkun> Humm
<exarkun> Is it okay if my 'bzr checkout' gets SIGKILL'd?  I mean, if I start it over again, does it pick up where it left off, or does it have to start from scratch?
<exarkun> It was still working through the write-to-.bzr/repository/upload/ step when it got killed
<exarkun> (my build system is configured to think 1200 seconds without output means something is broken :/)
<lifeless> exarkun: the various components are created in a safe order but generally you'll start over. If you're using bzr-svn it does repository insertions in batches
<exarkun> I'm just doing "bzr checkout svn://...", I'm not sure if that's bzr-svn or not, but I guess so?
<lifeless> if you're using a shared repositroy and bzr-svn, it will resume from ~ where it left off
<lifeless> thats bzr-svn
<lifeless> you're using a shared repository if you've done 'bzr init-repo' somewhere above the directory you're checking out into
<exarkun> Yea, that's what I've done
<lifeless> in which case it should resume for you
<lifeless> if this is twisted... you can also seed repo with an already converted branch by pulling that into it anywhere
#bzr 2010-05-22
<Lor> What would be the most efficient way to make a gazillion pulls from a particular host, with the assumption that most of those pulls will do nothing (the local branch will be up-to-date)?
<Lor> Would it make sense to open multiple transports in parallel?
<exarkun> If I want my shared repo to be more general, can I just move the .bzr directory up a directory level or two?
 * exarkun tries it to see what happens anyway
<Lor> I think it ought to work.
<exarkun> Hey cool it's working I guess
<Kamping_Kaiser> how can bzr use 33013KB to repack 850kb of text? ;s
<Kamping_Kaiser> [################|   ]  33319KB    48KB/s | Fetching revisions:Inserting stream:repacking texts:texts 9184/16360
 * Kamping_Kaiser kills it
<exarkun> How did I make this happen?  And how do I fix it?
<exarkun> bzr: ERROR: Repository KnitPackRepository('file:///var/lib/buildbot/.bzr/repository/') is not compatible with repository SvnRepository('svn://svn.twistedmatrix.com/svn/Twisted')
<hno> Hmm.. shouldn't bzr automatically figure out if my local shared repository already have a copy of a referenced remote branch?
<hno> did a bzr diff -r ancestor:. --new lp:...   and the shared repository of the current branch also includes a copy of the lp branch.
<hno> and yet it fetches some 10MB of data from the lp branch.
<spiv> hno: it should, yes
<spiv> hno: mind adding -Dhpss to that command line and filing a bug?
<spiv> hno: (attach your ~/.bzr.log)
<hno> spiv: Will do.
<hno> HPSS calls: 193 (188 vfs) SmartSSHClientMedium(bzr+ssh://henriknordstrom@bazaar.launchpad.net/)
<hno> hi lifeless
<hno> Hmm.. I must be stupid but how do I file a bug report. Can only figure out how to search for them...
<lifeless> hi hno
<lifeless> on ?
<hno> bzr
<lifeless> bugs.launchpad.net/bzr
<lifeless> top right 'report a bug'
<hno> ah, the big red one...
<lifeless> vila: haihai
<vila> lifeless: hey ;-)
<lifeless> I wish lp apis were easier to test with.
<lifeless> do we have a supported mocking tool ?
<vila> not that I know of :-(
<vila> I think I read people using staging for that lately
<vila> yes, I know you asked for a mockup
<lifeless> o/~ shave that yak
<lifeless> yakkity yak
<hno> bug filed.
<hno> wonder why I always seem to run into these cases of excess bandwidth usage by bzr.. can't imagine my use of bzr is that strange compared to what most others are doing.
<lifeless> we have two critical bugs open at the moment about just that
<lifeless> maybe you filed a dupe
<hno> bzr diff remotebranch fails to find that the remote revisions is already in the local repository.
<hno> https://bugs.launchpad.net/bzr/+bug/584148
<ubot5> Launchpad bug 584148 in Bazaar "bzr diff remotebranch makes poor use of revisions on local repository (affected: 1, heat: 0)" [Undecided,New]
<lifeless> ah
<lifeless> that isn't what we've got open; and it is a little unusal
<lifeless> while it works - and thats important - most folk mirror things locally to play with them
<hno> lifeless: I don't think the case based on bzr switch is that unusual...
<lifeless> hno: thats orthogonal really
<hno> ?
<hno> to the bug yes.
<lifeless> I use switch based workflow myself
<lifeless> for most everything
<hno> so it will bite you as well.
<hno> except that you diff by using merge...
<exarkun> Uh so
<exarkun> http://buildbot.twistedmatrix.com/builders/hardy32-py2.5-glib2/builds/24/steps/bzr/logs/stdio
<exarkun> Anybody?
<exarkun> I see there's a ticket filed about this.
<exarkun> Anyone know of any docs about bzr-svn plus tdb?
<exarkun> The last comment on https://bugs.launchpad.net/null/+bug/185200 suggests that just installing python-tdb will address the issue, but I've had it installed since I started setting this up, and it doesn't seem to have been used.
<ubot5> Launchpad bug 185200 in Bazaar Subversion Plugin ""database is locked" bzr internal error (affected: 2, heat: 0)" [High,Fix released]
<jml> jelmer_, hello?
<jelmer_> jml: hey
<jml> jelmer_, I was wondering if I could tempt you into helping out exarkun
 * jelmer_ looks at the backlog
<jelmer_> exarkun: hi
<exarkun> Heya
<jelmer_> exarkun: you may have to remove the existing cache files since they will be in sqlite
<exarkun> In ~/.bazaar/svn-cache/ ?
<jelmer_> exarkun: yep, or ~/.cache/bazaar/svn
<exarkun> Okay, I'll try that.
<jelmer_> we should be able to leave this whole thing behind us when the cache format becomes pack-file-based
<exarkun> The new cache file is a "SQLite 3.x database"
<jelmer_> exarkun: what version of bzr-svn and python-tdb do you have?
<exarkun> Bazaar (bzr) 2.1.1
<jelmer_> exarkun: and bzr-svn and python-tdb?
<exarkun> Uh, "svn 1.0.2"?
<exarkun> And python-tdb 1.1.1~svn26294-1 (ie, hardy package)
<jelmer_> exarkun: the hardy package of python-tdb is probably too old
<jelmer_> anyway, gtg - back in about an hour
<exarkun> I suppose I'll fix this some other way then
<strk> is 'bzr clone' different from 'bzr branch' ?
<exarkun> no
<exarkun> See the "Aliases" section of "bzr branch --help"
<exarkun> Uhm
<exarkun> How about this?
<exarkun> bzr: ERROR: Pack '51d53eb11548019c7208e76646979ac4' already exists in <bzrlib.repofmt.groupcompress_repo.GCRepositoryPackCollection object at 0x1cddc50>
<exarkun> lifeless: I think next time someone asks if concurrent access is safe, you should say no.
<jelmer_> exarkun: that's a known bug in older versions of bzr iirc
<jelmer_> exarkun: it doesn't have anything to do with bzr-svn at least
<marioxcc`> hi all
<marioxcc`> i have a question:
<marioxcc`> how are the branch in bazaar relative to branch in git?
<marioxcc`> Â¿do bazaar and git use the same model of heads or what are the diferences?
<exarkun> jelmer_: Seems maybe to have gone away after upgrading from 2.0 to 2.1, thanks
<ricqles> Hi all !
<exarkun> Can I have hooks run when 'bzr svn-update' updates a bzr branch from an svn repository?
<mkanat> exarkun: post_branch_tip_change would work, wouldn't it?
<exarkun> mkanat: I have no idea, I've never heard of that thing before
<exarkun> Google returns no hits for it
<mkanat> exarkun: "bzr hooks" will get you a list of hooks.
<exarkun> Neat
<exarkun> Oops
<exarkun> I get a traceback
<mkanat> exarkun: It's pre_change_branch_tip -- I tyoped it slightly. :-)
<mkanat> exarkun: Or post_change_branch_tip
<effstops> hey guys, has anyone had trouble with the OS X installer?
<effstops> as it's installing sip I get the error "The Installer could not install some files in "/".
<exarkun> mkanat: Thanks.
<exarkun> Hm, I guess that's not really my top priority now though
<exarkun> I still need to figure out how to fix this SQLite3 "database is locked" issue.
<exarkun> I bet I can set $HOME to get bzr-svn to use a different svn-cache
<exarkun> I wonder if there's a better way, though (hopefully a way that won't accidentally affect a ton of other stuff too)
<exarkun> Does 'bzr checkout svn://...' make a lot of connections to the svn server?
<marioxcc`> exarkun: use netstart to check
<exarkun> netstart?
<mkanat> exarkun: netstat
<exarkun> Ah.  That's kind of tricky, since I'd have to be sure to run it in a super fast loop and then filter the results to see how many connections it made.  I was hoping someone would just know.
<jelmer_> exarkun: one or two
<exarkun> I can use strace, though.
<exarkun> jelmer_: Aha, thanks.
<exarkun> I'm now seeing my inetd decide to disable svnserve because too many connections are coming in
<jelmer_> exarkun: it will reuse connections it opens, and it fetches revisions serially
<exarkun> but all I've done is switch things from 'svn co ...' to 'bzr co ...'
<exarkun> I suppose if it was already near the limit and sometimes bzr uses two, that might have pushed it over.
<exarkun> jelmer_: Any hints on a good way to get my different... actors... to use different svn-cache directories, aside from setting $HOME differently for each of them?
<jelmer_> exarkun: why would you want to?
<exarkun> jelmer_: Because I can't find a python-tdb package for Hardy that's new enough for bzr-svn and so most of my 'bzr checkout' commands are failing with SQLite3 errors
<exarkun> If you have other ideas about how to fix that, I'm open to suggestions
<jelmer_> exarkun: You could avoid using the cache altogether but that will impact performance
<exarkun> Yea... that's like an extra 30 - 45 seconds per checkout?
<exarkun> Or rather, it's whatever the regular cache initialization overhead is, but every time, because there's no cache?
<jelmer_> exarkun: no, it's less than that I think
<exarkun> Maybe I can try it and see.  How would I do it?
<jelmer_> exarkun: set use-cache = False in subversion.conf
<exarkun> am I overlooking some docs for bzr-svn?  I read what I could find with google, but it wasn't much, and didn't cover this.
<exarkun> What section does use-cache go in?
<exarkun> Probably not bbbe8e31-12d6-0310-92fd-ac37d47ddeeb
<jelmer_> the applicable repository
<exarkun> really, really, really slow :/
<exarkun> minutes in, still running
<exarkun> done... about three and a half minutes
<exarkun> so, sort of defeats the point in this case
<Lor> Is there some conceptual difference between push and pull? Or are they the same operation, just from different perspectives?
<jelmer_> Lor: they don't have any significant conceptual differences
<Lor> They don't seem to share much code, though.
<Lor> All right, Branch.update_revisions seems to be the highest-level operation that both call.
<Lor> (Not very high, it would seem)
<jelmer_> Lor: it's pretty high
<Lor> Well yes, but ideally, "bzr push -d foo bar" would just be an alias for "bzr pull -d bar foo", whereas now there are huge amounts of push- or pull-specific code.
<jelmer_> Lor: I think huge is exaggerating
<jelmer_> Lor: There's also a difference between conceptual difference and implementation
<Lor> All right, granted.
<jelmer_> Lor: I think the implementation is optimized so that you usually push from a local repo and pull into a local repo
<jelmer_> rather than pushing from a remote repo into a local repo, etc.
<Lor> Surely either operation could check which of the branches is local and choose a suitable implementation accordingly at runtime?
<jelmer_> well, s/implemented/intended to be implemented/
<jelmer_> Lor: sorry, s/local/quick/, s/remote/slow/
<Lor> Which would be faster if it is to be expected that both branches are in sync already?
<jelmer_> about the same speed I guess
<lifeless> Lor: cd into one of the branches, run push or pull appropriately
<exarkun> jelmer_: Will python-tdb 1.1.5 work with libdb1 1.1.1?
<Lor> lifeless, I don't understand. How is the working directory relevant?
<jelmer_> exarkun: I'm not sure I follow - libdb1 is unrelated
<exarkun> Pardon me
<exarkun> libtdb1
<jelmer_> I think so but I would recommend just upgrading libtdb1 as well while you're at it
<jelmer_> they're both from the sam upstream source package
<exarkun> That seems to work
<lifeless> Lor: push [largely] ignores the working tree, pull updates the local working tree
<lifeless> push updating the target working tree in a local push is a bit of an anachronism
<lifeless> Lor: are you preparing a patch for push and pull?
<Lor> No, I'm just wondering what's the best way to do a two-way sync between two repositories that have a large number of branches, only a few of which have probably changed.
<lifeless> there is a multi push / multi pull plugin aruond
<Lor> Yes, but this is a bit different.
<lifeless> the largest overhead there is that the same repo gets serially reopened and probed every time
<lifeless> ideally you'd gather the revs needed from all branches + all tags, fetch those at the repo layer, then update the branches
<lifeless> its somewhere on my list to make openning a branch with an existing repo object easier
<Lor> Actually, I have a directory hierarchy that contains a number of projects, each of which has its own repository, and one or more branches.
<Lor> I read somewhere that it's not a good idea to store unrelated projects in a single shared repository.
<Lor> But if both the local and remote branch are at the same revision already, then is the repository opened at all?
<lifeless> yes
<lifeless> opening a branch opens the repo
<lifeless> thats a single RPC to do both if you're using bzr+ssh
<lifeless> we don't care either way if you use a single repo or several; b+tree indices mean there is only marginal overhead until you get to loads and loads of revisions
<Lor> https://lists.ubuntu.com/archives/bazaar/2008q1/038715.html
<Lor> So this is outdated?
<lifeless> no its accurate
<lifeless> john describes the constraints well
<Lor> All right.
<lifeless> our scaling goal, when building the indices we use, was a repository with 1000000 revisions, and a total of 1000000 files.
<Lor> Shouldn't a repository be able to segregate different projects into distinct stores internally?
<lifeless> no
<Lor> After all, related branches always have the same tree root id nowadays, right?
<lifeless> same root id doesn't mean same project, because of old trees
<lifeless> also it would be a bunch of cpu overhead to do such an analysis
<lifeless> if you want separate stores, it should be really easy to use different repos
<Lor> Yes, except the directory layout is constrained by the fact that a repository must be in a parent directory.
<Lor> I can't do a branch/project layout, I have to do project/branch
<lifeless> regardless; we support having unrelated projects in one project.
<lifeless> they should perform ok
<Lor> All right.
<Lor> I'm a bit wary of that, though, since I remember that at one time I stumbled upon a bug that gave some collision alerts when I tried to store multiple unrelated projects in a shared repo.
<lifeless> if they don't, and you're under the 10^6x10^6 scaling factor, its likely a shallow bug. If you're scaling above that we may have deeper work to do.
<Lor> I know it's been fixed, but nowadays I'd rather keep each repository small just to limit possible damage if a repository gets broken somehow.
<Lor> Yes, I don't think I'm going to have any performance problems regarding the repositories themselves.
<Lor> I'm more worried about latency when doing a large number of pulls and pushes.
<Lor> But this is premature, I will soon see how well thing work in practice.
<lifeless> the potato programming around branches will be a signficant slowdown
<lifeless> We should help you with that and make it better for all. \o/.
<Lor> Does push record the pushed revision-id so that if another push to the same location is attempted before there are new local revisions, no transport is even opened?
<lifeless> no
<Lor> All right, I will probably implement something like that myself, then.
<lifeless> that would be a bug in any case, because the remote repo might have regressed
<lifeless> s/repo/branch
<Lor> Ah.
<lifeless> the possible_transports parameter will be of use to you, I suspect.
<Lor> I'm not sure. I'm probably arranging things so that I open a transport only once and then do everything with that transport.
<Lor> I was also toying with the idea of opening multiple transports to the same location.
<lifeless> as bzr is synchronous that won't help much unless you also use threads
<Lor> That was implicit. :)
<lifeless> if you use threads be sure to instantiate all bzr objects within that thread - we're thread safe as a library [modulo bugs] but don't support using a single object concurrently in different threads ;)
<lifeless> wil you be using bzr+ssh ?
<Lor> Probably, yes.
<lifeless> ok
<lifeless> I have a suggestion
<lifeless> the server is pluggable
<lifeless> you can add methods to it
<lifeless> calling them is a little....ugly, but doable.
<lifeless> write two server side methods
<lifeless> one to take a root dir
<lifeless> open all the branches
<lifeless> it would return two things
<lifeless> firstly, for each branch: the (branch lock token) and the (last_revision) for each branch
<lifeless> secondly, a set of heads obtained by checking the tags and last_revisions for each branch and using the local (its on the server remember) repository to remove ancestors - just call heads basically.
<Lor> I looked at the bzrtools implementation of heads and it seemed surprisingly nonstraightforward.
<lifeless> the second server side method would take a list of branches  with each getting a branch lock token, a new tip, a new tags dict, and would apply it to each branch, unlocking them afterwards
<lifeless> Lor: repository.get_graph.heads()
 * lifeless handwaves
<lifeless> its trivial to just do the core
<lifeless> anyhow, you'd then do this:
<lifeless> new_method_1()
<lifeless> open the remote repo (or pethaps new-method-1 returns it too
<lifeless> do a missing-graph-chatter [ its in remote.py's fetch codepath, I think. I can help you, just not today, on this bit]
<lifeless> remote_repo.fetch(local_repo, search_result=result-of-missing-graph-chatter)
<lifeless> new_method_2()
<lifeless> so, 5 or 6 round trips
<Lor> So basically a protocol extension to support repo-push directly?
<lifeless> yes
<lifeless> we designed to permit extensions [like this] - though this is one we do want the core to have eventually anyway
<Lor> I get the idea, but compatibility with current versions is important to me (I don't want to install a cutting-edge bzr.dev on every remote machine).
<Lor> Also, I just remembered, I try to use encrypted repositories when possible, and until bzr supports it directly, the best solution I've found is to use encfs+sshfs for the remote repo.
<lifeless> Ã¸shouldn't impact this
<Lor> Well it does, since then the remote repository will look like a local one, and the protocol is not used.
<Lor> The point of this all (if you're wondering) is to use bzr to back up everything in my home directory, using a possibly untrusted remote backup machine.
<Lor> And if you don't want to trust the remote machine at all, I don't think that the remote server could do anything very sensible with the encrypted data in the repository, other than send it to the client.
<lifeless> oh
<Lor> And that's what sshfs does already.
<lifeless> so if you're writing over vfs basically then it doesn't really matter; its going to slow no matter what ;P
<Lor> Well yeah.
<Lor> I also intend to use this to synchronize the home directory between trusted machines, so there the bzr protocol is relevant.
<exarkun> Anyone interested in this?
<exarkun> bzr: ERROR: Unprintable exception PermissionDenied: dict={'path': u'/srv/d_ubuntu-gandi/buildbot/.bzr', '_preformatted_string': None, 'extra': ": [Errno 13] Permission non accord\xc3\xa9e: '/srv/d_ubuntu-gandi/buildbot/.bzr'"}, fmt='Permission denied: "%(path)s"%(extra)s', error=UnicodeDecodeError('ascii', ": [Errno 13] Permission non accord\xc3\xa9e: '/srv/d_ubuntu-gandi/buildbot/.bzr'", 34, 35, 'ordinal not in range(128)')
<lifeless> sure
<lifeless> what bzr version ?
<lifeless> we've been fixing a bunch of issues like that in bzr.dev this last couple of weeks
<exarkun> 2.1.1, from the ppa
<lifeless> possibly a dupe
<lifeless> mgz: ^ ?
<exarkun> I don't think I'm in a position to test a newer dev version on this machine, unfortunately
<lifeless> thats ok
<lifeless> leave it with us
<lifeless> the underlying error is clear enough to you though ?
<exarkun> Yep
<exarkun> Hrm.
<exarkun> Same bzr version, 2.1.1, from the ppa, still seeing this error:
<exarkun> bzr: ERROR: Pack 'a60d0a0175e881a665d9d991452f2b79' already exists in GCRepositoryPackCollection(CHKInventoryRepository('file:///var/lib/buildbot/bigdog24-twisted/.bzr/repository/'))
<lifeless> thats interesting
<lifeless> are you pulling from two bzr-svn branches concurrently ?
<exarkun> There is definitely concurrency
<lifeless> can you do bzr dump-btree file:///var/lib/buildbot/bigdog24-twisted/.bzr/repository/pack-names
<exarkun> But it's probably from the same bzr-svn branch multiple times
<lifeless> has any of your tests reached a full checkout yet ?
<exarkun> dump-btree fails
<exarkun> generates a crash report
<exarkun> I dunno, hopefully.  It's kind of hard to tell though.
<lifeless> the crash report will have a backtrace in it
<exarkun> Should I pastebin it, or file a bug report?
<exarkun> maybe both, anyway http://pastebin.com/aJV30gXW
<lifeless> please file a bug
<lifeless> thats unexpected, at best
<exarkun> This looks maybe related?  https://bugs.launchpad.net/bzr/+bug/488607
<ubot5> Launchpad bug 488607 in Bazaar "bzr dump-btree .cix fails: tuple index out of range (affected: 1, heat: 6)" [Low,Fix released]
<exarkun> I'm not sure how to see which release the fix has been included in, if any, though.
<lifeless> different index file
<exarkun> Okay
<lifeless> however, it would be in 2.1.2 I think
<lifeless> lets see
<lifeless> no, 2.2.0
<exarkun> k, filed https://bugs.launchpad.net/bzr/+bug/584362
<ubot5> Launchpad bug 584362 in Bazaar "Unhandled IndexError from 'bzr dump-btree .../repository/pack-names' (affected: 1, heat: 0)" [Undecided,New]
<lifeless> thanks
<lifeless> off to see more houses; ciao
<exarkun> Have fun
<exarkun> (but I don't really care about `dump-btree`, I want `bzr checkout ...` to work :( :( :( :( :( :( :()
#bzr 2010-05-23
<arose> Is it possible to separate a file into two or more pieces in a way that bazaar is aware that it's not just some code deleted in one file and other code created in a new one?
<exarkun> arose: What if you 'bzr copy' the file and then edit each?
<arose> Sounds like that would work, thanks
<arose> ...is there a 'bzr copy'?
<exarkun> :(
<exarkun> not sure why I thought so, I must be mixing up systems, sorry
<arose> I guess not quite yet, finally found info on it, so in that sense "bzr copy" helped http://wiki.bazaar.canonical.com/BzrFileCopies
<exarkun> Ughh
<exarkun> The Windows installer fails with a "Runtime Error!"
<exarkun> R6034
<exarkun> Actually, it fails with about a thousand of them.
<exarkun> ... each has to be dismissed individually
<exarkun> Should I be trying to make bzr-svn use python-tdb on Windows too?  Or is that beyond the realm of conception?
<mgz> hm, two interesting things since last I were here.
<mgz> alexander hit the testtools traceback-isn't-unicode issue (good news there, nearly done with fix)
<mgz> and a twisted guy has a french nix system (bit more work, getting non-english errors printing correctly is also on my list)
<lifeless> mgz: cool
<mgz> on the less cool side of things, bug 583941 ...ugh
<ubot5> Launchpad bug 583941 in Bazaar "program crashes with "bzr: ERROR: socket.error: (4, 'Interrupted system call')" (affected: 1, heat: 56)" [Medium,Triaged] https://launchpad.net/bugs/583941
<lifeless> uhmm
<lifeless> that 56 would be better as 56/TOP
<lifeless> who runs ubotu again
<jpds> lifeless: tsimpson on #ubuntu-irc.
<lifeless> meh, that channel mocks people
<lifeless> :P
<lifeless> and its sunday evening ;)
<mgz> okay, actually that bug isn't our problem.
<mgz> can I dupe something against a Python bug?
<mgz> or is even launchpad not that amazing yet...
<lifeless> what you do
<lifeless> is click on 'affects other project'
<lifeless> add the url there to the python upstream bug
<lifeless> and mark our task as you think is appropriate
<mgz> hm, this is actually a little complicated, better explain in a comment
<mgz> wow, that... picked up the bugs from my comment?
<lifeless> no?
<mgz> there's a "Remote bug watches" thing on the right, with the bug numbers
<lifeless> ah, yes. nice
<mgz> might be something else to bug exarkun about, he landed the other socket bug for us, getting the fix for <http://bugs.python.org/issue1628205> on 2.6 as well would be great
<lifeless> exarkun: ^
<exarkun> lifeless: http://buildbot.twistedmatrix.com/builders/winxp32-py2.5-select/builds/8/steps/bzr/logs/stdio :)
<exarkun> lifeless: maybe we can trade
<spiv> exarkun: get one builder to do the conversion from svn, and have the rest branch from that?
 * spiv -> zzz
<mgz> a trade is fair :)
<mgz> and that looks like a straight-up bug in bzr-svn on windows
<mgz> the retrying thing is bogus though
<exarkun> I need a little more info about <http://bugs.python.org/issue1628205> though.  The last few comments sound like "fix applied" to me.
<mgz> it is applied, on trunk.
<mgz> http://svn.python.org/view?view=rev&revision=74426
<mgz> I'm right in thinking that the next 2.6 is going to be the last bug fix release, right?
<exarkun> People have said stuff to that effect, I think
<exarkun> So, backport the fix, gotcha
<exarkun> This patch looks super awesome
<exarkun> My favorite part so far:
<exarkun> del data  # explicit free
<jelmer_> mgz: it's a known issue with sqlite caching on windows
<jelmer_> mgz: unfortunately there isn't really a good way around it with sqlite
<mgz> that is a little special, and ideally all this catching and retrying would happen at the C level in Python
<mgz> but... that's been an open bug since 2002 or so.
<mgz> got a bug number jelmer?
<jelmer_> 520694
<mgz> ta.
<mgz> okay, so a fix for twisted would be to serialise bzr-svn operations on windows
<jelmer> mgz: the proper fix is to use a caching format that allows multiple concurrent writers; I have a plan on how to do this using bzr pack files
<exarkun> which I could try to cobble together in an ad hoc way inside my buildbot configuration... or which bzr-svn itself could try to enforce on windows, where concurrent access is known to always be broken?
<jelmer> but serializing bzr-svn operations is a good workaround
<mgz> http://bugs.python.org/issue210599 was the one I was thinking of
<mgz> the current signal/interrupt semantics in Python make it close to impossible to both 1) use signals, 2) use the standard library, and still write correct code
<jelmer> ah
<exarkun> mgz: Providing sensible semantics for combining blocking I/O and asynchronous signals might be beyond Python.
<Lor> Pretty much any language, except Haskell.
<exarkun> Could be
<exarkun> mgz: issue1628205 backported to release26-maint, in any case
<mgz> thanks!
<mgz> I owe you some well-handled french OSError messages.
<mkanat> Okay. I have local commits, I do bzr up, and I get a cryptic: bzr: ERROR: [Errno 13] Permission denied
<mkanat> This is with 2.1.1.
<mgz> look in your .bzr.log for the full traceback
<mkanat> mgz: Yeah, I realized that.
<exarkun> Anyone seen tree corruption on Windows with 2.1.1?
<jelmer> exarkun: what do you mean by tree corruption?
<exarkun> A file in a checkout has extra garbage at the end of it.  Perhaps bytes that belong to another file.
<exarkun> Looking for possible causes other than bzr now, though.
<mathbr> Hi. Is there some way to have --show-diff enabled by default for commits? I couldnât really find an option for bazaar.conf.
<cbz> jelmer: i have an odd problem where - for some reason - bzr-svn decided to commit a bunch of files to which there had been no changes. this was across a rebase operation (those files had been changed in the main branch - though other files had been changed too and were not committed). This only appears in the local repository
<jelmer> cbz: I'm not sure I follow - the files were actually changed incorrectly?
<cbz> jelmer: the files had been updated in the svn branch upstream. A subset of them show up in my commit after the rebase operation
<jelmer> cbz: so what did bzr-svn do incorrectly exactly?
<cbz> jelmer: i assume for some reasonnwhen bzr-svn pulled the files down (they are binaries btw png files) the modified time was marked incorrectly, which is why commit thought they were new?
<cbz> or rather 'updated)
<jelmer> cbz: modification times aren't used anywhere
<cbz> odd - i wonder why commit thought they had been updated then
<lifeless> exarkun: extra bytes - not that I know of
<jelmer> cbz: how do you tell they've been modified?
<jelmer> if they haven't actually changed in content I mean
<cbz> jelmer: i don't, bzr (q)commit tries to commit them
<cbz> or actually commited them
<jelmer> cbz: what changes does it claim they have?
<lifeless> poolie: morning!
<poolie> hi there
<lifeless> jetlagged ?
<poolie> a bit
<lifeless> :P
<cbz> jelmer: when i double click it says the files are identical (the change has already gone in)
<poolie> lifeless, https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/25400 updated if you want to reread it; not urgent
* 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: lifeless | bzr 2.1.1 is out
<poolie> lifeless, btw, you're it this week for pp
<lifeless> thanks
<lifeless> I have another small tweak up for hydrazine btw
<poolie> i'm going to finish an output_encoding option for bialix
<lifeless> poolie: your doc branch
<lifeless> poolie: I've commented -twice- - the second one is just 'please mention commit messages on merge proposals' ;) but it should be landed
<poolie> ok, i just asked again because you said you only scanned it
<lifeless> ah
<lifeless> if you want a line by line review I can, but it seems to be largely moves, which is a pain to deal with IME
<lifeless> I'm inclined with large doc changes to get them in and deal with fallout as it is discovered - a lot more mutable than code.
<mgz> ugh, I need to commit something here before this diff gets any bigger
<mgz> it's already nightmarish
<mgz> Robert is going to hate me.
<lifeless> no
<lifeless> I don't hate contributors
<lifeless> I may find it hard to review.
<poolie> lifeless, i agree about the moves and about docs
<poolie> it's easier to read the whole resulting product and see if it makes esnse
<wapcaplet> Hello all. Long time bzr user, first time caller :-) I recently started using bzr-svn, and noticed that when I use 'bzr log', it reports the svn revno for everyone else's commits, but not for my own commits. Anyone know what's up with that?
<lifeless> well, you're probably committing locally, in bzr ?
<wapcaplet> lifeless: I don't remember exactly how I originally branched, but my commits are going straight to svn
<lifeless> could you run 'bzr info' in your branch, and paste it somewhere
<lifeless> if there is stuff you want to obfuscate thats fine - just keep the sense of it intact
<wapcaplet> sure - http://pastebin.com/M4mJFxzm
<wapcaplet> not sure what's up with that related branch... that was from a while ago
<wapcaplet> IIRC, I originally checked out like 'bzr init-repo tovid; cd tovid; bzr checkout svn+ssh:// ....'
<lifeless> ok
<lifeless> you have a local reop
<lifeless> reop
<lifeless> that is getting your commits
<lifeless> and then they are translated to svn commits
<lifeless> so your commits *start* in bzr and don't get an svn revno attached as a result
<wapcaplet> aha
<lifeless> you could file a bug, if you like - this is in principle fixable
<lifeless> -> bank for a few minutes.
<wapcaplet> svn has a similar quirk of its own... the revno of the last commit isn't correctly reported until after doing an 'svn up'
#bzr 2011-05-16
<jam> morning all
<jam> poolie: How would you like me to call in?
<maxb> morning :-)
<fullermd> Shucks, morning _again_?  I haven't recovered from the last one yet.
 * maxb is in the millbank lobby
<jam> maxb: I'm glad you have network access in the lobby :)
<jam> Are there big angry guards keeping you out?
<maxb> android ftw - network access anywhere
<maxb> apparently no one's answering the phone in the office yet
<jam> maxb: I thought you just talked to the front desk, gave them your name, and they give you a visitor's badge.
<maxb> which is completely reasonable considering how early I am
<jam> but I haven't been to London in about 3 years
<jam> 9am is start time, so 9:30 is ... late :)
<jam> maxb: did you try poolie's cell phone? He has one just for london
<maxb> jam: it's currently 08:30
<jam> maxb: huh, I didn't think there was a TZ difference from here. Ok
<GungaDin> I need to create a patch from bzr diff and apply it on a different branch... but I always get that the patch is ignored... how do I do that?
<jam> GungaDin: "bzr diff | patch -p0" ?
<GungaDin> ?
<GungaDin> I need to apply the patch on a different branch
<jam> GungaDin: bzr diff > file.patch; cd ../other/branch; cat file.patch | patch -p0
<GungaDin> but that way I get that a lot of hunks fail.
<jam> GungaDin: then are you sure the patch would apply cleanly anyway?
<jam> are you trying to merge a bunch of changes?
<GungaDin> jam - no, I'm not.
<jam> GungaDin: if it is simple enough, then you could go "cd different/branch; bzr merge ../original/branch"
<jam> And if you just want some of the changes you can specify a range to merge
<jam> however, if you are getting conflicts, my guess is that the patch *just doesn't apply*.
<jam> We can't make your changes apply to code that doesn't look like the "pre" version.
<LarstiQ> GungaDin: can you explain in more detail what you are trying to accomplish?
<GungaDin> that's alright.. I suppose it's natural that all those hunks are failing.
<GungaDin> the other branch has progressed substantially.
<bialix> hi sprinters, are you already running?
<LarstiQ> GungaDin: so why diff/patch and not merge?
<LarstiQ> bialix: maxb was in the milbank lobby at 08:30, but no one to let him in yet
<GungaDin> because those changes haven't been committed to the other branch, nor should they now.
<LarstiQ> GungaDin: you could try merge --uncommitted
<bialix> LarstiQ: are you also in?
<LarstiQ> bialix: I'm not sprinting
 * LarstiQ shouldn't be here either ;)
<bialix> hehe
<fullermd> Sprinting's not my thing.  I'm sitting on the finish line, making sure it doesn't blow away.
<LarstiQ> just 5 more minutes and then I'll make my Fourier homework, I promise!
<LarstiQ> fullermd: :)
<bialix> oh, Fourier, so nice
<bialix> fullermd: we don't have spring here in my city. Yesterday was cold winter, and tomorrow will be hot summer.
<fullermd> Oh, that's nothing.  We have 2 seasons here; summer, and January 15th.
<bialix> rotfl
<jam> LarstiQ: who needs to actually finish a dissertation? I thought it was the journey that mattered :)
<bialix> wait, why 15th and 14th?
<bialix> wait, why 15th and *not* 14th?
<LarstiQ> jam: unfortunately (finally) getting my bachelor is required for being allowed to study towards a masters degree in Finland
<fullermd> I dunno.  I'm prejudiced against multiples of 7, maybe.
<LarstiQ> bialix: because the 14th is my birthday? ;)
<bialix> January 14th is old new year here in xUSSR
<fullermd> Maybe the sun hasn't gotten the news about Gregorian yet.
<LarstiQ> fullermd: did someone send it a message by pigeon carrier again? Those always burn up prematurely.
<fullermd> Just need faster pigeons.
<fullermd> Of course, if they go too fast, they slingshot around and travel back in time.
<fullermd> Sometimes even to somewhere under Julian calendars, which just adds to the confusion.
<bialix> right
<spiv> jam: how would you like to be called in? :)
<jam> spiv: Skype has seemed to be the most reliable in the past.
<jam> spiv: but I have mumble and Ekiga as well
<poolie> hi jam
<jam> morning poolie
<poolie> if you have something connected to our voip system, i think calling the table phone here would be good
<poolie> which is um
<poolie> 2428
<poolie> any good?
<jam> trying now
<jam> "User not found"
<jam> ah, you have to dial the millbank prefix first, I think
<poolie> you might need to use a headset
<lifeless> jam: in ekiga? I think you need a 5 or a 9 before it
<poolie> hi lifeless
<spiv> lifeless: he's connected
<poolie> you can dial itn too if you wish
<poolie> he's just echoy
<jam> lifeless: yeah, 51
<jam> for millibank
<lifeless> poolie: hi; uhm, I'll pass (2040 here - family time :P)
<spiv> lifeless: your bzr family misses you too :P
<lifeless> awww
<fullermd> Also, I spilled my milk in the corner...
<lifeless> I would have loved to be at uds
<lifeless> and the upcoming bzr sprint
<Merwin> Please, I can't apply a patch. In the patch file, the file 'xxx.yy', whereas in the path it is 'settings/xxx.yy'. I that's why bzr can't apply it
<Merwin> How can I do?
<poolie> Merwin: use plain patch and say 'patch settings/xxx.yy < foo.patch'
<poolie> lifeless: wow that's a bit tz gap
<poolie> it's funny to see it from the other side
<Riddell> hi poolie
<Merwin> poolie: Thanks ;)
<poolie> can you hear that jam?
<jam> spiv: that's a *long* push
<jam> brb, door
<jam> back
* spiv changed the topic of #bzr to: Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie
<lifeless> poolie: 11h at a guess :)
<poolie> yes, it is 11h
<poolie> have a good night
<poolie> we can have a chat at some better time if you like
<lifeless> sure
<jam> poolie: ~100k calls
<jam> same for emacs
<jam> very linear history
<jam> it can't expand quickly
<mgz> hi!
 * bialix waves at mgz
 * bialix has bzr t-shirt put on today
<jam> poolie: yes, I can hear him
 * mgz waves at bialix
<mgz> I asked riddell if he'd like to look at qbzr too :)
<Riddell> get your requests in fast while I'm still looking for things to do :)
<jam> looks like "dist-upgrade" just decided that Ekiga needs to die.
<jam> I'm going to go to lunch real quick while the upgrade finishes
<spiv> maxb: http://packages.python.org/manuel/
<bialix> hi Riddell! There is one bug I need somebody with Ubuntu expertise to look at and maybe provide some feedback: https://bugs.launchpad.net/bugs/782926 Actually any feedback will be helpful
<ubot5> Ubuntu bug 782926 in unity "[Unity] Application doesn't show up in Launcher when open" [Undecided,New]
<poolie> hi bialix
<poolie> i think it's a nuity bug
<poolie> i retargeted it
<bialix> hi poolie :-D
<Riddell> yes, sounds like Unity, it works fine in KDE
<bialix> I remember last year we have fixed a bug with Mac, with help of kaaloo
<bialix> Riddell, poolie: great
<Riddell> I wonder if adding a TryExec= line would help
<mgz> whoops. tried too big a chunk of selftest and got some bits of my desktop reaped.
 * mgz will be back shortly
<mgz> well, mostly working again but the session is borked somehow so xfwm4 doesn't come up on its own
<vila> bialix: \o_ me and spiv wear the same T-shirt too ;)
<bialix> ole, ole-ole-ole!
<vila> bialix: hmm, sounds like football supporter chanting... Was it the intended effect ? ;)
<bialix> vila: make you smile, no more
<vila> bialix: worked :D
<bialix> :-D
<jam> poolie: let me know when you guys come back from lunch
<jam> spiv: what is the status of your new Twisted patch? Has it landed upstream, and can it be deployed to LP?
<jam> I had a branch of LP that handled I think 2 more cases of exception => slow Failure objects
<jam> but I don't really want to push on it, if we can just make Twisted better for Launchpad
<poolie> we're back
<poolie> but now i'm off for a bit
<spiv> jam: yes and probably
<jelmer> hey jam :)
<jam> hi jelmer
<james_w> hi sprinters
<jam> hi james_w
<james_w> hi jam
 * jelmer waves
<jelmer> verterok, ping
<verterok> jelmer: hi! (pong)
<verterok> jelmer: reviewing :)
<vila> james_w: \o_
<vila> verterok: hey !
<jelmer> verterok, :)
<jelmer> verterok, thanks :)
<verterok> vila: hi! how's going? :)
<verterok> thank you :)
<vila> verterok: very well, back in Millbank where we meet... nice memories :)
<vila> s/meet/met/
<verterok> oh, nice. indeed!
<verterok> jelmer: approved and merged, thanks!
<jelmer> verterok: thank you :)
<spiv> jam: http://askubuntu.com/questions/29757/what-can-replace-system-monitoring-in-the-top-gnome-panel-in-unity
<jam> http://www.techdrivein.com/2011/05/10-useful-application-indicators-for.html
<spiv> jam: http://albertomilone.com/wordpress/?p=502
<poolie> hi all; statik says hi
<poolie> hi james_w
<spiv> jam: https://bugs.launchpad.net/unity/+bug/752098
<ubot5> Ubuntu bug 752098 in unity (Ubuntu) "In a dual monitor setup with different resolutions, Unity places windows in the "dead zone"" [Low,In progress]
<jamestunnicliffe> Hi, I have a branch on LP that has changed stacked on location. It is now set as: stacked_on_location = /~linaro-image-tools/linaro-image-tools/trunk
<jamestunnicliffe> I am getting an error when I check out
<jamestunnicliffe> bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for StaticTuple('__init__.py-20100827182754-i149503ctn97gm7c-2', 'salgado@canonical.com-20110128195048-5w2xc3ya7havirtn')")
<jamestunnicliffe> I am guessing I have done something wrong.
<jamestunnicliffe> Looking at a branch stacked on the new location, it has a branch.conf with stacked_on_location = /+branch-id/355746
<jam> spiv: I'm trying to call but the phone just rings. Should I try again?
<Riddell> jam: spiv is in a meeting
<jamestunnicliffe> Should I use that? Seeing a number in there made me worry that it may be tied to a rev.
<jam> ah, thanks Riddell
<Riddell> jam: the speakerphone is saying missed calls
<Riddell> so maybe it did get your calls but didn't ring at us
<jam> jamestunnicliffe: the number there is the launchpad db id for the branch you are stacking on
<jam> Riddell: trying again now
<jam> thanks
<Riddell> you're back!
<Riddell> they're talking about C
<jamestunnicliffe> jam: Just tried with the launchpad db id, same error. Maybe it is a real bug.
<jam> jamestunnicliffe: the AbsentFactory is a real bug. It indicates a file text that we think we should have but is not present.
<jam> I don't know *why* we think it should be there but it isn't
<jam> but there is something missing.
<jamestunnicliffe> Ah
<jam> the question is where is it, why isn't it where we expect, etc.
<jam> jamestunnicliffe: what is the original branch you were trying to branch from?
<jamestunnicliffe> I think it was lp:~linaro-maintainers/linaro-image-tools
<jam> jamestunnicliffe: there is a segment missing
<jam> lp:~USER/PROJECT/BRANCH
<jam> you only have 2
<jam> or lp:PROJECT/SERIES but you have ~
<jamestunnicliffe> I would guess there was a trunk on there. I will just hunt my email.
<james_w> yeah, it was trunk
<james_w> lp:~linaro-maintainers/linaro-image-tools/trunk
<james_w> I changed the owning team
<jam> james_w: why would "trunk" be stacked?
<james_w> jam, oh, that was the original stacked-on location
<jam> james_w: right, so the question is where is he branching from now, so we know why it thinks the data is missing.
<james_w> https://code.launchpad.net/~dooferlad/linaro-image-tools/my_dev is my guess
<jamestunnicliffe> that is correct
<jam> Have a good night everyone! Its time for me to go pick up my son from daycare.
<poolie> cheerio john
<jamestunnicliffe> right, time to rest my Ubuflu ridden head.
<sbarcteam> hi.
<sbarcteam> I think I've done bzr push in the wrong direction.
<sbarcteam> I got some files that I'd like to revert.
<sbarcteam> I understand that uncommit won't help me.
<sbarcteam> how can I track the files' changes conveniently ?
<spiv> sbarcteam: if you want to undo a push, you can do "bzr push -r OLDREV --overwrite"
<sbarcteam> spiv,  how do I know OLDREV value ?
<sbarcteam> is it a special keyword ?
<spiv> No, it's just a regular revisionspec (bzr help revisionspec)
<spiv> e.g. if you know the revno you can just use that.
<sbarcteam> so, during a push the previous revisionspecs don't get deleted ? (I was afraid this is what happens)
<spiv> Revisions are never deleted from a repository.
<sbarcteam> ok!
<sbarcteam> now, what happened is that the changes of the push were not inserted at the end log, but interleaved in the middle.
<sbarcteam> I don't know how to hunt them... ideas are welcome.
<sbarcteam> (it was 2 a bit diverged branches)
<sbarcteam> so, what happenned during the push is SEVERAL revisions entered. the ideal would be to undo this.
<spiv> And push (without --overwrite) will not succeed if the old tip revision isn't in the ancestry of the new tip.
<spiv> Take a look at the revision log, either with "bzr log -n0" or with a graphical tool like "bzr qlog" (from the qbzr plugin) or "bzr viz" (from bzr-gtk)
<sbarcteam> spiv, I took a look at bash history.
<sbarcteam> :-(
<sbarcteam> now, the command that was run is bzr pull -r-1 <folder>
<sbarcteam> So, the situation is maybe graver.
<spiv> No, jsut the same.
<sbarcteam> how do I "revert" back the history ?
<spiv> pull is just push in the other direction.
<sbarcteam> so what I should do in the location I was pulling from to run push -r --overwrite ?
<spiv> "bzr pull -r OLDREV --overwrite ."
<sbarcteam> spiv, the problem is there is no "oldrev"
<sbarcteam> or we don't know how to find it.
<spiv> The latter; it exists, you just need to find it.
<sbarcteam> so how can I identify it ?
<sbarcteam> or find it for that matter ...
<spiv> So it isn't something you can readily recognise from looking at the recent revisions?
<sbarcteam> nope. the branches diverged long ago. and once in a while we used to merge in the oposite (to that pull) direction.
<sbarcteam> my friend wanted to "rebase" and he accidentally ran this command
<spiv> Perhaps the "branch nick:" property in log will help?
<sbarcteam> ok.
<sbarcteam> reading on how do I see all the nicks available and look ...
<spiv> You could also try reading ~/.bzr.log's chatter from the offending command for clues
<sbarcteam> the problem is I don't see .bzr.log
<spiv> What does the "Bazaar log file" line of "bzr --version" say?
<sbarcteam> THANKS!
<sbarcteam> the log file is in ~/.bzr.log
<sbarcteam> I can see revid.
<sbarcteam> So, does revid of the pull command show the revide BEFORE the pulls or AFTER it ?
<spiv> pastebin the relevant part of ~/.bzr.log?
<sbarcteam> working on it(sanitation) man, you've made me alive again. Not sure something is going to help, but I'm learning something new about bzr :)
<spiv> (the ~/.bzr.log output is just to aid debugging, so the details vary a bit by bzr version and by which plugins you have installed, etc)
<spiv> As for the branch nick suggestion, "bzr log -n0 | grep nick: | sed -e 's/^ *//' | sort -u" is a crude way to see all the branch nicks
<spiv> By default a revision will have the "branch nick" property set to the basename of the directory that branch is at
<spiv> e.g. a commit in .../proj/trunk would have "trunk", and a commit in .../foo/releases/1.3 will have "1.3"
<spiv> So depending on how commits are usually generated for those two branches that may be a way to distinguish them.
<sbarcteam> http://pastie.org/1911389
<sbarcteam> this is the log of the multiple pull attempt.
<sbarcteam> I'm afraid it maybe not complete :-/
<sbarcteam> I got the branch nicks.
<sbarcteam> there are 2 nicks
<sbarcteam> SO, it is possible the nicks of pulled and pulling branch are same ?
<spiv> Sure
<spiv> See above description.
<spiv> So unfortunately, that revid is the new one, not your old one.
<spiv> (Btw, you can see revids in bzr log by passing --show-ids)
<sbarcteam> hm.
<maxb> james_w: Hello, I have a question about bzr-builddeb's import_dsc.py. Why is it necessary to do divergedness checking on the upstream branch as well as the main branch when determining if a pull from lesser/greater is acceptable?
<james_w> maxb, hmm, have a line reference for me?
<maxb> james_w: DistributionBranch.branch_to_pull_upstream_from, at the comment # Check for divergenge.
<maxb> (The point being, if you've established the debian part can be pulled OK, isn't checking the upstream part somewhat implicit?)
<james_w> maxb, yeah
<james_w> maxb, sometimes we just pull the upstream part though
<james_w> so the check is there for that
<james_w> a parameter/separate function to avoid the check would solve it if it's a significant overhead
<maxb> It's not overhead per-se, but I'm actually getting a failure of the upstream divergence check leading to unwanted parallel importing in the qbzr import I'm trying to fix
<james_w> hmm
<maxb> I think it's because I've got a weird tree shape already in that the final upstream import is one that involved a "Prepared upstream tree for merging into target branch." intermediate revision
<maxb> uhm, I mean "final in the existing branches before the problem arose"
<maxb> Hmm. So, I *think* the thing to do is to continue checking the upstream's md5 is right, because that could be important. But to not care about ancestry if the aggregate of upstream+debian has already proved to be undiverged
<LarstiQ> sprinters still around?
<mgz> yup, I just looked at the time and was surprised :)
 * LarstiQ grins
<LarstiQ> how is it going?
<mgz> http://pqm.bazaar-vcs.org/
<sbarcteam> hi.
<LarstiQ> hi sbarcteam
<sbarcteam> where does bzr log command take its data from ?
<sbarcteam> ~/.bzr.log ?
<LarstiQ> mgz: ooh, looks good
<mgz> good list of things waiting to land, plus some other progress :)
<sbarcteam> or the WorkingTree ?
<LarstiQ> sbarcteam: the branch actually
<sbarcteam> so, if I am bound it doesn't go to the bound_location, but looks at local copy of the branch. right ?
 * LarstiQ is digging into the pypy/generators leaking files problem
<sbarcteam> and it has not much to do with ~/.bzr.log ... right ?
<LarstiQ> sbarcteam: nothing at all with .bzr.log
<sbarcteam> ok.
<sbarcteam> this is good.
<LarstiQ> sbarcteam: .bzr.log is only to write debugging output to
<LarstiQ> sbarcteam: have you managed to undo the push yet?
<sbarcteam> no. now I'm getting strange bzr log outputs (with today's activities) from supposedly restored data of the last night.
<LarstiQ> sbarcteam: strange in what way?
<sbarcteam> I am getting bzr log output from AFTER the backup was taken.
<LarstiQ> sbarcteam: just a bare "bzr log", or are you giving it some arguments?
<sbarcteam> bzr log -n0 -r-1 | less
<LarstiQ> and how have you restored the backup? (ie, are you backing up/restoring what you think you are)
<sbarcteam> moment.
<sbarcteam> I removed ALL the stuff from the code folder (incl. .bzr)
<sbarcteam> restoring now...
<sbarcteam> waiting for "it" to complete....
<spiv> sbarcteam: perhaps double check that "bzr info" shows the branch and repo you expect for that directory?
<sbarcteam> I think the problem is NFS.
<sbarcteam> it's netapp thingie.
#bzr 2011-05-17
<jam> morning all
<poolie> hi jam!
<poolie> want to dial in?
<jam> certainly
 * bialix waves
<mgz> jelmer, spiv: bug 597686 was the one I was talking about at breakfast
<ubot5> Launchpad bug 597686 in Bazaar "bzr: ERROR: [Error 145] The directory is not empty: u'C:/Users/exarkun/twistedbot/windows7-64-py2.6-select/Twisted/.bzr/checkout/limbo/new-7/words'" [Medium,Confirmed] https://launchpad.net/bugs/597686
<poolie> jam: you need ":multiuser on" and ":addacl jriddell" i think
<poolie> if they fail, i think root needs to allow the change
<jam> Riddell: "screen -x jameinel/"
<poolie> jam do you know what's up with https://answers.launchpad.net/loggerhead/+question/80612
<jam> poolie: I posted an info request. I don't specifically know on that part.
<jam> Riddell: https://code.launchpad.net/~jameinel/bzr/2.4-update-basis-by-delta-781168/+merge/61232
<spiv> mgz: fwiw I've pushed those experimental transform.py tweaks to lp:~spiv/bzr/treetransform-robustness-597686
<bialix> http://stackoverflow.com/questions/6009280/git-gui-like-bzr-explorer-but-for-git
<mgz> spiv: lp:~gz/bzr/treetransform_create_file_interrupt_597686 has the tests in their current state
<spiv> bialix: haha, nice answer :)
<bialix> I know somebody from canonical did the same trick in the past
<bialix> spiv: the comments for that question is very funny too
<apw> i presume if i see _th
<apw> i presume if i see _this_, things are very very bad: bzr: ERROR: The file id "x_Matt_Zimmerman_<matt.zimmerman@canonical.com>_Sun_Mar_13_00:51:19_2005_1366.3" is not present in the tree <bzrlib.inventory.CHKInventory object at 0x3bf07d0>.
<james_w> it depends what you are doing
<etenil> Hi there
<etenil> I'm trying to use the bzrlib with python, but I don't know where to start (the auto-documentation isn't that descriptive). What I want to do is just read the revision log of a repository. Could someone help?
<spiv> etenil: http://doc.bazaar.canonical.com/bzr.dev/developers/integration.html
<etenil> oh I didn't find this
<etenil> thanks
<spiv> etenil: (and other docs in http://doc.bazaar.canonical.com/bzr.dev/developers/, like http://doc.bazaar.canonical.com/bzr.dev/developers/overview.html, will probably help)
<etenil> awesome, it's exactly what I looked for
<etenil> thanks a lot spiv
<spiv> etenil: you're welcome :)
<spiv> Riddell: we don't use Fix Committed for bzr bugs: http://doc.bazaar.canonical.com/bzr.dev/developers/bug-handling.html#bug-status
<spiv> poolie: added to http://webnumbr.com/profile?name=https%3A%2F%2Flaunchpad.net%2F~spiv
<spiv> poolie: http://webnumbr.com/.join%28launchpad-oops-bugs.all,launchpad-timeout-bugs.all,launchpad-critical-bugs.all%29
<maxb> james_w: I'd like to ask you a question about something odd the UDD importer does, when you have some time?
<james_w> maxb, I can talk now if you like
<maxb> Specifically, I'm confused about why the importer uses the method it does for plucking out the upstream branch
<maxb> This is in import_package.py extract_upstream_branch
<maxb> What it does, is to examine all the upstream-* tags, and pick the revision with the highest revision timestamp
<maxb> This has been causing me problems because of an import where the highest timestamp is not actually the highest debian version
<james_w> so it should just use highest debian version?
<maxb> That is one option
<maxb> The existing code in bzr-builddeb uses two different algorithms in different places
<maxb> merge-package, import-dsc and merge-upstream look at the changelog in the branch, take the upstream version from that, and find the appropriate upstream-<version> tag
<maxb> import-upstream reviews all upstream-* tags and picks the one with the highest debian version
<maxb> I was wondering if you had any insight on how the importer came to be using a third, different algorithm
<james_w> I think it was actually the first alogrithm :-)
<james_w> but I don't really know why there are three versions
<maxb> It looks like you introduced the algorithm in udd r36, replacing the old algorithm based on find_changelog
 * jelmer 's ignorance is probably the cause of one of the extra versions
<maxb> Ironically, the fix I've developed for the problem I'm having is effectively reverting back to the find_changelog algorithm
<maxb> "Hopefully fix the problems with resurrecting the upstream branches.
<maxb> is what you said back in 2009 :-)
<james_w> yeah, now I wish I had been more specific
<maxb> Hm. This poses a problem, because the current algorithm is definitely broken for my current pet testcase
<maxb> Whereas the other algorithm was presumably broken for something in the past
<spiv> Thinking of webnumbrs: http://webnumbr.com/.join%28bzr-active-reviews,bzr-pqm-queue-length,bzr-merged-reviews.derivative%29
<etenil> The example on how to get a revision doesn't work here: http://doc.bazaar.canonical.com/bzr.dev/developers/integration.html
<etenil> It complains that the module repository doesn't contain any "get_revision" function
<etenil> mistake?
<etenil> mmh, maybe I don't understand well
<etenil> let's say I have a done a bzr branch <some_repo> /tmp/branch/
<etenil> then should I consider /tmp/branch as a repository in itself?
<etenil> hum, that did it
<etenil> not as simple as expected
<etenil> ok so the example at http://doc.bazaar.canonical.com/bzr.dev/developers/integration.html is indeed incorrect and should read as http://dpaste.com/543458/
<etenil> http://dpaste.com/543461/ wrong paste :(
<etenil> dunno who I should contact to correct it
<Riddell> mgz: voila https://code.launchpad.net/~jr/qbzr/778012-user-error-handling/+merge/61289
<jam> etenil: actually, the way it is written is correct, but assumes you already have a Branch object named "branch".
<maxb> james_w: I have an udd importer branch with 1 approve review. What are the next steps? (This change is separate to what I was asking about a few hours ago)
<james_w> you can go ahead and merge it
<james_w> then someone on the bzr team can help you get it deployed
<maxb> james_w: I'm not an ~udd member - jelmer is, but wasn't clear on whether it was OK to land without an OK on deploying it from someone
<james_w> yeah, I think you can go ahead
<maxb> Alright, so then I just have to ask around for a ~canonical-bazaar member who is confident in deploying the change themselves?
<james_w> maxb, yeah
<acrawford> Hi all, I've set up a no-trees shared remote repository -nested style-
<acrawford> I branched it, checked it out
<acrawford> to my local machine,  added source
<acrawford> committed
<acrawford> what is the preferred method to publish /auto mirror /push a copy of the working tree to a directory
<acrawford> ? like /var/www/site?
<acrawford> I tried export but the dir is empty
<acrawford> I am trying to automirror the shared remote repository (which has no working tree))
<awilkins> Do branches that contain a debian/ folder need a packaging recipe?
<meoblast001> hi
<meoblast001> hm.. i think i answered my question by relooking at a directory string
<meoblast001> heh
#bzr 2011-05-18
<stewart> hi all!
<stewart> is there a magic "upgrade all launchpad bzr trees for project X to new repo format" button hiding somewhere?
<stewart> or does the magic sftp "bzr upgrade" work for all that...
<stewart> and also, any idea what "Standalone tree (format: unnamed)" could possibly mean ?
<lifeless> it info -v
<lifeless> bah
<lifeless> info -v will help you see what it means
<stewart> ahh.. packs with knits without subtree
<lifeless> probably an unusual combination of tree/branch/repo
<Jordan_U> I'm working with the branch http://bzr.savannah.gnu.org/r/grub/trunk/grub/. "bzr log | grep tags:" prints "tags: 1.99" yet "bzr checkout -r tag:1.99 /tmp/grub" fails with "bzr: ERROR: No such tag: 1.99". What am I doing wrong?
<Jordan_U> Ahh, I see what I did wrong now.
<Jordan_U> I thought that if ommitted branch location would be the branch corrosponding to the current directory. I guess it's not.
<LarstiQ> Jordan_U: it will try to check out /tmp/grub in the current location
<Jordan_U> LarstiQ: Thanks.
<LarstiQ> Jordan_U: I suspect you might be used to git checkout?
<Jordan_U> LarstiQ: Yes :)
<LarstiQ> Jordan_U: yeah, same names unfortunately don't always imply same operation :)
<Jordan_U> LarstiQ: I actually did read "bzr help checkout" before using it.
 * LarstiQ shakes a fist at Estonian/Finnish false friends while at it
<LarstiQ> Jordan_U: maybe it should be more explicit that one can't supply TO_LOCATION without supplying BRANCH_LOCATION?
<Jordan_U> LarstiQ: I'd say so.
<LarstiQ> hmm, not sure how to get the option parser to spit that out
 * LarstiQ will file a bug and let other people sort it out
<dandaman> is there anything for bzr in ubuntu 10.10 like there is for tortoise svn on windows where the UI is your file explorer?
<Jordan_U> LarstiQ: Thanks.
<LarstiQ> dandaman: nautilus-bzr exists, don't know if it is on the same level
<LarstiQ> dandaman: might be packaged in bzr-gtk
<dandaman> i shall investigate
<dandaman> i'm not well acquainted with the command line yet(which i'd really like to, but no time) and the explorer ui is garbage
 * dandaman apologizes if anyone who worked on that is in the channel, just my opinion
<dandaman> his*
<LarstiQ> dandaman: the apology would carry more weight if you gave feedback on why you think that ;P
<LarstiQ> not that I'm involved
<dandaman> its just a lot less inferior to a folder explorer UI, less intuitive
<LarstiQ> dandaman: mkay, that might be taste I suppose
<LarstiQ> dandaman: found nautilus-bzr yet?
<dandaman> yeah i installed it
<dandaman> I'll get it set up when i'm not stoned, and thus be able to read instructions
 * LarstiQ personally abhors the explorer/nautilus view
<LarstiQ> dandaman: hah, ok :)
<dandaman> really?
<LarstiQ> yeah
<dandaman> its so easy to us
<dandaman> use*
<LarstiQ> dandaman: how do you quantify easy? :)
<dandaman> just right click on the file you worked on a second ago and its committed
<LarstiQ> dandaman: except I don't use a filemanager in my daily workflow to begin with
<dandaman> barely worry about conflicts because you commit one file at a time
<dandaman> do you use the command line?
<LarstiQ> yeah
<dandaman> well see
<LarstiQ> and emacs/vi integration
<dandaman> command line is probably the most efficient
<LarstiQ> and qbzr
<dandaman> i just don't exactly have the time to learn how to use it to the point where i'd feel comfortable with it
 * LarstiQ nods
<LarstiQ> that's fair
<dandaman> after graduation i'll have some time
<dandaman> and i'm going to learn a whole bunch of stuff i meant to learn on the side
<dandaman> also, i need to find a place that wants to hire api programmers
<dandaman> don't know why, but i decided that's what I want to do
<LarstiQ> Jordan_U: took a while, but: https://bugs.launchpad.net/bzr/+bug/784459
<ubot5> Ubuntu bug 784459 in Bazaar ""bzr help checkout" should make dependence of TO_LOCATION on BRANCH_LOCATION more explicit" [Medium,Confirmed]
<mgz> morning all!
<LarstiQ> morning mgz :)
<mgz> LarstiQ: if you're still interested in the file handles issue for pypy, I have a couple of tools that may help
<mgz> also, vila and I are going to investigate later today to see if the babune osx and windows issues are also file handle exhaustion related
<LarstiQ> mgz: yeah
<LarstiQ> mgz: I have made some notes
<LarstiQ> and some lacking commits
<LarstiQ> I'll push the latter
<LarstiQ> mgz: http://richtlijn.be/~larstiq/DEBUG_NOTES
<LarstiQ> mgz: and maybe it is useful to put a small test script to demonstrate the generator-with-resources problem
<LarstiQ> mgz: http://richtlijn.be/~larstiq/halfcon.py
<LarstiQ> mgz: most fun: enable the pdb line, run the script (cpython or pypy, doesn't matter in this case), note the pid it prints out, run "watch -n 1 'ls -lU /proc/<pid>/fd"; and step through the code
<LarstiQ> mgz: (not too fast, watch only updates once a second)
 * jelmer waves
<LarstiQ> jelmer: hei jelmer :)
<jelmer> LarstiQ, dude!
<LarstiQ> mgz: even with those attempts at cleaning up resources, running `pypy ./bzr selftest -s bt.blackbox` the amount of open files fluctuates. Usually between 700 and 1023 (where we get too many open files)
<LarstiQ> jelmer: still alive ;)
<LarstiQ> mgz: I hope the DEBUG_NOTES file is clear?
<mgz> okay, back from swapping
 * mgz reads notes
<mgz> LarstiQ, so, jam recently added a cleanup in Transport._seek_and_read which is what Transport._readv (always?) calls
<mgz> are there cases where that codepath with the close isn't being hit?
 * LarstiQ looks at the code
<jam> mgz: LocalTransport should always call _seek_and_read, HTTP and others don't
<LarstiQ> mgz: where is this cleanup?
<jam> LarstiQ: try/except/fp.close raise else: fp.close
<jam> line 718 in bzrlib/transport/__init__.py
<LarstiQ> jam: that is no good if the generator is not fully consumed
<jam> mgz: and we can change that back to try/finally now \o/
<jam> LarstiQ: generators raise GeneratorExit if they aren't consumed
<jam> at least in python 2.5+
<jam> pypy *should* be doing the same
<LarstiQ> jam: in what case?
<LarstiQ> when they're garbage collected?
<LarstiQ> That may take a while
<jam> LarstiQ: yes
<LarstiQ> jam: it _does_ clean them up from time to time, dropping from say 800 to 300 open files
<LarstiQ> but not fast enough
<mgz> okay, that sounds fun.
<jam> LarstiQ: so 1) we can change it to try/finally so it is at least clearer. 2) We can look at changing the StopIteration code black to close them again
<LarstiQ> jam: the reason I think it is due to not being consumed is that I added debug prints/sys.counter checking, and we were not hitting the final fp.close
<jam> LarstiQ: http://paste.ubuntu.com/609397/
<jam> try that
<jam> it should allow the file to get closed when its associated iterator is consumed
<jam> before we yield
<jam> and it should be pretty rare that we don't access all the readv data
<mgz> LarstiQ: I also have a record of which testcases in the suite use files and rely on refcount semantics to clean them up, this can also add to your 800 files open scenario
<mgz> lots of the problems are shallow issues with particular tests
<jam> it will occasionally happen that we do "zip(X, readv)" and the X stops, so it doesn't even check if the readv is stopped
<jam> I have another idea, too
<LarstiQ> jam: that is almost what my code looks like, but I'll try that (the raise might be different)
<jam> LarstiQ: we don't want the raise there
<jam> that was a bug in my diff
<jam> ah, my diff removed it
<jam> I just read it wrong
<LarstiQ> mgz: hmm, maybe. But I don't think so
<mgz> see (warning, big page) http://float.endofinternet.org/xmlbin/newtestresult and click any of the little yellow boxes
<jam> anyway, you don't have to do that part, but you can
<jam> except... that's buggy to
<jam> too
<jam> it looks like we still iterate c_offset
<mgz> it's possible pypy can be clever about some of those formulations
<jam> so closing the file early will bring other bugs
<jam> let me think about it a bit
<jam> we should only close the file once we're sure we've read everything
<jam> ah, nm
<jam> if offset_stack is empty
<jam> then we know we're done
<jam> since we have returned everything the caller asked of us
<LarstiQ> jam: that fp.close in the StopIteration works wonder
 * LarstiQ failed to see it the first time :/
<jam> LarstiQ: it used to be there, but we moved it because it is cleaner to have just the try/finally (and doesn't matter much in production code)
<mgz> that's a little suprising,
<jam> mgz: I'm not terribly surprised. anything with a lazy garbage collector can be *really* lazy
<jam> and we do a lot of readv
<mgz> do lots of callers use the zip idiom and never exhaust the generator?
<jam> mgz: I wouldn't have thought lots
<mgz> if so, might want the close there, and try/except/close/raise
<jam> but if BTreeGraphIndex does
<jam> that is a pretty core
<mgz> rather than try/finally
<jam> mgz: you can always close twice
<jam> at least with all the objects I tried
<LarstiQ> but can't close lists
<mgz> ...that's probably safe
<jam> LarstiQ: fp should never be a list
<jam> mgz: note that you *can't* os.close(FID) twice, but that should be safely encapsulated for us
<LarstiQ> jam: aye, I was referring to the 'if isinstance(data_ranges, types.GeneratorType)' in https://code.launchpad.net/~larstiq/bzr/bzr-pypy/+merge/60986
<LarstiQ> since you can explicitly close a generator
<LarstiQ> since python 2.5 iirc
<mgz> yup.
 * LarstiQ is 10% into the blackbox tests and observes a maximum of 37 open files dropping down to 7 every couple of seconds
<jam> LarstiQ: so I'd rather not change btree_index unless we have to.
<jam> it is going to be really rare for btree_index to not get fully consumed
<jam> I'm guessing what you are running into is actually in pack.py
<jam> Where when reading disk content
<LarstiQ> jam: I have no firm grasp on the matter
<jam> we create a Readv* class
<jam> which doesn't have StopIteration written anywhere
<jam> so it is probably never consuming the readv object
<LarstiQ> jam: right, I pondered a .close method on that
<LarstiQ> jam: so, shall I uncommit the previous revision, reinstate the close on StopIteration, and push --overwrite?
<poolie> jam, hi
<poolie> you can dial in if you like
<poolie> also i was wondering if it would work for you to benchmark on gcc-linaro rather than a synthetic tree
<jam> poolie: I'm dialed in
<jam> just on mute because they are doing construction here
<jam> poolie: I did it on gcc-linaro
<LarstiQ> yay, blackbox tests completed with 160 open files max
<poolie> o/ LarstiQ
<poolie> great
<poolie> i wonder if we can add assertion there are no more open files from the start of a test to an end
<poolie> well, not specifically an assertion, but eg a fixture
<LarstiQ> mgz: I'm fixing the remaining cases of file(path, mode).write(content) in the blackbox tests
<poolie> jam are you still there and muted?
<poolie> i'm just putting statik's graphs onto the blogpost
<poolie> i love how the right hand bar is basically imperceptible
<Daviey> Hi, is there a pre branch hook?  I can't seem to find one?
<mgz> LarstiQ: cool. do refer to that webpage I posted earlier if it helps you see which tests don't close files.
<LarstiQ> mgz: I got the ones done that were causing failures in blackbox
<LarstiQ> loads more of occurences that don't cause immediate failures, but won't tackle those right now
<LarstiQ> mgz: http://float.endofinternet.org/xmlbin/newtestresult makes my browser unhappy :)
<mgz> yes, that's the problem with the number of tests bzr has... I need to remember one of the blackbox-only runs
 * LarstiQ is running all the tests now
 * LarstiQ knows of 3 failures in blackbox: 1 LocaleError, and two cases where the order of files returned is different than under cpython
<LarstiQ> we'll see if there are any outside
<LarstiQ> in, oh, 2 hours
<jam> mgz: is the width of an entry relevant there?
<jam> I don't quite understand the narrow grey vs the wide green, etc.
<mgz> the wide ones are tests
<mgz> the narrow ones are containers, test class, module etc
<mgz> click the narrow one to expand all the tests in that class
<jam> mgz, LarstiQ: the fp.close() change has landed in bzr.dev 5890
<LarstiQ> jam: cheers
<LarstiQ> bah
<LarstiQ> pypy oomed :/
<jam> LarstiQ: is there a way to ask pypy to run the garbage collector more often?
<LarstiQ> jam: --jit threshold=N maybe
 * LarstiQ looks for more documentation
<LarstiQ> or, now that I think of it, that probably has to do with how often code runs before it is cached
<jam> LarstiQ: AIUI, pypy has higher memory requirements than CPython, but mostly for the code parts, not necessarily for the data parts
<jam> though how would you OOM from code parts?
 * LarstiQ has trouble reading the oom-killer output
<LarstiQ> jam: http://paste.ubuntu.com/609458/ fwiw
 * LarstiQ does have a fairly memory constrained setup, and no swap
<jam> LarstiQ: not that I know what to do with that :)
<LarstiQ> jam: you're good at making sense of things ;)
<jam> offhand it looks like you were about 1.5GB which would certainly be oh-crap big
<jam> are you in 32-bit or 64-bit?
<LarstiQ> 32bit, and 1.5GB is the amount of physical memory I have
<LarstiQ> jam: trying PYPY_GC_MAX=50MB now
<jam> vila: set_last_revision_info *is* an RPC, but we always allow VFS fallbacks. so it is possible for clients to override if they get really clever, or run old versions of bzr
<jam> so in the "I haven't tested this" I think if the server says "append_revisions_only=True" then it will be refused
<vila> jam: yeah, I know this will take time to be truly fixed :-/
<vila> jam: but I'm happy enough with what we already have in the mean time
<vila> jam: also, IMHO, the "flaw" I'm referring to is that we shouldn't *blindly* allow overriding server settings
<jam> vila: believing that a pure client will respect server settings is flawed
<jam> someone can always hack the client to not
<jam> making sure that it is enforced *by the server* is a much better way
<jam> vila: and then we disable VFS
<vila> jam: sure, we can enforce that for a smart server but we should also try to have a reasonable behavior for dumb servers
<vila> jam: I think we're are in violent agreement here ;)
<jam> vila: I think having someone set it in locations.conf is not much removed from someone hacking branch.py to ignore the value
<jam> it is slightly easier, but they need to know to do it
<vila> jam: s/removed/remote/ ?
<poolie> jam:  what do we do with https://code.launchpad.net/~songofacandy/bzr/fix-523746-dev/+merge/20537
<vila> right, but you mentioned consenting adults, so my point is that we should be clearer for the users about what *can* be safely overriden in locations.conf and what shouldn't
<jam> vila: someone setting append_revisions_only = False in locations.conf could almost as easily change branch.py to ignore the setting
<jam> so if someone is going to hack their client to get around a setting
<jam> they're going to do it anywhay
<vila> ...
<jam> so lets make sure we do it correctly where it matters
<jam> and try to be nice, but we don't have to bend over backwards
<jam> vila: as said above, if they have direct write access they can also not hack bzr but just do
<jam> sftp .bzr/branch/last-revision sftp://REMOTE/branch/.bzr/branch
<jam> vila: so I file it under "I'm not worried about local settings overriding remote ones for cases where users can do the work anyway'"
<vila> dumb servers can't enforce anything obviously
<spiv> jam: I think perhaps vila's point is that it's surprising to users, not that users can do it anyway
<vila> what I want is that a smart server admin can say: this is my server, you can access it only with bzr+ssh, and don't mess my append_revisions_only, ok ?
<vila> we are not there yet
<jam> vila: we are if we were at the point that you could disable VFS
<jam> so lets do that instead
<vila> no
<vila> even with no vfs we don't forbid overriding in locations.conf
<jam> vila: with no vfs the *server* will enforce append_revisions_only
<vila> but yes
<jam> set_last_revision() is already calling an RPC
<vila> let's get rid of vfs first
<jam> and I'm sure the server can't read my locations.conf fil/e
<jam> file
<spiv> vila: well, if the server is enforcing it what the client's config thinks is a bit irrelevant.
<vila> really ? Even when we create the branch ? Where is append_revisions_only is coming from ?
<vila> and what if I just use bzr config -d remote a_r_o=False ?
<spiv> The server may have a plugin installed that always sets that flag when creating branches.
<spiv> It could even have a plugin that intercepts config update RPCs.
<vila> right, there are various ways to solve the issue, but there still is an issue ;)
<spiv> Or perhaps the server's locations.conf globally enables append_revisions_only ;)
<vila> spiv: indeed, but this works only for the smart server since we don't even try to read the remote locations.conf for the dumb ones
<spiv> Of course, but we were discussing the smart server case.
<vila> and that's the flaw I'm referring to, the actual model has some dark spots
 * vila nods
<spiv> There's no ambiguity about what dumb servers do :)
<vila> I'm worried for people that don't realize that running both a smart server *and* a dumb one can have surprising effects
<spiv> Conflicts during merge: Text conflict in doc/en/release-notes/bzr-2.4.txt
 * spiv blinks
<vila> and until recently even lp was running both a smart and an sftp server right ?
<spiv> vila: still is
<spiv> I think people aren't too surprised by "you can set a setting in multiple places, and if you do and they disagree, then you might have to think carefully/experiment to find out which value wins"
<vila> spiv: hmm, right, so I don't want to discuss to much on that now but can we agree that there are some confusing scenarios around ?
<vila> spiv: yup
<spiv> In general our story for "I'm an admin of a bzr host, and I want to set policies for the branches/repos" is pretty lacking.
<vila> spiv: yes, thanks, that's I was trying to express :)
<vila> s//what/
<vila> it's related to the way we [should] handle BranchConfig and RemoteBranchConfig (or even RemoteConfig)
<santagada> http://bazaarvcs.wordpress.com/2011/05/17/faster-large-tree-handling/ this seems really interesting, is there some more benchmarks planned for when this is merged?
<santagada> comparing to mercurial and git, etc
<santagada> I do know that the guy that did some benchmarks for bazaar passed away but this looks like a huge speed gain for it
<poolie> santagada: yes, we probably will
<poolie> do comparisons
<poolie> jam, still here? want to join us?
<LarstiQ> hrmf
<LarstiQ> someone with more memory will need to run the complete testsuite under pypy
<poolie> cos it leaks?
<santagada> LarstiQ, if you have a simple step by step I can run it here (4gb 64bit linux)
<LarstiQ> poolie: at 1.0GB rsize my oom-killer won't let it live anymore
<LarstiQ> santagada: just a sec
<santagada> LarstiQ, do you want to run it on trunk or 1.5? I would recommend trunk
<LarstiQ> santagada: I've been using a 1.5 binary, but if you can try pypy trunk that would be nice too
 * LarstiQ has no resources to translate it himself
<LarstiQ> santagada: once you have a copy of lp:bzr and pypy, it is just "pypy ./bzr selftest | tee selftest.log"
<santagada> LarstiQ, will do... will take some time to download lp:bzr
<LarstiQ> santagada: that's ok with me
<santagada> maybe I should update bzr first (2.3.1 here)
<LarstiQ> santagada: where is it at now?
<santagada> I think the daily nightly has some of the patches I just pated here so it should be faster at checkout stuff
<LarstiQ> santagada: the 2.4 fixes are about a local checkout afaik, the issue is working tree handling/building, not network transfer
<LarstiQ> santagada: are you branch over http or bzr+ssh? (ie, is your launchpad-login set)
<LarstiQ> santagada: do I understand correctly you already have pypy setup?
<santagada> bzr: ERROR: No module named testtools
<santagada> LarstiQ, bzr: ERROR: No module named testtools
<LarstiQ> santagada: ah, right
<santagada> LarstiQ, I use bzr+ssh, and I have pypy-1.5 and the latest nightly installed
<LarstiQ> santagada: cool :)
 * LarstiQ growls at browsers
<LarstiQ> santagada: you can download testtools from pypi.python.org
<LarstiQ> untar it, and run `pypy setup.py install`
<santagada> LarstiQ, ok
<LarstiQ> possibly you could get away with importing it from cpython site-packages, but this is quick enough
<santagada> LarstiQ, installed in both pypy version... it is running 5/25157
<LarstiQ> santagada: thanks!
<santagada> just to be clear, tests are probably going to be slower or the same speed as cpython
<santagada> not much the jit can do about those
<santagada> LarstiQ, I could also run some benchmarks if they are as easy as this selftest thing
<LarstiQ> santagada: they're quite a bit slower ime
<LarstiQ> santagada: that would be good too, let me see if I can figure out how the benchmarking is done
<santagada> I would guess merges are going to be faster if using this new ordering/data structure
<LarstiQ> santagada: https://launchpad.net/bzr-usertest replaced the old selftest --benchmark apparently
<santagada> should I stop the selftest?
<santagada> 118/25k
<LarstiQ> santagada: please let that run (first)
<LarstiQ> santagada: I'm aware of a couple of failures on pypy, but I'd like the complete set run now
<santagada> the docs on that page point to a user that doesn't exist anymore on launchpad
<LarstiQ> it is probably similar to what Naoki reported, but want to be sure
<LarstiQ> santagada: yeah :/
<santagada> LarstiQ, I'm running on nightly so you don't report on issues already solved. After I can run on pypy-1.5 just for comparisons
<LarstiQ> poolie: https://launchpad.net/bzr-usertest links to http://people.ubuntu.com/~ianc/plugins/usertest/doc/
<LarstiQ> poolie: which no longer exists
<LarstiQ> santagada: right, I'm reasonably confident they're bugs in bzr depending on cpythong behaviour, but extra confirmation doesn't hurt :)
<poolie> hm
<poolie> i wonder if i can still get it out
<poolie> or perhaps i have a copy
<santagada> LarstiQ, cpython
<santagada> :D
<LarstiQ> argh
<LarstiQ> santagada: indeed
<santagada> pythong would be a good 1st April joke
<LarstiQ> I think it's been made before
<santagada> a leaner python or something
<santagada> LarstiQ, 701/25k I think this will take a lot of time
<LarstiQ> santagada: hmm, I'm inclined to say that seems to go slower than it did on my netbook?
<LarstiQ> santagada: if you don't mind running it, I can wait
<LarstiQ> or rather, do mathematics in the mean time :)
<Riddell> vila: http://people.canonical.com/~mwh/bzrlibapi/bzrlib.html
<vila> Riddell: thanks ;)
<spiv> Riddell: http://doc.bazaar.canonical.com/bzr.dev/developers/integration.html and http://doc.bazaar.canonical.com/bzr.dev/developers/overview.html were those docs I just mentioned
<spiv> (in case you hadn't already seen them)
<LarstiQ> santagada: hmm, we might actually have found a pypy bug
<quiznilo> I'm trying to use bzr just to download some source code... I don't even know what that is called in bzr-lingo.  I can't find any docs basic enough to help me, is there a good starting point doc-wise?
<santagada> LarstiQ, what?
<santagada> quiznilo, I don't know for sure, but "bzr checkout --lightweight lp:<launchpad project>" might be exactly what you want
<LarstiQ> santagada: you might not have seen the failure yet, but you made me ready for the posibility it might not be bzr :)
<quiznilo> thank you sir
<LarstiQ> santagada: locale.setlocale() raises different error classes between python and pypy it seems
<LarstiQ> santagada, quiznilo: --lightweight isn't really designed for non-local usage, so that might be slower than just `bzr branch lp:<launchpad project>`
<quiznilo> unable to authenticate to SSH host
<quiznilo> I'm just downloading, I'm not uploading...
<santagada> LarstiQ, my log for now http://nopaste.linux-dev.org/?11997
<LarstiQ> quiznilo: if you have launchpad-login set, bzr will use ssh also for download because it can be faster that way
<quiznilo> so unset launchpad-login?
<santagada> quiznilo, I think launchpad should have a tarball download option you should probably fill a issue somewhere
<LarstiQ> quiznilo: that, or login, or there is some way to turn ssh off
<santagada> quiznilo, yep, or send your ssh-key to launchpad
 * LarstiQ looks it up
<quiznilo> this is windows lol
<quiznilo> I don't have a ssh-key
<santagada> ok then just unset it
<santagada> if you just want to look at code
<LarstiQ> santagada: hmm, blackbox.test_info.TestInfo.test_info_locking is new to me
<santagada> LarstiQ, this is running with the latest pypy
<LarstiQ> santagada: that, and mgz turned on unexpected successes counting as failures today or yesterday
<LarstiQ> but he's not online atm
 * LarstiQ is currently looking into that LocaleError
<santagada> LarstiQ, I leave work in 2 hours, but I will let this running
<LarstiQ> santagada: cheers
<LarstiQ> the mbcs one is also new to me, but the rest I've squashed
<quiznilo> there is no 'bzr unset' command or anything else to unset my user
<maxb> james_w: Thanks for the approve on lp:~maxb/udd/explanations - just to note, I don't have landing access - will you land, or shall I ask one of the folks at the bzr sprint with me to do so? (Or is it acceptable for me to be added to ~udd ?)
<james_w> maxb, I don't think there would be an issue with you being in ~udd, let me add you
<santagada>  quiznilo, I don't know, maybe edit the bzr config by hand
<james_w> maxb, added, please go ahead and land
<maxb> Thanks, will do!
<LarstiQ> santagada: https://code.launchpad.net/~larstiq/bzr/bzr-pypy/+merge/60986 fwiw
<LarstiQ> quiznilo: there is bzr config, which has a --remove option
<quiznilo> k
<santagada> LarstiQ, my user is santagada on launchpad.net also
<quiznilo> http://howto.praqma.net/bazaar/bazaar-on-windows <-- helped with SSH issues
<LarstiQ> santagada: stable usernames are so convenient :)
<LarstiQ> quiznilo: good
<quiznilo> bzr checkout lp:IrcDotNet <- yeilds: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/%2Bbranch/IrcDotNet/".
<quiznilo> I know the project has a link to the 0.4.0 SRC, but I was told to use BZR to download 'tip'
<LarstiQ> quiznilo: the projectname appears to be lower case
<quiznilo> I think he said 'tip'
<LarstiQ> quiznilo: lp:ircdotnet exists
<quiznilo> hmm
<quiznilo> there it goes... I think
<LarstiQ> quiznilo: 'tip' means the most recent revision (on a branch, in this case lp:ircdotnet is assumed methinks)
<LarstiQ> well, it's a bit more general in say mercurial, but never mind that :)
<quiznilo> I think I got it, thanks for your help, I've never used a VCS system before beyond: git co git://whatever
<santagada> quiznilo, if you plan to program you should learn at least one
<santagada> quiznilo, and use it
<quiznilo> I've been programming for years
<quiznilo> thanks for the help
<poolie> o/ jam
<jam> hi poolie, just casually around
<poolie> np, hi
<jam> I have this update_basis_by_delta monkey on my back
<jam> I can't shake it :)
<poolie> http://www.pixoulphotography.com/2011/05/18/official-uds-o-group-photo-and-personal-photo-set/ nice
<james_w> jelmer, maxb: thanks for all the branches/fixes
<james_w> I guess you've finished for the day now, so I can get back to work ;-)
<jelmer> james_w: Hey :)
<jelmer> james_w: Sorry (: Thanks for the quick reviews, that's really useful.
<james_w> no problem
<james_w> I'm only kidding
<jelmer> You know where to find me if I can return the favour :)
<james_w> it doesn't take me at all long to review your code
<workthrick> hiya, is it currently possible/reasonable to work with bzr-colo on a bound branch?
<workthrick> I work from multiple machines, and have in the past forgot to commit things in one place and then couldn't use it in the other. So I moved to having all of my branches bound to a single remote one so that it's impossible to forget to push
<workthrick> but now I've got enough complexity in the code that I'd actually like to have colocated branches. Yet I don't want to go back to pushing manually
<workthrick> I see I can't make a chain of bound branches, bzr errors at me if I have A bound to B and B bound to C
<workthrick> which is good in a way, at least it states plainly that it refuses to cooperate instead of breaking silently :)
<mgz> ...it's really time to leave and get some food now
<mgz> just *one* little merge proposal first
<LarstiQ> doh
 * LarstiQ will have to ask mgz tomorrow
<workthrick> hmm, actually it seems that bzr-colo should be happy working with a remote workspace
<thomi> Hi. Why is "Repository.copy_content_into(...)" a "destrive operation"? Surely if it's a _copy_... or am I missing something?
<thomi> *destructive, that is.
<workthrick> hmm, how can I tell bzr to filter out paramiko's messages below WARN? It connects a logger, and it outputs everything to console by default, which is horribly verbose
<workthrick> hmm, why does bzr connect 4 times (!) over ssh to carry out bzr colo-branches on a remote workspace?
<workthrick> remote == sftp://
#bzr 2011-05-19
<milleja46> Can someone help me? I run the commands after setting bazaar up so i can push just to see if it works and i get: "Key 'Bazaar-NG branch, format 5\\n' already registered";Unable to load plugin 'weave_fmt' from 'C:\\Python27\\lib\\site-packages\\bzrlib\\plugins';bzr: ERROR: Don't know how to handle SSH connections. Please set BZR_SSH environment variable." how do i fix it?
<milleja46> i set up bzr pagent and everything else and still it reports the no bzr_ssh var error
<lifeless> how did you install bzr?
<milleja46> i used the installer since i'm on windows
<milleja46> then installed the rest as well, generated the keys, put the public key in launchpad, ran the commands and ran almost completly fine until i had to push/commit and now it reports those errors listed above
<milleja46> would a restart help at all with this?
<lifeless> I don't know :(
<lifeless> spiv: ^ any ideas?
<milleja46> anyone?
<lifeless> milleja46: I don't use windows at all sorry, I'm very poorly placed to help :(
<milleja46> lifeless: i can tell, i'm just trying to get my comp ready so i can help out with a project called openlp
<milleja46> i guess i'll be back in the morning i gotta go to bed i've got school in the morning :(
<poolie> hi all
<vila> hello all !
<vila> And to start the day with some food for thought, let it be said that I will probably stop to listen to you all because you're biasing my judgement : http://arstechnica.com/science/news/2011/05/following-the-crowd-undermines-its-wisdom.ars
<vila> :-D
<fullermd> So, if I ignore you while you ignore me, we both get smarter in an infinite recursion?
<jam> morning all
<poolie> hi jam
<jam> hi
<fullermd> Hey, neat, selftest actually runs through.  With some apparently spurious errors, but it finishes.
<poolie> fullermd: on bsd?
<fullermd> Yah.
<fullermd> Stack of "ValueError: filedescriptor out of range in select()
<fullermd> Spot-checked a few individually, and they ran fine.  So probably just something leaking in the whole run.
<LarstiQ> fullermd: what was happening previously?
<fullermd> Previous to what?
<LarstiQ> fullermd: before it got to run through
<fullermd> Oh.  Last time I tried (which was a long time ago; year or so?) a full selftest would never finish.  Deadlock threads partway through.
<LarstiQ> ok
<poolie> aoueaou
<poolie> oops
<fullermd> You forgot 'i' and sometimes 'y'.
<Lo-lan-do> Hi all.  IÂ understand there's a Bazaar sprint going on these daysâ¦ could a few minutes be set apart to upload a newer bzr-svn to Debian so we can upgrade to 2.4 goodness?
<spiv> Lo-lan-do: we just poked jelmer, he'll take a look
<Lo-lan-do> Thanks :-)
<jelmer_> hi Lo-lan-do
<Lo-lan-do> Hi jelmer_ :-)
<Lo-lan-do> I'm seeing a lot of commits in bzr-git too these days, I'm jumping up and down with impatience :-)
<jelmer_> :)
<jelmer_> I'm trying to get the whole bzr testsuite to pass against the foreign plugins - that should also help enormously with 'bzr serve --git'
<milleja46> ok over the past several days after installing everything i should when i went to push i got the follwoing errors: ""Key 'Bazaar-NG branch, format 5\\n' already registered";Unable to load plugin 'weave_fmt' from 'C:\\Python27\\lib\\site-packages\\bzrlib\\plugins';bzr: ERROR: Don't know how to handle SSH connections. Please set BZR_SSH environment variable." how do i fix that?
<milleja46> (i'm on windows)
<milleja46> and i get it after running the command "bzr push --use-existing lp:~milleja46/openlp/milleja46"
<jelmer_> milleja46, hi
<milleja46> jelmer_: hi
<jelmer_> milleja46, did you downgrade bzr recently perhaps?
<jelmer_> milleja46, it looks like you are using a part of the a new bzr with an older version of bzr
<milleja46> jelmer_: no i have version 2.3 or whatever the latest version is
<milleja46> should i just try un-installing and reinstalling?
<jelmer_> milleja46: it seems like you have at least something that comes from a newer version - weave_fmt was added in bzr 2.4 only
<milleja46> well why does it reference that in 2.3.1?
<milleja46> (that's the version i have since that was the latest version i saw on site
<milleja46> well if weave_fmt is only in 2.4 i sure see it in 2.3.1 when i go to the plugins folder under bzrlib in the site-packages folder in lib
<jelmer_> milleja46, How did you install bzr?
<milleja46> by going to the site, and downloading the py2.7 installer for bzr 2.3.1
<LarstiQ> mgz: I don't know what the policy is on discussing things on a merge proposal
<LarstiQ> mgz: so, pypy -c "import codecs; codecs.lookup('EUC-JP')" gives LookupError: unknown encoding: EUC-J
<LarstiQ> ah, but not under pypy-nightly
<LarstiQ> progress!
<milleja46> jelmer_: though oddly enough i could do everything else to get it set up just not this for what reason i have no clue
<jelmer_> milleja46, you could try removing the weave_fmt directory, but I'm still not sure where it could come from
<LarstiQ> jelmer_: though that doesn't seem to be he reason the ssh connection won't work?
<LarstiQ> milleja46: does http://howto.praqma.net/bazaar/bazaar-on-windows help with setting up ssh?
<jelmer_> LarstiQ: I hadn't even looked at that yet :) Yeah, it won't help with the ssh issue.
<jelmer_> Lo-lan-do, a new bzr-svn is planned, with matching debian upload
<milleja46> funny thing is i have putty set up and my private key linked to it and everything yet it doesn't work like it should.....
<LarstiQ> milleja46: ok, so why not?
<milleja46> it just keeps reporting the the bzr_ssh var needs to be set
 * LarstiQ nods
<LarstiQ> milleja46: what does .bzr.log say about this?
<LarstiQ> milleja46: `bzr version` reports its location
<LarstiQ> milleja46: "Bazaar log file: /home/larstiq/.bzr.log" in my case, don't know where it will be on Windows, but bzr knows :)
 * Lo-lan-do hugs jelmer_ 
<milleja46> as soon as pastebin loads it i'll paste the link to it so you can see there are quite a bit of errors aparently
<LarstiQ> milleja46: how's that going?
<milleja46> not very well i think pastebin is down....
<mgz> there are many pastebins, try another one.
<LarstiQ> milleja46: paste.pocoo.org for example
<mgz> larstiq: so, if your remaining os lock unexpected success just a platform detection issue?
<mgz> or is there actually something incorrect in the locking code?
<LarstiQ> mgz: good question. It works under python, but not under pypy.
 * LarstiQ has a look at the test code
<LarstiQ> I so do not like locking code
<mgz> hm, if you just comment out that check in assertCheckoutStatusOutput, what does the test do?
<mgz> doesn't look like a sys.platform issue, but likewise I'd expect *lots* more failures if the locking semantics really were different under pypy
<LarstiQ> unexpected return code, hmm
<LarstiQ> time to break out pdb
<milleja46> dang all of thse paste sites are taking a long time to load the page after i click the paste button i'm on the ocoo.org one righ tnow
<LarstiQ> how big is the thing you're trying to paste?
<LarstiQ> milleja46: we only need the output of one run
<milleja46> like 1.96 mb
<milleja46> but after i enter the captcha it just takes me to a new paste
<LarstiQ> milleja46: strip that down
<LarstiQ> milleja46: if you don't want to manually figure out which part to paste, move the file out of the way, do one bzr run so you get the BZR_SSH message, and then paste the file
<LarstiQ> mgz: which at that point should contain less than, say, a 100 lines
<LarstiQ> ehm
<LarstiQ> well know
<LarstiQ> now
<LarstiQ> mgz: back to you then, it is failing in the L L L case
<mgz> hm.
<LarstiQ> mgz: specifically, under pypy `bzr info -v lightcheckout` returns info output, while without it complains it couldn't acquire a lock
<LarstiQ> so then retcode = 0 instead of the expected 3
<LarstiQ> which trips up the self.assertEquals(retcode, result, message='Unexpected return code') in _run_bzr_core()
<LarstiQ> although I don't quite get that
 * LarstiQ detaches from irc for a while
<santagada> LarstiQ, hi
<LarstiQ> santagada: hey
<LarstiQ> santagada: how did the run go?
<santagada> LarstiQ, not good, just commented on the ticket
<santagada> http://paste.pocoo.org/show/391764/
<santagada> and it was using 1.9gb of ram so my machine was unusable
<LarstiQ> santagada: ouch, that needs to be resolved
<mgz> so, I've got a branch that may help that side as well
<santagada> LarstiQ, I think there is a leak on bzr testsuite because pypy has been used with very big projects without signs of leaking memory
<mgz> currently we keep testcases alive for the whole run
<santagada> ah
<mgz> which is pypy uses a lot of memory for various things might... getbig
<mgz> if you try a run on <lp:~gz/bzr/cleanup_testcases_by_collection_613247> which I updated to bzr.dev yesterday, you may have more luck
<santagada> pypy should be using less memory than cpython unless you were using __slots__ in cpython
<mgz> it uses more memory for jit
<mgz> and if we're keeping lots of test methods alive...
<spiv> santagada: it depends
<santagada> python objects are smaller, as if they were all using __slots__
<mgz> it may not be smart enough to free generated code when it's not needed any more
<santagada> pypy jit uses some memory, but it is a more or less fixed amount and it does release unused compiled loops
<santagada> mgz, it does... well there could always be a bug somewhere :)
<santagada> but it should be releasing unused memory
<santagada> I think there is cases where if you mutate your __dict__ then the objects get as big as cpython ones
<LarstiQ> santagada: I did a cpython run under memusage.py yesterday, and it got up to 500Mb
<santagada> because it has to actually create a dict for it
<LarstiQ> https://codespeak.net/svn/user/arigo/hack/misc/memusage.py
<LarstiQ> that is
<santagada> maybe it is a mixture of a bug/missing feature on pypy that bzr testsuite is using
<santagada> LarstiQ, also if you want me to run the tests again I should do it on your branch
<LarstiQ> santagada: my branch got merged into bzr.dev
<santagada> ahh
<santagada> so lp:bzr should have it right?
<santagada> I don't know what bzr.dev is
<LarstiQ> santagada: yeah, lp:bzr
<LarstiQ> santagada: sorry, I'm stuck in my terminology
<santagada> mgz, you are going to land your changes on lp:bzr today? because I can rerun the tests later if you are
<LarstiQ> santagada: r5893 to be precise
 * LarstiQ is going to give mgz's branch a spin
<LarstiQ> if it works, I can actually run the testsuite to completion under pypy
<santagada> wish I knew why it ran so slowly on my machine
<santagada> its a core 2 duo with 4gb ram so it should be faster
<LarstiQ> santagada: iirc subprocess is slow on pypy, so that would explain why the blackbox tests take long
 * LarstiQ is now at 958/1388 blackbox tests in 100 minutes
<LarstiQ> on a 1.5gb ram Atom N270
<santagada> uhmm that is true
<santagada> I don't remember why it is slow
 * LarstiQ merges bzr.dev into cleanup_testcases_by_collection_631247 and gives it another go
<LarstiQ> hi abentley
<abentley> LarstiQ: Hi.
<LarstiQ> mgz: I'll wait till this run is done before crying victory, but at this point pypy has run 600 blackbox tests in under 10 minutes. That is incredibly much faster than without your branch.
<LarstiQ> mgz: so, the previous pypy run did 958 blackbox tests in 100 minutes, with your branch it is 1388 in 19. Consider me in favour of merging it.
<Lo-lan-do> Hear, hear.
<abentley> It's nice that we're getting to a place where we can support pypy, but isn't pypy supposed to be fast?
<mgz> larstiq: that's great post-lunch news
<mgz> abentley: you'd need his numbers for those tests on cpython without extensions compiled for a sane comparison
<abentley> mgz: Ah, unfair comparison, then.
<santagada> and pypy is not very fast in unittests
<santagada> I think the biggest advantage for bzr would be startup time in most cases
<santagada> and then for long merges the jit would help also
<santagada> s/long merges/any slow operation that is somewhat cpu bound/
<LarstiQ> abentley: benchmarks to see how pypy without extensions compares with cpython with extensions have yet to be done
<santagada> benchmarking before making the tests pass also don't make much sense
<santagada> a broken bzr could be easily faster than a working bzr :)
<LarstiQ> santagada: although it wouldn't hurt to already set the environment up so it can roll when we get there
<santagada> LarstiQ, that would be great
<jam> santagada, abentley, LarstiQ: And we'd have to rewrite the GroupCompress code to actually do the same thing in pure python
<jam> at the moment it runs an entirely different algorithm that just generates compatible streams
<LarstiQ> right
<santagada> when everything is working there are many venues to go to get more performance on pypy
<spiv> Also, we've spent a considerable amount of time and effort tuning bzr for CPython.  So a completely fair comparison would involve doing the same for pypy.
<LarstiQ> if we're lucky pypy will be faster without doing anything, but I'm not holding my breath
<poolie> jlemer can you answer https://answers.launchpad.net/bzr/+question/158196
<LarstiQ> poolie: did you manage to find ianc's old homedir btw? https://launchpad.net/bzr-usertest still points to a non-existing link
<poolie> ah ok
<poolie> LarstiQ: can't you getto https://code.launchpad.net/~bzr/bzr-usertest/trunk ?
<poolie> i mean can you?
<poolie> oh, you mean just the link in the description
<poolie> i'll see about that
<LarstiQ> poolie: sorry, yes
<poolie> no you were clear
<poolie> i thought someone else asked me about access to one of his branches
<poolie> are you going to run it?
<poolie> http://people.canonical.com/~mbp/ianc-plugins/usertest/doc/
<poolie> and i updated the page too
<LarstiQ> poolie: I would like to have a go at benchmarking with pypy, yes
<LarstiQ> poolie: thanks!
<poolie> np, thanks
<poolie> ?
<LarstiQ> abentley: fwiw, doing the same blackbox test run but now with cpython instead of pypy takes 14.5 minutes instead of 19
<LarstiQ> poolie: hmm?
<poolie> oh, john was saying "yay" that his delta-update patch is finished
<poolie> i wonder if we can make usertest draw graphs through R
<jam> poolie: if someone wants to go through the diff with me, I do realize 1400 lines is a bit long
<abentley> LarstiQ: Cool!
<spiv> vila: lp:~spiv/bzr/import-tariff-test-subprocess-deadlock should fix that deadlock
<vila> spiv: thanks
<vila> spiv: ... but no :-/
<spiv> vila: drat
<LarstiQ> mgz: what should be done to get cleanup_testcases_by_collection_613247 moving?
<mgz> larstiq: vila suggested last night that I try and split it up into smaller bits
<mgz> larstiq: the main complication is ensuring we don't regress is hard
<mgz> okay, we're heading off globewards nowish
<arnetheduck> hi, I'm playing around with the log -m option and was thinking about extending it to also match committer and author(s)
<arnetheduck> the other option would be to add another option that only matches committer, one for author etc etc...
<arnetheduck> does anyone have any opinion?
<jam> arnetheduck: offhand, I think it would be ok to just make -m match it. I don't think you'll get spurious matches
<arnetheduck> indeed, it seems more simple both to implement and above all for the user
<jam> arnetheduck: right.
<jam> the only question is if it should match the *email* which can cause more spurious matches because of domain names. But I'd probably still say go for it
<arnetheduck> the other option I considered was maybe to use some sort of property specifiers to only match a certain field (-m message=xxx or -m committer=abc) and match all fields if none are specified
<arnetheduck> but that of course complicates matters...
<jam> yeah
<jam> not worth the mental overhead
<arnetheduck> in any case, do you think a patch in this direction would be interesting for upstream?
<jam> yes
<arnetheduck> also, I tried looking for an existing bug but the obvious keywords (log, author etc) yield a massive list - does anyone maybe recall seeing a bug for this? (I recall a posting on the bzr mailing list where I lurk =)
<jam> arnetheduck: I don't know of a specific bug about that.
<arnetheduck> jam: thanks for the input
<arnetheduck> is it normal that the self test takes close to an hour? also, is there any (simple) way of knowing which tests pass through a particular function except guessing by test name?
<jam> arnetheduck: that is about right. I've seen it go faster on better hardware, and we have "bzr selftest --parallel=fork" if you have multiple cpus
<jam> LarstiQ, mgz: my attempt at helping you out: https://code.launchpad.net/~jameinel/bzr/2.4-exc-info/+merge/61630 https://code.launchpad.net/~jameinel/bzr/2.4-613247-cleanup-tests/+merge/61636 https://code.launchpad.net/~jameinel/bzr/2.4-613247-test-cases/+merge/61637
<jam> I'm guessing that isn't the #1 important bits, which is the changes to TestUtil and some of the other helper functions
<jam> but it was the bits I felt I understood.
<jam> and it should at least reduce your divergence vs bzr.dev
<jam> arnetheduck: most tests are grouped by the module they effect, so "bzr selftest -s bt.test_log -s bb.test_log" is going to handle most of the 'test_log' cases
<jam> they correspond to "bzrlib/tests/test_log.py" and "bzrlib/tests/blackbox/test_log.py"
<jam> bt => bzrlib.tests bb=>bzrlib.tests.blackbox
<LarstiQ> jam: thanks!
<LarstiQ> jam: and oooh, I didn't realise you could specify -s multiple times
<milleja46> Ok can someone help me? when i run the push command on windows i get the following error: ""Key 'Bazaar-NG branch, format 5\\n' already registered";Unable to load plugin 'weave_fmt' from 'C:\\Python27\\lib\\site-packages\\bzrlib\\plugins';bzr: ERROR: Don't know how to handle SSH connections. Please set BZR_SSH environment variable."
<milleja46> and here's the log: http://paste.pocoo.org/show/392030/
<LarstiQ> ooh, a log
<LarstiQ> milleja46: you went offline unexpectedly earlier
<milleja46> LarstiQ: i didn't randomly go off i had to go to school i'm still a high school junior :P
<LarstiQ> milleja46: a note would have saved me the line I was typing to you ;P
<LarstiQ> anyway
 * LarstiQ looks at the log
<milleja46> did i mention that i'm using the python 2.7 installer for bzr?
<LarstiQ> milleja46: I think so
<milleja46> LarstiQ: i'd take it there has to be some kind of issue for it to be 1.96 mb in size
<LarstiQ> milleja46: as I was saying then, we only need the last bit of it
<LarstiQ> milleja46: it is a debug log all bzr operations write to
<LarstiQ> milleja46: so posting the entire log is a bit overkill
<LarstiQ> milleja46: but if you want, you could move it out of the way, run bzr, and upload the new log formed that way with only 1 run
 * LarstiQ needs to look up what the regular setup on windows with putty is
<milleja46> LarstiQ: ok i'll try that just let me close out all my bzr stuff :)
<LarstiQ> milleja46: for next time, I've got the info I was after now
<milleja46> LarstiQ: good and sorry about that...ohand the specific command i ran was "bzr push --use-existing lp:~milleja46/openlp/milleja46" if i didn't mention it earlier
<LarstiQ> milleja46: can you set BZR_SSH=paramiko ?
<milleja46> LarstiQ: where would i set that and do i have to get paramiko? i don't recall anything called paramiko
<LarstiQ> milleja46: paramiko should be bundled with the installer
<milleja46> ahh
<LarstiQ> milleja46: hmm, iirc there is an environment variable setting in System somewhere
<LarstiQ> milleja46: or to test, on a commadline, 'set BZR_SSH=paramiko' I think
<LarstiQ> and then run bzr
<milleja46> bzr: ERROR: Unrecognised value for BZR_SSH environment variable: paramiko
<LarstiQ> really, hrmf
<milleja46> LarstiQ: so i guess i need to figure out why paramiko isn't known
<LarstiQ> milleja46: try BZR_SSH=plink?
<milleja46> ok next error: bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; [Error 2] The sy
<milleja46> stem cannot find the file specified
<milleja46> i've got the keypair and gave launchpad the public one and have both saved on my system
<milleja46> LarstiQ: would i happen to possibly be missing the private one being set somewhere?
<milleja46> i've got putty on my computer
<milleja46> as well as that pagent stuff
<LarstiQ> milleja46: can you paste the traceback corresponding to that bazaar.launchpad.net error?
<milleja46> LarstiQ: yea hold on
<LarstiQ> it _sounds_ like a dns problem
<milleja46> http://paste.pocoo.org/show/392050/
<LarstiQ> right
<LarstiQ> milleja46: does ping bazaar.launchpad.net work?
<milleja46> yes
<LarstiQ> hmm
<LarstiQ> milleja46: how about, 'plink bazaar.launchpad.net' ?
<milleja46> LarstiQ: umm, how would i do that one?
<LarstiQ> milleja46: from commandline too
 * LarstiQ is looking at http://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter7.html
<milleja46> ahh now that i added it to the path variable it works...but i get this error after giving it my login as stuff: FATAL ERROR: Disconnected: No supported authentication methods available
<LarstiQ> milleja46: that sounds like it isn't trying your key
<milleja46> maybe this is why i opened up the keys Pagent knows and there is nothing on the list
<LarstiQ> milleja46: that would not help, no :)
<milleja46> LarstiQ: well i add the key then it says: "No shells on this server"
<milleja46> when i re-run the plink command on bazaar.launchpad.net
<milleja46> i mean
<LarstiQ> milleja46: that's good!
<LarstiQ> milleja46: now try bzr again
<LarstiQ> milleja46: (bazaar.launchpad.net doesn't let you log in to a shell, but trying to is useful to see if keys etc are all set up)
<milleja46> LarstiQ:well so close->"Key 'Bazaar-NG branch, format 5\\n' already registered";Unable to load plugin 'weave_fmt' from 'C:\\Python27\\lib\\site-packages\\bzrlib\\plugins';Using default stacking branch /+branch-id/40441 at lp-85209680:///~milleja46/openlp;bzr: ERROR: KnitPackRepository('lp-85209680:///+branch-id/40441/.bzr/repository')is not compatible with CHKInventoryRepository('lp-85209680:///~milleja46/openlp/milleja46/.bzr/repos
<LarstiQ> aha
<milleja46> http://paste.pocoo.org/show/392060/
<LarstiQ> milleja46: you're not pasting the relevant things, but in this case I know what is going on
<LarstiQ> milleja46: so, the problem is that your branch is in a newer, unfortunately incompatible format
<milleja46> well it's the last bit of what pops up after sending it
<milleja46> LarstiQ: just ran it again it's working i think!
<LarstiQ> really?
<milleja46> it looks like there's some transfer rates popping up on screen
 * LarstiQ wouldn't expect that to work with either 1) lp:openlp being upgraded 2) not stacking on it
<LarstiQ> milleja46: you'll note that in the the log it also mentions what command you ran
<milleja46> LartsiQ: well i haven't updated my branch in a few days...
<LarstiQ> and above that a timestamp
<mwhudson> spiv: btw, i get an email every day with the list of bzrlib docstrings that aren't valid reST :)
<LarstiQ> milleja46: for example, 0.585  bzr arguments: [u'info', u'lp:~milleja46/openlp/milleja46']
<mwhudson> i guess that should be 'got' now
<milleja46> this is what i see:   6690kB    34kB/s \ Fetching revisions:Inserting stream:Estimate 38703/68556
<LarstiQ> milleja46: so everything from the timestamp (Thu 2011-05-19 23:03:20 +0200 in that case) to the next blank line; timestamp is the relevant bit
<LarstiQ> milleja46: on a push?
<milleja46> LarstiQ: yea
<LarstiQ> milleja46: ok, let's wait and see then :)
<milleja46> yea this is gonna take awhile the branch is 24.6 mb
<milleja46> and i've really and truly made no revisions yet
<LarstiQ> milleja46: ah, that sounds like it fell back to not using stacking then
<LarstiQ> milleja46: maybe you should ask the openlp people to upgrade lp:openlp
<milleja46> LarstiQ: what do you mean upgrade it?
<LarstiQ> milleja46: `bzr upgrade lp:openlp` should do the trick, with any bzr 2.0 or higher
 * LarstiQ goes to sleep
 * milleja46 hopes this works
 * milleja464 almost had it...then lost connection.....
<milleja46> LarstiQ: thanks it finally worked, now just to start learning some PyQt and hopefully i can make a change that i need to soon
#bzr 2011-05-20
<Daviey> lifeless, Do you know when the UNRELEASED package of bzr-svn is going to be uploaded to Debian?
<lifeless> no idea
<Daviey> lifeless, ok - no worries.. thanks :)
<lifeless> jelmer will
<lifeless> but hets not online just now
<Daviey> lifeless, yeah, i saw he was offline and he made the change.. I wondered if you knew as it seems you are both uploaders..
<Daviey> lifeless, thanks... it is not urgent, just that it is stuff in oneiric atm.. Depends bzr < 2.4
<bignose> if I have done âbzr shelveâ and the shelf is now created, can I apply a message to it post-hoc?
<bignose> so that it shows up in âbzr shelve --listâ.
<jam> morning all
<mgz> morning all
<spiv> mwhudson: lucky yoU!
<LarstiQ> Riddell: if you're still looking for things to do, https://bugs.launchpad.net/bzr/+bug/785633 perhaps? :)
<ubot5> Ubuntu bug 785633 in Bazaar "bzr missing doesn't like :parent" [Low,Confirmed]
<Riddell> LarstiQ: I'll keep it in mind
<jam> mgz: bzr branch --switch . ../new-feature-branch
<jam> bzr revert -r submit:
<jam> # revert everything to upstream
<jam> bzr revert file1 file2 # stuff I want to keep
<jam> bzr commit
<jam> bzr switch ../orig-branch
<jam> bzr merge ../new-feature-branch
<jam> bzr revert .
<jam> bzr commit -m "supersede new-feature-branch"
<jam> for the next one, you want to do "bzr branch --switch -r XXX" before you split of new-feature-branch
<jam> otherwise the branches end up depending on eacother
<mgz> Thanks jam, that makes sense.
<jam> jelmer: I can try to talk to you via irc
<jam> they sometimes stay quite for like 10 min
<jelmer> jam: That works too :)
<jam> but you never know wehn
<jam> You're welcome to talk alound
<jam> I'm listening
<bialix> hi
<bialix> vila: hi, are you still release manager?
<Riddell> bialix: he is but he's talking to poolie right now
<bialix> hi Riddell, ok, thanks, np
<vila> bialix: yup
<bialix> have a couple of minutes? re windows installers
<bialix> short question: can I expect to see new beta very soon?
<vila> bialix: err, see the lp page ?
<vila> right 2.4b3 is planned for next week (2011-05-26) for freeze
<bialix> ok, I need fixes for sphinx
<vila> new ones ?
<bialix> latest
<bialix> mgz: can I have your little help?
<bialix> anybody has idea about https://bugs.launchpad.net/bzr/+bug/785661
<ubot5> Ubuntu bug 785661 in Bazaar "`make chm-sphinx` is always exits with error code 1" [Undecided,New]
<mgz> looks like htmlhelp is failing?
<mgz> try running just that command seperately?
<bialix> make is make.bar actually, I have to use call make ...
<bialix> my bad
<bialix> sorry, for the noise.
<bialix> so, I have problems with chm-sphinx anyway, even with latest patches for it
<spiv> maxb: https://bugs.launchpad.net/bzr/+bug/741375
<ubot5> Ubuntu bug 741375 in Launchpad itself "using +branch/~user/project/branch prevents automatic stacking of new branches pushed to Launchpad" [High,Triaged]
<jam> jelmer: poke
<jam> The _cleanup thing is a bug
<jam> def unlock() should only call _cleanup when the lock is finally released
<jam> not for every unlock call
<jam> arguably path2ids shouldn't have needs_read_lock (because I'd like to get rid of those in general)
<jam> but we shouldn't be nuking the ignore list on a re-entrant lock
<mgz> bug 785671
<ubot5> Launchpad bug 785671 in Bazaar "calling WorkingTree.path2id resets ignore list cache" [Medium,Confirmed] https://launchpad.net/bugs/785671
<jam> mgz: thanks, though jelmer, you can just fix that to land your apply delta stuff
<jam> it is really just moving the call further down after the "if lock_count == 0" sort of stuff
<jelmer> jam: I'm now using inventory.path2id to work around it
<jelmer> Though perhaps I should indeed just Do The Right Thing
<jam> jelmer: I thought the whole point of this was to get away from inventory
<etenil> Hi there
<jam> hello
<jelmer> jam: that's what I initially set out to do, but I had to use inventory deltas so the foreign plugins need a custom implementation anyway
<etenil> I'm using a git-like workflow with bzr. And I've refactored a bit my code in my latest branch, so that functions have a slightly different name (a sed was enough). However, when I patch my stable branch and merge up the patch, it screws up all my refactoring. Does bazaar have facilities that could solve this?
<jelmer> jam: They already have custom implementations now (and can take some shortcuts, as there's no need to worry about e.g. directories for hg and git)
<jam> jelmer: converting from iter_changes => inventory delta should be straightforward (I think)
<jelmer> jam: I'm now just focussing on fixing bug 146165
<ubot5> Launchpad bug 146165 in Bazaar "smart_add uses _get_inventory, _write_inventory, but should not" [Medium,In progress] https://launchpad.net/bugs/146165
<jam> jelmer: sure, and thats a good start, but the unlock thing should be pretty easy
<jelmer> jam: I'm not disagreeing :)
<chriscauser> Hello everyone. I think I've found a bug in bzr-svn but I thought it best to discuss here before I file a bugreport
<jelmer> hi chriscauser
<jelmer> etenil, hi
<etenil> hi jelmer
<jelmer> etenil, what do you mean exactly with "it screws up all my refactoring"?
<chriscauser> When I have a checkout of trunk, and I do a "bzr diff https://scm...../branchname", it whirrs for ~ 2 hours on "9197kB  1171kB/s / fetching changes for file ids 0/415" with the download size getting larger and larger (probably > repo size) before falling over
<etenil> jelmer: well let's say I've renamed my function foo() to bar() and updated all the code accordingly, when I merge up my patch from stable (where foo() is still foo()), I'd like foo() to get renamed to bar() automatically
<jam> chriscauser: I assume that "bzr diff $" is having to do a conversion of the history to get the information you want.
<jam> probably better to fetch it locally, and then "bzr diff ../local" instead
<jelmer> etenil: merge doesn't have any custom support for C functions so it just does a three way merge
<etenil> jelmer: right, I'd just like it to be aware of the name change. Maybe I could hook up sed or something?
<chriscauser> jam: Thanks
<jam> jelmer: would it be a lot of work to factor the smart_add stuff into a helper class, I'm a bit sad to see *more* nested functions.
<jelmer> etenil, You can write a plugin for bzr which adds a custom merger for those files and basically does the sed
<etenil> ah
<etenil> mmh
<etenil> well I'll see about that then. Or maybe I'll just suffer a bit longer until my unstable branch becomes stable :D
<jelmer> etenil, however, it's easy to do something that handles the trivial case but hard to handle all cases properly without actually properly parsing the full file
<etenil> ok
<jelmer> jam: Sure, I'll have a look.
<etenil> well thanks for your help jelmer, I think I'll just stick to manual handling for the time being
<chriscauser> jam: Although I think perhaps something else is going on because the diff downloads substantially more than the repo size
<chriscauser> Hmm
<jelmer> chriscauser: You're probably better off pulling down the repository and looking at it locally
<jam> chriscauser: well, you're doing cross-format conversions
<jam> We don't always try to optimize the bandwidth, etc.
<chriscauser> jam: I guess that's it. I'll work with branching the two branches and working locally
<chriscauser> Thanks!
<jelmer> chriscauser, can you file a bug about this particular case?
<poolie> is bug 785377 a dupe of one that was recently fixed?
<ubot5> Launchpad bug 785377 in Bazaar "merging into a new branch leaves working tree in bad state (bzr: ERROR: exceptions.ValueError: WorkingTree.set_root_id with fileid=None)" [Undecided,New] https://launchpad.net/bugs/785377
<poolie> about merge into a new directoly?
<jam> poolie: yeah, well the fix from Riddell was to just refuse with a nicer message
<ScottK> So Riddell's niceness will now infect bzr?  "bzr: Friendly version control"
<Riddell> :)
<fullermd> I miss when it used to laugh at you for screwing up   :(
<jam> fullermd: yeah, but hooking into sound libraries seemed too big of a dependency
<fullermd> If you wanna make an omlette, you gotta break a few lions.
<santagada> LarstiQ, hi, how is your bzr-pypy branch going? need someone to test it?
<LarstiQ> santagada: nothing new from my end, jam did some work on the test cleanups
<LarstiQ> santagada: I got lost in trying to debug the locking code
<jam> LarstiQ: well, only getting bits of it merged into bzr.dev
<LarstiQ> jam: for which I'm thankful :)
<LarstiQ> santagada: on the pypy there seems to be an issue with keeping around the loops too long
<LarstiQ> santagada: antoncuni seems interested in that
<LarstiQ> santagada: maybe you could help drive that along by providing him with data when needed?
<chriscauser> jelmer: Will do.
<poolie> jam, well, refusing that merge with a nice message should avoid the bad state
<poolie> canny version control
<poolie> jam i don't know if you overheard but http://babune.ladeuil.net:24842/job/chroot-natty/ should now be pretty stable
<poolie> as far as avoiding spurious vmbox or jenkins failures
<poolie> fingers crossed
<poolie> also it should build up to every hour if there are new commits
<jam> poolie: sounds nice, though if we still go through pqm first, I don't see *natty* being a super important target
<jam> unless pqm is just lucid?
<jam> still nice for it to be stable
<poolie> hm
<poolie> pqm is on lucid
<poolie> but really the main point here is that it's stable
<poolie> and we ought to be able to replicate it for other ubuntu releases and other linux distributions
<poolie> and then that should mean there are so few actually running as vms that they can run all the time, which should avoid another class of problems
<poolie> jam, i think they reliably fail for me on wine
<james_w> jelmer, hey, I just remembered, are you adding the new substitution variables to the plugin help via the module docstring?
<james_w> I think the current ones are documented there
<jelmer> james_w: Ah, I wasn't aware of that. I'll update it - thanks for the reminder.
<james_w> np
<james_w> jelmer, if you could add in https://bugs.launchpad.net/launchpad/+bug/624094 while working on these, that would be great
<ubot5> Ubuntu bug 624094 in Launchpad itself "Support package version found in branches when specifying version numbers in recipe" [Medium,Triaged]
<jelmer> james_w: sure
<james_w> thanks
<jelmer> james_w: would it perhaps be useful to have a variable for just the debian revision than the entire thing?
<james_w> maybe
<james_w> for this use case we want the whole thing, epoch, debian revision and all
<BjornW> can someone tell me if bzr has something like svn:externals or git submodules?
<mgz> there's bzr-externals and bzr-scmproj plugins
<BjornW> mgz: ok so nothing in bzr core itself? Mhhm too bad
<mgz> nearly time for me to head off
<spiv> poolie, mgz, jam, maxb, jelmer, Riddell, vila: http://wiki.bazaar.canonical.com/May2011Sprint
<dcoles> Is it unusual to see ghost-revisions when inspecting a svn repository which has had bzr commits pushed to it?
<dcoles> I have a branch which I've just pushed which contained several merges. If I look at the history in the bazaar branch it looks fine, but if I branch from the svn repository anything with depth > 1 appears as a ghost.
<LarstiQ> dcoles: there is a config setting that might help iirc
<LarstiQ> dcoles: push_merged_revisions
<dcoles> For the svn server or for bazaar?
<LarstiQ> dcoles: for bzr-svn
<dcoles> Ah. I'll take a look if I've got that set.
<dcoles> First time I've used bzr-svn on an extended svn project.
<dcoles> Ah. Yes. Expected behavior: https://bugs.launchpad.net/bzr-svn/+bug/569360/comments/3
<ubot5> Ubuntu bug 569360 in Bazaar Subversion Plugin "bzr log <path> skips merge revisions" [Undecided,Invalid]
<dcoles> Thanks LarstiQ
<LarstiQ> I forget why it doesn't default to that
<dcoles> I think it will create branches automagically
<dcoles> Much like tags do
<LarstiQ> really?
<dcoles> Which may be unexpected.
 * LarstiQ hasn't used bzr-svn in a while, admittedly
<LarstiQ> dcoles: right
<LarstiQ> dcoles: but ending up in your situation isn't nice either
<dcoles> At least that's how it sounds like it's supposed to work. :)
<dcoles> Yes. I hope I have some of those branches around locally.
 * LarstiQ nods
<dcoles> Otherwise I just lost the individual commits. The reason I use bzr-svn rather than subversion
<LarstiQ> although bzr should be able to cope with ghosts
<LarstiQ> you may hit some rough corners
<dcoles> Bazaar is fine (though doesn't show them well in the UI). bzr qlog pukes a bit (bug reported)
<dcoles> https://bugs.launchpad.net/ubuntu/+source/qbzr/+bug/785967
<ubot5> Error: Launchpad(https://launchpad.net) bug 785967 not found
<dcoles> Oh. Private.
<dcoles> The other fix is to just push the merge branches to the subversion branches by hand
<LarstiQ> dcoles: right
<LarstiQ> dcoles: if you still have them
<LarstiQ> bzr heads from bzrtools might help find them in some cases
<abeld> Hi! how can I fast-export a _repository_ (as opposed to a single branch)? All the references to fast-export that I can find by googling deal only with branches. "bzr fast-export" says ""
<abeld> I mean it says "bzr: ERROR: Not a branch: "/path/to/repo/.bzr/branch/": location is a repository."
<abeld> (i.e. fast-export -ing a bzr "shared repository")
<LarstiQ> abeld: it's not really geared to that I don't think
<LarstiQ> abeld: it might make sense to extend it, but I don't know the fast-export format enough to judge
<abeld> So what is the recommended way to convert such a shared repository to a git one?
<abeld> Will fast-export (then fast-import to git) the branches inside the repository one-by-one make me end up with a 'many branches in one repo' git repository?
<LarstiQ> abeld: I would assume so, but I don't know
<LarstiQ> abeld: you could also see if bzr-git could be of help
<LarstiQ> abeld: I know bzr-svn has svn-import to do it the opposite direction atleast
<dcoles> Last time I used bzr-git I'd either push my branches by hand or checkout each branch in git and then push to them from bazaar.
<abeld> Hmm. bzr fast-export has a "--git-branch=...." arg, I'll try that to specify the name when exporting the repositories.
<dcoles> Bazaar doesn't handle the colocated git repos all that great.
<LarstiQ> dcoles: does bzr-colo improve that at all?
<LarstiQ> or is that wishful thinking, bzr-colo and bzr-git interoperating magically
<dcoles> I'm not sure. I don't think that existed about a year/year-half ago.
<dcoles> Certainly the issue I was having was dependent on colocated branches.
<LarstiQ> launchpad.net/bzr-colo fwiw
<dcoles> I think it was the case where you wanted to check out a git repository with branches... but I've not used git for a while and can't remember the exact weirdness that goes on.
<abeld> Ok, I tried it out, and it apparently worked (at least it did what I wanted). I ran 'bzr fast-export path/to/bzr_repo/branchname/ --git-branch=branchname | git fast-import' for each branch
<dcoles> Nice.
<abeld> The git repo I ended up with contained the right branches, and commits merged from one to the other were apparently not duplicated (which was what I was afraid of might happen)
<abeld> So this will work for me.
<dcoles> I think it's pretty good so long as you do it from the same repo.
<dcoles> I know some exporters will end up with non-determanistic ids if run from different machines, but I think there's a cache that keeps track of the mappings.
<dcoles> Another cool feature is the svn branch name can differ from the bzr branch name and it will still find the correct mapping.
<bignose> if I have done âbzr shelveâ and the shelf is now created, can I apply a message to it post-hoc?
<bignose> so that the message shows up in âbzr shelve --listâ.
#bzr 2011-05-21
<mangojambo> Hi there!
<mangojambo> I'm starting to use bazaar at OSX. On Ubuntu it makes an shortcut for bzr explore on the Ubuntu menu and there is no such option for OSX. SO, how can I create an icon / app launcher for Bazaar, so I don't need to open terminal to launch it everytime.
<dcoles> mangojambo: I'm not familiar with how OSX aliases work, but you want to create a shortcut to "bzr explorer". For most programs I think you can just locate the binary and do 'make alias' action, but it's harder since bzr explorer is launched from the bazaar binary.
<dcoles> The only way around it I can think of is using a shell script what just runs those commands.
<dcoles> Would be a useful feature to be included in the OSX package.
<bignose> evidently I've been bouncing in and out of the server, so sorry for the duplicate:
<bignose> if I have done âbzr shelveâ and the shelf is now created, can I apply a message to it post-hoc?
<bignose> so that the message shows up in âbzr shelve --listâ.
<dcoles> bignose: Best option I've found is shelve current changes, unshelve the one you want to name by ID, reshelve with a message and then unshelve your workspace
<dcoles> Bit of a nightmare when you get 4 or 5 unnamed shelves and all you can do is unshelve --preview to see what they are.
<bignose> dcoles: so that's a âno, one can't apply a message to an existing shelfâ?
<dcoles> Not as far as I'm aware (not a dev)
<bignose> dcoles: thanks for your answer
<bignose> I hope a dev can notice and suggest a more elegant solution
<dcoles> bignose: Sounds like it'd be a handy feature. Something like `unshelve --rename SHELVE-ID`
<dcoles> It would be a good feature request. I'd use it.
<bignose> dcoles: I think it would better fit on the âshelveâ command (which is already the one used for, e.g. , listing existing shelves)
<bignose> although, hmm, this is modifying a shelf. I dunno :-)
<dcoles> Hm. Well the shelves are stored in .bzr/checkout/shelf, so in theory you could just edit the shelf format by hand...
<dcoles> The right way would be to it with shelf.py from bzrlib.
<bignose> dcoles: it's not an easily edited format.
<bignose> sure. but that's not something I can expect to work on any arbitrary Bazaar installation :-)
<dcoles> Might take a look at it tonight and propose a patch. Shouldn't be too hard.
<dcoles> Anyway. 7pm on a Friday. Pub-wards!
<mgz> how, after a week of nothing but bzr, do I have 96 bzr related emails from launchpad to catch up on...
<fullermd> Maybe you wasted that whole 8th day in the week.
<jam> mgz: because everyone else had nothing-but-bzr for the same week
 * mgz wonders what jam normally works on :)
<jam> mgz: :). Even so, we don't usually have that many submissions, even when we're all working on it
<jam> sprinting just makes you more productive
<mgz> and woho, fourth time lucky for the unicode conflicts branch
<jam> mgz: I *think* 4 times is less than my update-basis-by-delta patch
<mgz> and I think we were both beated by one of the ~jr branches were he was trying to get pqm to accept his credentials :)
<jelmer> heh :)
<jam> mgz: true, but at least ours had real problems
<LarstiQ> jam: the mini tutorial looks weird, "We'll make a a *repository directory*, which means that the" is truncated like that
<dandaman1> how do i commit in command line and tell it to ignore a specific file?
<mgz> `bzr commit -x path/to/file/to/exclude`
<LarstiQ> usertest needs some fixes
#bzr 2011-05-22
<workthrick> bzr: ERROR: Invalid url supplied to transport: "sftp://mathrick@lynx.imada.sdu.dk/home/mathrick/public_html/repo/.bzr/branches/gtk/": local urls must start with file:///, UNC path urls must start with file://
<workthrick> any idea why that happens?
<workthrick> http://pastebin.com/V6HeubrE is a fuller output
<workthrick> this is on win32, and it worked before
<workthrick> (but the local repo and working tree has since been recreated)
<workthrick> also previous colo-sync-from which I used to create the repo worked fine
<workthrick> oh, hmm
<workthrick> light checkout root: .
<workthrick>    checkout of branch: sftp://mathrick@lynx.imada.sdu.dk/home/mathrick/public_html/repo/.bzr/branches/gtk/
<workthrick> this is wrong, it should be .bzr/branches/gtk
<gour> morning
<gour> i'd like to use bzr for git-based project and wonder if 'explorer' will use dpush when i push to github or i've to use cli?
<AuroraBorealis> what is dpush? :o
<gour> AuroraBorealis: from the help "Purpose: Push into a different VCS without any custom bzr metadata."
<AuroraBorealis> you can run a 'custom command' in explorer
<AuroraBorealis> or just use the  command line if it doesn't have a explicit option to dpush
<gour> ok
<gour> i dpushed my branch to the github, but i do not see it listed at github which still shows only original braches from the forked repo
<gour> i created shared repo, pull from github. created 'feature' branch locally and pushed back to github...what am i missing or how to use 'feature branch' workflow to contribute to github project?
<AuroraBorealis> feature branch is just a trunk branch inside a shared repo
<AuroraBorealis> not a trunk branch but just some branch inside a shared repo
<AuroraBorealis> so you just dpush the branch to github i guess :o
<gour> right...i cloned pulled-ed github branch in order to work on it and wanted to push it back (afer commiting some fixes)
<AuroraBorealis> so you would probably dpush that back
<gour> but that 'new' branch (named as 'doc-fixes') was dpushed back to github, but it's not listed there :-/
<AuroraBorealis> maybe it takes a minute?
<gour> hmm
<AuroraBorealis> wait like 20 min then try again i guess
<AuroraBorealis> or maybe dpush is bugged or something o.o
<gour> i believe it's something else...like some github idiosync...
<gour> hopefully jelmer or someone experienced with bzr-git & github will appear
<AuroraBorealis> heh.
<gour> what is the status of colo-branches in bzr? are they going to appear in 2.4?
<d_ed> heya, I'm new to bzr. (coming from git) and can't find out the name of the command I want to do the follow
<d_ed> Ive made some commits in a branch
<d_ed> i want to remove one of them
<d_ed> (like gits, interactive rebase, and not pick one of the commits)
<d_ed> is this possible?
<gour> in same file?
<d_ed> yeah
<d_ed> if it's not trivial, I'll just sort something out by hand
<gour> maybe you can try withe shelve
<d_ed> it's alright. I'll make a new branch then apply patches of the parts I do want
<d_ed> *new branch from master
 * gour is usung fossil atm considering to switch to bzr
<d_ed> it's so hard trying to switch betweem RCS systems
<d_ed> I'm normally on git, except for one project, and I'm sure bzr is just as good, but it's nonetheless different
<d_ed> and that gets so confusing
<d_ed> especially when the same word mean different things
 * gour thinks git is too complex
<gour> fortunately, there is fast-import machanism to switch
<mgz> `hg clone -b 2.7 . 2.7` ...that looks a little funny
<LarstiQ> d__ed: you can use the bzr-rewrite plugin
<LarstiQ> mgz: what does that mean?
<LarstiQ> mgz: clone the branch/tag called 2.7 from the current dir to the dir 2.7?
<mgz> yup. I'm not sure the way the cpython repo is structured really makes sense to me.
<mgz> but then, neither does what mercurial calls branches.
<mgz> can't work on bzr without a newer python now though, and no point testing against my rusty svn copy.
<mgz> larstiq: getting to merging the rest of my test cleanup branch which should reduce the number of things to file bugs about for pypy support
<mgz> ha... and that mercurial command did the wrong thing, created the working tree in the cwd rather than the 2.7 dir
<mgz> perhaps branching into a subdir upset it.
 * LarstiQ blinks
<LarstiQ> mgz: possibly :)
<LarstiQ> mgz: and yay test cleanup \o/
<mgz> ...now it's got a working tree in both dirs. probably just overwrote the no trees setting.
<LarstiQ> mgz: about things failing on pyp, as you know the multi byte codec test fails. Not very surprising considering https://bitbucket.org/pypy/pypy/src/7f593e7877d4/pypy/module/_multibytecodec/app_multibytecodec.py
<mgz> heh.
<LarstiQ> mgz: I didn't manage extracting a small example from bzr to disprove Armin's assumption there
<mgz> well, he's wrong
<LarstiQ> I guessed as much :)
<LarstiQ> mgz: and was hoping you could give me some pointers
<mgz> the module isn't well maintained these days
<mgz> but is likely to in use for anyone on a ckj terminal
<mgz> various applications use streamwriters to put things on the terminal, and look at sys.stdout.encoding to create them
 * LarstiQ generates a ja_JP.EUC-JP locale
<mgz> ...the pypy version I have installed doesn't set sys.stdout.encoding at all, which might be why they've not got bug reports
<mgz> or they've fixed that since 1.2.0
<LarstiQ> mgz: it's None in my nightly from a couple of days ago
<mgz> okay, that's the main bug then.
<mgz> if pypy isn't detecting terminal encoding printing unicode just doesn't work.
 * LarstiQ wonders how to test that
<LarstiQ> my terminal inteprets the utf8 back again when I think it shouldn't
<mgz> print u"\xa7" # or similar?
<LarstiQ> ah, that works (as in, gives me a UnicodeEncodeError)
<mgz> if it works, perhaps they've got the default locale set to utf-8 now?
<mgz> ^good good.
<LarstiQ> and it does indeed work in cpython
<mgz> It's likely most of the unicode related tests are being skipped on pypy then.
<mgz> see bzrlib.tests._UnicodeFilesystemFeature implementation
 * LarstiQ hasn't been able to run the full testsuite yet
<mgz> if we can't stat a unicode name, we don't run the test, so output bugs are probably also not being exposed.
<mgz> one thing I do is run useful test subsets.
<LarstiQ> mgz: I can run all the blackbox tests, off-hand I don't recall any skipped tests due to unicode feature
<mgz> hm.
<mgz> maybe that step now works? which would be good.
<mgz> at least utf-8 would be being output correctly then.
<mgz> `os.stat(u"\xa7")` on pypy 1.2.0 raises UnicodeEncodeError for me, but that may be windows only/since fixed
<mgz> the `-s bt.test_` subset is quite good as an alternative to `-s bb.`
<LarstiQ> mgz: gives a UnicodeEncodeError on the nightly
<mgz> so, when I get the test cleanup stuff landed, we probably want bugs filed for all the remaining failures
<LarstiQ> bweh, 10 seconds per test
<LarstiQ> mgz: yup
<mgz> ugh.
 * LarstiQ will make an account on bugs.pypy.org in the next weeks
<LarstiQ> mgz: thanks!
 * LarstiQ goes cooking
<mgz> bye!
<gour> anyone using bzr-git with github?
<gour> i wonder how to push my branch tobe visible at github, if possible or is it better to (as i did) import git repo to LP, use bzr and then just email 'bzr send' bundle to git-repo maintainers?
<mgz> hm, I suspect they might prefer a plain patch. jelmer probably knows how well bzr-git works with github.
<gour> mgz: 'send' bundle  has too much 'context'?
<mgz> I doubt git understands the extra metadata in the bundle, they had a different method of doing the same thing.
<gour> i just wonder what's the easiest way to submit patch(es) to git-based project by using bzr
<mgz> it's a good question.
<james_w> I think there is bzr send --format=git now
<gour> i read the following in the manual: "They can also be useful when communicating with upstream projects that donât use Bazaar. In particular, the preview of the overall change in a merge directive looks like a vanilla software patch, so they can be applied using patch -p0 for example."
<gour> in regard to merge directives
<gour> james_w: in 2.4?
<james_w> I'm not sure when it was added
<gour> sounds good
<gour> james_w: http://bazaar.launchpad.net/~jelmer/bzr-git/send/revision/533
 * workthrick looks around for jelmer
<mgz> I'm having trouble resuming my collection branch from jam's partial merges
<mgz> if I merge the current version to dev it has some of the changes that have already landed, and misses the most important bits in bzrlib.tests
<mgz> presumably this relates to the "Warning: criss-cross merge encountered.  See bzr help criss-cross." I get
 * gour played/used bzr after long time today....very pleased with it
<mgz> but it's odd that the merge command lists bzrlib/tests/__init__.py
<mgz> but bzr diff on that file is empty
<gour> i sent test 'bundle' with git format hoping it's possible to apply it upstream
<mgz> I think maybe what jam did works on branches where he works in his normal fashion, but something in my branch history broke it?
<mgz> I'm not sure what the fix is then as two partial merges are already on bzr.dev
#bzr 2012-05-14
<mgz> morning
<jelmer> hi mgz
<mgz> jelmer: need a samba summary, what did you get up to?
<mgz> know it was a holiday thing, but I'm curious :)
<jelmer> it was mostly just a developer conference like any other :)
<jelmer> met up with other folks again, listened to/gavee talks, drank beer, didn't do a lot of coding...
<jelmer> how were things here?
<mgz> generally confused, as normal
<jelmer> mgz: do you perhaps have some time for a mumble?
<mgz> I do, let me startx
<jelmer> thanks!
<jelmer> the audio gods appear to be in a bad mood today
#bzr 2012-05-15
<mgz> morning
<jelmer> hey
<smspillaz> jelmer: around ?
<jelmer> smspillaz: hi
<smspillaz> jelmer: hey :)
<jelmer> smspillaz: what's up?
<smspillaz> jelmer: so I was looking at getting bzr join working for git imported branches, although it seems to fail when adding the new items to the inventory, since git imports set the file_id of the entry in the inventory to the name of the file (which can clash with items in the new inventory easily)
<smspillaz> so I was wondering - is it safe to modify bzr-join to modify the file_ids of imported entries to be, eg, prefixed with the branch we're joining ?
<smspillaz> (sorry if that sentence was a bit long, been poking around in pdb a bit)
<smspillaz> here's an example in case you need one: http://paste.ubuntu.com/988614/
<jelmer> smspillaz: it should be safe to do that, but it will mostly defeat the point of using bzr join at all
<smspillaz> jelmer: hmmm, how so ? the history would be kept right ?
<jelmer> smspillaz: the revision history will be kept, but the files will appear to have been removed and readded
<smspillaz> ah, that's a problem
<smspillaz> jelmer: do you think there might be any other way around the name conflicts in the inventory then ?
<jelmer> smspillaz: I guess you could use something else for importing from git (fastimport?)
<jelmer> smspillaz: which will generate non-deterministic file ids
<smspillaz> jelmer: right, although I'm already imported from git
<jelmer> smspillaz: yeah, you would have to reimport in that case
<smspillaz> jelmer: so I guess the next question is, is it possible to export to git while keeping the history (not flattened ideally) ;-)
<jelmer> smspillaz: using fastexport/fastimport? I'm not sure how well that works, to be honest.
<smspillaz> mmm
<smspillaz> ok, I'll give a couple of things a try then
<smspillaz> thanks :)
<jelmer> smspillaz: it might be useful to have a look at git-bzr-ng
<jelmer> IIRC it allows that sort of thing (but from the git UI)
<smspillaz> mm
<jelmer> and it uses fastimport/fastexport internally
<mgz> jelmer: do you recall what in 2.5.0 conflicted with launchpad when you tried to update it in their codebase?
<jelmer> mgz: well, launchpad has to be updated to avoid the methods deprecated in bzr 2.5
<jelmer> mgz: doing that broke a bunch of things
<mgz> for parallel testing reliability, they could do with the fix for bug 396819
<ubot5> Launchpad bug 396819 in loggerhead "AttributeError: _factory - lazy imports are not threadsafe" [Critical,Triaged] https://launchpad.net/bugs/396819
<mgz> which is in 2.5.0 but not current launchpad bzr-2.5.0dev2_r6152
<mgz> see bug 998040
<ubot5> Launchpad bug 998040 in Launchpad itself "lp.codehosting.tests.test_bzrutils.TestGetBranchStackedOnURL.testGetBranchStackedOnUrlNotStacked(RemoteBranchFormat-v2) fails rarely/intermittently in parallel tests" [High,Triaged] https://launchpad.net/bugs/998040
<mgz> maybe some of our maintenance time would be well spent working through the things preventing that upgrade?
<jelmer> mgz: I guess it would be better to just cherrypick that fix?
<mgz> perhaps? I don't think I have a good sense of the comparative amount of work involved.
<mgz> using an actual release rather than a random dev revision seems like a good thing to do regardless,
<mgz> but if it's really disruptive maybe not.
<cjohnston> jelmer: I was told to paste you this http://paste.ubuntu.com/988992/  to see if you had any idea why its throwing an error..
<jelmer> cjohnston: hi
<jelmer> cjohnston: at a quick glance it seems like python-dev isn't installed
 * jelmer EODs
<cjohnston> that seems to be it.. thanks jelmer
<ovnicraft> hello i am working in a team so we get a centralized server, but i want to configure to push from team needs an approve, when the push don't auto commit changes
<ovnicraft> so i need to implement a workflow with gatekeeper
<ovnicraft> but is not clear for me
<ovnicraft> how to user make a request to merge
<mgz> that's really a social question
<mgz> asking and giving a reference to the branch is the basic requirement
<mgz> if the gatekeeper is a person, yelling across the office would work
<mgz> for a script, you generally want to send email, or something along those lines
<mgz> click a button on a webpage, whatever
<mgz> there are various existing tools like pqm and tarmac that do this and much more with launchpad
<ovnicraft> mgz: so pqm work with bze send ?
<ovnicraft> and yes gatekeeper is a person
<mgz> if the gatekeeper is going to be a person, just tell everyone to put branches they want merged (with or post review) somewhere he can access them
<ovnicraft> with or post review ?
<ovnicraft> mgz can you help me  explaining it  or give a doc link ?
<wgz> ovnicraft: http://doc.bazaar.canonical.com/beta/en/user-guide/using_gatekeepers.html
<ovnicraft> well i understand how it works but i don't get it how implement it
<mgz> what's to implement with a human?
<ovnicraft> so gatekeeper will make merges from users branches ? or users can try to merge ? and gatekeeper is notified to reviewed
<vila> ovnicraft: the gatekeeper does the merges (on his side of the gate), submitters publish their branches wherever they want as long as the gatekeeper can read them (on the other side of the gate)
<ovnicraft> ok and users can use bzr send to notify the gatekeeper a patch
<ovnicraft> hello i am working with pqm but i can't installed so it can't find pqm python library, i branch code from LP and ./autogen.sh;make; sudo make install
<rbasak> How do I see a branch as it was in a previous revision? I want to see a tree that looks like revision 51. In git, I'd do "git checkout 51". What's the bzr equivalent? "bzr switch -r51" crashes on me.
<jelmer> rbasak: bzr revert -r51
<jelmer> rbasak: or perhaps 'bzr up -r51' (which updates the branch too)
<rbasak> jelmer: both of those commands crash too :-(
<ovnicraft> there is any way to implement my own pqm manager
<ovnicraft> i need to use merge proposal workflow (gatekeeper) and but lp-send works with LP
<ovnicraft> and code review app
<jelmer> rbasak: how do they crash?
<jelmer> ovnicraft: perhaps tarmac?
<ovnicraft> really pqm doc is poor
<ovnicraft> in fact there is no exists
<jelmer> ovnicraft: pqm is pretty hard to set up
<ovnicraft> yes miy friend
<ovnicraft> have you experience with tarmac to read your feed back ?
<jelmer> I have experience with both pqm and tarmac
<jelmer> tarmac is a lot easier to set up; I'd recommend it if you're using launchpad
<ovnicraft> well i am working in my own server
<ovnicraft> i want to implement my own server with merge proposal workflow
<ovnicraft> with bzr send, iget this errror
<ovnicraft> bzr: ERROR: Public branch "sftp://USER@192.168.1.119/home/gnuthinkserver/proyectos/nomina_61/addons/" lacks revision "ovnicraft@gmail.com-20120515180023-rgtcfe3a2fcibyq8".
<ovnicraft> i can't understand the problem?
<jelmer> ovnicraft: bzr send won't work with tarmac - tarmac picks up merge proposals from launchpad only, not from bzr send
<jelmer> sorry, I can't help right now - about to get some sleep
<ovnicraft> yes i know i just working with bzr send
<ovnicraft> ok thanks
#bzr 2012-05-16
<ovnicraft> so i get working bzr send but i want to know if there is any web tool to scan the email or mail list check the patches and manage it  ?
<spiv> ovnicraft: bundlebuggy
<ovnicraft> yes i am trying to install, but last update was in 2009
<ovnicraft> is not a good signal
<ovnicraft> i can't install it
<ovnicraft> there is any another tool like it?
<vila> hi all (and a special hi to 7 digits lp bugs ;)
<mgz> morning all!
<mgz> bug 1000000
<ubot5> Launchpad bug 1000000 in Edubuntu "For every bug on Launchpad, 67 iPads are sold" [Wishlist,Triaged] https://launchpad.net/bugs/1000000
<mgz> ehehhee
<fullermd> Who knew apple was causing so many problems?
<bob2> if it's the same price, it doesn't really address the listed problems (but of course: FREEDOM)
<vila> mgz: hehe, too bad you don't have IRC logs ;O)
<fullermd> Of course an iPad is, what, like 400 bucks?  So fixing a bug on LP should be worth...  $26,800...
 * fullermd gets hacking.
 * bob2 kicks in $5
<fullermd> The sad part of getting a mail from PQM on -commits is that it underlines how few mails have come from PQM on -commits of late...
<mgz> indeed.
<bob2> fullermd, otoh, PQM LIVES
 * fullermd dives for a shotgun.
<mgz> ha, christian perrier complaining about inflated launchpad bug count,
<jam> mgz: because of the 1M rollover?
<mgz> and too many dupes of bug 728840 on samba4... which jelmer fixed!
<ubot5> Launchpad bug 728840 in samba4 (Ubuntu Natty) "upgradeprovision crashed with LdbError in connect(): (80, 'Failed to load modules from: /usr/lib/samba/ldb\n')" [Undecided,Confirmed] https://launchpad.net/bugs/728840
<bob2> the ipad one above seemed to have used spamming to get the round number
<mgz> yeah, flooding bug reports to get the magic number is a little silly, but it's not unusual
<mgz> I remember peeps doing it to get a magic number wikipedia article
<fullermd> Is that supposed to be a _supporting_ argument?  :p
<bob2> tl;dr some people are lame, film at 11
<jelmer> mgz: I don't think bubulle is really complaining about the bug numbers
<jelmer> mgz: more about the fact that there are so many bug reports that aren't particularly useful
<mgz> jelmer: but the whol point of errors.ubuntu.com and related work for precise was to improve this
<bob2> making bug reporting very easy isn't without downsides :)
<mgz> and the samba4 thing he's complaining about isn't even new
<jelmer> mgz: for precise, we still good a flood of duplicate bug reports
<jelmer> mgz: all of which had to be marked as dupes
<mgz> right, the crash deduping stuff isn't perfect, but it's (mostly) a big improvement
<mgz> there's only one 9-series bug in that impressive dupe list.
<jelmer> mgz: it doesn't seem to be working for the samba4 package
<jelmer> mgz: the bug only occurs for the upgrade to oneiric afaik
<mgz> certainly the crash stuff on precise has mostly worked for me, pointed at (already fixed) bug reports where they existed
<mgz> though didn't do anything useful for one with a smashed stack (unsuprisingly)
<jelmer> I've been doing a lot of manual bug duping for samba4 in precise too, so it certainly doesn't seem to work for that
<jelmer> related, opening the stracktraces attached to those automated bug reports in chromium/firefox (often the only way to see what the bug is about) has quite a bit of overhead
<jelmer> I do think we have made progress, but I also agree with bubulle that (at least for the samba4 package) the automated bug reports are more of a nuisance than really useful at this point.
<mgz> right, launchpad attachments aren't the best way of looking at that info
<mgz> really they need to link back to the new fancy stuff
<jelmer> mgz: hmm, errors.ubuntu.com is interesting
<mgz> it's a mini version of the really nice crash stuff mozilla have had for ages
<jelmer> mgz: it seems it has only reports for specific packages though
<mgz> which is great for analysing crash frequency and causes
<jelmer> mgz: so it's not apport based then?
<mgz> I'm not sure on all the details, it's Evan's baby
<jelmer> ah
<bialix> hi all
<jelmer> hi bialix
<mgz> hey alexander
<vila> hey bialix
<vila> ha, too late ;)
<mgz> just missed, vila :)
<vila> hey bialix
<bialix> hi bzr-core guys!
<vila> darn, sound broken again...
<bialix> what is your plans about new releases?
<jelmer> vila: *piiiing*
<mgz> bialix: well, we really need to release 2.5.1 with the various fixes
<bialix> it seems all you are very busy last months, it's very quiet in ML/merge proposals
<mgz> right, we've not been working on bzr
<bialix> mgz: can I ask why?
<mgz> meh, we should have posted something to the list ages back
<mgz> so, I'm still not sure what we're going to be working on next month
<mgz> but we're not on bzr feature work for the forseeable future.
<mgz> jam is doing sprint hand-off this week of the U1 work he was doing on rotation since the autumn
<mgz> then hopefully we can get a few things better sorted out.
<bjp> is something wrong with this revisionspec: -rbefore:date:2012-05-03,11:34:00
<bjp> i'm getting 'requested revision does not exist in branch' but there are plenty of revisions and the last one is from before that
<james_w> bjp, "bzr help revisionspec" reads like there has to be a revision after the date in question for that to work
<bjp> for -rdate:, but i read (somewhere) that -rbefore:date:  grabs one before that date
<james_w> bjp, it probably grabs the revision before the one pointed to by the date thing
<bjp> ooh
<james_w> before(date) rather than (before date)
<bjp> so i need to do a special case for last revision older than date? (i'm trying to batch some bzr commands)
<james_w> bjp, that's what it reads like, but I'm not positive
<thopiekar> hello. Using "bzr branch ftp://<user>:<pass>@<ip>/<dir>/<branch>/ " gives me the error that the connection has been refused and using bzrlib in a python script gives the same error: http://pastebin.com/mb6aPK7p
<lifeless> thopiekar: that suggests that the ftp server isn't running or is firewalled
<thopiekar> but the link is working as you put it into a browser or connect to it via ftp client
<thopiekar> lifeless: ^
<thopiekar> and I get the same error when using the local ip in my private network (no firewall)
<thopiekar> something similar when pushing code via ftp: http://pastebin.com/WiEv4FHk
#bzr 2012-05-17
<mgz> morning all!
<lifeless> mgz: morning
<lifeless> mgz: btw, you might like to idle in #launchpad-dev too
<mgz> morning lifeless!
<mgz> ...dangerously close to my ten irc channels mental limit
<lifeless> mgz: :P
<mgz> is the MutableTree.post_transform hook called whenever we poke a file in a tree?
<jelmer> mgz: define "poke" :-)
<mgz> bug 997933 is the context
<ubot5> Launchpad bug 997933 in Bazaar "Bazaar revert fails to maintain file permissions" [Undecided,New] https://launchpad.net/bugs/997933
<mgz> so, poke=use fancy_rename to replace a file's contents
<mgz> which is wrong on windows, because it doesn't preserve ACLS
<jelmer> mgz: the post_transform hook is called after transform operations - so revert, merge, etc
<mgz> ace, so should be fine then
<mgz> just to check I'm not being a fool,
<mgz> there's nothing on the treetransform by the time it gets to the post_transform hook that tells you what it actually did?
<mgz> so post_transform only knows what tree, the object of operation, and that something (may) have happened?
<jelmer> mgz: that sounds about right
<lduros> how can one remove the .~x files in a bzr local repo?
<lduros> branch
<lduros> I should say
<lduros> where do these files come from, btw :-)
<mgz> lduros: see `bzr help clean-tree`
<lduros> mgz: ah, thanks
<mgz> they come from situations like when you revert a file you've changed, bzr keeps a backup by default rather than throwing away the existing file
<lduros> yeh, i've been reverting a lot
<lduros> when I do bzr clean-tree though it tells me nothing to delete
<mgz> try the --ignored flag
<lduros> ok
<lduros> mgz: ah very cool. All Gone!
<lduros> I was trying --unknown
<lduros> but that's not the same :-\
<lduros> mgz: thanks much
<mgz> no sprobs
<GeorgeJetson> just some feedback. the GUI gives two options after adding files - show diff or commit... I think some other good things to list are back out and undo the add on certain files
<GeorgeJetson> why cant you right-click on unversioned files to add them to the ignore list?
#bzr 2012-05-18
<thomi> I'm sure I'm missinbg something really obvious, but how do I switch branches with the colo plugin?
<thumper> thomi: switch
<thumper> just a wild stab in the dark
<thomi> oh, well that was obvious
<thomi> I was expecting a colo-something command
<bob2> it's le pluggable
<lifeless> over-usability, when things just work that you would not expect to do so
<fullermd> Boy, if I had a nickel for every time people have said that about my software...
<fullermd> I don't even know what I'd do.  What CAN you buy for two bits nowadays?
<lifeless> fullermd: a nickel display cabinet
<bob2> one one thousandth of a nickel display cabinet
<fullermd> So, if we band together, and find 997 like-minded people, we can have an awesome unveiling party!
<bob2> velvet curtain will cost extra
<mgz> morning all!
<vila> hey mgz et al. ;)
<mgz> how goes vila?
<vila> knee-deep in setting up a local launchpad ;)
<vila> catching up, I agree we should release a 2.5.1 (and merge up the delta too)
<quicksilver> is there any way to see the extra diff in a merge?
<quicksilver> I mean, the diff between what you would get by doing a straight merge, and what actually got committed
<mgz> not easily
<mgz> there's a plugin lifeless has pointed me at least twice called...
<mgz> lp:difftacular
<mgz> that can do that kind of thing.
<quicksilver> strikes me as a failing
<quicksilver> sometimes you really want it.
<mgz> patches welcome.
<quicksilver> no doubt
<quicksilver> I hope it's still permitted to discuss the bzr feature set here without being asked for a patch on each point.
<quicksilver> difftacular looks interesting.
<mgz> it's such a nice answer when explaining the underlying complexities would be too much effort though :)
<quicksilver> one could look at the merge-preview diff from the rev before, and the merge-preview diff from that rev
<quicksilver> I wonder if anyone has considered a tool to sensibly compare two diffs
<fullermd> There's probably an emacs mode for it.  I think it's under ctrl-meta-hyper-sasquatch.
<quicksilver> ;)
<quicksilver> well one natural way to compare to diffs is just to actually apply them to the tree (in a scratch branch)
<quicksilver> and then compare the resulting trees
<fullermd> Anyway, as far as bzr is concerned there is no post-facto "extra diff".  You'd have to basically redo the merge (and hope it came out the same way, which you have no way of knowing), then compare to what's committed.
 * quicksilver nods
<quicksilver> fullermd: why "hope it came out the same way" ?
<quicksilver> you mean if they chose a different merge algorithm?
<fullermd> Or reprocess.  Or bzr changes/bugfixes/bugadditions have happened since then that change the outcome.
 * quicksilver nods
<fullermd> 's not out of the question that a merge algorithm could be nondeterministic too, though I don't know of any in common use.
<fullermd> (and various other even bluerskier merge behaviors that could be difficult to reproduce)
<fullermd> And that aside, a straight diff could look kinda weird in the case of conflict resolution.  By the third or fourth time you hit that, you'd be tempted to go off and invent a new semantic language for representing that.
<fullermd> Which would be (a) cool, and (b) save you from wasting time on your original boring problem  ;)
<quicksilver> yes, I considered the conflict problem.
<quicksilver> In fact this is really all about conflicts in general
<quicksilver> but there is of course a distinction between textual conflicts and "mere" semantic conflicts.
<quicksilver> the kind of work you do in a merge commit is to fix the semantic conflicts.
<quicksilver> (subroutine's API got changed in the other branch, perhaps)
<fullermd> Nah, you just commit those.  If it's important, the end user will tell you eventually.
<quicksilver> :P
<quicksilver> you can't commit them fullermd
<quicksilver> commit does work unless all test pass.
<quicksilver> doesn't.
<fullermd> I didn't say you commit them under your _own_ name!
<jimis> hi, how can I diff latest committed version of a file, excluding uncommitted stuff, versus the one in another branch?
<mgz> eg `bzr diff -r-1..branch:../trunk path/to/file`
<mgz> but probably you want that revspec the other way around?
<jimis> thanks mgz
<jimis> no that way is good
<jimis> so -r-1 refers to the latest committed changes?
<mgz> yup, you can count revno backwards with negative numbers, like with lists in python
<jimis> cool, I was just thinking it was one before last commit
<pfrost> if i've merged a branch and introduced a regression, what's the most reasonable way to revert the merge such that i can fix the issue and later re-merge the branch?
<pfrost> if i do something like "bzr merge . -r 123..122", I can reverse the commit that did the merge, but when i later merge the branch again, all the changes prior to the first merge aren't merged.
<mgz> pfrost: more 'merge' than I can parse there :)
<pfrost> it should be a fairly typical situtation in a branch-based development
<pfrost> you have a "production" branch, and branches for each feature. You merge feature A, then later discover it introduces a regression, so you want to un-merge it. How would you do that?
<mgz> can you give a more specific example of the problem when later wanting to merge the branch?
<mgz> because the reverse merge is what I'd generally do.
<pfrost> what do you mean by "reverse merge"?
<mgz> -r 123..122
<pfrost> in the production branch?
<mgz> yup.
<pfrost> ok, so let's just forget about fixing the regression
<pfrost> if at that point you try to merge the feature branch again, it will do nothing, because it's already been merged to production. The fact that the merge was reverted seems irrelevant to bzr.
<pfrost> does that make sense?
<mgz> yup.
<pfrost> so what do you do to get around that?
<pfrost> I imagine another problem with doing it this way is that if feature A branch merges production, all of feature A will be blown away.
<mgz> that might be more of a worry., but it's generally not hard to revert
<pfrost> sure it's not hard, but at this point, bzr is no more functional than CVS
<mgz> the easy fix is for the feature branch to do exactly that, merge the rev where production does the revert
<mgz> then revert the contents but keep the merge marker
<mgz> then when it's next merged, the changes will come back to the production branch again
<pfrost> how's that accomplished?
<mgz> ...this is rather hard without diagrams
<pfrost> i understand the approach, just not sure how to have bzr do it
<mgz> so, current state is production is on r124 which reversed the merge done in r123 of the feature branch
<mgz> so, in the feature branch do:
<pfrost> i see bzr revert --forget-merges...i'm hoping to find something like bzr revert --keep-merges
<mgz> `bzr revert *` is how you spell that
<pfrost> ah
<mgz> as in, revert all the contents, but keep the merge marker
<pfrost> ok, that all makes sense
<mgz> `bzr merge -r124 ../production && bzr revert * && bzr commit`
<pfrost> coincidentally, i think git handles this process much more elegantly
<mgz> I've never done it with git.
<mgz> have only done it a couple of times with bzr.
<pfrost> as i recall there's a command that puts all the revisions in a text editor, and you can just delete the one you want to undo, and it deletes that revision, then attempts to re-apply all the revisions that come after it
<pfrost> provided that can be done without conflicts, it works
<pfrost> if there are conflicts, it stops along the way so they can be resolved
<mgz> right, that sounds like a history rewrite though
<mgz> you'd not want to do that on a public production branch.
<pfrost> hm, true
<jelmer> pfrost: right, git rebase -i
<mgz> (as opposed to a branch just for deployment or something which was a leaf you don't much care about the history of)
<pfrost> well, git aside, i do wish there was a way to actually undo a merge, which isn't the same as creating a new revision that applies the inverse changes.
<pfrost> the way things work around here, features get branches, and if they break anything, they get rejected outright, immediately. There's no merging of broken branches, then letting them hang out for a while until a separate fix is created.
<mgz> but they land on production before testing?
<mgz> or just that sometimes it's only picked up after a while on production
<pfrost> production might be a misleading name
<pfrost> the goal is to have the trunk branch be as close as what might be a release all the time
<mgz> what we do is have a bot which creates a branch, applies the merge, runs the test suite, and only if it passes pushes that to the public trunk
<pfrost> i do similar, but sometimes there are issues that aren't picked up by the tests
<mgz> if the merge has conflicts or a test fails, you get email complaining
<mgz> right, sometimes you'll want to back something out regardless
<pfrost> that usually results in the merge being reverted, new tests being written to address the hole in test coverage, and another merge attempt made
<mgz> it's a good habit, rather than letting things site
<mgz> *sit
#bzr 2012-05-19
<neXyon> awesome: http://pastebin.com/Nf8JBdvq :-(
<vila> neXyon: shot in the dark: do you have a working tree with at least one revision here (as opposed to a just-created-never-committed one) ?
<fullermd> That sounds familiar.
<neXyon> vila: I just did a bzr branch, that's the cause?
<fullermd> Though hazy enough that whatever it's reminding me of is well before 2.5...
<vila> neXyon: what does 'bzr revno' says ? And 'bzr info' ?
<fullermd> Is there a working tree there?
<neXyon> I deleted the directory and branching again atm, will tell you then
<vila> I suspect (as fullermd) that you have a branch with no working tree (i.e. the directory contains only a '.bzr' dir)
<fullermd> Great minds think alike.
<fullermd> And vila gets lucky sometimes, too.
<vila> . o O (Glad I re-read his remark until I realized he meant *no* wt there )
<neXyon> vila: yes true, only a .bzr dir
<fullermd> On the one hand, it might point at the error.  Though, on the other, the command being run seems like something that might be embedded in a build script, not something you'd just come up with manually.
<vila> so, first of all, this is a bug, at the very least a friendly error message should be displayed, not a traceback, so please file it at http://pad.lv/fb/bzr
<vila> neXyon: now, what's your use case ?
<neXyon> vila: I just did as http://doc.bazaar.canonical.com/latest/en/mini-tutorial/#creating-your-own-copy-of-another-branch told me to
<vila> neXyon: and then, a workaround would be to do 'bzr checkout .' to create a working tree there
<neXyon> vila: bzr init-repo stellarium; bzr branch lp:stellarium stellarium
<vila> err, are you sure you didn't do 'bzr init-repo --no-trees' ?
<vila> and my question is: why do you run 'bzr version-info' ?
<neXyon> vila: the zsh does
<vila> eeerk
<neXyon> and no, I didn't add any --no-trees :D
<vila> who told it to do that ? ;)
 * vila scratches head
<neXyon> the grml zsh configuration :D
<fullermd> I never trust something with that few vowels.
<vila> bzr branch creates a working tree by default
<neXyon> so why didn't do it in this case?
<neXyon> +it
<vila> hehe, *you* tell me :)
<vila> bzr alias ?
<neXyon> how could I? xD
<vila> neXyon: :)
<vila> because it's probably caused by some setting on your side
<vila> and my crystal ball is currently being checked in this place I cannot name
<neXyon> nah, I have no alias for it and I also didn't change any bzr configuration
<vila> so, back to previous question: 'bzr info -v' ?
<neXyon> ah, sure
<neXyon> vila: http://pastebin.com/03ddtbQE
<vila> 'brz config' ?
<neXyon> vila: nothing special there: http://pastebin.com/RPADTTY0
<neXyon> Name Mail and IRCnick got changed by me before pasting ;)
<vila> ls -lR .bzr
<neXyon> vila: http://pastebin.com/wsKuASVA
<vila> puzzling...
<vila> so, there is indeed no working tree, get one with 'bzr  checkout .'
<neXyon> yeah, that might fix it, but what about the bug that it isn't there as it should be? :D
<vila> I don't understand how this can happen :-/ Try looking into in ~/.bzr.log ?
<vila> s/ in / /
<vila> gotta go soon
<neXyon> vila: nothing special there
<neXyon> the checkout however fixed it
<vila> it should have happened at 'bzr branch' time, everybody is relying on it :)
<vila> I know of only two ways to avoid it: 'bzr init-repo --no-trees' and 'bzr branch --no-tree'
<vila> and your 'ls -lR' says you didn't use 'bzr init-repo --no-trees'...
<fullermd> Once upon a time, --no-trees was the default for init-repo.  But that was a _long_ time ago.
<vila> fullermd: and is reflected by a 'no_working_trees' file under .bzr/repository
<fullermd> To be sure, it is a _little_ odd to make a shared repo, then have one branch in the root of it...
<neXyon> vila: yes the log tells I didn't do it too
<neXyon> fullermd: so what's the expected way to start developing on a launchpad project?
<neXyon> fullermd: if it's not "bzr init-repo stellarium; bzr branch lp:stellarium stellarium"?
<vila> it *is*, that's why it's puzzling, that's what everybody does :)
<neXyon> xD
 * fullermd peers at vila.
<fullermd> Nobody I've ever met...
<neXyon> fullermd: it's not? what else?
<fullermd> (although, meeting other bzr users would require that I leave my cave in the first place, but still...)
<fullermd> Generally, you'd have a branch in its own dir under the repo, not colocated with the repo root.  Otherwise, where would you put the second branch that would share space and make the shared repo be pointful anyway?
<fullermd> But it's not something that should _break_ anything.  I think.
<fullermd> Oh ho.  Back up.
<fullermd> Yes, it is.
<vila> eeerk, 'bzr init-repo xxx; *cd* xxx ; bzr branch lp:xx yyy'
<fullermd> I can reproduce it.  If I bzr init-repo something, then bzr branch $SRC something, I wind up with a treeless branch.
<fullermd> (lp: having nothing to do with it)
<fullermd> So it's a behavioral oddity when the bzrdir exists.
<vila> neXyon: you need to *CD* into the repo before branching
 * vila nods @ fullermd, that's another bug (unless there is a rationale for it (doubtly))
<vila> could also be a fallout from an unrelated fix
<fullermd> It's probably a 2nd or 3rd order consequence of some other sensible behavior that nobody ever ran into.
<neXyon> hah, so we found the bug :D
<fullermd> Man, we should write some more wrong docs; think of all the extra bugs we could find!
<vila> neXyon: roughly, you create a shared repo if you intend to create several branches (so they will share their revisions)
<mgrandi> this seems like the weird thing i had if you try to make a branch a shared repo
<vila> if you want a single branch, no need for a shared repo
<mgrandi> you get really weird state
<neXyon> vila: and how to create a not shared repo? xD
<vila> just 'bzr branch'
<vila> no 'init-repo'
 * vila gone
<fullermd> neXyon: You don't need to explicitly create a repo if you don't want a shared one.
<neXyon> vila: I just want to develop somewhere; stay in sync with trunk and probably at some point be able to push the changes to trunk :)
<neXyon> so I just had to run "bzr branch lp:stellarium stellarium" ?
<fullermd> Might as well just ignore it.  If down the line you start having several branches around and want to switch them to sharing a repo, that's easy enough to do then.
<fullermd> Correct.
<mgrandi> don't even need to specify the 'stellarium', by default it creates that folder
<neXyon> I first had a "bzr checkout lp:stellarium" is it possible to change that to a "bzr branch lp:stellarium"?
<fullermd> You can use 'bzr unbind' if you avoid thinking too carefully about the semantics.
<fullermd> Or something under 'reconfigure'.  I'd have to dig around to figure out what.
<neXyon> fullermd: can I still keep it up to date with trunk after the unbind?
<fullermd> Sure, just 'pull' whenever.
<neXyon> awesome, well as it works currently with the shared repo, I'll leave it as it is :)
<neXyon> fullermd: shall I report that bug somewhere or will you handle it?
<fullermd> I can file it I guess.
<neXyon> fullermd: if you wish, sure; otherwise I could too
<fullermd> Well, I wouldn't want to steal your LP karma.
<neXyon> fullermd: whatever that is xD
<neXyon> nah, I know it, but no clue what it's for
<fullermd> Neither do I.  But it's a number, so it MUST be important.
<neXyon> fullermd: so? looks like we're both too lazy :)
<fullermd> Laziness is a virtue.
<jave> is someone having success using bzr on the fedora 17 prerelease?
<AmberJ> Is there a way to search for when few consecutive lines of code were added to the repo?
<AmberJ> I want to find the revision when those lines were added.
<AmberJ> Nevermind, I used "Change to this file" in launchpad web GUI to find what I was looking for.
<AmberJ> Though this was more of manual searching.
#bzr 2012-05-20
 * jimis watching bzr log -p consuming 800MB RSS and still going...
<jimis> "bzr merge -cREVNO ." is telling me it has modified 2 files, but bzr status shows nothing was modified. Any ideas?
<jimis> hmm never mind I used -rREVNO..REVNO-1 and it worked
<lduros> is there a way to delete a remote repository?
<vadi2> Is anyone else's bzr viz from 12.04 severely broken in terms of UI not functioning? Scrolling all the way up to the latest commit does not work.
<caravel> hello there o/
<youlysses> o/
<caravel> what is the status of the kde service (as of 4.8.3, running Fedora here) ? repo branched via bzr+ssh, cli tool works fine, but in dolphin all I get is some message in status bar : "Update of version information failed"
<wolter> I am trying to revert my branch one version back but it keeps printing out the names of files I have modified and it will not complete the operation
<wolter> What can I do to fix this?
<bob2> http://bpaste.net the command you ran and the full output
<wolter> bob2, I uncommitted and that seemed to work, thanks for trying to help though!
#bzr 2013-05-13
<Meatball_py> Hi all, what command should I run the know the current branch of a local repository?
<lifeless> Meatball_py: bzr info
<jdoles> I have a big directory with .bzr in it. How do I get the directory filled with the latest version?
<jdoles> No files are visible currently.
<jelmer> jdoles: "bzr co" (no arguments)
<hypnocat> how can i change the last description of the last revision i committed?
<LeoNerd> You can't, as such. You -can- uncommit and recommit again but that's kinda rude on anyone else who might have pulled the branch since then
<LeoNerd> So only consider doing that if it's unpushed, or it's a private thing nobody else is likely to be using
<hypnocat> i'm the only user of the particular repo where i need to make this change
<hypnocat> i'll uncommit and recommit, then
<hypnocat> thanks for your help
#bzr 2013-05-15
<chmac> Experiencing weirdness between bzr update / bzr commit, working with the "centralised" model, and a local bzr commit / bzr push.
<chmac> Somebody else pushed changes, then I committed changes locally, when I tried bzr push I got an error. So I ran bzr merge, and then bzr commit then bzr push.
<chmac> Now only my commits (including the merge) are showing in the log, it's like I wiped out the other commits, combined them into one, and attributed it to me...
<chmac> Maybe I'm missing something?
<chmac> Is there a neater way to achieve this workflow?
<chmac> In git there's some way to merge the whole thing, while persisting each person's individual commits. Can I do something similar in bzr?
<jelmer> chmac: log only shows mainline commits by default. Try "bzr log -n0"
<chmac> jelmer: Nice, ok, that's what I was after...
<chmac> jelmer: We're using codebase and there's some weirdness there, it doesn't show sub commits or something...
<jelmer> chmac: codebase?
<chmac> jelmer: http://codebasehq.com/ I think
<chmac> It's like a launchpad / github type service, but supports a handful of scms
<chmac> Launchpad is nice, but it's expensive to get started...
<Wiz_KeeD> How the hell do I remove bzr from a directory?!
<jelmer> Wiz_KeeD: what do you mean exactly?
<Wiz_KeeD> so it will be a simple directory not tracked by bzr so i can make a separate repository
<Wiz_KeeD> to include this directory
<Wiz_KeeD> otherwise i cannot make it because it complains it has child branches whatever
<Wiz_KeeD> i tried remove-tree remove rm delete
<mgz> you really don't want one branch containing another like that
<Wiz_KeeD> yes that why i want it completly removed
<Wiz_KeeD> i just deleted .bzr
<mgz> but `bzr rm --keep` should do
<Wiz_KeeD> i did rm without keep and still bzr info and .bzr dir is there
<mgz> ...you want the whole thing gone? then just deleting .bzr is fine, or using rmbranch and moving stuff
<Wiz_KeeD> deleteing then, still when i do bzr add on multiple directories including the one i've dleted bzr from
<Wiz_KeeD> it still does not add them with bzr add .
<Wiz_KeeD> fuck this i'm reading the tutorial from scratch
<Wiz_KeeD> ok so i followed the tutorial i create a new directory i do bzr init on it i add all the contents commit to the branch then push with bzr+ssh on the server where it says the it has created a branch
<Wiz_KeeD> but the directory on the server is empty...what the hell is up with that?
<jelmer> Wiz_KeeD: it doesn't create a working tree on the server, just pushes the contents of the branch
<jelmer> Wiz_KeeD: run "bzr co" in the directory on the server to create a working tree
<Wiz_KeeD> but there is nothing there, it's completly empty
<jelmer> Wiz_KeeD: there is a .bzr directory there, presumably?
<Wiz_KeeD> what is the definition of a working tree then? the tutorial said you can push the content of your branch there
<Wiz_KeeD> yes it is there, it has been created
<Wiz_KeeD> and with that i can pull now?
<jelmer> yes
<Wiz_KeeD> it says i cannot pull location not specified and no working tree exists
<Wiz_KeeD> the tree is the actual "server" so to speak
<Wiz_KeeD> the actual mother repository?
<jelmer> Wiz_KeeD: when does it say that?
<jelmer> Wiz_KeeD: you'll need to specify the location to pull from the first time you pull
<Wiz_KeeD> http://doc.bazaar.canonical.com/bzr.dev/en/tutorials/tutorial.html#publishing-your-branch
<Wiz_KeeD> here
<Wiz_KeeD> why didn't the contents of my directory get pushed on the server?
<Wiz_KeeD> what about that jelmer ?
<jelmer> re
<jelmer> Wiz_KeeD: the contents did get pushed. have you tried running "bzr log" in the directory on the server?
<Wiz_KeeD> i see the message, i don't see the contents
<Wiz_KeeD> now what?
<Wiz_KeeD> In the case where i develop on localhost and push modifications to server, i should have a shared repository?
<jelmer> Wiz_KeeD: you can have bzr create the contents on disk by running "bzr co" on the server
<jelmer> Wiz_KeeD: the contents are there, they're just stored under .bzr/
<Wiz_KeeD> ok, how did you know that? why did that happen and why didn't the files appear there in the first place?
<Wiz_KeeD> i'm still confused as fuck
<Wiz_KeeD> hello
<Wiz_KeeD> jelmer, still there?
<jelmer> Wiz_KeeD: yes
<Wiz_KeeD> that was quick, how are you? :)
<Wiz_KeeD> jelmer, if i have my development environment on localhost and i want to ocasionally push modifications to the production server
<Wiz_KeeD> what would be the best setup?
#bzr 2013-05-16
<Wiz_KeeD> hey guys
<Wiz_KeeD> is anyone online?
<bob2> many
<Wiz_KeeD> bob2, If I develop on my local enviroment and ocasionally want to push my modifications to the production server when i see fit.What is the best setup with bzr to do so?
<Wiz_KeeD> And have a proper backup in case one of them goes down
<bob2> are you sure you want to pick bzr?
<bob2> and something like http://doc.bazaar.canonical.com/plugins/en/push-and-update-plugin.html
<Wiz_KeeD> I was reffering to shared repository, where to place it how to work with it
<bob2> no need to do that
<Wiz_KeeD> how come?
<bob2> because there's no need to do that
<bob2> the thing you are after is the above link
<bob2> but, well, be sure to think about whether bzr is what you want to use for this
<Wiz_KeeD> i pretty much have to, all the addons are on launchpad and bzr is used to retreive them
<Wiz_KeeD> i might as well use the same thing
<bob2> what is?
<bob2> is this all about drupal
<Wiz_KeeD> openerp of the openobject framework
<bob2> you'll probably want to talk to them directly
<Wiz_KeeD> this is for a personal project
<Wiz_KeeD> I had a module that was versioned with bzr, then i split the module into multiple ones and tried to move the bzr tree to include the rest of the modules
<Wiz_KeeD> i ended up losing most of my work
<bob2> I'd carefully consider 'able to get support' when picking a dvcs
<bob2> well, obviously back thigns up before doing anything dangerous
<bob2> regardless of what you're doing
<Wiz_KeeD> should of thought of that sooner, i have some previous version but not the latest
<Wiz_KeeD> and that sucks
<bob2> but really really do consider "how easily can I get help" when picking a tool like a dvcs, especially if you don't have any experience with any of them
<Wiz_KeeD> how complicated can it be for basic tasks i need? it's not like i'm merging branches or working with a big team
<Wiz_KeeD> just need to backup and push my modifications that's pretty much it
<bob2> yes
<bob2> but tbh I'd suggest really thinking about it and picking something else
<bob2> if you can't figure it out from the above docs
<Wiz_KeeD> i don't imagine git being much easier
<Wiz_KeeD> either way it's the terms that are really bugging me branch,repository,tree, working tree
<Wiz_KeeD> but i'll figure it out sooner or late
<Wiz_KeeD> r
<bob2> it's not
<bob2> but the problem isn't difficulty, it's supportability
<Wiz_KeeD> what do you mean by that?
<bob2> that you're going to continue to struggle
<Wiz_KeeD> if it's not difficulty then why would i struggle?
<bob2> ok then, best of luck
<Wiz_KeeD> I'm asking because i don't know what you're refering to
<Wiz_KeeD> :)
<Wiz_KeeD> bob2, when moving files around in a versioned directory, are you supposed to add them with bzr add or can it figure out for himself that they have been moved?
<vila> Wiz_KeeD: if you're moving versioned files, better mention it to bzr with 'bzr mv old_path new_path'
<Wiz_KeeD> but now that i did not to that,  removing/adding them shouldn't be much of an issue should it?
<vila> Wiz_KeeD: if you forget to do that, you can still catch up before commit with 'bzr mv --after old_path new_path'
<vila> Wiz_KeeD: remove/add and mv are different
<Wiz_KeeD> of course
<vila> remove/add is saying bzr: I don't care about the old one. I care about the new one. They are different files.
<Wiz_KeeD> yes you are right
<vila> mv is saying: old and new are the same file, I'm changing its name
<Wiz_KeeD> so bzr mv --after file.xml new_dir/file.xml
<Wiz_KeeD> ?
<vila> please keep track of that so that if I do modifications to old in a different branch and merge it here, I want these changes to be carried over
<vila> Wiz_KeeD: yes
<Wiz_KeeD> ok let me do that, thanks for the tip man
<vila> Wiz_KeeD: explicit is better than implicit
<Wiz_KeeD> what do you mean?
<Wiz_KeeD> can bzr move take multiple arguments?
<vila> Wiz_KeeD: 'bzr mv --auto' will try to guess what you did and should be reasonably accurate but you know better and you will always be right when saying which file/dir has been renamed
<vila> Wiz_KeeD: bzr mv --help
<Wiz_KeeD> ahhh that what you were reffering to, i was looking at the manual for that
<Wiz_KeeD> what if it's wrong, there must be a way to step back and do the explicit move yourself
<vila> yeah, 'bzr mv wrong good'
<vila> Wiz_KeeD: as long as you don't commit, you're free to change your mind
<Wiz_KeeD> aluart/purchase_view.xml => aluart/view/purchase_view.xml (assuming this would have been an auto move and wrong, which is not_
<vila> Wiz_KeeD: well, even after committing you can still change your mind...
<Wiz_KeeD> vila i have a question...i have a production server where i upload my modules and they go into production.on my local machine i develop...what is the best possible setup to have for this environment to have proper backup on both machines and be able to push my modifications
<Wiz_KeeD> ?
<vila> Wiz_KeeD: generally it boils down to: can you put the branch on the production server without fear of people accessing your source to read them or write them
<Wiz_KeeD> yeah there's no problem for that
<vila> Wiz_KeeD: if you can, as bob2 mentioned, push_and_update is the most transparent way
<Wiz_KeeD> bzr+ssh, it's secure and the server is not widely available
<Wiz_KeeD> so i have to install a bzr plugin for that
<Wiz_KeeD> a repository is not needed for this job?
<vila> Wiz_KeeD: if you can't, the bzr-upload plugin will upload the modified files without requiring a remote branch
<Wiz_KeeD> is there any downside to the remote branch?
<Wiz_KeeD> i did this setup before and just did bzr push :parent
<vila> Wiz_KeeD: repository and branch have different meanings in bzr, you generally should use and think about branches
<vila> Wiz_KeeD: (hold on, I'm trying to answer your questions in order ;)
<vila> Wiz_KeeD: a repository is where a branch will store the revisions that defines the branch history
<vila> Wiz_KeeD: a repository can be used by a single branch or by several branches
<Wiz_KeeD> isn't the branch history stored in the branch itself?
<vila> Wiz_KeeD: when you use multiple branches that shares a lot of history, using a shared repository makes sense but is a conscious and explicit decision. If you don't do it, things will still work but each branch will consume a bit more disk space
<vila> Wiz_KeeD: no, the branch only stores a pointer to the most recent revision, the revisions themselves are in the repository
<vila> Wiz_KeeD: so, when dealing with branches, you rarely have to think about the repository which is an implementation detail
<vila> Wiz_KeeD: if you want to think about it, well, you think about it when creating it, knowing that creating branches in directorieS below the shared repo will use that
<vila> Wiz_KeeD: are things clearer about branches and repository ?
<Wiz_KeeD> to get things straight...a BRANCH is basically a mirror-copy version of the original content
<Wiz_KeeD> which is what defines the distributed version control system
<Wiz_KeeD> a repository is a central location where information about versions and changes reside as you said
<vila> Wiz_KeeD: you can think of it this way, under the hood, there is no difference between a mirror-copy and the original content since they are both defined by a revision identifier
<Wiz_KeeD> so when i'm able to see all the changes that have been done on my localhost, that means i copied the repository as well?
<vila> Wiz_KeeD: yes
<Wiz_KeeD> ahh, starting to make sense
<Wiz_KeeD> so there is no "master repository"
<vila> Wiz_KeeD: but again, things are clearer if you think about branches
<vila> Wiz_KeeD: there are branches, master or trunk or HEAD generally have a special social meaning: that's where people share a common definition of some code
<vila> Wiz_KeeD: people can be reduced to yourself ;)
<Wiz_KeeD> what do you mean?
<Wiz_KeeD> ahh
<vila> Wiz_KeeD: that you can put the same branch in different places, what you do with them is up to you and people using them
<Wiz_KeeD> Is a branch a state of the code at any given moment?
<Wiz_KeeD> Without the revision history
<vila> it is a state of the code at a given moment as well as the history
<Wiz_KeeD> but you said branches don't hold revisions
<Wiz_KeeD> maybe they hold some sort of identifier or tag or revision number
<Wiz_KeeD> but no more?
<vila> Wiz_KeeD: exactly
<Wiz_KeeD> starting to make sense here, thank God for your patience vila :))
<vila> so by using that identifier, you're referring to the revision definition which also includes its parent revisions
<vila> when you do a commit, there is a single parent
<vila> when you do a merge, there are two parents
<Wiz_KeeD> So the reason you guys suggested i use push and update is not to have two separate repositories just one on my localhost and one in the production environment?
<Wiz_KeeD> and not one*
<vila> you can merge several parents at once and commit that, the resulting revisions will have even more parents but it's... rarely used
<Wiz_KeeD> The thing is...if i have a repository only on localhost, and just push changes to a branch on the server
<vila> Wiz_KeeD: indeed, I asked you if you wanted a remote branch or not (the repositories will be handled for you so we can stop talking about them now)
<Wiz_KeeD> What if something happened to my computer, how can i do reverts and see changes on the server?
<vila> Wiz_KeeD: suppose you lose your computer or needs to start on a different computer,
<vila> Wiz_KeeD: on the new computer you do 'bzr branch <remote_url> <local_url>'
<Wiz_KeeD> and i'll have the full log of changes?
<vila> yes
<Wiz_KeeD> i like using qlog for example
<vila> that's what dvcs is about
<vila> you have the whole branch history and you can work offline
<vila> you don't need access to the server anymore, hence distributed
<vila> whereas in a centralized vcs, you need access to the server to get access to the history
<Wiz_KeeD> yeah i read about that
<Wiz_KeeD> but that means the repository is copied as well if you can see all the changes
<vila> Wiz_KeeD: now, let's stop talking about repositories, that's not what we care about, we care only about branches
<Wiz_KeeD> It's still a concept problem in my head that's why i keep bugging them
<vila> Wiz_KeeD: what we care about too is working trees
<Wiz_KeeD> if branches are only a version of data at a given moment with a identifier
<Wiz_KeeD> then it means that without a repository you cannot revert or see a full log
<vila> Wiz_KeeD: right, one repository will always be there
<Wiz_KeeD> that's why i'm curious about the repositories and how they are created
<vila> ha ok
<Wiz_KeeD> where? on the server? or with the branch?
<vila> Wiz_KeeD: both are possible
<vila> Wiz_KeeD: in the simplest scenarios, each branch has its own repository
<Wiz_KeeD> "when you use multiple branches that shares a lot of history, using a shared repository makes sense but is a conscious and explicit decision. If you don't do it, things will still work but each branch will consume a bit more disk space"
<vila> yes
<vila> but if your history is small you probably don't care
<Wiz_KeeD> let me look up the definition for a shared repository
<Wiz_KeeD> ah this is it
<Wiz_KeeD> Because all branches store all revisions and each branch is related to another branch at some version, you have a lot of duplicate revisions stored on your computer.
 * vila nods
<Wiz_KeeD> what were you trying to say about working-trees?
<vila> Wiz_KeeD: pedantically: branches don't store revisions, repositories do. But a branch is always associated with a repository. So you can safely forget the repository and think of a branch as revision pointer and a repository where this revision and its ancestry is stored
<Wiz_KeeD> ahhh that makes much more sense
<vila> Wiz_KeeD: the working tree is where you work (doh ;), a working tree is associated to a branch
<Wiz_KeeD> even with a shared repository, the actual repo is copied as well
<vila> Wiz_KeeD: yup
<Wiz_KeeD> because if it waren't it wouldn't be a dvcs
<Wiz_KeeD> If you had to use the repository from the server it would be a centralized version control system?
<Wiz_KeeD> always needing the server to see changes, commit, revert
<vila> Wiz_KeeD: that is, when you pull a branch (or merge or whatever), the revisions involved are copied from the remote branch's repository to the local one
<vila> Wiz_KeeD: yup
<Wiz_KeeD> slowly comming together
<vila> so the working tree (WT) also keeps track of the changes versus the branch it is associated with
<Wiz_KeeD> confusing
<vila> bzr diff and bzr status will tell you what are these changes
<Wiz_KeeD> another question about shared repositories, when there is a simple repository on the server, 3 people do a pull (branch initially) all make modifications
<vila> bzr commit will record these changes in a revision and makes the wt in sync with its branch
<Wiz_KeeD> and then push to the server
<vila> Wiz_KeeD: the first to push succeeds
<Wiz_KeeD> okay
<Wiz_KeeD> then
<vila> Wiz_KeeD: the others are told that their branch has diverged
<vila> Wiz_KeeD: they cannot push
<Wiz_KeeD> and they need to merge?
<vila> Wiz_KeeD: they have two choices
<Wiz_KeeD> yes...
<vila> Wiz_KeeD: 1) they merge, commit and then they can push
<vila> Wiz_KeeD: 2) they 'bzr push --overwrite'
<Wiz_KeeD> and kill the poor guy's work :))
<Wiz_KeeD> bastards
<vila> not kill
<vila> move it aside
<Wiz_KeeD> overwrite it
<vila> yeah
<vila> but the pushed revision is still in the remote repo
<Wiz_KeeD> ahhhhhhhhhhh
<vila> but the remote branch does not refer to it anymore
<Wiz_KeeD> sweet sweeeet
<Wiz_KeeD> now, the difference of this case if it's a regular repository or a shared repository
<vila> so push --overwrite is disruptive as far as the sharing is concerned
<vila> no
<vila> the branches matters here, the repo is still just a place to put revisions
<vila> *matter
<Wiz_KeeD> http://wiki.bazaar.canonical.com/SharedRepositoryTutorial
<Wiz_KeeD> Wouldn't it be great if they could all share the revisions they have in common? This is where shared repositories come into play.
<vila> yes, that's what shared repos are about
<Wiz_KeeD> share in what way?
<vila> ha, good point
<vila> they are shared because all branches will add the revisions they need into it
<vila> and will also find the revisions they need into it
<Wiz_KeeD> hmm
<vila> so if you have several local branches that at one point were the same remote branch, when creating or updating one of these local branches, you will download only the missing revisions from the remote branch (and its associated repo)
<Wiz_KeeD> so it's not a separate entity
<Wiz_KeeD> that makes sense
<vila> instead of downloading all the revisions that are part of the whole branch history
<Wiz_KeeD> if you create a branch from scratch it will download all the revision anyway
<Wiz_KeeD> now returning to my setup
<Wiz_KeeD> there is no reason to make a shared repository you said
<Wiz_KeeD> vila?
<vila> Wiz_KeeD: it's up to you, if you understand how it works and what are the fallouts, create one. If you doubts, use standalone branches and revisit that decision later.
<vila> *if you *have* doubts
<vila> Wiz_KeeD: if your history is small enough it won't really change your life
<Wiz_KeeD> it's just me working on it, not 800 people around the world
<Wiz_KeeD> I do tend to commit more frequently in order to prevent loss of data
<vila> Wiz_KeeD: good practice !
<vila> Wiz_KeeD: especially if you also push often
<vila> Wiz_KeeD: because then you get a remote backup for free
<vila> Wiz_KeeD: and at the same time, a local backup of your remote
<vila> Wiz_KeeD: and if you want yet another backup, well, push your branch on yet another server ;)
<Wiz_KeeD> I think i would do that vila
<Wiz_KeeD> and it's nice that you do a backup of every revision until then, not just the lame backup of the last version
<Wiz_KeeD> So i create a branch on localhost, push it to the server and maybe a 3rd one
<Wiz_KeeD> over bzr+ssh
<hikiko> hello, I got the error can't delete ... because it is not empty in bzr... the documentation says that bzr can't resolve it and depends on the case etc ... anyone who could help me to fix it please? :)
<Wiz_KeeD> what does push AND update do?
<vila> Wiz_KeeD: ha, back to wts
<Wiz_KeeD> sure
<vila> hikiko: hi, can you wait a bit while I reply to Wiz_KeeD ?
<Wiz_KeeD> hikiko's sounds more urgent, i can wait
<Wiz_KeeD> i'm getting a free lecture anyway :)))
<hikiko> sure vila
<vila> Wiz_KeeD: so, if you have a remote branch, you don't always need the associated wt to be in sync
<Wiz_KeeD> okay...
<vila> Wiz_KeeD: for example, if you push to that 3rd place, what you care about there is to be able to create a branch and a wt locally, you don't care about having a wt in that 3rd place
<Wiz_KeeD> that is correct yes
<vila> Wiz_KeeD: but on your production server you *need* a wt
<vila> Wiz_KeeD: now, push will only update your remote branch  but *not* the remote wt
<Wiz_KeeD> this is just for pure backup locations, the non-working tree
<vila> Wiz_KeeD: to update the remote wt you can:
<vila> 1) connect to the server, do 'bzr update' after you've pushed. By pushing new revisions, you've changed the remote branch, now you want the wt to be in sync again with that branch
<vila> 2) use push_and_update that will do the above for you ;)
<vila> hikiko: have you read 'bzr help  conflict-types' ?
<Wiz_KeeD> So basically vila, when you push to a branch, it updates the branch information but the working tree (the actual state of the code in regards to the information stored in the branch)
<Wiz_KeeD> is not updated
<Wiz_KeeD> hence you must do update in order to bring the files to the state of the latest changes
<vila> Wiz_KeeD: exactly
<Wiz_KeeD> what if you do, pull...modify something and then update
<Wiz_KeeD> you lose your modifications?
<vila> Wiz_KeeD: hard question
<vila> Wiz_KeeD: you should never lose your modifications
<Wiz_KeeD> and what does the checkout command do
<Wiz_KeeD> wait
<Wiz_KeeD> just read it now
<vila> Wiz_KeeD: but you may end up in situations when you don't know anymore what your modifications are because they are mixed with other modifications you asked for
<vila> Wiz_KeeD: bzr tries to protect you from that but obey your orders in the ned
<vila> end
<Wiz_KeeD> haha indeed
<Wiz_KeeD> Finally it's starting to make some sense
<vila> Wiz_KeeD: if you want to be on the safe side, bzr diff and bzr status will tell you about your pending changes
<Wiz_KeeD> So having a branch with no working tree is useful only for pushing and pulling without doing actual development there
<vila> Wiz_KeeD: if you check those changes before issuing a bzr command that may change them, you should be sage
<Wiz_KeeD> No working tree, no actual files are generated, just the bzr data
<vila> Wiz_KeeD: exactly
<Wiz_KeeD> Why the hell don't they make a legend of some sort?
<vila> legend ?
<Wiz_KeeD> A repository is the place where all changes are tracked in regards to branches, branches are a copy of the code as a set of instructions and revisions and a working tree is a physical representation of the branch information that generates the actual content from the branch
<Wiz_KeeD> or something like that
<Wiz_KeeD> So you know what is what...
<Wiz_KeeD> So i could make a branch on a 3rd server without a working tree pull from it on my localhost and production server with working tree
<Wiz_KeeD> and in order to do that i pull and checkout
<Wiz_KeeD> if you do a pull it does update the working tree no?
<vila> Wiz_KeeD: yeah, if there is a wt... can be confusing but is generally what you expect
<Wiz_KeeD> hmm
<vila> Wiz_KeeD: I think you're on the right track, if you understand what are a repo, a branch and a wt, you should better understand which command affect each part in which way. From there, using the right commands to match your workflow and the layout of your branches across your various PCs should become clearer
<Wiz_KeeD> slowly but surely
<Wiz_KeeD> i have a repository initiated on the production server
<Wiz_KeeD> how can i remove that
<Wiz_KeeD> just the repository, keep the files
<vila> Wiz_KeeD: now to understand what you mean here, I need you to properly use repo and branches when they are involved ;)
<vila> Wiz_KeeD: more to the point:
<Wiz_KeeD> i have created a shared repository sorry
<Wiz_KeeD> i did bzr init-repo dir
<Wiz_KeeD> then bzr init dir
<vila> Wiz_KeeD: if you have a shared repo setup on the remote server and have created branches that use that shared repo you should NOT remove the repo or your branches will be broken
<vila> Wiz_KeeD: then you're good, keep going
<Wiz_KeeD> well isn't creating a shared repository something we agreed was not neccesairy?
<Wiz_KeeD> I did it because it says so here http://doc.bazaar.canonical.com/latest/en/mini-tutorial/
<vila> Wiz_KeeD: if you want your mind, use 'bzr info' on branches and repository to see how they are configured (you can also use 'bzr config' for that as long as you issue the command in the related directry)
<vila> Wiz_KeeD: it is not necessary but once you do it, references are kept in the branches
<vila> Wiz_KeeD: see 'bzr reconfigure --help' if you want to tell bzr what you want to change
<vila> Wiz_KeeD: in other words: 'bzr init-repo project ; cd project ; bzr init trunk' will create 'trunk' as a branch using 'project' as its repository
<vila> Wiz_KeeD: whereas 'bzr inti-repo dir; bzr init dir' will create a shared repo BUT the 'dir' branch will use that repo as ?
<vila> Wiz_KeeD: a shared repo or as branch's private repo ?
<vila> Wiz_KeeD: note that the tutorial says: 'bzr init-repo sample' and 'bzr init sample/trunk'
<vila> Wiz_KeeD: I don't remember precisely when they were fixed but at some point there were bugs in bzr if you used a shared repo as a branch's private repo, so double-check with 'bzr info'
<vila> Wiz_KeeD: and re-read 'bzr init-repo --help' to make sure you understand the different layouts
<vila> Wiz_KeeD: (I'm not saying you don't, just that I don't know if you do ;)
<vila> Wiz_KeeD: and many people (including me ;) had to learn it the hard way ;)
<vila> Wiz_KeeD: oh, and because it also helps me countless times, when in doubt, also use 'bzr missing' to understand how branches differ
<vila> Wiz_KeeD: and use 'bzr qlog' to understand what your branch's history is (qlog is provided by the qbzr plugin)
<vila> hikiko: 'bzr qlog' can also helps you understand why you end up with conflicts which is generally a good way to understand how to solve them
<hikiko> vila, sorry I was on a meeting, yes I just found a way to do it, not the best one it was just a hack
<hikiko> but seems to worj
<vila> hikiko: careful with hacks while resolving conflicts, they sometimes come back to hunt you :) But if you're out of trouble, good !
<hikiko> i merged with a previous version, deleted using rm the directory that was causing the conflict then diff and patch and commit
<hikiko> and it seemed to work
<vila> hikiko: you didn't issue any 'bzr resolve' command ?
<vila> hikiko: anyway, if 'bzr commit' was happy and you didn't commit any file ending with '.THIS' or '.OTHER' or '.BASE' or '.moved' (you get the idea ;), you should be safe
<vila> hikiko: 'bzr st -c-1' should tell you
<hikiko> :D
<hikiko> yes everything is fine vila
<hikiko> thank you!!
<vila> hikiko: great, have a nice day ;)
<hikiko> you too
<Wiz_KeeD> sorry i was away a second
<Wiz_KeeD> hmm
<Wiz_KeeD> i should remove the repository all together
<Wiz_KeeD> vila, in case there is a branch on the server, i pull it, the server dies somehow and then i recreate it on the server
<Wiz_KeeD> the initial branch from where it was pulled will be missing right?
<Wiz_KeeD> still there vila?
<vila> Wiz_KeeD: yes, it will be missing, your local branch will still refer to it in its branch.conf file (in the .bzr/branch directory)
<Wiz_KeeD> dunno how good that is
<Wiz_KeeD> in another tutorial it says if you do bzr branch branch then it makes a independent copy if you do bzr checkout it gets the actual branch that you will merge later on
<vila> Wiz_KeeD: 'bzr info' and 'bzr config' will tell you that, that's the parent_location config option
<Wiz_KeeD> idk for my development case how it would be better
<Wiz_KeeD> i guess a separate branch would be better, don't ask me why :)
<vila> Wiz_KeeD: that's true, at the time you did bzr branch and later bzr pull, your remote and local branches were in sync
<vila> Wiz_KeeD: if you want your local branch to refer to a different parent you should do: 'bzr config parent_location=<new_url>`
<vila> Wiz_KeeD: or 'bzr pull --remember <new_url>'
<Wiz_KeeD> hmm interesting
<Wiz_KeeD> What would you do in this scenario vila? You have the modules that run into the framework on the production server, and you develop on your local server
<Wiz_KeeD> You can test on local and push just when you want and you are sure it's okay
<Wiz_KeeD> Create a branch on server, bzr branch on local then push and update?
<vila> yup
<vila> creating and keeping in sync as many branches you need to hold the framework and the modules
<Wiz_KeeD> well 2 in this case i guess
<vila> Wiz_KeeD: you know better than me ;) If all modules are in the same branch and the framework in another, then yes, 2 should do
<Wiz_KeeD> let me try that setup
<Wiz_KeeD> does it make a difference where the "parent" branch is, so to speak?
<Wiz_KeeD> now i have the shared repository and the branch in the same place
<Wiz_KeeD> the best way to have just the branch and remove the shared repository out of the equation?
<Wiz_KeeD> vila?
<vila> Wiz_KeeD: bzr reconfigure
<Wiz_KeeD> --standalone
<vila> yup
<Wiz_KeeD> bzr: ERROR: '/opt/openerp/extra/' is already standalone.
<Wiz_KeeD> yet bzr info says   repository branch: .
<vila> good then
<Wiz_KeeD> how is it good, it says it's a shared repository still, no?
<Wiz_KeeD> or not
<Wiz_KeeD> ?
<vila> does it says 'shared repository:  some_path' ?
<vila> *say
<Wiz_KeeD> hmm
<Wiz_KeeD> i guess not
<Wiz_KeeD> though i did init-repo on it
<Wiz_KeeD> should be ok then and i can push modifications
<Wiz_KeeD> but you say it will not be updated unless i do update as well
<Wiz_KeeD> or push-update
<vila> yes, try it, start with an up-to-date remote tree (bzr diff and bzr status outputs should be empty)
<vila> push from local
<vila> check bzr diff and bzr status again
<vila> do bzr update
<Wiz_KeeD> i have to install the plugin?
<vila> check bzr diff and bzr status again
<vila> Wiz_KeeD: not yet
<Wiz_KeeD> well i did bzr branch over bzr+ssh
<Wiz_KeeD> made some changes, commited (or i should now)
<vila> Wiz_KeeD: now, install the plugin, push from local, check bzr diff and bzr status once more
<Wiz_KeeD> i have to check a tutorial on how to install it
<vila> bzr branch lp:bzr-<plugin_name> ~/.bazaar/plugins/<plugIn_name> if you want to install from source
<vila> Wiz_KeeD: don't forget to remove the leading 'bzr-' which is illegal as  a python module name
<vila> Wiz_KeeD: use 'bzr plugins -v' before and after the install to check
<Wiz_KeeD> ah the plugin is on bazaar?
<Wiz_KeeD> on launchpad sorr
<Wiz_KeeD> what other options are there?
<Wiz_KeeD> ugh bzr: ERROR: Parent of "/home/wiz/.bazaar/plugins/push_and_update" does not exist.
<Wiz_KeeD> bzr branch lp:bzr-push-and-update ~/.bazaar/plugins/push_and_update does not work
<Wiz_KeeD> hm, i had to create the directory myself
<Wiz_KeeD> strange
<Wiz_KeeD> vila, now i have to do bzr push-and-update :parent
<Wiz_KeeD> right?
<Wiz_KeeD> also setup a ssh key so i don't enter the password 20 times
<vila> Wiz_KeeD: yup, yeah, the .bazaar/plugins should be created manually. I think there is a bug about creating automatically but I don't remember the details
<vila> Wiz_KeeD: yup, setting an ssh key is the way to go
<Wiz_KeeD> i created the plugins dir myself
 * vila nods
<Wiz_KeeD> YAY it worked so quick
<Wiz_KeeD> ssh-copy-id user@example.com
<Wiz_KeeD> :o
<Wiz_KeeD> and that's it!
<Wiz_KeeD> i use the same one for launchpad, should be good
<Wiz_KeeD> i see it makes 3 ssh connections when i do bzr push-and-update
<vila> Wiz_KeeD: $HOME/.bzr.log may contain more details
<vila> Wiz_KeeD: lunch time here, bbl
<Wiz_KeeD> enjoy your lunch vila!
<Wiz_KeeD> vila, still there?
<jelmer> hi Wiz_KeeD
<Wiz_KeeD> hello jelmer, how are you?
<jelmer> well, yourself?
<Wiz_KeeD> working on the project now that i've solved most of my bzr problems
<Wiz_KeeD> thanks to vila
<Wiz_KeeD> i was wondering, if you do a push and update on a branch and the tree of that branch has uncommited modifications...what happens?
<jelmer> it merges the changes and reports conflicts if there were any
<Wiz_KeeD> ugh...
<Wiz_KeeD> and i can just push-and-update --overwrite yes?
#bzr 2013-05-17
<archangle25> im most likely overlooking something very obvious. how can i check out or branch a previous milestone release from my local up to date branch
<spiv> archangle25: bzr branch -r THAT_RELEASE new-branch-dir
<archangle25> spiv,  ah thanks - i got it, bzr branch -rtag:mysql-5.6.10 mysql-5.6 local-release-5610
<Wiz_KeeD> Good morning vila, jelmer
<Wiz_KeeD> how is everyone?
<quicksilver> is there a shortcut for 'merge in another branch as mainline and present my local commits as a merge' ?
<quicksilver> it would be something like : ( bzr branch . ../copy-of-me; bzr pull --overwrite ../mainline; bzr merge ../copy-of-me)
<quicksilver> the same thing that bzr update does in a bound branch in fact (?)
<LarstiQ> quicksilver: cd otherbranch; bzr merge ../old-trunk would work
<LarstiQ> there is also merge-into or something
 * LarstiQ checks
<fullermd> No, that's a subdir merge thing.
<fullermd> What you want is a merge --pivot or --reverse or something, but it doesn't exist.  So, no, no shortcut.
<fullermd> Alternately, the shortcut is to always have a pristine trunk around to do the landings into.
<quicksilver> fullermd: well this isn't the pristine trunk case
<quicksilver> it's the two developers both working on a branch
<quicksilver> ok well it depends what you mean by trunk :)
<quicksilver> it would have been fine if both developers had had bound branches which is what I usually recommend anyway.
<quicksilver> yikes. An innocent (and rather small) commit has just provoked a very time consuming repacking of everythin
<quicksilver> over a minute repacking texts
<Wiz_KeeD> vila, are you there?
<vila> Wiz_KeeD: partly
<Wiz_KeeD> vila, i just wanted to thank you very much for your time yesterday.I'm by FAAAAR a pro or a regular with bzr but i'm using it almost to it's full eextent
<Wiz_KeeD> ignore, commits, reverts, push-and-update, status, diffs, partial commits
<vila> Wiz_KeeD: hehe, thanks ;)
<Wiz_KeeD> It's so much easier and safer, i feel great using it now, thanks a lot man!
<vila> you're welcome, thanks to you for the feedback
 * Wiz_KeeD huggles
#bzr 2013-05-19
<Amis> Hello!
<Amis> What is the best way to deal with forgotten bug-fix props on a commit? (beside the obvious "don't forget to add them")
<vila> Amis: there are several other options (beside the ovious ;): 1) bzr uncommit ; bzr commit --fixes... ; 2) bzr commit --unchanged --fixes...
<vila> Amis: a more complex one would be to branch from the commit where you forgot --fixes; use --fixes --unchanged there, merge the result where it makes sense
<Amis> I see, thanks
<mekeor> what does this line mean while 'cloning' a repo with bzr?: "136334kB    52kB/s \ Revisionen herunterladen:Inserting stream:Estimate 676760/1277014" (yes, it's german.)
<mekeor> i mean, what does the first, the second, third and forth/last number mean? O.o
<mekeor> well, in particular, the first number.
<jelmer> the first number is the total amount of data transferred
<mekeor> okay. the second one is the speed? and the last two?
<mekeor> do they show me how far the download proceed?
<jelmer> the last two are some indicator of the progress
<jelmer> the number of records retrieved so far and the *current* estimate of the total number of records to fetch, I believe
<jelmer> the second one often changes during the fetch
<mekeor> yep :) i see :) thanks :)
#bzr 2014-05-14
<bubbly193> Where does bzr download to on windows by default?
<LeoNerd> Download to...?
<Peng> the current directory?
<bubbly193> Ok, new to bzr, been using git for so long
<Peng> same as git, then?
<bubbly193> Yeah, just didn't know what to expect from windows, wouldn't be the first time a unix/linux command acted wierd
#bzr 2014-05-15
<bubbly193> Ello, I've been having problems with bazaar on windows 8.1 64 bit.  All it is saying is that it has hit an internal bug.
<bubbly193> Are there any known comparability issues with win8.1 64bit?
#bzr 2015-05-11
<trickvi_> hello, is it possible to fix emails on old commits?
#bzr 2016-05-21
<psusi> I checked out the ubuntu bzr branch of installation-guide and modified it and pushed it, but there is no option to propose a merge.  Any idea why? https://code.launchpad.net/~psusi/ubuntu/yakkety/installation-guide/partition-limits
#bzr 2017-05-21
<mgz> this one?
